Ramblings & Rants

Michael Sanford on Windows Installer, Software Development and life in general!

COM Advertising Support in Windows Installer

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!

Posted: Dec 22 2004, 06:35 AM by Michael | with 23 comment(s)
Filed under: , ,

Comments

Michael said:

Hi,
if WIX contains <Class/>, <TypeLib/>, and <ProgId/> elements they definitely should be built into the corresponding tables.

If it doesn't currently, then this behavior is deceiving und should be changed ASAP. If it will not be corrected, then this will certainly lead to branching of the sources.

IMO WIX's first task should be to provide a thorough and clean mapping from XML to MSI tables. Everything else should come after and on top of that. If one chooses to go through the registry entries, even using tallow, fine, but the other possibilities given by by MSI should be equally viable. I personally distaste tallow, if others like it, fine, but nobody should be pressed one way or the other.

One more point: DllUnregisterServer is a rollback to DllRegisterServer.
Stefan
# December 22, 2004 11:10 AM

Michael said:

Great points Stefan!

What I meant is that once you call DllRegisterServer, you can't rollback to whatever may have been there before, even if you call DllUnregisterServer. Once you overwrite it, it's gone...
# December 22, 2004 11:20 AM

Michael said:

Advertisement is supported by the WiX Toolkit toolset for all of the elements you mention. You can control whether Advertisement is on or off by specifying the "Advertise" attribute on those elements. Note, that TypeLib table does not actually do advertisement per-se.

If the WiX toolset does not support a feature of the Windows Installer, then it is considered a bug (unless the Windows Installer team has started to actively dissuade use of a feature, such as nested installations). I believe it would be much more productive for the community if bugs were filed when you find issues with the toolset.

Also, tallow has always been presented as just quick way to get your registry keys our of SelfReg and into a .wxs file. There are many issues with the output from tallow (not just with the registry keys) and some people in the community have discussed improving it.
# December 22, 2004 1:13 PM

Michael said:

Finally, it is considered a very big deal to prompt the user to find their original source media. When I was in Office, we went to extreme lengths to avoid any prompt for the source media because customers could not always access the media when prompted. Fundamentally, customer's hated being prompted for the source media at any point in time *except* initial install. The story I told was just one of my favorite examples explaining how using the Class tables is a great way to lose control over prompts to your source media.
# December 22, 2004 1:19 PM

Michael said:

It sounds to me that you are trying to discredit the use of the WiX Toolkit Toolkit for your own personal benefit. Looking through your past history shows that you have had competing products to WiX. Are you a little bitter perhaps? Statements like, "Microsoft competitors are hard at work on intelligent application deployment and management solutions" sounds like they come right out of a marketing brochure. Why don't you just say which product you are promoting and be done with it.
# December 22, 2004 2:14 PM

Michael said:

Well, at least your blog is appropriately titled... "Ramblings & Rants".

There's just one thing in there that I can't leave on the table. In your ranting, you suggested that to avoid DLL hell one should just use selfreg. <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/selfreg_table.asp">Here</a> is some documentation explaining why you should _NOT_ do that. Tallow is one approach to a solution for the problems described in that documentation. As you've pointed out it may not be a perfect solution in all cases. It does however make it easier for MSI package developers to do the "right thing" and not use self-reg.

Anyone can point out problems and criticize. Coming up with solutions... now that's the part is valuable.
# December 22, 2004 2:39 PM

Michael said:

Sorry, I don't post comments to blogs very often. Here's that documentation link again without my HTML decorations:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/selfreg_table.asp
# December 22, 2004 2:41 PM

Michael said:

Hey Rob -- Instead of naming that attribute "Advertise", can we change it to "PleaseJustDoWhatISaid"? ;-)
# December 22, 2004 4:37 PM

Michael said:

Well, if you want to advertise something, logically you'd set the advertise attribute on wouldn't you ;-)

Most of michaels comments on the wix mailing lists have been of high quality and he obviously knows a massive amount about the windows installer (and obviously thinks he knows far more than Rob M, but whether he does is irrelevant really.)

However, having read his past history (and the fact that he seems to be currently employed by zero-g), one can't help but wonder if michael does in fact have some agenda to push... the more people use wix, the less potential customers his company has... It'd be like windows developers contributing code to the linux kernel or somesuch...
/me takes out the proverbial grain of salt for future use
# December 22, 2004 5:06 PM

Michael said:

Hey Scott -- thanks for the comments, but that isn't what I meant. I see how can think that, but is was meant as sarcasm. In other words, if you're going to do that, you might as well save the trouble and go the final tiny step to self-registration.

See Scott -- almost every reason cited in the link you gave applies to what tallow does too!

Lastly, you are suggesting that I am criticizing without offering solutions. I'll quote myself now:

"If there is a problem, let’s identify and document it. Let’s educate WiX Toolkit 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."

The entire point to this whole crusade I'm on is that (if it's broke) I want to fix this...
# December 22, 2004 5:08 PM

Michael said:

Orion -- ;-) I do love your sense of humor!

Thanks for the compliment (I think...), but, no -- I don't think that I know more than Rob. I just think that I know a lot about this stuff in general.

Lastly, I don't work for that company and have NO ongoing relationship with them whatsoever.

Lastly, I have no problem with the "Advertise" attribute and what it does, but think the defaults should be the other way around. The sheer existence of those elements is an explicit statement that you DO want them "advertised". Having to explictily set the "Advertise" attribute is like have a "YesIReallyWantToDoThis" attribute...
# December 22, 2004 5:19 PM

Michael said:

We could name the attribute "PleaseJustDoWhatISaid", but do you think that would be more accurate? Is your main issue here the fact that the default for the Advertise attribute is "no"? If so, then there is a reason for that. Advertisement was done in a rather whacky way in WiX Toolkit v1 (that never was released) and when we moved to the WiX v2 schema we added the Advertise attribute to maintain backwards compatibility.

I can't believe that this is the whole issue? The default on this attribute?
# December 22, 2004 5:31 PM

Michael said:

Rob -- the larger issue for me is abandoning the COM related tables. Understanding that some people may choose not to use them, an option to translate those entries to the registry table is an option that I could live with. As I indicated to Orion, the mere existance of those entries in your xml is an EXPLICIT statement that you want them to be there, so with all due respect to old versions, the "Advertised" attribute seems redendant and confusing. Implementing it as a "ConvertToRegistry" attribute that has a default of no would have made much more sense to me. Even having said all that, I still have to wonder: If you don't want COM advertsing, why would you create those entries in the first place? If you were decompiling an existing msi, then a compiler directive to convert them would have been cool, or if you were authoring from scratch, just put that stuff in Registry elements in the first place. Based on what you said, I'm guess it is a limitation caused by previous versions of WiX Toolkit, but can't we fix this in a more elegant way now so we don't have to live with this forever?
# December 22, 2004 5:48 PM

Michael said:

Michael,

Think about the WiX Toolkit schema as a language instead of a direct mapping to the Windows Installer tables. Then, try working with the Class, ProgId and AppId elements for a while. You'll find that they are far less complex to manage the 20 or so Registry elements you'd need to accomplish the same thing. It also alows you to specify the registry keys that always have to go into the Registry table (like ThreadModel) in the same place as the rest of the definitions. That's definitely a win (it is at least less typing and you don't need to duplicate a GUID in multiple Registry elements).

Now the Windows Installer has the ability to "advertise" COM registration. Do you call the attribute "ConvertToRegistry" because the implementation in the Windows Installer uses tables called Class/ProgId/AppId for advertised stuff and the Registry for non-advertised stuff, or do you call it "Advertise" because the COM registration is supposed to be advertised. I obviously agree with Orion's thinking that "Advertise" is a better name for the attribute.

Now, the question turns to what should the default for "Advertise" be? At a certain level, you just flip a coin. Some people will like it one way, others will like it the other. Fortunately, the toolset is able to do both (one just requires more typing). Note, that adding Advertise='yes' also adds the complication that you must pick your "primary Feature" for advertisement. In the end, flipping a coin wasn't necessary because we weighed a lot of the issues above (plus the WiX v1 syntax) and picked the default to be "no".

I still believe that Advertise="no" is a better default. You're welcome to disagree with me and if you really want a different default, download the source code and tweak the YesNoType.NotSet value in Compiler.cs:1633 to YesNotType.Yes. Or add default='yes' to the wix.xsd for the Advertise attributes.
# December 22, 2004 6:17 PM

Michael said:

Thanks for the thoughtful and complete explanation! I cetainly have a better understanding of the thought process that went into this now. For what it's worth, most of the WiX Toolkit schema elements follow suit with the Windows Installer table names. Given that a firm grasp of Windows Installer is a prereq. for WiX, I still think the default behavior is not what one would intuitively expect. Perhaps if the "Advertise" attribute required an explicit yes or no, and had no default, that would have prompted me to read the docs and realize what was going on. In any case, I accept your explanation and thank you again, for spelling it out so clearly!
# December 22, 2004 7:21 PM

TrackBack said:

# December 23, 2004 2:52 AM

TrackBack said:

# December 28, 2004 1:41 AM

TrackBack said:

# January 10, 2005 5:19 PM

TrackBack said:

^_^,Pretty Good!
# April 15, 2005 5:27 PM

TrackBack said:

^_~,pretty good!csharpsseeoo
# May 18, 2005 10:37 PM

TrackBack said:

COM Advertising Support in Windows Installerooeess
# July 22, 2005 1:49 AM

TrackBack said:

COM Advertising Support in Windows Installerooeess
# August 2, 2005 8:03 PM

TrackBack said:

If people were following the the WIX-Users Mailing list, they would find that it has been a little hot recently. The first instance (as far as my knowledge goes) was with Michael creating a validation tool for the WIX Toolset called 'smoke'. I personally
# August 30, 2005 9:40 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)