PDA

View Full Version : Advance planning to facilitate easy patching



marc.gibian
09-06-2005, 02:43 PM
I am working with an existing set of InstallShield X basic MSI projects. In the past, someone prior to me apparently attempted to generate patches and failed badly. I do not have any knowledge of what was attempted, what failed, or why.

The product is now approaching a new major release and I'd like to do all the preparation and advance work to facilitate easy patching of the product. I have made a first pass through the InstallShield 11 documentation and searched through the forums, but don't see a whole lot of guidance.

I am looking for information regarding what choices make patching simpler and automatic (or automatable) vs. those choices that make it harder and more manual.

The current build for this product does a full delete of the software tree, fetches the current version of all source files, and then does a clean rebuild of the entire product. There is a build number for the product that is automatically incremented and this number is attached to all files included in the build. Version numberings is 1.0.00.0054 where 1 is the major version, 0 is the minor, 00 is currently unused, and 0054 is the build number that is automatically bumped by each formal build.

Ideally, I need to fully automate generation of patches, though I truly don't see much information on how that might be accomplished. I am also concerned that the build and versioning scheme currently used will cause all generated files to be included in a patch simply to bump the build number?

The clock to RTM for the new product is quickly counting down and I absolutely must get a handle on this issue and at least what must be done, both before RTM and prior to shipping the first patch.

Thank you for your help with this,
Marc

Ajay Ladsaria
09-06-2005, 09:14 PM
It is best to follow best practices for the various upgrade options available with Windows Installer. If you are creating patches, then you will want to take a look at the requirements for minor upgrades:

Windows Installer Updates and Patches
http://www.installsite.org/pages/en/msi/updates.htm

Minor Upgrades
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/minor_upgrades.asp

InstallShield provides an Upgrade Validation Wizard which you should always use to validate your upgrades. This is available from the Build menu as well as from the Patch Design view.

If you use a binary difference for your patches, minimal information will likely be stored for files that only are different in version number.

There are a couple things to avoid using if possible to make your life easier.

1. Dynamic File Linking -- This does not give you control over the structure/GUID of newly created components at build time.
2. VS.NET Primary Outputs - Same as above.
3. Files added through dynamic scanning - Same as above. (You are better off adding this manually yourself.)

Another thing to know is that MSI 3.0 introduced new patching functionality which IS X is not capable of authoring. If you want to use MSI 3.0 functionality (recomended), then you should get IS 11.
What's New in Windows Installer Version 3.0
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/what_s_new_in_windows_installer_version_3_0.asp

The information mentioned here is to facillitate in creating robust patches. I hope it helps in designing a successful patch. Automating the process of creating new patches with a script or batch file is more difficult to accomplish, and maybe someone else can comment on this.

FileNET_guru
09-23-2005, 02:47 PM
I am also looking for a comprehensive list regarding doing updgrades/patches. The links above are helpful but I don't think cover all of the updgrade/patch pitfalls. Recently I rewrote a installer package and early on in the project did some prototyping to see if patching worked using MSI technology (I tried prototyping a patch with InstallScript MSI projects and could not get it to work at even the simplest level, so we settled on MSI). It appears to me that patching is fine until things start getting complicated. As I look through the MSI & InstallShield documentation and the forum, I keep running into gotchas such as custom action restrictions that might not be in the original installation, issues with dynamic file linking, installation level settings etc.

I have a project that needs to use dynamic file linking and also needs to support patching. We are componentizing our files as much as possible but we have thousands of files that RoboHelp generates that we want to dynamically acquire. Another question I have is regarding the Shared setting for a component. What should this be set to to enable correct patch behavior?

It seems to me like you don't know whether you can do a patch until you need to do a patch and by that time it is too late because your full installation has already been released...