ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

May 12, 2008

[More] Problems with MS VC++ 8 SP1 Merge Modules

[updated 5-16-08, see end of blog]
I've had to explain this problem in detail to Microsoft Tech Support so I thought I'd go ahead and blog the details in case anyone else is using the MS VC++ 8 SP1 merge modules in their MSI installation and are unable to reference the assemblies at runtime after updating their product using an MSI major upgrade on a Vista [pre-SP1] system.

Now, in fairness to the Visual Studio team, this problem is most likely an issue with MSI 4.0. I say 'most likely' because I don't know that for sure yet - MS tech support is still working with the MSI team on my case (# SRZ080507000538). However, I feel it's an educated guess based on the fact that installing Vista SP1 fixes the issue and that Vista SP1 contains fixes to MSI 4.0 [nice of the MSI team to slip undocumented fixes to MSI 4.0 into Vista SP1 - see the MSI team blog for a list of changes].

So, we're in the final stages of testing an update to our application (I'll call it OurApp SP1 and you should note that it is an MSI major upgrade with the Upgrade table entry set to uninstall the previous [FCS] install) when QA discovers that running OurApp SP1 on a Vista [pre-SP1] system where OurApp FCS is already installed results in the Win32 assemblies from the MS VC++ 8 SP1 merge modules (Microsoft_VC80_CRT_x86.msm and policy_8_0_Microsoft_VC80_CRT_x86.msm) not being published globally on the Vista system. This was causing one of our java apps to fail because it couldn't load msvcr80.dll when it started [and I know I can install the msvc*80.dll binaries as side-by-side assemblies to the same folder and have the app work - but that's not the point of this blog]. Oddly enough, running an installation repair immediately after the upgrade install completes does publish the assemblies globally. Furthermore, running the OurApp SP1 on a Vista [pre-SP1] system that does not already have OurApp FCS installed results in the assemblies being properly published. To make it even more interesting, installing Vista SP1 on the system before running the OurApp SP1 update results in the assemblies being properly published.

Now, I'm not a novice. I did a thorough comparison of MSI logs from all three scenarios described above and, except for the expected time stamps and property values related to the different system configurations, the log files are exactly the same.

BTW, I opened the MS support incident because I need to know whether or not the fixes to MSI 4.0 that were snuck into Vista SP1 can be applied independently of Vista SP1 (via a hotfix or redistributable) as it doesn't make sense for us to document that our customers should upgrade to Vista SP1 prior to applying our update. However, based on the fact that previous MSI updates have only been made available as redistributables, I'm not going to hold my breath. But I will update the blog once MS figures out the answer.

[UPDATE 5-16-08]
Evidently, this is caused by a known issue with the latest version of msvcr80.dll made available via merge modules (8.0.50727.762), see http://support.microsoft.com/?kbid=905238. However, MS isn't providing a means to incorporate the updated msvcr80.dll (8.0.50727.1434) into your installation via merge modules so the only way to get the update is to have your customer apply either the .NET Framework 2.0 SP1 or .NET Framework 3.0 hotfix (or Vista SP1, which applies the hotfix). The other way to resolve the problem, as mentioned in the KB article, is to move execution of the RemoveExistingProducts standard action so that it occurs after InstallFinalize.

I think it's a pretty lousy decision on the part of Microsoft to not update their damn merge modules. I didn't find this issue until the tail end of the QA process so I can't change the location of RemoveExistingProducts without potentially introducing additional issues and requiring my customers to apply the .NET Framework update when my application doesn't use the .NET Framework is ridiculous. I should be able to incorporate the updated files directly into my application since MS provided a means for me to incorporate the bad files in the first place!

3 comments:

Christopher Painter said...

My two cents is that product teams at Microsoft should just quit trying to ship merge modules. Time has shown over and over how ugly it gets. For my money, static linking seems to have the least amount of pain.

Jesse said...

I stumbled on this by accident, but I've been running in to an issue where my Major Upgrade on Vista removes the existing VC runtime(while uninstalling the old version), but then doesn't put it back.

The installation itself is a bit of a legacy nightmare, so I'm not completely ready to point the finger at MS. I'm not completely sure if it's the same issue you've had either because I believe ours happened on Vista SP2 as well. We never saw it on a different OS though.

We were down to the wire time wise, so I kind of gave up on Merge Modules and just used the redist as a setup prereq and called it a day.

The merge modules for the VC Runtime have never been anything but a huge headache for me.

Jesse said...

I forgot to mention that after our upgrade, a resiliency check would fire and fix everything up, but that's a pretty poor customer experience, and fairly unnecessary.