This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Applying patches one after the other fail
Started by
aarthi_m
, Apr 14 2008 10:54
2 replies to this topic
aarthi_m
-
- Full Members
- 65 posts
Posted 14 April 2008 - 10:54
I have version 1.0 of a product. Following this version, there were 2 patches released to upgrade to version 1.1 and version 1.2.
Patch P1.msp - upgrades from 1.0 to 1.1
Patch P2.msp - upgrades from 1.0 to 1.2, 1.1 to 1.2
I upgraded from v1.0 to v1.1 using the first patch (P1.msp). Now, the product version has upgraded to 1.1. When i try to upgrade to v1.2 using the second patch(P2.msp), it does not update any files or registry settings. The product still remains at v1.1.
However, the logs show upgrade is successful. The logs indicate that the install product version is 1.0 and the patch P2 will upgrade to 1.1.
Should it not read the installed version as 1.1 and the patch P2 let me upgrade to 1.2?
Is the installer trying to apply P1 patch again? If so, why?
How can i upgrade to 1.2 using the patch?
VBScab
-
- Full Members
- 436 posts
Posted 16 April 2008 - 14:59
| QUOTE (aarthi_m @ 2008-04-14 09:54) |
| The product still remains at v1.1. |
From where are you reading that version information? If it's from the product's registry entries in HKLM\Software\Microsoft\CurrentVersion\Uninstall\[ProductCode], does the patch change the version number?
If it's from the application's EXEs or DLLs, have they had their file version information updated?
It wouldn't be the first time I've seen one or both errors, even from some major vendors...
What happens if you apply patch 2 directly to the product, without first applying patch 1? Your post says that it should u/g from 1.0 to 1.2. Does it?
Edited by VBScab, 16 April 2008 - 15:02.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Tonko
-
- Full Members
- 4 posts
Posted 27 April 2008 - 14:50
I have been testing trial versions of several third-party installer tools and had this happen due to my misunderstanding of how the product works (to be fair to myself, tool documentation did not mention the issue either)
Namely, to create MCP both the target and the update files (and MSIs) must be uncompressed. Tools will often create a separate folder where they will store uncompressed installs. In effect this folder becomes a cache that must be properly refreshed when creating a new patch.
When creating MCP verify that this folder contains uncompressed files with expected versions. Otherwise, installer will not install them because the target and the updated files may be the same.
However, excluding this case of an operator error, I had a few cases while using Installer 4.0 on Vista when patches were not applied for a reason that I never figured out. Log file didn't report any error.
While some tools support multiple targets for patches, I don't think that MS endorses or recommends that practice. In fact, my reading of MS Installer Team Blog and MSDN Installer documentation is that they don't recommend patching MSIs that were already patched as small updates.
<QUOTE>from MSDN Installer Team Blog link
Use binary delta patching. You can patch efficiently by just targeting baselines (RTM, SP1, SP2, etc.).
</QUOTE>
Granted, inferring from this that it not recommended to target 'baselines' that are not RTM or minor upgrades (i.e. SPn) but are, instead, small update patches, is open to interpretation.
Finally, Creating a Small Update Patch MSDN Library link] says:
<QUOTE>
Your company ships version 1.0 of Myproduct.msi. Shortly thereafter, you ship a small update patch for Myproduct.msi called QFE1. This does not change the ProductCode property or the ProductVersion property.
Later, you author a second small update patch for Myproduct.msi called QFE2. This second patch must target Myproduct.msi version 1.0. This second patch must not target both Myproduct.msi version 1.0 and Myproduct.msi version 1.0 + QFE1. When QFE2 is applied it should remove QFE1.
</QUOTE>
This (bold empahsis is mine) kind of nails it down, even if without any explanation.
It is also unclear what is the exact recommended procedure for removing QFE1 when QFE2 is applied?!? One would imagine that you should set supersede flag but according to some people in the know, for small updates supersedence flag is ignored.
Correctly interpreting what is written is complicated by the fact that MSDN online documentation sometimes contains gross typos and errors. For example, you have a few Installer object methods documented like:
<QUOTE>
FileVersion( Path, Language )
Parameters
Path
Required string containing the path to the file.
Language
Flag for designating whether the returned value is a language ID or version string. TRUE returns the language, FALSE returns the version. This parameter is optional, with a default value of FALSE.
Return Value
This method does not return a value.
</QUOTE>
Bold emphasis is mine. This is obviosly a simple copy-paste typo but it does raise some doubts about the accuracy of the rest of the documentation.
There are quite a few reports of failures when patching patches, with failures either logged as error 1328 or with no errors logged but files simply do not get updated.
So far the only answer to patching the patch (for non-administrative installs) problems seems to be: if it works for you, great. If it doesn't, then patch the RTM or Service Packs only, in the sense of selecting them as patch targets.
The term 'patching the patch' is ambiguous (and has possibly created a lot of misunderstandings in some discussions and problem reports) because minor upgrades (i.e. SPs) can also be distributed as patches. Specifying the patch target makes things clear. For example, is your patch targets a RTM, a minor upgrade or another small update patch?
Namely, to create MCP both the target and the update files (and MSIs) must be uncompressed. Tools will often create a separate folder where they will store uncompressed installs. In effect this folder becomes a cache that must be properly refreshed when creating a new patch.
When creating MCP verify that this folder contains uncompressed files with expected versions. Otherwise, installer will not install them because the target and the updated files may be the same.
However, excluding this case of an operator error, I had a few cases while using Installer 4.0 on Vista when patches were not applied for a reason that I never figured out. Log file didn't report any error.
While some tools support multiple targets for patches, I don't think that MS endorses or recommends that practice. In fact, my reading of MS Installer Team Blog and MSDN Installer documentation is that they don't recommend patching MSIs that were already patched as small updates.
<QUOTE>from MSDN Installer Team Blog link
Use binary delta patching. You can patch efficiently by just targeting baselines (RTM, SP1, SP2, etc.).
</QUOTE>
Granted, inferring from this that it not recommended to target 'baselines' that are not RTM or minor upgrades (i.e. SPn) but are, instead, small update patches, is open to interpretation.
Finally, Creating a Small Update Patch MSDN Library link] says:
<QUOTE>
Your company ships version 1.0 of Myproduct.msi. Shortly thereafter, you ship a small update patch for Myproduct.msi called QFE1. This does not change the ProductCode property or the ProductVersion property.
Later, you author a second small update patch for Myproduct.msi called QFE2. This second patch must target Myproduct.msi version 1.0. This second patch must not target both Myproduct.msi version 1.0 and Myproduct.msi version 1.0 + QFE1. When QFE2 is applied it should remove QFE1.
</QUOTE>
This (bold empahsis is mine) kind of nails it down, even if without any explanation.
It is also unclear what is the exact recommended procedure for removing QFE1 when QFE2 is applied?!? One would imagine that you should set supersede flag but according to some people in the know, for small updates supersedence flag is ignored.
Correctly interpreting what is written is complicated by the fact that MSDN online documentation sometimes contains gross typos and errors. For example, you have a few Installer object methods documented like:
<QUOTE>
FileVersion( Path, Language )
Parameters
Path
Required string containing the path to the file.
Language
Flag for designating whether the returned value is a language ID or version string. TRUE returns the language, FALSE returns the version. This parameter is optional, with a default value of FALSE.
Return Value
This method does not return a value.
</QUOTE>
Bold emphasis is mine. This is obviosly a simple copy-paste typo but it does raise some doubts about the accuracy of the rest of the documentation.
There are quite a few reports of failures when patching patches, with failures either logged as error 1328 or with no errors logged but files simply do not get updated.
So far the only answer to patching the patch (for non-administrative installs) problems seems to be: if it works for you, great. If it doesn't, then patch the RTM or Service Packs only, in the sense of selecting them as patch targets.
The term 'patching the patch' is ambiguous (and has possibly created a lot of misunderstandings in some discussions and problem reports) because minor upgrades (i.e. SPs) can also be distributed as patches. Specifying the patch target makes things clear. For example, is your patch targets a RTM, a minor upgrade or another small update patch?
Edited by Tonko, 28 April 2008 - 01:25.