Yesterday I mentioned some discussion on the WiX Toolkit mailing list about the use of COM Advertising support and the challenges that go along with it. Rob Mensching argued that the tables which enable this functionality should be avoided due to some “strange behavior” that he has seen. I pressed him for more information, pointing out that most of the 43 merge modules that you can get here and the MSXML, SOAP, FoxPro, and Crystal Reports Merge Modules all use this technique without any problems whatsoever. Additionally, Office 2003 makes extensive use of this feature, so I really wanted to know what was driving Rob to make such a statement.
Rob followed up today with a vague reference to some bizarre scenario where if you install Office XP and the Speech Control Panel Applet in a particular order, a repair would occur the next time you launched the Speech Control Panel applet. While I appreciate Rob’s follow-up, I am disappointed as it does nothing to explain what the specific problem was and why this scenario proves that COM Advertising is fatally flawed. Based on what he said, it sounds like a one-time repair that is required to get Office and the Speech API in synch. While having to dig for your Office CD is a bit of a bummer, it does not sound like that outrageous of a scenario to me. For what it’s worth, my searches of the Knowledge Base did not turn up any results that seem to describe this problem.
We have to move on, so I wanted to post these as my final thoughts on this issue:
Rob is a Microsoft employee with strong ties to the Office and Windows Installer team. If his assertions are correct, why didn’t the Windows Installer team deprecate the use of these tables in Windows Installer 3.0? Why does Microsoft continue to advocate the use of these tables in the Windows Installer docs? Why can’t he cite a specific technical problem that supports his position? Why is there not a single Knowledge Base article that even mentions this problem?
WiX supports authoring <Class/>, <TypeLib/>, and <ProgId/> elements which should be built into the Class, TypeLib and ProgId tables respectively. In spite of you specifically authoring these elements, WiX will ignore your intentions and dump the data into the registry table instead. WTF? I mean, come on. If you want to make your own personal and unsubstantiated assertions that COM Advertising if fatally flawed, then fine. That is your opinion, but why the hell would you make WiX ignore what the author obviously intended? Wouldn’t it have been better to not even include (or remove) these elements? At least then you would not be deceiving authors…
COM Advertising is a really important part of the application resiliency that Windows Installer delivers. There are very few “entry points” that will cause Windows Installer to check the integrity of your application. Shortcuts and file associations are the most common, but may apps don’t have those. What about services? What about Web Apps? What about Web Services? What about background apps that start with windows? What about apps that are programmatically started by another app? COM Advertising support is the ONLY entry point that Windows Installer can use to try and keep those apps in a properly installed and configured state. Selling out and simply writing off this feature is a really bad idea at it’s face value alone, but doing that when you can’t even make a half-assed reasonable case for why you are doing it is – well – ridiculous… If there is a problem, let’s identify and document it. Let’s educate WiX authors on how to avoid that problem. Let’s work with the Windows Installer team to get it fixed. I know those guys, and I know if it’s broke, they’ll want to fix it.
Decisions like the one used in tallow’s implementation are self-defeating. Basically the approach is to dump all of the COM registration data into the Registry table. Unless by some stroke of luck, your install just happens to install the file to the exact same location as an existing version, the net result is that when your component is installed, it will overwrite previous data in the registry, making the COM subsystem use whatever version of the COM server you’ve installed, even if it is an OLDER version. Given that Microsoft doesn’t let you dump shared components into System32 anymore, there is not a clear or consistent story around what to do with shared components. Most people just dump them into their app folder or \bin folder. Using tallow output, there is no legacy reference counting, no checking the registry to see if a newer version is currently installed elsewhere, no intelligence whatsoever… If you are thinking that through this behavior, WiX is taking us right back to the DLL-hell we all have grown to hate, you are exactly right!
What exactly is the benefit of using tallow? Why not just add the file and have it self-register? I mean the only tangible benefit of tallow I can dream up is that if a rollback occurs, the registry data won’t be written (you can’t rollback a call to DllRegisterServer). Anyone can dump a bunch of crap blindly into the registry table. Isn’t the value of an installation tool to do the hard work for us?
In conclusion, Microsoft competitors are hard at work on intelligent application deployment and management solutions. In many respects, their work is inspired by the powerful features of Windows Installer. We, as developers and deployment advocates, owe it to the Windows Platform to do our part to make Windows Installer work the way it was intended. To educate developers on how to properly use it. To work with the Windows Installer team to improve and refine it. Not to sell out on the vision cause it’s too much work or because you don’t understand it.
That is what I call fighting the good fight for setup!