Hi, Our builds run a custom TFS build task that checks out a build number file, updates it and checks it back in. This is used as a msbuild property that is passed to our wixprojs which are built from a .sln.
In the 'Define preprocessor variables' setion in votive we have a mapping from msbuild "buildNumber=$(SdlBuildNumber);" In our wix we use e.g. <?define productVersion = "2.0.$(var.buildNumber)" ?> Which is then used in Product@version and in the upgrade elements, where we can't use the MajorUpgrade element. e.g. Version="$(var.productVersion)" We follow the basic versioning scheme for MSIs:- Major.Minor.BuildNumber The msi version is controlled by the deployment team to allow upgrades and patching to work correctly. If marketing want a product to be version 2011 we make the display name into 2011 but just increment the major version by one. So 2011 of one of our products has an msi version of 2.0 The Major version is changed by hand when we do a new full release. These are major upgrades and sometimes side by side installations with the older version. The Minor version is also changed by hand for smaller releases, we call these service packs (2011 SP1 aka 2.1) and deploy as major upgrades. The Build number increments every build and is also applied to the file version of all binaries/assemblies. We don't really use the fourth part of file versions. For compatibility reasons Assembly versions only change when the assembly has been updated. We make cumulative update MSPs that we deploy automatically with True Update. Dave -----Original Message----- From: Dandre [mailto:dandre...@gmail.com] Sent: 20 January 2011 09:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting the version number... Hi Rune I haven't checked your links but what we use is the Tfs build server's ability to download the new source from repo, look for all assemblyinfo.cs files and update the version numbers. Then using a wix include file using the variable holding version 1.0.0.0 we update that file and so all installers referring to that include file will get updated appropriately. So far it is working very well for us. We even have an XML file where we store our sprint number in sothat the build server will create a version number in the following format: 1. (sprint).(days since beginning of sprint).(tfs build revision number) Let me know if this might work for you. I think you can apply this to any CI app. On 20 Jan 2011, at 10:24, Rune Moberg <jjfl...@gmail.com> wrote: > I have googled my eyes out recently, trying to figure out an easy way > of setting my installer's version number to match that of my product. > > I found three alternatives. None of them appeals to me, because they > are either kludgy, involves some kind of plug-in or ...well, kludgy: > > http://morten.lyhr.dk/2007/10/how-to-insert-assembly-version-number.html > (which links to the third option) > http://vsts-fu.blogspot.com/2009/01/injecting-version-numbers-into-wix.html > > My idea is this: When I include a project reference, I get all sorts > of nice variables defined. Target platform - check. TargetDir - check. > Target version... Target version? The one really interesting attribute > of my included project is MIA. > > Is there a possibility this can be included eventually? I suspect this > would prove helpful to quite a few users. > > Or is there already a more elegant solution to this seemingly simple > "problem"? > > Thanks for all the great help so far guys. > > -- > Rune > > --- > --- > --- > --------------------------------------------------------------------- > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how > you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ----------------------------------------------------------------------------- - Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users