COM Advertising Support in Windows Installer

My 2 cents

TrackBack — Wed, 31 Aug 2005 02:40:00 GMT

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

re:COM Advertising Support in Windows Installer

TrackBack — Wed, 03 Aug 2005 01:03:00 GMT

COM Advertising Support in Windows Installerooeess

re:COM Advertising Support in Windows Installer

TrackBack — Fri, 22 Jul 2005 06:49:00 GMT

COM Advertising Support in Windows Installerooeess

re:COM Advertising Support in Windows Installer

TrackBack — Thu, 19 May 2005 03:37:00 GMT

^_~,pretty good!csharpsseeoo

re:COM Advertising Support in Windows Installer

TrackBack — Fri, 15 Apr 2005 22:27:00 GMT

^_^,Pretty Good!

Washing my hands...

TrackBack — Mon, 10 Jan 2005 23:19:00 GMT

Tallow, where art thou

TrackBack — Tue, 28 Dec 2004 07:41:00 GMT

My 2 cents

TrackBack — Thu, 23 Dec 2004 08:52:00 GMT

re: COM Advertising Support in Windows Installer

Michael — Thu, 23 Dec 2004 01:21:00 GMT

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!

re: COM Advertising Support in Windows Installer

Michael — Thu, 23 Dec 2004 00:17:00 GMT

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.

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 23:48:00 GMT

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?

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 23:31:00 GMT

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?

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 23:19:00 GMT

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...

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 23:08:00 GMT

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...

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 23:06:00 GMT

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

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 22:37:00 GMT

Hey Rob -- Instead of naming that attribute "Advertise", can we change it to "PleaseJustDoWhatISaid"? ;-)

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 20:41:00 GMT

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

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 20:39:00 GMT

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.

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 20:14:00 GMT

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.

re: COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 19:19:00 GMT

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.