[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!