As I was working with some of my demo code for the Azure posts I have been putting up lately, I came across a very odd thing. I had a solution with several projects that built and worked perfectly fine. I did however need to make some changes to the solution before zipping it up and putting it on my blog. So I made a copy of the solution folder, removed my source control bindings and everything else that shouldn’t be in the zip.
Before zipping it up, I thought I would just make sure it built ok after my changes, which it obviously should as I made no code changes. So I loaded the solution into Visual Studio and everything looked fine. But pressing Ctrl+Shift+B made Visual Studio cough and tell me that XXX was not available in namespace YYY, which is really odd as I had made no code changes.
More...
One “feature” in VS2010 (and 2008 I assume) that bugs the hell out of me, is the way that referenced assemblies are packaged in Silverlight projects… And please let me know if you know of any fix for this!
Imagine that you have a solution with at least 2 projects. One Silverlight application project, and one class library project. The app project references the class library project as it contains functionality it needs. The class library project in turn references another assembly (or maybe more than one) that is needed for it to be able to run. This (or these) other assemblies are not default Silverlight assemblies, so they will not be on the target machine and needs to be included in the deployment… Unfortunately, this is where VS screws up…
More...
Lately I have been working a bit on a couple of Windows Phone 7 apps, and I found a couple of interesting things along the way. I am going to try to blog more frequently soon, and try to cover as much of the interesting stuff as I can find. But it will have to wait until after TechEd New Zealand. But if you happen to be going to TechEd Australia or New Zealand, don’t forget to come to one of my talks and say hi.
Anyhow, the funky problem I am going to write about today is around a feature called InputScopes. On the phone, you can configure your TextBoxes to use different InputScopes. The InputScope defines which of the different software keyboards to use when writing in the TextBox. This is a really cool feature as it helps the user to write the type of info he/she is supposed to provide. It can be things like numbers or currency or chat. Each InputScope results in a different keyboard. Or at least some of them do. There seems to be more InputScopes than cool keyboards at the moment though…
More...