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: VC80 merge modules lost on major upgrade.
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
Dec 17, 2007
05:31 PM
VC80 merge modules lost on major upgrade.
If you:
1. Compile your application with Visual Studio 2005
2. Distribute VC80 libraries with Microsoft’s VC80 merge modules in your basic msi project.
3. Do a major upgrade of your product that previously distributed VC80 merge modules on a Vista platform.
And:
•If no other software installations on the target system distributed/used the VC80 merge modules.
Then…
•The VC80 merge modules will be removed, not reinstalled and any applications that depend on those libraries will not function.
There is a workaround mentioned here:
http://support.microsoft.com/?kbid=905238
The article is related to Items in the GAC but the fix apparently works for SXS libraries too. I have tested the workaround method2, re-sequencing RemoveExistingProducts, which works.
Has any one dealt with this issue before?
here is a link to something similar:
http://community.installshield.com/showthread.php?t=163650&page=2&highlight=assemblyversion
1. Compile your application with Visual Studio 2005
2. Distribute VC80 libraries with Microsoft’s VC80 merge modules in your basic msi project.
3. Do a major upgrade of your product that previously distributed VC80 merge modules on a Vista platform.
And:
•If no other software installations on the target system distributed/used the VC80 merge modules.
Then…
•The VC80 merge modules will be removed, not reinstalled and any applications that depend on those libraries will not function.
There is a workaround mentioned here:
http://support.microsoft.com/?kbid=905238
The article is related to Items in the GAC but the fix apparently works for SXS libraries too. I have tested the workaround method2, re-sequencing RemoveExistingProducts, which works.
Has any one dealt with this issue before?
here is a link to something similar:
http://community.installshield.com/showthread.php?t=163650&page=2&highlight=assemblyversion
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 18, 2007
03:42 PM
.NET and Win32 side-by-side assemblies are treated very similar by the Windows Installer in that Windows Installer delegates assembly installation to fusion.dll (http://blogs.msdn.com/windows_installer_team/archive/2005/10/07/473320.aspx).
The resolutions in the KB would be recommended, or do not use the VC8 merge modules and instead use the redist executable to install the VC8 libraries.
The resolutions in the KB would be recommended, or do not use the VC8 merge modules and instead use the redist executable to install the VC8 libraries.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 18, 2007
06:35 PM
This blog seems to recommend against using the VCRedist exe except for "Click Once" installers.
from:
http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx
I guess I will have to move the RemoveExistingProducts. In the IS Forum link I posted earlier they moved the action to occur before the costing process (I tried this and it works). The Microsoft article says to move it after InstallFinalize.
Which approach do you think would be best?
Intuitively, I think removing existing products before file costing seems the better approach but the big M says to move the action to after InstallFinalize.
from:
http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx
Finally, there is one additional scenario for redistributing the Visual C++ libraries DLLs. This scenario is if you are using “Click Once” deployment. In this case, “Click Once” will use a custom built installer package called “VCRedist_.exe” to install the libraries for you. DO NOT use the VCRedist_ .exe installer packages for any other purpose.
...MSIs are not ref counted like the components in the MSMs, so if you install it, you can never uninstall it...
I guess I will have to move the RemoveExistingProducts. In the IS Forum link I posted earlier they moved the action to occur before the costing process (I tried this and it works). The Microsoft article says to move it after InstallFinalize.
Which approach do you think would be best?
Intuitively, I think removing existing products before file costing seems the better approach but the big M says to move the action to after InstallFinalize.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 19, 2007
10:05 AM
Unfortunately, the information from the VC blog does not take in to account the issues with the merge modules like the one you are experiencing or other issues like not being able to depend on the VC8 DLLs until after InstallFinalize in an MSI installation. In general, this advice seems to be a bit behind other teams at Microsoft that no longer use merge modules due to the issues they introduce (see MSDE/SQL Express, MSXML as examples).
By resequencing RemoveExistingProducts after InstallFinalize, the old product is not uninstalled until after the new product is installed. Since the new product is installed first, all of the files are still present on the machine and are ref counted which then prevents ones with ref counts greater than one from being uninstalled when RemoveExistingProducts runs. Running RemoveExistingProducts prior to CostFinalize has the effect of removing the old product before the new one is costed, which eliminates the original problem. You could take either approach; in general we typically recommend sequencing after InstallFinalize since that can be done through a setting in the Upgrades view. In either case, we would recommend testing the setup thoroughly to ensure there aren't any significant issues encountered.
By resequencing RemoveExistingProducts after InstallFinalize, the old product is not uninstalled until after the new product is installed. Since the new product is installed first, all of the files are still present on the machine and are ref counted which then prevents ones with ref counts greater than one from being uninstalled when RemoveExistingProducts runs. Running RemoveExistingProducts prior to CostFinalize has the effect of removing the old product before the new one is costed, which eliminates the original problem. You could take either approach; in general we typically recommend sequencing after InstallFinalize since that can be done through a setting in the Upgrades view. In either case, we would recommend testing the setup thoroughly to ensure there aren't any significant issues encountered.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 21, 2007
05:29 PM
I neglected to mention one very important fact that this only occurs on Vista machines because the VC80 merge modules distribute different components (labeled uplevel) for Vista platforms that use MsiAssembly tables.
joshstechnij - Thanks for the information. Hopefully the many others that that are about to encounter this problem will find this thread useful.
joshstechnij - Thanks for the information. Hopefully the many others that that are about to encounter this problem will find this thread useful.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jan 08, 2008
08:24 PM
I am facing this same issue; at first we were unsure of why it was working on some systems, but not others, but I'm pretty sure that the working systems have another component (a different installation) that references the same dependencies, thus causing the ref count to be higher.
I am about to test scheduling RemoveExistingProducts after InstallFinalize. However, will this not create a need for the component/feature architecture to remain intact at major upgrade (similar to a minor upgrade situation) as related to MigrateFeatureStates? (A major advantage of a major upgrade vs. a minor upgrade being that one can change the data hierarchy without issues.)
Has scheduling after InstallFinalize worked well in all cases for you?
I am worried about working around one issue and breaking most of everything else....
I am about to test scheduling RemoveExistingProducts after InstallFinalize. However, will this not create a need for the component/feature architecture to remain intact at major upgrade (similar to a minor upgrade situation) as related to MigrateFeatureStates? (A major advantage of a major upgrade vs. a minor upgrade being that one can change the data hierarchy without issues.)
Has scheduling after InstallFinalize worked well in all cases for you?
I am worried about working around one issue and breaking most of everything else....
hsteinbeck wrote:
If you:
1. Compile your application with Visual Studio 2005
2. Distribute VC80 libraries with Microsoft’s VC80 merge modules in your basic msi project.
3. Do a major upgrade of your product that previously distributed VC80 merge modules on a Vista platform.
And:
•If no other software installations on the target system distributed/used the VC80 merge modules.
Then…
•The VC80 merge modules will be removed, not reinstalled and any applications that depend on those libraries will not function.
There is a workaround mentioned here:
http://support.microsoft.com/?kbid=905238
The article is related to Items in the GAC but the fix apparently works for SXS libraries too. I have tested the workaround method2, re-sequencing RemoveExistingProducts, which works.
Has any one dealt with this issue before?
here is a link to something similar:
http://community.installshield.com/showthread.php?t=163650&page=2&highlight=assemblyversion
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jan 08, 2008
08:26 PM
By the way, to counter the InstallFinalize/GAC commit issue, which is not the same as this issue yet closely related to the VS C++ runtimes, I used a commit custom action with the noImpersonate bit set (2048 + commit bit) in the Type column, then placed it above InstallFinalize to ensure that the build didn't error out. I hope that helps in some way too.
NHM2007 wrote:
I am facing this same issue; at first we were unsure of why it was working on some systems, but not others, but I'm pretty sure that the working systems have another component (a different installation) that references the same dependencies, thus causing the ref count to be higher.
I am about to test scheduling RemoveExistingProducts after InstallFinalize. However, will this not create a need for the component/feature architecture to remain intact at major upgrade (similar to a minor upgrade situation) as related to MigrateFeatureStates? (A major advantage of a major upgrade vs. a minor upgrade being that one can change the data hierarchy without issues.)
Has scheduling after InstallFinalize worked well in all cases for you?
I am worried about working around one issue and breaking most of everything else....
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jan 09, 2008
07:27 PM
We have not re-sequenced the RemoveExistingProducts action yet. We really don't want to do it because of unforeseen consequences, like what happens to unversioned files.
We have a case open with Microsoft. Microsoft admits this is a problem. I am hoping to get a hot fix. I’ll let you know how it goes.
We have a case open with Microsoft. Microsoft admits this is a problem. I am hoping to get a hot fix. I’ll let you know how it goes.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Apr 08, 2008
08:05 PM
By the way…
The workaround Microsoft proposed is to mark the components in the merge module as permanent. That is how we do it now. We only mark the components that install on Vista as permanent.
The Windows Installer 4.5 beta still does not fix this issue.
The workaround Microsoft proposed is to mark the components in the merge module as permanent. That is how we do it now. We only mark the components that install on Vista as permanent.
The Windows Installer 4.5 beta still does not fix this issue.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)