2 replies to this topic

[calpha]

Hello--I'm a tad bit confused by the best way to implement patches.

[b]Background [\b]
I've got an application that has mutliple merge modules, 6 custom dlls, several activex components, and one central .exe

99% of the time, the only thing changing will be the central .exe. The dlls themselves are pretty change free. What I've been doing so far works---but I don't think I'm doing it right:

Most all of the changes to the .exe are small changes---ie, bugfixes. I've got my build number set to auto increment with each build. The version number in the installer is = to the Build Number (ie, currently at 4.1.50). When I patch, I only patch one version to the next. In other words----if a user is on build 4.1.49 and the next release is 4.1.50 I only create a patch from 4.1.49 to 4.1.50. If a user is using 4.1.40 and wants to upgrade to 4.1.50 they should instead choose to download the entire setup package instead of the .msp patch file.

First of all, my first question---
In my experience, if you try to patch multiple MSI's (say from 4.1.40 - 4.1.49 to 4.1.50) the patch created will include the full version of whatever file you are changing. That is not my desired result---as I am wanting to limit bandwidth when I can. With merge modules, the entire download is about 50 megs (thanks to MDAC and Crystal). Is my understanding of this correct? IE---best practice for creating patches, and to have the .msp patch the existing .exe is to only go one version to the next?

Second question:---
For all my bug release setup creations of a given major release---in this case Release 4.1.0- 4.1.99., I keep the same product code. This way, if a user is on 4.1.39 and decides to upgrade to 4.1.50 by downloading the entire package, the windows installer runtimes will automatically uninstall the first version since the product version is lower, before installing the second.
Am I correct in keeping the same product code for each minor release? Should I also be changing the upgrade code for each subsequent bug release setup creation?


Thanks for the responses----I hope to one day FULLY understand windows installer, but it's been a long winding road for me.

[calpha]

Well, I'm incorrect on one notion---I thought that wasn't right.

Windows installer w/ the same product code will not allow installation on top of one another. You have to manually uninstall the older version.

I guess that gets back to my question regarding product codes....... and upgrade codes.

So, again---here's the rephrased question.

We're on version 4.1.50. 4.1.50 full build should update all versions from 4.1.0 to 4.1.49 w/o having the user to uninstall. This means that I should treat all minor builds as diff't product codes, but keep the same upgrade code right?

Furthering that.......this means patches will be patching across one product code to another----which would not let the users upgrade from 4.1.48 to 4.1.50?

I've tried so many things I'm spinning in circles. I miss my old days of Wise Installer Pro.

[Stefan Krueger]

If you create a patch that can update several old versions (4.1.0 through 4.1.49) to the latest version (4.1.50) the installer has two options:
A) Using binary differences: in this case it has to include the diffs between 4.1.0-4.1.50, and 4.1.1-4.1.50, and 4.1.2-4.1.50, etc. so you end up with 50 binary diffs.
Including the whole file.
In your case option B will most likely result in the smallest patch.

You can't install the updates 4.1.0-4.1.1-4.1.2...4.1.50 in one step. That may be possible with MSI 3.0

You should not change the upgrade code. You can change the product code, i.e. create a major upgrade. Installing major upgrades with .msp patches doesn't seem to work right, so you would ship the complete package.

You can install a minor update (i.e. same product code). However that requires command line switches or a setup.exe launcher. (InstallShield Developer 8 includes such a launcher)