Monthly Archives: May 2008

100% Frustrated

A very interesting thread is going on over at the WiX-Users list: `yep – back to being 100% frustrated` It’s a very good read.

Basically it started with Chris Mumford complaining that MSI sucks and that WiX doesn’t make it any easier. At first there was just your typical rude fan boy comment ( yes Rob, WiX fan-boys DO exist and not everyone who disagrees with you is a troll or a newbie ):

well.. the local supermarket here .. is looking for a Security Guard???
if u want i can help pass ya resume…


Then follows a back and forth an interesting discussion of the pains of Windows Installer and WiX.

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

Goodness or Badness?

I’ve noticed a disturbing trend that I’ve also been guilty of and I’d like my readers opinions.

As we all know, MSI databases are an open format. It’s very easy to inspect them and transform them to fit the consumers needs. This is a good thing and yet it’s a bad thing.

It seems that various Windows Installer Experts/Bloggers seem to think it’s within their right to stand up on their soapbox, proclaim to be the all knowing expert of “Setup Goodness(TM)” and then proceed to mercilessly judge the authors of packages who don’t meet their exacting standards. Typically the packages being reviewed are from companies that are competitors of Microsoft.

Granted, their are valid technical points, but I believe the message comes across in a very arrogant, vicious manner. So I’d like my readers opinion. Below are a few of examples for you to judge yourself. Afterwords, head over and vote on my new poll.

VirtualBox 1.6.0 setup another example of the second law of thermodynamics
Google Earth setup experience Google App Engine delivered to Windows by WiX.
Google Toolbar Beta for Enterprise a “Trojan horse” MSI package
ComponentID GUID Sloppiness Observation

Welcome Back SeBackupPrivilege

Back in October 2006 I reported about an undocumented security change in MSI 4.0/Vista that prevented Deferred NoImpersonate CA’s from having the same security rights as they had previously had on downstream operating systems. The story was picked up by Microsoft’s Vista Compatibility blog and justified as an attempt to tighten OS security. Maarten van de Bospoort of the MSFT AppCompat team said that it was `design decision made by the installer folks.`

The argument was naturally pointless since any elevated process ( including MSI CA’s themselves or bootstrappers ) could easily tweak the registry and restart the MSI service to get around the restriction. As an aside, my discovery was also cited by Microsoft MVP Stefen Kruger.

Tonight I read on the Windows Installer team blog that after 1 1/2 years, Microsoft is finally correcting this issue an restoring SeBackupPrivilege.