One of the issues with using a single solution for building both Windows Mobile and desktop (or even web applications) is that when you do a build, by default, the Windows Mobile application will not only build, it will try to deploy to the device or emulator.  This can add a few extra seconds to every build so it’s not something you want happening on every build.

Luckily there is a quick way to disable this functionality: Right-click on the solution node in Solution Explorer and select Configuration Manager.  You will see that there is an additional column entitled Deploy and you’ll see that the mobile application has a check in this column. If you uncheck this your mobile application will not be deployed on each build.

There is one little gotcha here – if you are not careful you will experience a number of side effects:

• Build and run will NOT run the latest version of your mobile application.  It will build it but because you have not told it to deploy your application it will run the last instance of your application to be deployed to the device.
• If this is the first time you are running your application there is no previous version of your application on the device, so you will see a prompt similar to the following:

Unable to start program ‘%CSIDL_PROGRAM_FILES%\MobileApp\MobileApp.exe’.

The system cannot find the file specified.

There are two ways to address this:

1. You can force a deploy by right-clicking your mobile application project in Solution Explorer and selecting the Deploy option. Now when you run your application it will run the version you have just deployed.
2. You can create different build configurations – one for doing destop development and debugging, and one for doing mobile development and debugging.  In the former you can uncheck the build and deploy checkboxes for the mobile application.  In the latter you need to check both the build and deploy checkboxes for the mobile applications (note: you don’t need to deploy mobile class libraries so long as they are referenced by the actual mobile application as they will automatically get deployed along with the application).

Whilst the v3.5 toolset will install and register against Visual studio 2008 as well, you will need to update your wix projects to point to the v3.5 targets:

<WixTargetsPath Condition=" ‘$(WixTargetsPath)’ == ” ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.5\Wix.targets</WixTargetsPath>

The Extension Manager is just one of the many ways that Microsoft is opening up Visual Studio 2010 as a platform, not just a best of breed IDE for developers.

At this stage this feature doesn’t appear to work across files (ie selecting a method in one file and seeing it highlighted in other open files) or across assemblies (ie selecting a method call in the code of one assembly and seeing a highlight appear in another file from a different assembly).

• Jason Zander has a great post explaining a lot of the new functionality.
• Phil Haack gives the low-down on ASP.NET MVC with this beta.
• The documentation has also be released to MSDN.
• On Twitter everyone is discussing this using the #vs10 hashtag.

Unfortunately if you just want to open a single file or a project just to look something up you need to load up the entire Visual Studio IDE.  Here’s a tip from Dr Neil at nsquared solutions: Install the express skus (eg Visual Basic 2008 Express, Visual C# 2008 Express or Visual Web Developer 2008 Express) and use those to open these files.  These skus can be installed alongside the professional version and are much lighter wait.

private void ThreadWork()
        {
            for (int i = 0; i < 100000; i++)
            {
                DoWork();
                System.Threading.Thread.Sleep(100);
            }
        }

Now say that something is going wrong on this thread, the first thing we can do is to place a normal breakpoint:

Here we can see a regular breakpoint that has been hit and notice that you can hover over variables to see what their current values are. But what happens if the error only happens after say 1000 iterations.  We can use a breakpoint hit count to limit when the breakpoint is hit. Right clicking the line with the breakpoint you can set the Hit Count property via the Breakpoint –> Hit Count… menu item.

In this case we want the breakpoint to be hit after 1000 cycles:

Note that setting the Hit Count sets up a rule where by the breakpoint will be hit based on the number of times the line has been executed.  If the loop was instead modified to the following the breakpoint would be hit after 1000 * 100 iterations of the for loop, rather than the 1000 iterations we wanted.

for (int i = 0; i < 100000; i++)
           {
               if (i % 100 == 0)
               {
                   DoWork();
               }
               System.Threading.Thread.Sleep(100);
           }

To get around this we can use a breakpoint Condition.  Again this can be set using the Breakpoint –> Condition menu item from the right-click menu.

In this case every time the breakpoint line is reached the expression i>=1000 will be evaluated and the result used to determine if the breakpoint has been reached.  Note that this expression can be as complex as you would like but it does add an overhead to execution.  If timing is important then you should make this expression as simple as possible.

If you have specified either a Hit Count or a Condition you will see that the marking alongside your code has changed slightly.  Instead of the normal red dot, you should now see a red dot with a white plus sign inside it.

One thing to be aware of is that Hit Count and Conditions are not mutually exclusive which means that you have have both of them set.  As they use the same breakpoint marking it’s not that easy to see if they have both been set.  However if you right-click the breakpoint line you will see that the menu actually indicates which items have been set.

Unfortunately the process of actually stopping the execution of your application at a breakpoint often has the side effect of hiding or obscuring the issue you are trying to track down.  Luckily there is a way that you can write an output to the output window and continue execution.  From the right-click menu select the Breakpoint –> When Hit… item.

This dialog allows you to either specify an output to be written to the output window or to run a macro.  You can also toggle whether execution continues or breaks when the breakpoint is hit.

In this screen shot the output consists of a number of parts.  Essentially the output is just a string literal that will be printed to the output window.  However, $FUNCTION is a predefined value corresponding to the current function name which will be substituted into the output.  The dialog points out that there are a number of other predefined values that can be used.  Quite often you will want to put your own custom values in there – this is where the { <expression> } syntax is used.  In this case we have chosen just to output the value of the variable i, but we could make this expression more complex so long as it can be converted to a string. Again the more complex this expression is the more it will affect your application.

Now when your breakpoint is encountered by your application it will no longer break, it will simply write a string to the output window.  This can help you track down issues on background threads without affecting your application execution significantly.

The WPF designer issue crops up whenever I wanted to edit a xaml file.  I’d tried opening it as XAML only but to no avail.  Opening it as just xml works and allows changes but of course you lose all your intellisense (writing XAML is a pita at the best of time and just a miserable experience if you don’t have intellisense).  I half resolved this issue: Karl has a post here that points to a hotfix that works on all platforms except Windows 7 (that would be me). My resolution involved moving to a different machine that wasn’t running Windows 7 when doing WPF work.

Now when I went to add a new item to the toolbox this morning I ran into what appeared to be the same issue.  This connect issue shows a number of people seeing the same issue.  Most of them have found solace in removing PowerCommands, even if they didn’t have it installed in the first place. However, the workaround is actually to run Visual Studio in safe mode (ie devenv /safemode) as discussed here and here. 

So far, here’s a rough list of episodes:

10-4 Episode 1: Working with the Visual Studio 2010 CTP VPC

10-4 Episode 2: Welcome to Visual Studio 2010

10-4 Episode 3: ASP.NET WebForms 4.0

10-4 Episode 4: No More Parallel Development Pain

10-4 Episode 5: Code Focused in Visual Studio 2010

10-4 Episode 6: Parallel Extensions

10-4 Episode 7: No More Planning Black Box

10-4 Episode 8: Pure Client-Side Development with ASP.NET AJAX 4.0

10-4 Episode 9: Visual Basic 10

10-4 Episode 10: Making Web Deployment Easier

10-4 Episode 11: Bi-Directional Routing with ASP.NET WebForms 4.0

10-4 Episode 12: Simplifying Your Code With C# 4.0

[Updates]

10-4 Episode 13: No More Late Surprises

10-4 Episode 14: Sentient DSLs

10-4 Episode 15: Model-First Development with the Entity Framework 4.0

10-4 Episode 16: Windows Workflow 4