The MSBuild property DefineConstants is passed into Candle parsed as a ';'-delimited list of Name[=Value] pairs. It is defined in a wizard-built wixproj file with the content "Debug" when the configuration is "Debug".
In your .wixproj files you could add a new PropertyGroup under all of the conditional PropertyGroups (possibly before the first ItemGroup?) and place <DefineConstants>$(DefineConstants);BuildVersion=$(BuildVersion);"Produ ctDescription=$(ProductDescription)"</DefineConstants> in that PropertyGroup and pass /p:BuildVersion=1.0.0.1 "/p:ProductDescription=My Product's Description" to MSBuild and have those show up as $(var.BuildVersion) & $(var.ProductDescription), respectively. How you get $(BuildVersion) into your assemblies is a different matter. The "Using MSBuild and Team Foundation Build" book by Hashimi and Bartholomew suggests using the "AssemblyInfoTask" task that is purported to be found at http://code.msdn.microsoft.com/AssemblyInfoTaskvers (I have not looked it up or downloaded it myself). They make it look kinda easy. That task can generate version numbers AND update code files (I assume it looks for the version attributes) with those numbers (watch out for source control since the file has to be modified, you may want to copy the file and build the assembly with the copy and not the original). -Blair -----Original Message----- From: Asker Brodersen [mailto:asker.broder...@esri-sgroup.se] Sent: Sunday, November 29, 2009 10:49 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Cannot register assembly I use a hierarchy of *proj files from the root of my build tree. I use a 'Deploy' target for the installer that depends on my 'CoreBuild' target. What I have done so far is very close to your suggestion. I have created a separate Assemblies.wxi with the output from Heat.exe, and substituted the version info with $(var.Version). In a separate Common.wxi I define the version and also put things like Name for <Product> and Description for <Package>. I thought I'd be clever and put all version related info in one place and update that. Since these attributes (in our case) contain strings that also include version info, I've found them hard to update via sed. But, as they probably will need to be looked over for each release anyway, it's an acceptable manual step for nor, or until I come up with something better. I would much prefer to pass things like version, product description etc to msbuild so I would have just one place for the entire build to specify this. Thanks for your input, Asker -----Original Message----- From: Blair [mailto:os...@live.com] Sent: den 28 november 2009 04:32 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Cannot register assembly >From your description I'm assuming you are building the .wixproj file using msbuild. What is not clear is how directly (do you use msbuild to "build" your .sln file which happens to include your .wixproj or do you use a hierarchy of *proj files from the root of your build tree?) you call wix in your build invocation. Don't worry about answering that unless you are trying to get rid of sed entirely from your build. Either way (since you are already using sed), the easiest for you may just be this: Create/prepare a .wxi file in a similar way to your already created common AssemblyVersion.cs file. Let's call it Version.wxi. Version.wxi (replace 1.0.0.0 with whatever you have in your AssemblyVersion.cs file you target using sed): <?xml version='1.0' encoding='ascii'?> <Include> <?define version="1.0.0.0"?> </Include> Then add updating this file to your .cmd batch that already updates AssemblyVersion.cs (you can possibly use the same sed expression, changing only the filename). In your .wxs files, add the text <?include path\to\sed-output\Version.wxi?> either right above or right below your <Wix> element, then you can use $(var.version) everywhere you need the current version CruiseControl (via sed) set your assemblies to. If you create different version values (assembly version/file version/product version) and you want to reference those separately in your wix authoring and you already have different targets you update, you can easily extend the above for that. There are several ways that msbuild itself can also be extended which would eliminate using sed as you have already done, which is why I asked how you were already supplying the version info in your build. Version/build numbering is something we all have to do, but msbuild doesn't prescribe a canonical way of performing that task, which has lead to a huge number of varying implementations. For that reason I asked how you were doing it. If msbuild itself had been extended (not your case), then I would have suggested creating/appending the msbuild property DefineConstants in your .wixproj file with the version information in your build using a format like "$(DefineConstants);version=$(BuildVersion)" based on how the version information is represented in your build's process flow. -----Original Message----- From: Asker Brodersen [mailto:asker.broder...@esri-sgroup.se] Sent: Thursday, November 26, 2009 11:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Cannot register assembly This is how things are setup: All assemblies reference the same AssemblyVersion.cs. CruiseControl runs a .cmd batch file that executes sed and updates the version infos in the file using the build number from CruiseControl. CruiceControl then starts an MSBuild task that compiles and packages the build. Perhaps this could be simplified further. Just need to figure out how to get the version info passed down to candle, or perhaps it's enough to supply it to msbuild. /Asker -----Original Message----- From: Blair [mailto:os...@live.com] Sent: den 27 november 2009 08:19 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Cannot register assembly If the version info that shows up in the output from heat is something you provide as an input to your build, you could replace it in heat with "$(var." or"$(env." entries where you supply those inputs to candle or the build environment, as appropriate. That would "automate" that part of the process without resorting to sed. How do you currently set your assemblies' versions today? -----Original Message----- From: Asker Brodersen [mailto:asker.broder...@esri-sgroup.se] Sent: Thursday, November 26, 2009 10:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Cannot register assembly I need COM/Interop registration. Yesterday I harvested my assemblies with HEAT, cleaned up the output and use that as a separate .wxs. It works, but still requires that I update the version info for the assemblies manually in the file before a release. Well, I guess I could use sed to replace the strings to automate it all... I just don't see why this should be necessary, or maybe it's not? /Asker -----Original Message----- From: Blair [mailto:os...@live.com] Sent: den 27 november 2009 02:33 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Cannot register assembly What kind of registration do you need? COM/interop registration? Or just the ability of the two assemblies to find each other when installed into the same directory? -----Original Message----- From: Asker Brodersen [mailto:asker.broder...@esri-sgroup.se] Sent: Thursday, November 26, 2009 1:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Cannot register assembly Hi, I'm trying to have WIX register my assemblies, but when I do the install they are only copied to the right location, not registered. What's the correct way of doing this, I don't want them in the GAC? This is what I'm doing (two different attempts): <Component Id='ArcMeldisDrift' Guid='5B079754-C848-4E08-B2F6-D41D07D08F90'> <File Source='..\build\Release\ArcMeldisDrift.dll' Assembly='.net' AssemblyApplication='ArcMeldisDrift.dll' AssemblyManifest='ArcMeldisDrift.dll' KeyPath='yes'/> </Component> <Component Id='ArcMeldisFiler' Guid='EE384F8D-F35F-42c2-A112-2D246F768670'> <File Id='ArcMeldisFiler' Name='ArcMeldisFiler.dll' Source='..\build\Release\ArcMeldisFiler.dll' Assembly='.net' AssemblyApplication='ArcMeldisFiler' AssemblyManifest='ArcMeldisFiler' DiskId='1' KeyPath='yes'/> </Component> Looking around the net I've seen several older postings from people using Heat to extract info from the dll:s and manually populating the registry. Surely this shouldn't be necessary?, and that would break automation as it would need to be re-done for every assembly version update. Regards, Asker ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
