When I first tripped across this blog entry about using Windows Work Flow to generate .wxs files, I thought it was written by Clemens Vasters. That surprised me because I imagined (having never actually met him) Clemens as being a guy that would grasp data models really well and that blog entry missed a very important distinction in the data model differences between work flow and the WiX toolset. Well, as you can see from the two links that the blog entry was written by a different Clemens.
So, then I thought about what it was about the blog entry that bugged me. I knew it came down to something in this statement:
WiX uses XML to define the installer packages and that’s not the way to go. XML isn’t a programming language! That’s why people are making windows applications (like InstallShield or Wise) for WiX to define the packages...
It turns out there are two things that I disagree with here.
First, XML is definitely not the way I would define a procedural language. However, the WiX toolset is not producing a procedural executable. The WiX toolset is building a declarative installation package. Because the output is declarative, XML becomes a very reasonable way of representing the data. XML is actually well suited to Windows Installer installation packages because so much of the Windows Installer data is hierarchal.
Now, I know that I often draw analogies between procedural languages' (like .cpp or .cs or .vb) compilers and linkers to the WiX toolset's compiler and linker. However, those are really just analogies and while the metaphors work out really well the outputs from the tools are different. The WiX toolset is more about integrating the creation of the installation packages into the typical build process than creating a procedural language to create installation packages.
You are not going to understand the Windows Installer if you do not switch from thinking procedurally to declaratively. I think this is where the blog entry went awry. The original goal was to create a procedural work flow to write a declarative language specification. That would essentially serialize a procedural work flow into a declarative format with the hope that another engine (the Windows Installer) would later execute the declared data in a similar way as the original work flow. I think Clemens realizes this half way through the blog entry and, unfortunately, ends up looking at a way to shove the whole work flow into a CustomAction. All I can think is "Why bother? Just run the freakin' work flow if that's what you want." A CustomAction like that would really just create a Trojan Horse MSI package anyway.
The second issue I have with the statement is that the fact that WiX uses XML as the foundation for its language is why people are looking for GUI tools to create the .wxs files. That's a simply logical fallacy. There are plenty of people out there that want a GUI to do all sorts of things for them, including abstracting away the the details of the language. However, there are other people out there that are very happy that the language is directly accessible. Many of those "other people" are happy the language is XML (all kinds of text editors that natively support XML) while a few others have asked for a language that was a bit less verbose.
Besides, we're a bit beyond changing the native language of the WiX toolset. The "X" in WiX stands for "XML" after all. <smile/>
posted @ Friday, May 04, 2007 3:09 AM