Tao of the Windows Installer, Part 2

re: Tao of the Windows Installer, Part 2

Rick — Fri, 12 May 2006 18:44:00 GMT

In regard to Rule 14, Use Consistent Package Naming Conventions, can you elaborate on what constitutes a "base package name"? That phrase doesn't appear anywhere in the Windows Installer 3.1 Help file. For example, does MyApp_v1.00.MSI have the same base package name as MyApp_v1.01.MSI? How much latitude is there in the naming convention without breaking this rule?

Base Package Name

Troy Phillips — Sat, 13 May 2006 16:24:13 GMT

Hi Rick
I would suggest that base package name refers to the actual msi file (I think the SDK actual refers to it as the package database from memory?).

What you can't do is name the MSI file Blah_v1.msi then patch the install point, rename it to Blah_v1a.msi and expect clients to be able to redeploy/install updated features only.

Personally, we use the folder name to identify the package and name all our base package files "setup.msi" (we agree with all the other points though!)

Hadn't yet considered point 18 (turning off system restore) - although given the environment we work in I have already emailed a link to my colleagues.

re: Tao of the Windows Installer, Part 2

Stefan Krueger — Sun, 14 May 2006 18:57:58 GMT

I think that "base package name" means the name of the .msi file that was used for the original/initial install (the "base package"). Small and Minor updates ("update packages") must use the same .msi file name as the base package.

re: Tao of the Windows Installer, Part 2

Windows Installer Team — Mon, 15 May 2006 16:54:23 GMT

"what constitutes a 'base package name'?"
Yes, it's not the clearest explanation mankind has ever seen! What it's referring to is the point made in bullet 4 here:

Changing the Product Code
"The update must not change the name of the .msi file of the installation package. Instead, because it modifies the package, it should change the package code. Note that this means that the update can change the tables, custom actions, and dialogs in the .msi file without changing the file's name."

For example, let's say I install an application using a package called "MNP2000.msi". I then decide to update the application by applying a new version of the .msi - I simply make a copy of the package and change the contents as appropriate. Then I call this "MNP2001.msi" and patch by re-installing:

msiexec /fvomus C:\Red_Park_Small\MNP2001.msi /l*vx c:\MNP2001.log

This will fail, and looking at the log we see why:

MSI (s) (F8:D0) [14:11:57:711]: Resolving source.
MSI (s) (F8:D0) [14:11:57:711]: Using cached product context: User non-assigned for product: C3329A8143B072149A662C75832607CB
MSI (s) (F8:D0) [14:11:57:711]: Using cached product context: User non-assigned for product: C3329A8143B072149A662C75832607CB
MSI (s) (F8:D0) [14:11:57:711]: Resolving source to launched-from source.
MSI (s) (F8:D0) [14:11:57:711]: Setting launched-from source as last-used.
MSI (s) (F8:D0) [14:11:57:711]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Red_Park_Small\'.
MSI (s) (F8:D0) [14:11:57:711]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Red_Park_Small\'.
MSI (s) (F8:D0) [14:11:57:711]: PROPERTY CHANGE: Adding SourcedirProduct property. Its value is '{18A9233C-0B34-4127-A966-C257386270BC}'.
MSI (s) (F8:D0) [14:11:57:711]: SOURCEDIR ==> C:\Red_Park_Small\
MSI (s) (F8:D0) [14:11:57:711]: SOURCEDIR product ==> {18A9233C-0B34-4127-A966-C257386270BC}
MSI (s) (F8:D0) [14:11:57:711]: Determining source type
MSI (s) (F8:D0) [14:11:57:711]: Note: 1: 2203 2: C:\Red_Park_Small\MNP2000.msi 3: -2147287038
MSI (s) (F8:D0) [14:11:57:711]: Note: 1: 1316 2: C:\Red_Park_Small\MNP2000.msi
MSI (s) (F8:D0) [14:11:59:037]: Product: MNP2000 -- Error 1316. A network error occurred while attempting to read from the file: C:\Red_Park_Small\MNP2000.msi
MSI (c) (14:F4) [14:11:57:711]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1316. A network error occurred while attempting to read from the file: C:\Red_Park_Small\MNP2000.msi
MSI (s) (F8:D0) [14:11:59:047]: Machine policy value 'DisableRollback' is 0
MSI (s) (F8:D0) [14:11:59:047]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
Action ended 14:11:59: ProcessComponents. Return value 3.
MSI (s) (F8:D0) [14:11:59:047]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (F8:D0) [14:11:59:047]: No System Restore sequence number for this installation.
MSI (s) (F8:D0) [14:11:59:047]: Unlocking Server
Action ended 14:11:59: INSTALL. Return value 3.

The Installer is looking for the original package name "MNP2000.msi", which it obviously doesn't find. To get around this I would need to rename the updated package back to its original name.

So, to answer the original question, this means that there is no latitude in naming the package in this scenario as "MyApp_v1.00.MSI" and "MyApp_v1.01.MSI" would be treated as completely different packages.

[If you've worked through the SDK examples, you might recognise "MNP2000.msi" and "Red Park" ...]

[Author: Richard Macdonald]

This posting is provided "AS IS" with no warranties, and confers no rights.

re: Tao of the Windows Installer, Part 2

Phil Wilson — Tue, 16 May 2006 22:55:06 GMT

I have a suggestion for a new rule:

"Design and test your servicing strategy *before* you ship the initial product. You must know in advance how you'll be updating your product, and once it's shipped it's too late to change its design. So build and install your product, then create an update (a patch, a minor update, a major upgrade, whatever you'll be using) and make sure that it actually works."

I've lost track of the number of times I've seen people ship the product then run into a servicing issue because the product has been shipped and it's too late to change that original design.

re: Tao of the Windows Installer, Part 2

Mark Rovetta — Wed, 17 May 2006 01:07:59 GMT

The term ‘base package name’ is not used in the SDK documentation and notice that a definition of ‘base package’ does not appear in the glossary. The phrase ‘base package’ appears in various parts of the documentation describing customization and instance transforms. It has been used to mean the target or unmodified version for a transform.

As general advice to users of the documentation – If a term is not in the glossary, or does not appear in a SDK topic title, it has not been defined precisely. So expect the words were used in their ordinary sense.

My understanding of Rule 13 and Rule 14 is that these could be combined:

Rule 13.5 – Keep application identifiers consistent

The product code GUID is the principal identification of an application and must change whenever there is a comprehensive update to the application. Changing the name of the application’s .msi file is considered a comprehensive change and always requires a corresponding change of the product code to maintain consistency. The .msi file can be given any name that helps users identify the package, but the name should not be changed without also changing the product code.

"Design and test your servicing strategy before you ship the initial product"

Stefan Krueger — Wed, 17 May 2006 12:40:27 GMT

I second that! In general I recommend that you use your msi installer during the beta phase of the product, and ship (at least some) beta updates as msi updates/patches.

re: Tao of the Windows Installer, Part 2

Windows Installer Team — Wed, 17 May 2006 14:53:15 GMT

"Design and test your servicing strategy *before* you ship the initial product"
Agreed. I think this is fairly prevelant and relates a little to Rule 5 - developers are often too focussed on just getting an application working, so never think of setup, let alone servicing.

I'll add this to the up-coming "Patching" blog.

[Author: Richard Macdonald]

This posting is provided "AS IS" with no warranties, and confers no rights.

re: Tao of the Windows Installer, Part 2

Phil Wilson — Tue, 23 May 2006 20:48:25 GMT

Rule 25: Should there be a custom action rule about not showing UI in a custom action in the execute sequence?

re: Tao of the Windows Installer, Part 2

Doug Glenn — Tue, 23 May 2006 21:34:23 GMT

The link http://support.microsoft.com/?id=264478 on disadvantages of repackaging installations is quite old and now contains a number of errors despite being reviewed recently. It also only covers up to v1.2 of the Installer technology.

Isn't it about time you all brought it up to date? There are dozens of repackagers now that support isolated components and other high end features that were not available at the time that was written, so it is somewhat misleading to be used on this blog :)

Just my two cent.

re: Tao of the Windows Installer, Part 2

Mark Rovetta — Tue, 23 May 2006 23:51:00 GMT

[Edited for reading clarity - Richard Macdonald]

Although repackaging tools are always improving, I still think a list of Windows Installer ‘good practices’ should recommend designing for the Windows Installer early in the development process over running a legacy setup through a repackaging. A legacy setup that has been repackaged won’t be capable of taking full advantage of all Windows Installer features.

I think the following revised repackaging rules should hold for the most current Windows Installer versions.

Design for good installation and servicing rather than repackaging

Installation and servicing should not be an afterthought of the development process. Applications that have been designed from the start to take advantage of Windows Installer features can be easier for users to install and service. Repackaging tools convert legacy installations into a Windows Installer package by taking a picture of the system before and after installation. Any registry changes, file changes, or system setting that occurs during the capture process will be included in the installation. Repackaging an existing setup application is not the best development practice.

The following guidelines can help mitigate some of the common problems associated with using a repackaging tool.

• Configure the hardware and software of the computer used to repackage the installation as close as possible to the intended user's system. Create a separate package for each different hardware configuration. Repackage using a clean computer. Remove any unnecessary applications. Stop all unnecessary processes. Close all non-essential system services.

• Always make a copy of the original installation before starting to work on it. Always work on the copy. Never stop a repackager before it finishes building the package. If the repackager damages the package you will still have the original.
Do not repackage Microsoft software updates

Microsoft releases software updates, such as service packs, as self-extracting files that automatically runs installation. These updates use different installers than the Windows Installer to replace protected Windows resources and cannot be converted into a Windows Installer package.

• Do not attempt to repackage Microsoft software updates into a Windows Installer package.

• For information about how to deploy Windows service packs, see the appropriate Service Pack Deployment Guide on Microsoft TechNet.

Customize, rather than repackage, existing Window Installer packages
The Windows Installer adds configuration information to the system as well as application resources. When a repackaging tool compares the system before and after the installation, the repackager misinterprets the configuration information as part of the application. This usually damages the repackaged application.

• Do not use a repackaging tool to convert a Windows Installer package into a new package. Instead use customization transforms to modify an existing Windows Installer package, or develop an new package. You can create customization transforms using the MsiTrans.exe tool. This tool is only available in the Platform SDK Components for Windows Installer Developers.

• Do not use a repackaging tool to consolidate several Windows Installer packages into a single package. Instead you can use the Msistuff.exe tool to configure the Setup.exe bootstrap executable to install the packages one after another.

re: Tao of the Windows Installer, Part 2

Windows Installer Team — Wed, 24 May 2006 01:47:35 GMT

"Although repackaging tools are always improving, I still think a list of Windows Installer ‘good practices’ should recommend designing for the Windows Installer early in the development process over running a legacy setup through a repackaging"
Yep, I agree. If you look Rule 5 from Part 1 of this series, that's exactly what is recommended. However, re-packaging is unavoidable in some cases, such as when dealing with legacy applications.

And, yes, you could re-write the rules in a more compact form, but the thing I like about the current format is that the rule headings serve as nice, easy-to-remember bullet points. Having multiple ideas in each would make them less memorable - the short "body" text is there for further explanation.

"Rule 25: Should there be a custom action rule about not showing UI in a custom action in the execute sequence?"
There is a point in there that does say generally not to show dialogues from custom actions and recommends MsiProcessMessage for reporting errors. Does this cover what you mean?

"The link http://support.microsoft.com/?id=264478 on disadvantages of repackaging installations is quite old"
Yes, that's one of those references I've been using for so long I slipped it in there almost on auto-pilot. I'm looking into having it reviewed and updated.

[Author: Richard Macdonald]

This posting is provided "AS IS" with no warranties, and confers no rights.

Windows Installer best practices

Aaron Stebner's WebLog — Sun, 09 Jul 2006 03:29:35 GMT

I recently noticed a series of in-depth articles that have been posted on the Windows Installer team...

Windows Installer Team Blog : Tao of the Windows Installer, Part 4

Windows Installer Team Blog : Tao of the Windows Installer, Part 4 — Tue, 19 Sep 2006 00:53:31 GMT

PingBack from http://blogs.msdn.com/windows_installer_team/archive/2006/06/27/648447.aspx