VC80 merge modules lost on major upgrade.

[hsteinbeck]

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

[joshstechnij]

.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.

[hsteinbeck]

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

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.

[joshstechnij]

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.

[hsteinbeck]

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.

[NHM2007]

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....

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

[NHM2007]

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....

[hsteinbeck]

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.

[hsteinbeck]

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.