December 2004 - Posts
The last few days have been pretty interesting around the WiX Toolkit community, and I guess I’ve been the catalyst for most of the commotion. A lot of folks have been following along as I publicly aired by feelings about some of Rob Mensching’s comments on COM Advertising, but what you may not know is that Rob and I have also been exchanging some very lengthy emails offline. In spite of what you may have seen publicly, our offline emails have been anything but a shouting match. We both shared our feelings on a number of issues that we were both concerned about and I think we both benefited from the exchange by learning about each other and how to interact with the community. I’m writing today to own up for my mistakes and set things right.
My comments through this whole thing have been motivated SOLELY by my passion for Windows Installer and deployment technology in general. I have committed myself to this segment of software development and that commitment has been both a blessing and also an enormous curse for me personally. The result of everything that I’ve been through is that sometimes I tackle things a bit too aggressively. So, while I adamantly insist that both my intentions and arguments were honest and correct, I recognize now that my demeanor and mannerisms were easily perceived as being brash and abrasive. For that, and that alone, I extend my sincere apologies to Rob, and to anyone else following along who may have felt insulted by my words. I do see now that I might have been able to achieve my goal of making this an important issue without resorting to “shock” value to get people’s attention.
I’m happy to be putting this behind us, and look forward to working with Rob and everyone else in a much more productive (but less exciting) fashion in the future!
Oh – and by the way – I realize that the underlying issue of COM Advertising may still be a question in some of your minds, so I think you can expect to hear more on the topic from either Rob or myself very soon! ;-)
Ha! Ha! Thanks for the laugh Justin!
Seriously now. How anyone can come to the conclusion I have a secret agenda to promote some other product when I am in the process of contributing smoke, and fighting hard to keep features working with WiX Toolkit is a mystery to me, but I guess stranger things have happened…
For the Record:
I have NO AFFILIATION with any company anywhere. I am NOT pimpin’ any commercial product, and frankly, even if someone wanted to pay me to evangelize their product, I don’t think they could afford me (but they are welcome to try!). I’ve got big plans for the future and a great relationship with industry leaders like Wise and InstallShield. I may do work for them from time to time, but the only agenda I am pushing is my own, and there is certainly nothing sinister about that...
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!
I’m getting beat up a little bit on the WiX Toolkit mailing lists. L It seems that since I’ve been questioning some issues (here and here), and now Rob and Orion think I’m on a war-path. They’ve got me all wrong. I’ve given tons of time to helping other people solve their problems and it would be completely out of character for me to try to undermine everything I’ve done by being obnoxious for no reason. I tend to write passionately and in a very “animated” sort of way. I guess sometimes that comes off like a rant or something, but it’s not intended that way.
Anyway, this got me thinking about what it means to run or be a part of an open source project.
Pride has got to be a serious factor for Rob. I mean, he wrote this thing all by himself and obviously poured his heart and soul into it. Freely and openly sharing something that cost you so much time and energy is hard enough with out someone like me coming along and being critical of your implementation decisions. I know how hard it is to make those critical decisions along the way. ActiveInstall was nearly a half-million lines of code and I can’t begin to count the number of nights I spent staring at the ceiling while trying to make key decisions. At the end of the day, you just have to make the best decisions you can, and be prepared to deal with the fallout if you are wrong. And sometimes you are wrong. I made mistakes, and I suspect Rob has too.
I hope that Rob will come to think of it more like this:
What he did all by himself is excellent! It’s a stellar piece of work for sure. But now, by opening it up for all to see and scrutinize, it can get even better. There’s three ways that can happen:
- Bug identification and fixes through normal usage
- Enhancement or contributions from the community (think smoke)
- Revision/Refactoring driven by public scrutiny
It’s number three that is the most intriguing to me today. The first two are no brainers, but the third is less obvious, yet much more profound in my opinion. It may be painful at first to hear criticism or to have someone challenge what you say, or the decisions you made, but isn’t that the true (or hidden) power of open-source? In my opinion, the real value is not that people can find bugs in your source code, or that like minded people will contribute new code to it, it is that the best and brightest minds around can join in and question everything! The host should encourage discussion and yes – even debates over features and implementation decisions. This only serves to either improve the product or validate the decisions that have already been made.
While I really don’t want to be viewed as a trouble-maker, I’m gonna keep on doing what I’ve been doing. Why? Because I care. Because I like WiX and want to see it grow and mature. Because I want to be a part of it’s success.
‘Nuff said!
A while back, I posted a code sample on my blog that demonstrated how to implement MsiSetExternalUI in VB6. That post certainly got a lot of hits, but there was a catch that quickly came back to haunt me. The sample I provided worked like a champ in the VB6 IDE, but caused your app to crash when it was compiled. I promised to provide an update, and while it is pretty late, here it is!
http://www.DeployNow.com/Articles/Details.aspx?ID=3
The Windows Installer validation tool I’ve been babbling about for a few days now is available for download on DeployNow! Stop by and check it out:
http://www.deploynow.com/Articles/Details.aspx?ID=2
I’ve even enhanced it a bit more to allow for either delimited text output, or xml.
Included in the zip file is a sample batch file that shows how conditional logic can be applied based on smoke’s return value to take alternative courses of action if problems creep into your msi files.
Enjoy – and make sure you link to it, blog about it, and give me some feedback on it!
It seems Joel on Software is really showing his true colors with his shallow and horribly ignorant comments about independent consultants. Thankfully Christopher Hawkins has set him straight.
I'll have to take a few minutes to relate my experiences regarding Joel on Customer Service sometime...
I've been working on a long-overdue update to DeployNow. If you don't already know, DeployNow is my deployment resource site. I came up with the idea a long time ago, but have just been waaaay too busy to really do much with it. Now that I am settling into a groove, I am ready to start packing it with cool stuff!
Stay tuned!
Rob Mensching noticed that the MSN Toolbar Suite's installer was built with WiX. He goes on to admit he was upset to see some “non-ideal” authoring in their .msi file.
Hmmm... If only they had an easy way to incorporate validation of their msi file into their build process...
;-)
UPDATE: Sorry for mangling your name Rob... Fixed!
I was working on one my next MSDN articles (hint, hint), which deals with writing a custom validation engine for Windows Installer packages (*.msi files), when I had the brilliant idea of going a step further and implementing it as a command line app which could be used with the WiX toolset. It’s working like a champ now, but I’m not quite ready to release it. I’d like to solicit some feedback from anyone who’s interested in this sort of tool!
So, here’s what I have so far:
- Command Line executable
- Outputs XML to stdout (it assumes you’ll redirect to a file, then do something with it)
- Allows you to suppress “info” messages
- Allows you to suppress “warning” messages
- Allows you to use custom *.cub files
- Works for Merge Modules
- Free of course! ;-)
So – would this sort of thing be useful for you? What else would you like to see it do?
If you have any ideas, I’d love to hear them!
BTW, I named it smoke.exe. Where there’s smoke, there’s fire. “Smoke test”… Get it? Got a better name?
UPDATE: So, I posted this to the WiX mailing lists as well, thinking those guys would have some good ideas or words of encouragement. What do I get? Cracks about Orca and MsiVal2 as though I did not know they existed... Sheesh...
I'll repeat here what I said there (basically):
Orca does validation, but not from the command line
MsiVal2 does validation from the commandline, but not in a useful way
The idea here is a command line tool that you can integrate into automated build processes. For example, you could:
-
Transform the XML into a nice html report
-
Flag the build as being bad if an errors creeps into your msi
-
Use XSL to filter out noise
-
Check the return value and take action or bail out
-
Extend the source code to do whatever the heck you want
Of course, neither Orca or MsiVal2 can do any of that...
Seriously, I would have expected people involved in open source development to embrace new ideas and people interested in contributing... Besides, if the mere existance of another tool mitigates the need for something newer, better or cooler, then what the heck are they doing? I guess they forgot about MsiDb.exe, MsiFiler.exe, MsiMerge.exe...
But whatever... To be honest, I'm not that surprised. I drafted a post a while back on their plans to write an authoring tool, but it was pretty critical, so I opted not to post it. Maybe I'll reconsider...
Anyway, I think it's cool, and I'm already using it on a client project... If you want to check it out, just drop me a line!