Problem applying delta patches & versioning

[mctozzy]

Have come across a new problem with patching which I have not seen before. Have already emailed your tech support about this (nearly 24 hrs ago) but no reply yet. Here is the summary:

But first, a question. In AI ( 4.7.1) , if you change just the fourth version number element, you get a message saying that Windows Installer ignores this, and that "changing it alone will not generate a new package". Can you explain what you mean by the last bit? My understanding is that even for a "Small Update", (no change in first three parts of version) the resulting msi must still have a new package id?

The problem I am getting is that in certain situations of applying a delta patch, Windows complains :

"Error applying patch to file D:\Config.msi\PT18f.tmp. It has probably been updated by other means, and can no longer be modified by this patch. For more information contact your patch vendor".
(Cancel, Retry, Ignore)

This seems to be happening while trying to apply a patch to a base install that has already been patched with a "minor upgrade", (i.e. same product code, different version number).

Both patches target the original msi, and have patch sequencing information. (I set the sequence # to the same as the full four-part version number)

However, the second patch does successfully install in either of these two scenarios:

• The patch only contains whole files (no deltas), or
• the patch is installed directly against the base install without the first patch being applied in between.

I can't see anything in the MS Installer SDK docs that describes the reason for the error, nor can I find any discussion on the web about it either.

Any ideas?
MT

[Cosmin]

Hi,

Have already emailed your tech support about this (nearly 24 hrs ago) but no reply yet.

I apologize for the delay, it took some time to investigate the behavior you encountered.

In AI ( 4.7.1) , if you change just the fourth version number element, you get a message saying that Windows Installer ignores this, and that "changing it alone will not generate a new package". Can you explain what you mean by the last bit?

Windows Installer ignores the fourth field of the version of a MSI package. For example, lets say you have two versions of a package: 1.0.0.0 and 1.0.0.1. For Windows Installer, these two packages are one and the same because the first three fields of the versions are identical. If the packages would have the versions 1.0.0.0 and 1.0.1.0, the two packages would be seen as two versions of the same package.

My understanding is that even for a "Small Update", (no change in first three parts of version) the resulting msi must still have a new package id?

Microsoft states that for a small update you need to change the package code. Advanced Installer automatically changes the package code when a build is performed, therefore it follows the Microsoft rules.

In your case, the problem is caused by the fact that Windows Installer ignores the fourth field of the version (it is not related to the package code). In order to create a valid patch, please increase one of the first three fields in the version of the upgraded package.

Regards,
Cosmin

[mctozzy]

I apologize for the delay, it took some time to investigate the behavior you encountered.

No problems!

In AI ( 4.7.1) , if you change just the fourth version number element, you get a message saying that Windows Installer ignores this, and that "changing it alone will not generate a new package". Can you explain what you mean by the last bit?

Windows Installer ignores the fourth field of the version of a MSI package. For example, lets say you have two versions of a package: 1.0.0.0 and 1.0.0.1. For Windows Installer, these two packages are one and the same because the first three fields of the versions are identical. If the packages would have the versions 1.0.0.0 and 1.0.1.0, the two packages would be seen as two versions of the same package.

OK We need to be really precise about terminology here. I think what you mean is that 1.0.0.0 and 1.0.0.1 are the same version as far as Windows Installer is concerned. However as you stated later on, AI still gives the msi a new package code at build time, hence they are technically still different packages as such? I think there is some ambiguity about the use of the word "package".

In your case, the problem is caused by the fact that Windows Installer ignores the fourth field of the version (it is not related to the package code). In order to create a valid patch, please increase one of the first three fields in the version of the upgraded package.

Umm, I respectfully disagree with this explanation. There is no requirement for the version number to change when building a patch - by MS definition that is exactly what makes it a "small update". If you change the version number but not the product code that makes it a "minor upgrade". So what you have just said is that you can only make patches for minor upgrades! That contradicts the MS documentation which explicitly says that small updates can be delivered as patches.

I think there must be another thing at work here, concerning how the caching of baseline files must work. Thinking about it logically, when building a delta patch, it can only construct a delta between one original version of the file (i.e the targeted version), and another version of the file.

I pulled this from the latest SDK docs for Windows Installer:

Beginning with Windows Installer version 3.0, the installer selectively saves baseline information about files when they are updated. Information about the original base application (the RTM version) and the most recent minor upgrade (service pack) are saved in a private location when the application is installed or receives a minor upgrade.

The installer does the following to minimize the size of the baseline cache:

No more than two baselines are maintained for each application: a baseline of the file as originally released (RTM) and a baseline of the file at the most recent minor upgrade (service pack.)
A file is not added to the cache until it is patched. The baseline cache is copy-on-write.
If the application has never been updated, there are no files in the baseline cache.
When the application's last servicing was a minor upgrade (service pack) the application is at a baseline level and at most two copies of a file can be present on the computer. One copy of the file is in the target directory of the installation. The other copy can be in the RTM baseline cache.
When the application's last servicing was a small update (QFE) the application is not at a baseline level and at most three copies of a file can be present on the computer. The first copy of the file is in the target directory of the installation. The second copy of the file is in the RTM baseline cache. The last copy of the file is in the most recent baseline cache.
The application's baseline cache is removed when the product is uninstalled.

Beginning with Windows Installer version 3.0, the installer can use the baseline cache when patches are applied to the application. The baseline information can be used to apply a delta patch or to revert a file to a previous version during a patch uninstall. This can enable patch authors to benefit from smaller delta patches. If the installer finds that the delta patch cannot be applied to the target file, the installer can attempt to use a file saved in the baseline cache as a starting point. The installer only resorts to requesting the original installation source after trying all the possibilities in the cache.

I still can't see why what I am doing is producing this result, because I don't appear to be doing anything that contravenes the rules. Perhaps I should post to the MS Installer team and see what they say.

--MT

[Cosmin]

Hi,

AI still gives the msi a new package code at build time, hence they are technically still different packages as such?

Yes, technically they are different packages because they have different package codes. However, since they have the same Product Code and the same Product Version, Windows Installer will see them as copies of the same package. These copies may have different parts (like the package code, the fourth field of the version number, a couple of files etc.), but this doesn't mean that they are seen as different versions of the same product.

I'm not sure if my terminology is completely correct, but a package is a MSI installation package. A product (which is an application packed into installation packages) can have multiple packages (one for each version).

I think what you mean is that 1.0.0.0 and 1.0.0.1 are the same version as far as Windows Installer is concerned.

Yes.

There is no requirement for the version number to change when building a patch - by MS definition that is exactly what makes it a "small update".

Yes, this is true. However, your case is a bit special:
- the baseline has the version 7.08.01.01 (like you mentioned in your email)
- the minor upgrade patch upgrades it to 7.08.02.03
- the small update patch upgrades it to 7.08.02.04

Since a small update patch must target the baseline (and not the baseline plus other patches), your second patch would upgrade the baseline from 7.08.01.01 to 7.08.02.04, changing the Product Version. Therefore, it is not a small update (technically it is because of the minor upgrade patch, but the MSDN articles contradict each other). However, most likely it conflicts with the first patch because they both upgrade the baseline to the same version.

From our experience, small update patches are not recommended because they usually show a lot of problems.

Regards,
Cosmin

[mctozzy]

Since a small update patch must target the baseline (and not the baseline plus other patches), your second patch would upgrade the baseline from 7.08.01.01 to 7.08.02.04, changing the Product Version. Therefore, it is not a small update. However, most likely it conflicts with the first patch because they both upgrade the baseline to the same version.

From our experience, small update patches are not recommended because they usually show a lot of problems.

This explanation sounds reasonable. All I can say is that this is really "black art" stuff!

I still think what I'm doing is legal, and that Windows Installer still has everything it needs to apply the second patch to the original baseline since it still caches all the original files (otherwise the thing wouldn't be restorable to its original state).

However, what I propose to do in future is make sure that small updates only target the most recent service pack, rather than the original baseline. i.e. to me, a service pack equates to a minor upgrade. So on the target system, you can end up with RTM + hotfix1 + hotfix2 + SP1 + hotfix3 + SP2 etc, where each SP is a minor upgrade patch and always targets the RTM (superseding all prior patches), but each hotfix is a small (superseding) update patch, and targets the most recent SP. I have tested this strategy out before and I'm sure it worked OK. It's just this time we sort of tripped ourselves up by not following our own rule, even though it still seems like it should work. Oh well. Thanks for your help...I realise this issue is more of a Microsoft problem than your one.

Cheers...

[mctozzy]

I also just found this:

http://blogs.msdn.com/windows_installer ... 87044.aspx

The example is not identical to my case, but close enough to confirm that what I was trying to do is not correct. Perhaps it might have worked had my second patch obsoleted the first one. But I think the strategy I outlined in my previous post should work, so long as it is legitimate for a series of minor upgrades to all target the original baseline. (Which makes sense, since it should just be possible to directly install the 'latest' service pack for a product, and not have to worry about all the earlier ones since RTM).

Like I said...black art...

[mctozzy]

Uh oh, I think my strategy for cumulative SP's (without having to specify pairings for every possible from/to combination) is still going to fail ...

http://blogs.msdn.com/heaths/archive/20 ... 31423.aspx

Can I please request that Caphyon adds support for the MinorUpdateTargetRTM property to be added to the MsiPatchMetadata table in the patch file? This property was added in Windows Installer 3.1. (This also requires using patchwiz.dll V4.0 to generate the msp file but that's fine...)

In the mean time, we'll just have to add this property to the MSP file for a service pack by manually using ORCA.

Thanks,
MT.

[Cosmin]

Hi,

I have added this improvement on our TODO list and it will be available in a future version of Advanced Installer. Thank you for your suggestion.

Regards,
Cosmin