This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Basic MSI - Problem with patch and GUID change.
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 31, 2009
09:59 AM
Basic MSI - Problem with patch and GUID change.
Is there any way to get a patch to work across two different versions of a product where the Product GUID changed without having it request the previous install media?
We also can't get it to accept the previous install media. It's looking for the .msi but we ship the product as a compressed single .exe, so the .msi isn't on the disk to point to.
We also can't get it to accept the previous install media. It's looking for the .msi but we ship the product as a compressed single .exe, so the .msi isn't on the disk to point to.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 31, 2009
12:16 PM
If the product code changes with a patch, this would be considered a major upgrade patch. Unfortunately, except in the simplest of installations (one feature, one component, one file), we've never seen a successful major upgrade patch. Using this type of patch is generally discouraged by Microsoft (see http://msdn.microsoft.com/en-us/library/aa369786(VS.85).aspx). The new setup should be deployed as a full upgrade, or be authored to not change the product code so that a minor upgrade patch can be used.
In normal patching cases, the following article contains recommendations on methods that can be used to mitigate most causes of source prompts in a patch (note as mentioned in the article, it is impossible to eliminate all possible causes of source prompts):
Preventing a Patch from Requiring Access to the Original Installation Source
In normal patching cases, the following article contains recommendations on methods that can be used to mitigate most causes of source prompts in a patch (note as mentioned in the article, it is impossible to eliminate all possible causes of source prompts):
Preventing a Patch from Requiring Access to the Original Installation Source
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2009
09:45 AM
joshstechnij wrote:
If the product code changes with a patch, this would be considered a major upgrade patch. Unfortunately, except in the simplest of installations (one feature, one component, one file), we've never seen a successful major upgrade patch. Using this type of patch is generally discouraged by Microsoft (see http://msdn.microsoft.com/en-us/library/aa369786(VS.85).aspx). The new setup should be deployed as a full upgrade, or be authored to not change the product code so that a minor upgrade patch can be used.
Thanks for the Information. Is there any way to determine which version of the product it's asking for when it requests the Source Media? Is it asking for the installed version with the old GUID, or the newer version (with the new Product Code).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2009
11:07 AM
A verbose log should provide some information as to what package MSI is looking for. There are typically lines containing 'SOURCEMGMT' when MSI is attempting to resolve a source package. Windows Installer looks for an MSI package matching a specific product code and package code that it has information registered for.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)