I was reading a blog about using TFS to update the ProductVersion property in a WiX Source file before building an MSI package. I found the solution rather `interesting`: calling exec and going out of process to a PowerShell script to do a search and replace on the .wxs source during the AfterGet target.
I guess I shouldn't be too critical because God knows I've seen it done stranger ways in the past in InstallShield. I've seen using the automation interface, using the interface using reflection from .NET, using the Windows Installer automation when the package source .ISM is in Binary format, using MSDOM/XPath when the package source .ISM is in XML Format and calling VBS Postbuild steps to hit the build MSI. There are probably more strange ways out there but starting with InstallShield 2008 there really is a better way to do it.
IS2008 IsCmdBld and IsSaBld support a -y argument for passing ProductVersion into the build. For MSBuild support using the standard InstallShield targets file, you merely define $(InstallShieldProductVersion) and it's taken care of for you.
Yes, it really IS that easy.
BTW, if you really like how easy this is, you can thank me with a beer for requesting this particular feature.
Unfortunately as this other blog shows, WiX isn't as easy. You could always ask the WiX team to consider the feature request. Then again, you could always just use InstallShield instead since they actually listen to their customers.
8 comments:
InstallShield listen to their customers?
Are you sure?
What's your technique to get them to listen to you? Megaphone? Kidnap? Bomb threats?
I've tried them all and they have never listened to me
In WiX, since in the other blog's example the product version is already in a variable, why not just pass the variable in to light as a -d argument? I do something like this with msbuild:
<CreateProperty Value="ProductVersion=$(AssemblyFileVersion);$(DefineConstants)">
<Output TaskParameter="Value" PropertyName="DefineConstants" />
</CreateProperty>
John
Chris, you weren't very clear in stating that is BRAND NEW functionality to InstallShield. Before you either had to the IS Automation object or edit the project XML during the build process.
...and it's that easy in WiX as well. We use a preprocessor variable and accomplish the exact same thing.
Why all the nitpicking on WiX? It's not like InstallShield has had over 15 years to mature their product or anything.
Actually I said "...but starting with InstallShield 2008...". I'm sorry if this wasn't clear enough.
Actually I'd say that InstallShield is probably around 8 years old and that it works against it, not for it. It's probably alot easier to work on WiX in .NET. The only problem I see with WiX is project managment ( not meant to infer project manager ) / requirements / resource allocation.
I believe they were founded in 1987. I was referring to their product line as a whole, not specifically the Windows Installer product.
WiX is not without its flaw, but it's unfair to compare it to InstallShield that has many, many times more man hours and resources allocated to it than WiX.
Thanks for the comment on my blog.
I agree, there must be an easier way to do it, but many shops (esspecially those with blanket MSDN licences) feel compelled to go all the way with Microsoft.
So.. without purchasing Installshield, is there still an easier way to do this? :)
Getting the install team at MVSN to listen is easy: be thorough, professional, consistent and offer examples. Chris does a great job of all four, and he knows his craft inside-out.
I'm in a very pro-Microsoft shop. We use a lot of Microsoft technologies in our solution. Everyone has a seat for VS TFS and an MSDN subscription. But, that doesn't mean you can't incorporate technology from other vendors. We use Sybase PowerBuilder, Oracle, DB2, Infragistics and of course InstallShield.
The truth is while we do use Windows Installer for the runtime, Microsoft MSI authoring tools are inferior. Orca isn't designed to be used as an authoring tool. VDPROJ truely is limited and while WiX has some really great features, it really a bear to work with. WiXAware fills in these gaps but it's not really ready for prime time either.
On the other hand, InstallShield integrates very nicely with Visual Studio so I have no problems with using it.
Post a Comment