Si - I wasn't as clear as I meant to be before. Because our automated packager builds at least 2 MSI's a day per product and has built up to 6 versions in a day when we are close to deadline I really don't want to open and update Wix by hand to change the variables.
Today, I use a VB script to open the last msi, read it's Product Version and then increment it and feed the New and Previous Version numbers into Candle via the command line. I'm wondering if there is a better, or safer, long term approach to these steps than reading the last MSI, such as storing the old values in a DB or log file. What are others doing? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of si Sent: Thursday, March 06, 2008 12:26 AM To: Wheeler, Blaine (DSHS/DCS) Cc: WiX Users Subject: Re: [WiX-users] Preventing upgrades for versions older than the previous release Hi Blaine, cc'd to list. > I really like your code sample, particularly the use of the variables. > Which raises a question about managing sequential-multiple builds. May > I ask how you get the $(var.ProductVersion) and > $(var.PreviousProductVersion) to pass into Wix? They're just WiX variables: <?define ProductVersion = "1.0.0.0" ?> <?define PreviousProductVersion = "0.0.0.0" ?> It will probably always be a manual process for the developer to define the PreviousProductVersion, but I think that's OK because they also have to co-ordinate the change-set between versions, whether that's files, config or db changes. For the ProductVersion we've gone with a hybrid approach which I wrote about recently on another list: http://tech.groups.yahoo.com/group/altdotnet/message/3728 Basically the ProductVersion variable always matches the product assembly version. In the BeforeBuild target (csproj) we modify the AssemblyInfo.cs file using the FileUpdate tasks from msbuildtasks.tigris.org, and this is then piped into the ProductVersion variable so it gets set automatically in the BeforeBuild target (wixproj) using a combination of FileUpdate and RegexReplace tasks. However I've only got this 95% working due to an annoying RegexReplace issue with the MSBuild task (I think due to named capture groups). I'm happy to post the BeforeBuild code for ProductVersion auto-update from AssemblyInfo.cs once it's working 100%. > Today, I read the previous msi to find the values, but am debating > whether or not it would be better to use a database table or file to > store the values and read from it instead. We're trying to keep it as simple as possible, and WiX variables seemed the easiest way. -- It's a wild world that we live in, you step to the vibe like a new found religion, take your position, compile your vision, futurism, algorithm has risen up! pfm - the western ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users
