Orca is to hex editor as WiX is to ...?

Jonathan Perret made the following interesting comment on a previous blog entry:

...I find it worrisome that even when using such a powerful tool as WiX, one still has to memorize such oddities. I mean, if my app has a prereq it sounds obvious I don't want to require it to uninstall the app. Why can't WiX implement this for me ?

Do you think it is a fair analogy to say that if Orca is like an hex editor then WiX would be MASM ? I.e. powerful for experts but every bit as dangerous ?

I'm going to address those in the opposite order.  First, I often introduce the WiX toolset as the C/C++ compiler/linker for MSI files.  With C/C++ you can leak memory, deference NULL and all kinds of other things that the programmer probably didn't intend.  The WiX toolset will similarly allow developers to do things that might not be what they actually intended.

I think comparing the WiX toolset to MASM is cutting a bit too deep.  There are many things the WiX toolset handles that the developer never has to worry about.  Always lining up primary/foreign key references in the MSI database is an obvious one but there many others like the handling of the NULL property ([~]) in MULTI_SZ registry keys and the NT service groups and enabling distributed setup development through Fragments and linking.

So why doesn't the WiX toolset just handle everything for the developer?  The answer is quite simple: "Because a developer might actually need to do what you wanted protection from." 

In this particular case, I provided guidance that the Installed property should always be OR'd into your LaunchConditions.  Doing so ensures that you can uninstall the application even if the condition is wrong.  The WiX toolset could probably always automagically add "Installed OR" to LaunchConditions to make sure that this guidance is followed.

But what if you as a developer actually need to block the uninstall of your application for some very specific reason?  If the WiX toolset always adds "Installed OR" to the LaunchCondition the developer is now fundamentally screwed by the very tools that were supposed to be helping.  Being a developer, I know that stupid tools trying to be smart are one of the fastest ways to infuriate a developer.

Remember, one of the guiding principles of the WiX toolset is that if the Windows Installer supports the scenario then the WiX toolset does as well or it's a bug.

So the question now is how do we enable developers do what they need to do while helping them avoid known pitfalls?  I know of two methods, both of which are supported in the WiX toolset.

1.  Static code analysis.   Tools that understand the code and point out things that you probably did not intend are wickedly cool.  Visual Studio added static analysis features in VS2005.  The Windows Installer has actually had static analysis since the late 1990s.  It's called "validation" and msival2.exe and Orca both support it.  In WiX v3, light.exe now runs the same static code analysis after every build and there is a tool called smoke.exe that you can use to analyze MSI files without building.

That said, today there is no rule that checks for the Installed property in LaunchConditions but it seems like a great thing to open as a Feature Request, Jonathan.

2.  Higher level languages.   I am obviously biased but I don't believe you will find a better low-level language for creating Windows Installer databases than WiX.  You can edit the .wxs files directly, use a GUI that converts the WiX elements into graphical concepts, or build another language that generates .wxs files and build your MSI files that way.  Higher level languages can be more simplistic because they target a specific need.

For example, I haven't talked about ClickThrough much lately but if you look at the language required to describe an Isolated Application in ClickThrough, I think you'll agree it's much higher level.

<IsolatedApp xmlns="https://wix.sourceforge.net/schemas/clickthrough/isolatedapp/2006">
   <Package>
      <Feed>https://localhost/ct/dc/DrizzleCast.feed</Feed>
      <UpdateRate>1</UpdateRate>
   </Package>
   <Application>
      <EntryPoint>DrizzleCast.exe</EntryPoint>
      <Source>C:\build\dc</Source>
   </Application>
</IsolatedApp>

For more information check out this blog entry about "domain specific languages".

Comments

• Anonymous
  October 23, 2006
  There is one thing that WiX "protects me from". WiX forces all MSM IDs to end with a GUID.  MSI strongly encourages this, but does not require it.  WiX forces this. 99.9% of the time, WiX is correct.  0.1% of the time, I need some flexibility.  WiX doesn't give it to me. It doesn't need to be easy or pretty.  In fact, I would expect it to be quite ugly and obviously scary (like reinterpret_cast in C++).  But it should be possible.  Otherwise, there are significant things I can't do (mainly when interoperating with other MSMs or MSIs that might not have been authored correctly).

• Anonymous
  October 24, 2006
  Rob, Thank you very much for taking the time to answer my (somewhat rambling) comment. I totally agree about "stupid tools trying to be smart" (said looking at VS setup projects :-) ). I'll definitely take a look at the static analysis options in WiX v3.

• Anonymous
  October 24, 2006
  Doug, can you be more specific about the "0.1%"of thigns that you can't do with the WiX toolset?  I'm not aware of any valid MSI/MSM things that can't be created by the WiX toolset.

• Anonymous
  October 24, 2006
  That really depends on the definition of valid.  I've created several MSM's and MSI's that while the may be unconventional they do function as designed.   Typically dark will transform the database to WiX without complaints but candle and light will throw a ton of fits.    With a bunch of tinkering it can be made to compile, but I'm forced to put all sorts of plumbing in that really isn't needed in my particular context.

• Anonymous
  October 24, 2006
  Christopher, can you be more specific about what the WiX toolset required that you didn't think was necessary?  As far as I know, the tools are only trying to ensure that the installation packages will succeed under the widest array of situations they may encounter.  If you find extra stuff being required, that would be good to know so we can fix it.

• Anonymous
  October 24, 2006
  Two issues come to mind, though I think I've run into a few others. First, if I transition an MSI or MSM from old-skool to WiX, the old MSI/MSM doesn't always follow the rules.  Sometimes, for compatibility reasons, I need to keep the IDs the same.  I have some old MSMs that didn't always end with a GUID.  Others end with a GUID, but not in exactly the same format as WiX uses and MSDN recommends.  In both of these cases, I have to break compatibility with the old MSMs. Most of the time, this isn't a problem, but sometimes it is.  QA gets upset because their validation tools report changes.  It becomes impossible to create a good patch for any MSI that consumed my old MSM and now wants to update to the new WiX-based MSM. The other issue is when the MSM and the consuming MSI need to share information.  I would like to tell the MSI creator "just set the YourProduct_TargetDir property and my MSMs will take care of all of the necessary registration".  Instead, I have to say "set MyProduct_TargetDir.GUID1 if you use MSM1, MyProduct_TargetDir.GUID2 if you use MSM2, etc...". I certainly agree that this kind of cross-module interfacing should be minimized and carefully controlled.  I would definitely want this kind of thing to be ugly so it stands out.  But I do want it to be possible. I've heard that this can be avoided if you use wixlibs.  Unfortuately, not everybody uses WiX, and not everybody is using the same version of WiX.  I can't publish a wixlib to my customers, but they do need to be able to communicate a few properties to my MSMs.

• Anonymous
  October 24, 2006
  Oh, and while I'm whining...  :) The wonderful WiX extension custom actions seem to not work very well if used in an MSM.  I understand that MSMs complicate things quite a bit, so I'm actually not going to directly ask that the extensions be fixed for MSMs (that would be nice, but it would also likely be a whole lot of work). What I would like is a way to make use of some of the WiX custom actions even when I can't use them precisely "as directed".  In other words, when the fully-automatic extension mechanism fails, as it does with MSMs, I would still like to be able to use the custom actions, even if it means I have to do some extra manual authoring of the MSM. A few times, since the custom actions got confused when used in an MSM, I've pulled out the DLL and used it directly.  It would be nice if this were a bit easier to do.  I currently have to decompile the WiX CA DLL to get at the resources, pull the DLLs out of the CAB, figure out which DLL is the one I'm looking for via depends.exe, and guess at how to invoke it. For example, with some performance counters that get registered by my MSM, I currently manually insert the server CA DLL into the Binary table and author 6 custom actions for each performance counter.  The extra authoring is probably unavoidable without taking the whole-lotta-work route.  However, it would have been nice to not have to grovel through ildasm and depends to get at the DLL.  And a little documentation would have been nice, too. Ok, I'll stop whining (for now).

• Anonymous
  October 25, 2006
  The comment has been removed

• Anonymous
  October 25, 2006
  There is a big difference between letter of MSI and spirit of MSI.   Letter is an implementation  that MSI will successfully process at runtime and get the developers expected behavior. Spirit is  narrow minded, over zealous, pedantic rule enforcement .   Often times I agree with these rules but occasionally I have a good reason to go against them. If the philospohy of WiX is to only allow the latter and not the former then fine.  Just don't claim that WiX can do the former. I've posted several times in the Wix Users list examples and the only response I get is from people who have spent a total of 15 seconds reading my question, not knowing my installations full story and then jumping in saying I should do it a different way.    really don't feel like repeating that.

• Anonymous
  October 25, 2006
  Christopher, I disagree with your definitions of "Letter" and "Spirit".  It is an interesting topic though and I don't think I've written down the drving forces behind the WiX toolset so I should do that.  That would provide a great time to dig deeper into what I meant by "Letter" and "Spirit" of the law by MSI. I'll go back and try to find the emails you are refering to on wix-users.  It is easier if bugs and feature requests are opened on things that don't work well because I'm always getting a flood of email and issues get overlooked. I'm also sorry if you felt that your issues did not get the full attention they deserved on the mailing list.  For future reference, bugs and feature requests are better ways to get specific issues tracked.  We don't necessarily make quick progress through bugs and feature requests but I do scan them regularly to keep a general feel of what is missing/not working well.

• Anonymous
  October 25, 2006
  I'm afraid I've also been through the drill of initially being told to open a bug just to have it closed saying works as designed.   We've gone from installation stories and patterns to best practices to rules and now laws.   I'm all for good design and obviously I've choosen to adopt a great deal of MSI philospohy by abandoning pure script installs, but to start looking at certain patterns as breaking the law is a road I choose not to go down.