views:

778

answers:

2

In my current project, I'm producing weekly releases. I've been using the technique described in this post to keep the version numbers of all of the assemblies in my project in sync. (I don't presently have any good reason to track the assemblies' version numbers separately, though I'm sure that day will eventually come.)

When I push out a release, I build a new version of the installer. Unlike all of the assemblies, which can get their version numbers from a shared SolutionInfo.cs file, the version number of the installer isn't, as best I can tell, an assembly property. So my release process includes manually advancing the version number in the setup project.

Or, I should say, usually includes doing that. I'd like to turn that into something I can't screw up. I'm finding the documentation of setup and deployment projects to be surprisingly opaque (it was quite a bit harder to find out how to make it possible for the MSI to uninstall properly if the user installed it to a non-default path, which is a pretty freaking common use case to be undocumented) and have no idea if it's even possible to do this.

Any ideas?

Edit:

Just to clarify, this is a Visual Studio setup and deployment project I'm talking about.

+2  A: 

Its going to depend on the installer toolkit you are using.

We use TFS Team Build and WiX v3. I have a custom build task that increments the build number in Team build (5.0.0.X for example), then this version number is pushed to the common AssemblyInfo.cs AssemblyFileVersion field. It is also passed by MSBuild to our solutions/projects as a property which is then passed into WiX and used to update the installer version as well.

We probably will need to do better with the assembly versioning someday as well, but right now this has been working pretty well for us.

Rob McCready
+5  A: 

CodeProject has a script to set the version number of an MSI file, which you could run in the pre-built step of the setup project. You find it here:

http://www.codeproject.com/KB/install/NewSetupVersion.aspx

More Details

Be aware that with Windows Installer things are a bit more complicated. MSI files (as the one that you create using a VS Setup and Deployment project) not only have a version number but also a product code which is a GUID value. This product code is used by Windows Installer to uniquely identify your product e.g. in Control Panel -> Add Or Remove programs where you can decide to uninstall or repair a product.

However, when changing you MSI version number, this product code must also be changed in a number of cases. MSI technology is poorly documented but you can find some recommendations when to also change the product code on the following MSDN page: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx.

In my projects I always generate a new product code for every new version. The script on CodeProject will also change the product code for you.

And one more thing: Windows Installer only checks the first three places of the version number afaik, anything in the forth place will be ignored, i.e. 2.3.0.1234 is considered equal to 2.3.0.5678.

(There is a related article on CodeProject which might also be interesting to you: http://www.codeproject.com/KB/install/VersionVDProj.aspx)

0xA3
It didn't occur to me that the problem might just boil down to programmatically updating the project file. That'll work (though I sure won't use regular expressions to modify XML). And thanks for the reminder about the product code: VS reminds you to do this, but I would have forgotten.
Robert Rossney