WiX Wednesday Part 1.0: Oh, You Mean THAT WiX!
Hello, I thought I’d make the coming month of May all about WiX. And I don’t mean the free website builder. In the past I’ve gone looking for WiX tutorials and began reading some stuff before realizing that they are referring to Wix and not WiX, so I thought it best that I get that out of the way rather than waste peoples time. Over the Wednesday’s of May, I’m going to post a short example of WiX, including:
WiX, (which stands for Windows Installer XML) is a toolset that builds Windows installation packages from an XML document (or maybe more). WiX is notable for being the first software by Microsoft under the open-source Common Public License (others being FlexWiki and the Windows Template Library) and is now supported by the non-profit OuterCurve Foundation. It is free to download from CodePlex and as of writing (2013) the latest stable version is 3.7 and supports Visual Studio 2008, 2010 and 2012. The integration of WiX into Visual Studio means that we can use MSBuild to create MSI’s (which are actually relational databases which outline how the various components of the application are to be be unpacked and copied) by adding WiX projects into our Solutions. You can then utilize Visual Studio tools like Intellisense. Some of the tasks that we use in WiX are relatively straightforward ie copy all the dlls out to a folder location. But software can be a complicated thing, and we can do many more things other than copy files around. IF that is all you want to do then maybe WiX is not for you. During the post-deployment phase there may be several steps we wish to automate, or you may wish to use Wizard style dialogs, or just run a repair, or have multiple versions of your software installed. Utilizing WiX we can script these within the XML documents. And we can run conditional checks so that if the condition is not met, then we can halt the installation. An example of this might be making sure that the user is an Administrator or running the cmdline window as an administrator.
Other than a simple progress bar when installing, WiX lacks a default user interface. For the simpler installs this is not so much an issue as double clicking an MSI will succeed in installing the software. However, if for example you wish to pass in parameters, like for username and password for an IIS based MSI, then you can either go ahead and create a UI or you can install via the command line.Which route you take ultimately depends on who the product is for: mercifully our product contains a lot of backend products so we were able to just rely on msiexec. If you open up a cmdline windows now and run msiexec /? a window will pop open showing you the options that are available when installing an MSI using msiexec. The logging option is especially useful when an MSI has failed to deploy. If however you do require a UI then you are in luck as WiX does come with a standard user interface library, WiXUI. WiXUI is based on the interface in the MSI SDK. WiXUI provides the user interface of a typical installer package, so it provides all typical wizard pages: licence agreement, customer information, different types of setup (typical/custom/complete), customisation of the target deployment folder, disk usage requirements etc. If you are going to create a UI and you are using an IDE, you do need to include a reference to the WiXUI dll in your project. If however you do want to create your own UI then you can (see sources below).
As WiX is available under the CPL, it has a very regular release cycle: every week there is a release and at the time of writing, despite the last stable version being 3.7 (which I recommend you use if you are writing enterprise-level software) you can download and try the latest features earmarked for version 3.8 and 4.0! It offers version for debugging, and on his blog back in January, Rob Mensching wrote about the next generation of WiX developers and encourages people to get involved.
WiX is made up of several components, however the two I want to talk about briefly are Candle and Light.
When I took on my current role I did not know a thing about WiX. But because it overlapped with managing builds it was something that I became acquainted with as there are post-deploy tasks that need to be done at the deployment step as opposed to the build step. And so I got to know WiX and how the developers and the community at large see WiX. I’ll be direct here: people seem to hate WiX. The general consensus is that people feel it is clunky and complicated to use. Also, the documentation on SourceForge is not the most explanatory, and in order to get WiX to do things you want it to do probably don’t make much sense to a dev who is used to OOP, as you will see from some of the examples. Plus finding documentation and examples is very difficult. To a point I agree however based on the fact that, other than MakeMSI, WiX is the only tool-set that is available to create MSI’s for Windows for free, and ironically it comes from Microsoft! WiX has also been around since 2004, and is supported well, so there’s little chance of it discontinued I’ll also tackle the point that there are few examples; I don’t see many people blogging bout it, but surely it must be used by lots of teams out there? So if there are a lack of examples then it is the fault of the community that uses WiX in not giving back, so they have no one but themselves to blame here. The whole point of this series is to provide examples of WiX that I have not seen covered elsewhere, and perhaps because I am a little simple they will be simple to follow…. Also, the verification step in Light for creating an MSI is important and probably overlooked because we don’t see it: it checks hundreds of potential issues which would prevent our MSI from being installed first time. This, as well as Microsoft’s extensive use of Dog Fooding the product (SQL Server and Office are packaged using WiX) has made WiX the recommended option to create a Windows Installer package.
Sources