Setup and Deployment

Beware the unseen checkout in Visual Studio Setup Projects

Matt Simner Setup and Deployment, Visual Studio ,

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.

 

 

Visual Studio Steup Project Bug

Matt Simner Setup and Deployment ,

I found a cracker of a bug (undocumented feature) this morning that was keeping me ‘amused’ for a couple of hours.  I was trying to use Visual Studio 2003 Installer to create a Setup package to actually deploy setup packages (yes, you read correctly!) to a number of ‘deployment’ servers.  These are localised servers where users pick up new versions of software (we’re not quite at one-click deployment yet 🙂 ).


I was using a checkbox dialog to give options on which servers to deploy to, and was then using the properties set in the dialog to control whether the specific ‘custom folders’ (public shares on the different servers) were deployed.  This doesn’t work!

You actually have to ensure that you don’t specify a condition at the folder level, and then select all files and add the condition there (for all files). 

I think the documentation fairy neglected to mention that one!