When you build and run a Windows Mobile (ie .NET Compact Framework) application from with Visual Studio it does a number of things in the background. After building your application it has to deploy it out to the device or emulator that you want to run it on. It then of course has to attach to the remote process so that you can step through your code in the debugger.

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).

There has been some confusion as to whether Wix will ship with Visual Studio 2010.  The latest I’ve seen is that it will not ship as part of the product.  However, the good news is that if you go to the Votive website you can already download a weekly build of the Wix Toolset that will register itself with the beta of VS2010.

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>

New to Visual Studio 2010 is the Extension Manager (accessible via the Tools –> Extension Manager menu item).  This allows you to access the Visual Studio Gallery directly from with Visual Studio, where you can search and download extensions to Visual Studio that will help you work more productively. 

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.

One of the smaller features that has made its way into Visual Studio 2010 is Reference Highlighting. The following screenshot illustrates how all calls to the method MethodToBeCalled, as well as the method itself, have been highlighted. This means that you can easily scan up and down a file to see where this method has been called (quicker than calling Find All References or loading the new Quick Search window)

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).

Dan Fernandez has posted a Cheat Sheet which will help you get started with Beta 1 of Visual Studio 2010 and the .NET Framework 4.  I noticed that one of the links in his list is that of the Visual Studio 2010 and .NET Framework 4 Training Kit – May Preview.  The previous training kit was really useful as it provided a number of worked examples that highlighted new features of the product and framework. Microsoft have committed to update this training kit, saying that they will make it available for each beta/rc and the final rtm product to help developers skill up with the new features.

For those of you who love the bleeding edge, Beta 1 of Visual Studio 2010 and .NET Framework 4.0 has been released to MSDN subscribers (general availability on Wednesday). Here’s a few of the more useful posts:

• 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.

Visual Studio has been around for so long and has gone through so many changes in recent years to accommodate different technologies that quite often it gets bogged down in it’s own wait.  In the VS2005 release a little toolbar notification bubble was added to indicate that Visual Studio was still thinking – useless and almost as annoying as Clippy.  Essentially Visual Studio has become so bloated that it takes up more memory and other resources than most applications developers will build.

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.

One of the challenges with debugging applications with multiple threads in Visual Studio is that when you place a breakpoint you tend to interrupt the flow of the application.  This can often mean that tracking down an issue is very time consuming.  Let’s take a very simple example where we have a thread that performs a task then sleeps for 100 milliseconds.

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.

Over the last couple of weeks Visual Studio has started to infuriate me.  First it was the WPF designer and just now it was adding new items to the toolbox.  Essentially what was happening was that Visual Studio would just disappear; no errors, no dialogs, no crash report. 

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. 

That’s right it’s time to start looking into the future at what’s coming down the line with the next iteration of both Visual Studio 2010 and the .NET Framework 4. Luckily, there is an awesome Channel 9 show called 10-4 that is covering a range of topics.  These are based on the currently available CTP and provides a great starting point for getting familiar with what’s in the next release of these products.

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