Using Batch Build in Visual Studio

This is a really simple one, but if you want to build a solution in a specific ‘Configuration’ and you have a big solution open, it can sometimes be an awfully long time to switch configurations – e.g. Debug -> Release.  You may find yourself needing to do this when you’re needing to build and rebuild setup projects whilst testing.


You could of course run a command line compile, but a simple way to stay in the IDE and Debug configuration whilst running a Release build is the Batch Build facility. 


Just go to Build –> Batch Build, then select all the Release versions of the projects you want to build (or whatever you want to build), and then click Build.  The settings will be remembered for the next time you go in too…


I said it was simple. 

Beware the unseen checkout in Visual Studio Setup Projects

I was inadvertently responsible for a broken build this morning as I checked out a Setup Project last night in Visual Studio 2003 that ended up checking out a merge module that was included in the Setup.  This merge module is built and subsequently stored in SourceSafe (I know – it shouldn’t be! – this is a temporary measure) by the build script, and the build failed as the .msm output file was checked out to me.

 

Shouldn’t Visual Studio prompt you when you check out?

The project was checked out in Visual Studio and it gave no warning that the .msm was also going to be checked out.

 


In other setup projects you’ll often find that other files will appear in the Check Out dialog (i.e. you’re about to check  out all the ‘files‘ that have been explicitly included into your setup – from their source location).  As a matter of course it’s wise to first untick everything (right at the top), and then select only the .vdproj file to actually check out.

 

Why didn’t it prompt in this case?

The problem in this case appears to be that the offender is a merge module and was added to the setup project as such rather than as an included ‘file’.  It seems that Visual Studio neglects to mention merge modules when you check out as it probably thinks they’re static and not something it should worry you about! (which is probably true – yadayadayada)

 

How to prevent this happening to you

Well, while this file is still in VSS there’s little option but to just be vigilant whenever you check out a setup project that includes it. Either check out in VSS Explorer or if in Visual Studio -go immediately to VSS and undo the offending checkout.  Another option is to add some more resilience into the build and somehow force an undo-checkout (as no one other than the build should be updating the file).  A variation of this is to disallow checkout for all but the user running the build process through SourceSafe Admin (but this is a pain to administer), and the final and best solution is to remove the need to store the merge module in Source Control by sorting out cross-dependencies in different components so that they all pick the file up from the same central location.

 

 

.NET Class Wizard disappearance

It finally happended today.  The thing that’s plagued so many other people who’ve installed and uninstalled multiple Visual Studio addins.  My C# Class, Form (and probably every other) wizard gave up the ghost which meant no new projects or new classes because the wizards had got themselves in a twist. 

It happened at work today so I googled and luckily got sorted out within 5 minutes!  If you’re in the same fix then look here as that very quickly did the trick for me!  I didn’t need to go as far as reinstalling the scripting engine thank goodness.

You might need to alter paths a little as your extensibility.dll may be in a publicassemblies folder (like mine) rather than the IDE fiolder.  dir /s should sort you out anyway

Looks like they still haven’t sorted out the ReSharper installer then!