Click here to Skip to main content
15,312,353 members
Articles / Programming Languages / C#
Posted 3 Jan 2004


58 bookmarked

VS.NET Deployment Project Version Updater

Rate me:
Please Sign up or sign in to vote.
4.88/5 (25 votes)
3 Jan 2004CPOL6 min read
A command line ulitity that updates the version and GUID of VS.NET deployment project files.


Visual Studio .NET deployment projects are a simple and cheap way to generate merge modules and Windows Installer MSI files for deploying an application. Unfortunately, the VS.NET toolset provides no way to increment the version of the installer media, outside of the IDE.

This becomes a problem when VS.NET deployment projects are part of your build process, as version and packaged identifiers need to be automatically updated with each build.

This command line utility does just that.


At my day job, I have spent the last month or so defining and refining the build process for a fairly complex application, built primarily in Visual Studio .NET 2003. Over the years, I've taken on the build and deployment engineering for a number of software projects, with varying degrees of success.

I've seen things that work and things that don't. One of the things that doesn't work (but is unfortunately the most common approach to deployment) is to allow each engineer to completely ignore deployment issues and then, almost as an after thought, saddle some poor sap with creating an installer.

Using this approach, deployment issues get addressed too late and the installer tends to become complex and top heavy. As the project evolves past its first release, it becomes too complex to fix and often collapses under it own weight.

My department is currently moving from InstallScript to Windows Installer, and I saw this is the perfect opportunity to define a development process that addresses deployment issues from the beginning of development and keeps it as a first class citizen throughout the life of the project.

Our application uses an n-tier architecture, with clear separations between GUI, business and data layers. Each tier is broken down into one or more packages, each represented by a Visual Studio Solution. This keeps packages cohesive and reduces coupling between packages and layers.

In order to keep deployment a first class citizen of our process, each package's solution includes a merge module deployment project. It is the responsibility of the engineer who "owns" the package to also maintain this merge module. This ensures that the package is always correctly installed. This also means that all of the package's dependencies (from DLLs, to contents files, to registry settings) are maintained by the engineer who understands them best. If the installer breaks, it is up to each engineer to find and fix the problem, rather than a single engineer who may not fully understand the dependencies of a particular layer or assembly.

When the product is built, each package solution get's builds a merge module containing all of the solution assemblies and their dependencies. As each layer grows in complexity, it becomes a collection of merge modules, with dependencies between packages expressed as merge module references.

The installer for the application, is then simply a MSI that includes the installation UI and all of the merge modules that make up the application, rather than a complex nest of logic that attempts to encompass the entire application.

Versions and Codes

The one sticking point to all of this has been updating the installer version with each build. A Windows Installer MSI includes three GUIDs which identify the application being installed:

  1. Upgrade Code - This identifies the application and should not change through it's lifetime
  2. Package Code - This identifies a particular version of the MSI installer and should never be reused across builds. It must always be updated.
  3. Product Code - This identifier is used to ID a particular version of the application. It is up to the installer author to decide when to assign a new product code. MSDN gives the example that in case where changes to the product are "relatively" minor, a new product code does not need to be assigned.

This tool can be used to update each of these values separately by passing it a GUID for the desired code. By default, it will generate a GUID to use for both the product and package values, and will not modify the upgrade value.

MSI files also include a version number. If you attempt to install two different versions of the same application, without updating the package code, Windows Installer will tell you that a different version of the application is already installed and it must be uninstalled first. (Which makes sense since the package code is meant to identify a particular build.) This becomes a problem when both testers and engineers are installing new builds on a daily basis.

Merge modules only have one identifier: the module signature. Microsoft recommends that no two builds of a merge module share the same signature. This becomes especially important if you are distributing components to other developers using merge modules. The module signature is of the form <SOMESTRING>.<GUID> (the GUID must be upper case and have the dashes removed).

By default, when updating a merge module project, this utility will generate a merge module signature that looks like this: MergeModule.20BF370511B54AAC8A9C8B9A0263D3CF. If you specify your own signature on the command line, make sure it is the correct format.

When you change the version of a deployment project in the Visual Studio .NET IDE, it will prompt you to also update the package and product codes. What it doesn't do is allow any way to do this from the build process. That's why this tool was created.

After some initial fits and starts, this approach has worked surprisingly well. Each engineer maintains their installation dependencies in the same place that they maintain their code. These are incorporated into the application installer by the build process itself, rather than as an after thought.


This utility is a command line app that can be integrated into an automated build procedure in order to update the version number of an installer project, and also update the product and package code GUIDs for each build.

Just before the solution that contains the application installer is built, we run this utility, passing it the build number generated by the build tool we are using.

There are two commands that can be passed to this utility: -msi and -msm. The former is used when updating an MSI installer project and the latter when updating a merge module project.

Each command is passed the path to the vdproj file as the first argument, followed by a set of name value pairs. The command switches and name value pairs are not case sensitive. GUIDs can be passed with or without curly braces.

VersionVDProj -msi <PATH> version=<VERSION> [package=<PACKAGECODE>]
        [product=<PRODUCTCODE>] [upgrade=<UPGRADECODE>]
The -msi switch is used for updating MSI installer projects 
<PATH> is the path to the vdproj file (without braces)
<VERSION> is the version to use in format #.#.# (without braces)
<PACKAGECODE> Optional package guid (if not specified will be auto-generated)
<PRODUCTCODE> Optional product guid (if not specified will be set to the
        same value used to set the package guid)
<UPGRADECODE> Optional upgrade guid (if not specified the upgrade code will
        not be modified)
VersionVDProj -msm <PATH> version=<VERSION> [signature=<SIGNATURE>]
The -msm switch is used for updating merge module projects 
<PATH> is the path to the vdproj file (without braces)
<VERSION> is the version to use in format #.#.# (without braces)
<SIGNATURE> Optional unique id for the merge module (if not specified a guid
        based signature will be auto-generated) 
Named arguments can be specified in any order

This utility has allowed us to define a build process that uses Visual Studio's deployment projects to great effect, with no investment in more complex (and expensive) installer technologies.

Hopefully, it will come in handy for others as well.


  • 01/04/2004 - Initial release
  • 01/05/2004
    • Added ability to specify product code separate from package code
    • Added ability to specify upgrade code
    • Added ability to update merge module projects


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Don Kackman
Team Leader Starkey Laboratories
United States United States
The first computer program I ever wrote was in BASIC on a TRS-80 Model I and it looked something like:
10 PRINT "Don is cool"
20 GOTO 10

It only went downhill from there.

Hey look, I've got a blog

Comments and Discussions

GeneralLatest code is on Codeplex [modified] Pin
Don Kackman3-Jun-11 16:24
MemberDon Kackman3-Jun-11 16:24 
GeneralRe: Latest code is on Codeplex [modified] Pin
kiquenet.com16-Aug-12 20:48
professionalkiquenet.com16-Aug-12 20:48 
GeneralMy vote of 5 Pin
ding3r24-Feb-11 3:32
Memberding3r24-Feb-11 3:32 
GeneralPrerequisities Pin
Nemzi24-Oct-08 8:40
MemberNemzi24-Oct-08 8:40 
GeneralRe: Prerequisities Pin
Don Kackman9-Jun-11 15:14
MemberDon Kackman9-Jun-11 15:14 
Generalproduct should be productcode Pin
chuckfossen26-Sep-08 11:15
Memberchuckfossen26-Sep-08 11:15 
GeneralRe: product should be productcode Pin
Don Kackman4-Jun-11 9:34
MemberDon Kackman4-Jun-11 9:34 
Generalpatch development Pin
jawahar srinivasan25-May-08 21:59
Memberjawahar srinivasan25-May-08 21:59 
AnswerPreserve File Encoding Pin
curtwilliams009-May-08 8:41
Membercurtwilliams009-May-08 8:41 
GeneralRe: Preserve File Encoding Pin
Don Kackman4-Jun-11 9:34
MemberDon Kackman4-Jun-11 9:34 
QuestionAuto Increment Product Version? Pin
dashrendar15-Jan-07 5:49
Memberdashrendar15-Jan-07 5:49 
AnswerRe: Auto Increment Product Version? Pin
LyphTEC13-Oct-08 16:28
MemberLyphTEC13-Oct-08 16:28 
GeneralRe: Auto Increment Product Version? Pin
ksalvage13-Aug-09 4:26
Memberksalvage13-Aug-09 4:26 
GeneralRe: Auto Increment Product Version? Pin
Don Kackman13-Aug-09 5:30
MemberDon Kackman13-Aug-09 5:30 
GeneralRe: Auto Increment Product Version? Pin
Don Kackman5-Jun-11 5:08
MemberDon Kackman5-Jun-11 5:08 
GeneralRe: Auto Increment Product Version? Pin
Don Kackman5-Jun-11 5:04
MemberDon Kackman5-Jun-11 5:04 
QuestionPatch management Pin
Baber Saeed16-May-06 2:29
MemberBaber Saeed16-May-06 2:29 
QuestionCorrect command to change Upgrade code Pin
spy00819-Apr-06 13:42
Memberspy00819-Apr-06 13:42 
AnswerRe: Correct command to change Upgrade code Pin
Jeremy Thomas6-Aug-07 14:51
MemberJeremy Thomas6-Aug-07 14:51 
GeneralRe: Correct command to change Upgrade code Pin
Don Kackman4-Jun-11 9:34
MemberDon Kackman4-Jun-11 9:34 
QuestionWorks with VS2005? Pin
seak20044-Apr-06 15:28
Memberseak20044-Apr-06 15:28 
AnswerRe: Works with VS2005? Pin
Don Kackman4-Apr-06 17:56
MemberDon Kackman4-Apr-06 17:56 
GeneralRe: Works with VS2005? Pin
hairyfellow14-Jun-06 20:25
Memberhairyfellow14-Jun-06 20:25 
QuestionRe: Works with VS2005? Pin
ivs10018-Oct-06 10:56
Memberivs10018-Oct-06 10:56 
QuestionRe: Works with VS2005? Pin
dashrendar15-Jan-07 5:39
Memberdashrendar15-Jan-07 5:39 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.