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.
Historical archive 2003-2016
Wednesday, September 26, 2007
Thursday, September 13, 2007
Setup Ethics
I noticed an interesting article linked on Slashdot alleging that Microsoft is now pushing down stealth updates to Windows clients even when users have not given consent by turning off automatic updates. This is of particular concern to corporate environments where change control and testing is very important.
It makes me think again about the power Deployment Engineers have and are sometimes asked to wield. It's almost a given that we will run with elevated privileges. With this great power comes great responsibility. I get really irritated thinking about some Setup Developer going along with management to push down software without consent, install root kits, install Spyware, put crap on the desktop, automatically start programs on login.... all without user consent. There really should be some code of conduct that takes into consideration ethical treatment of the customers machine and we should really push back on management asking us to do unethical things.
I recall back to 1997-1998 when I was asked to add a call to secedit.exe and apply the Compatible Workstation policy to resolve an application compatibility bug. First of all this was the wrong solution to the wrong problem... fix the damn application. What was worse was that the requirement came across to do it without notifying the user. Another time I was asked to change the regional date/time settings.
I was livid and I absolutely refused to implement either of these requirements. But I can't help wonder how many other developers would have gone along with it.
If the story about Microsoft is correct, it seems they have some Deployment Engineers that don't have any issues at all with doing what they are told.
It makes me think again about the power Deployment Engineers have and are sometimes asked to wield. It's almost a given that we will run with elevated privileges. With this great power comes great responsibility. I get really irritated thinking about some Setup Developer going along with management to push down software without consent, install root kits, install Spyware, put crap on the desktop, automatically start programs on login.... all without user consent. There really should be some code of conduct that takes into consideration ethical treatment of the customers machine and we should really push back on management asking us to do unethical things.
I recall back to 1997-1998 when I was asked to add a call to secedit.exe and apply the Compatible Workstation policy to resolve an application compatibility bug. First of all this was the wrong solution to the wrong problem... fix the damn application. What was worse was that the requirement came across to do it without notifying the user. Another time I was asked to change the regional date/time settings.
I was livid and I absolutely refused to implement either of these requirements. But I can't help wonder how many other developers would have gone along with it.
If the story about Microsoft is correct, it seems they have some Deployment Engineers that don't have any issues at all with doing what they are told.
Friday, September 7, 2007
Build InstallShield using TFS
I've
contributed a `keep it simple` sample to Windows Installer MVP Stefan Krueger's InstallSite that demonstrates building a C# windows application and then package it using InstallShield 2008 via TFS Team Build. The example can be downloaded here:
The following is a step by step on how to wire it up:
Prepare To Build:
1) Extract TFS_Build_InstallShield_Example.zip and add the TeamBuildTypes and WindowsProduct folders to your TFS Project source control.
2) Update WorkspaceMapping.xml ServerItem attribute to reflect where you added the WindowsProduct folder in your source control tool.
3) Update TFSBuild.proj:
Set the BuildMachine ProjectExtension to reflect the name of your build machine. The build machine only needs to have .NET 2.0, TeamBuild and InstallShield 2008 or InstallShield 2008 Stand Alone Build Engine installed. Visual Studio 2005 is not required.
Update the TeamProject Property to reflect which TFS Project you added the files to. ($/PROJECT )
Update the DropLocation Property to reflect where you want the builds dropped/archived.
Commit your changes and run a build. When it's all done you should see a good build with an Install folder containing Setup1.msi and a Release folder containing WindowsApplication1.exe.
How It Works in the context of InstallShield:
This sample uses standard TFS TeamBuild solution based build concepts. I don't like to use Project Output references so instead I use an xcopy post build command in the C# project to drop the $(TargetPath) into a folder underneath the InstallShield project directory. I also use Project Dependencies to make sure the C# code compiles first.
InstallShield 2008 has built-in MSBuild/VSIP support. In addition to the standard XML .ISM project, there is an MSBuild file called Setup1.isproj. This document teaches MSBuild/TeamBuild/Visual Studio how to interact with and build the .ISM project. Basically it matches your solution configuration manager settings to the InstallShield Product Configuration/Release settings.
Finally I've instructed InstallShield to do a postbuild event and copy the MSI to ISProjectFolder\..\..Binaries\Install. This allows TFS to include the MSI as part of it's BinariesRoot Drop pattern.
What's Not Included:
This is a simple example and doesn't implement advanced patterns like versioning the ISM/MSI. In my day job I import a build_install.config project that overrides the BeforeCompile target and inserts a call to a custom build task called VersionInstallShield. This task uses COM Interop Reflection to invoke the InstallShield SAB automation interface and update the ProductVersion property of the ISM before building.
contributed a `keep it simple` sample to Windows Installer MVP Stefan Krueger's InstallSite that demonstrates building a C# windows application and then package it using InstallShield 2008 via TFS Team Build. The example can be downloaded here:
The following is a step by step on how to wire it up:
Prepare To Build:
1) Extract TFS_Build_InstallShield_Example.zip and add the TeamBuildTypes and WindowsProduct folders to your TFS Project source control.
2) Update WorkspaceMapping.xml ServerItem attribute to reflect where you added the WindowsProduct folder in your source control tool.
3) Update TFSBuild.proj:
Set the BuildMachine ProjectExtension to reflect the name of your build machine. The build machine only needs to have .NET 2.0, TeamBuild and InstallShield 2008 or InstallShield 2008 Stand Alone Build Engine installed. Visual Studio 2005 is not required.
Update the TeamProject Property to reflect which TFS Project you added the files to. ($/PROJECT )
Update the DropLocation Property to reflect where you want the builds dropped/archived.
Commit your changes and run a build. When it's all done you should see a good build with an Install folder containing Setup1.msi and a Release folder containing WindowsApplication1.exe.
How It Works in the context of InstallShield:
This sample uses standard TFS TeamBuild solution based build concepts. I don't like to use Project Output references so instead I use an xcopy post build command in the C# project to drop the $(TargetPath) into a folder underneath the InstallShield project directory. I also use Project Dependencies to make sure the C# code compiles first.
InstallShield 2008 has built-in MSBuild/VSIP support. In addition to the standard XML .ISM project, there is an MSBuild file called Setup1.isproj. This document teaches MSBuild/TeamBuild/Visual Studio how to interact with and build the .ISM project. Basically it matches your solution configuration manager settings to the InstallShield Product Configuration/Release settings.
Finally I've instructed InstallShield to do a postbuild event and copy the MSI to ISProjectFolder\..\..Binaries\Install. This allows TFS to include the MSI as part of it's BinariesRoot Drop pattern.
What's Not Included:
This is a simple example and doesn't implement advanced patterns like versioning the ISM/MSI. In my day job I import a build_install.config project that overrides the BeforeCompile target and inserts a call to a custom build task called VersionInstallShield. This task uses COM Interop Reflection to invoke the InstallShield SAB automation interface and update the ProductVersion property of the ISM before building.
WS08 Certification Requirements: MSI Not Required
I love good tools, but I love great practices even more. I dislike it when people think tools are more important than practices. My friend Paul Duvall says it better then me:
So while I love MSI, I love it as a tool that implements sound practices... practices that can also be accomplished using other NON-MSI tools.
So with that in mind, a friend recently forwarded me this email stating that Windows Installer is being dropped from WS08 Logo requirements.
However, having a tool synonymous with a practice can be bad thing because people can get carried away with the various bells and whistles different CI servers provide. Don’t get me wrong, I’m a big fan of CruiseControl and other CI servers, but let’s not get lulled into thinking that the tool is what provides the practice. Vendors may want us to think this, but we’re smarter than this, right?
So while I love MSI, I love it as a tool that implements sound practices... practices that can also be accomplished using other NON-MSI tools.
So with that in mind, a friend recently forwarded me this email stating that Windows Installer is being dropped from WS08 Logo requirements.
From: Meg Muran (Corestaff) [mailto: xxxxxxxxxx@microsoft.com]
Sent: Thursday, September 06, 2007 4:34 PM
To: [REDACTCED]
Subject: PLEASE READ: Change in WS08 Certification Requirements
Importance: High
MSI installation is now RECOMMENDED/OPTIONAL and no longer REQUIRED. This should make your development team very happy if, like many ISVs, the MSI installation requirement has been blocking your path to certification.
The following language (or something very similar) will replace the existing section of the certification requirements documents and tools available at www.innovateonwindowsserver.com. As always, wslogofb@microsoft.com is the technical support alias you should use for all certification-related issues.
Installation requirements in detail
2.1 Installer related requirements
Use Windows Components for Installation.
Using the built in installation engines creates consistent, reversible, transacted installations. This ensures the quality of the user's application experience upon installation and throughout the software lifecycle.
Ø It is optional and recommended that application use use the Windows Installer (MSI) or ClickOnce for installation. When using Windows Installer, Installation packages must not receive any errors from the Internal Consistency Evaluators (ICEs) listed here:
1-24, 27-31, 33-36, 38-57, 59, 61-63, 65, 67-72, 74-84, 86-87, 89-94, 96-99
Warnings represent design guidance to the package author which should be studied for applicability. Any warnings that do not apply or will not be fixed must be documented.
If your applications setup is a non-MSI based setup it must be clearly documented as part of the Logo submission documentation. If any generic installation requirement outlined in this document applies to your installer, then they must be satisfied as well.
Additional Information
A variety of third-party tools are available that can be used to create Windows Installation packages. The ICEs can be run from the Orca application, which ships with the Windows SDK.
For information on ICE, see:
http://msdn2.microsoft.com/en-us/library/aa369554.aspx
Ø Support command line installation
Applications must support command line install uninstall. This applies to applications regardless of the use of Windows Installer.
Applications using Windows Installer must successfully install in quiet mode via a command line with /qn switch.
All command line options for install uninstall must be clearly documented.
Meg Muran (Corestaff)
Windows Server Marketing - Logo Team
425-421-5238
xxxxxxx@microsoft.com
www.innovateonwindowsserver.com
Thursday, September 6, 2007
Hatch Chile and Artichoke Dip
Being a Deployment Engineer ( just fancy way of saying Build/Install Automation Dude), I'm a real stickler on repeatability and process/procedure. After all, one day I might be working somewhere else and the show must go on. Those who have worked with me know I love to cook and my coworkers love to eat. So frequently I'll even check my recipes into source control just to make sure that everything will go on if/when I get hit by the next bus. With that said, here is a wonderful recipe from Central Market. I don't see a copyright on it and I'm tired of losing it around the house.
Hatch Chile and Artichoke Dip ( transform applied to original recipe )
2 T. Butter
2 Cloves Garlic, Minced
1 Can Artichoke Hearts, Drained and Chopped
1 pkg Frozen CHOPPED Spinach, thawed and drained
2 Hatch Chilies roasted, skinned and cleaned then pureed
8 oz Lite Sour Cream
8 oz Lite Cream Cheese
8 oz Hatch Shredded Monterrey Jack Cheese
Saute garlic for several minutes. Reduce heat to medium. Add next 5 items and mix well. Stir in cheese until well melted.
Now just rip open a bag of your favorite tortilla chips and announce that the build is ready. This dish is best served right away.
Hatch Chile and Artichoke Dip ( transform applied to original recipe )
2 T. Butter
2 Cloves Garlic, Minced
1 Can Artichoke Hearts, Drained and Chopped
1 pkg Frozen CHOPPED Spinach, thawed and drained
2 Hatch Chilies roasted, skinned and cleaned then pureed
8 oz Lite Sour Cream
8 oz Lite Cream Cheese
8 oz Hatch Shredded Monterrey Jack Cheese
Saute garlic for several minutes. Reduce heat to medium. Add next 5 items and mix well. Stir in cheese until well melted.
Now just rip open a bag of your favorite tortilla chips and announce that the build is ready. This dish is best served right away.
Continuous Integration
Paul Duvall has just finished his newest book Continuous Integration: Improving Software Quality and Reducing Risk. It's published by Addison Wesley and is part of the Martin Fowler Signature Book collection.
Paul and I are good friends and we spent many years in the trenches together back in the 1990's when I worked in Virgina. It would be accurate to say Paul was one of the few architects that I've worked with over the years that really understood the importance of creating a strong development infrastructure for supporting development and designing/constructing applications for deployment/production. Simply put, we learned how to integrate and deploy systems make easy. This was over 10 years ago when concepts like Agile, XP and CI were in their infancy.
So congratulations on the new book Paul and BTW, thanks for dropping my name in the preface. :-)
Wednesday, September 5, 2007
Stream Explorer
We all have our bag of tricks.... Regmon, FileMon, Depends to name a few... well today I have added a new one: Stream Explorer
This little utility comes in handy to identify streams added to files as recently discussed on Stefen Krueger's blog.
I really dislike security by obsecurity and I find it really annonying that downloading the same file in two different ways will generate a file that has the same MD5 hash but will be treated differently by Windows. However, that's the way the world works.
This little utility comes in handy to identify streams added to files as recently discussed on Stefen Krueger's blog.
I really dislike security by obsecurity and I find it really annonying that downloading the same file in two different ways will generate a file that has the same MD5 hash but will be treated differently by Windows. However, that's the way the world works.
Subscribe to:
Posts (Atom)