Installer Hell
I don't know if it is just because I am tired (in the IT sense) or because I am just busy or simply because I have just become lazy, but I like out of the box stuff and I like it to work without having to read a 400 page help file and spend hours on Google searching for the answers. I don't have the energy to stuff around with installers of all things.
Let the stuffing around begin...
Anyway, so we have a complex solution which uses .vdproj Visual Studio 2005 Setup and Deployment projects to build installers. Why I hear you ask? Well because they are there, they are integrated into the solution build and the IDE, they have a simple GUI interface, they don't require you to download and install and configure additional components, they are fully supported by Microsoft (being part of the official VS 2005 RTM and all) and they just work! Yippee, well not quite.
While .vdproj setup projects seemed like a good idea at the time, it turns out it wasnt. So here comes along Microsoft with their NAnt rip-off - MSBuild. But don't even get me started on NAnt - yet another failed open source initiative to add to the ever growing list of open source investments (gambles?) gone south (lets not mention NDoc with VS 2005, .NET 2.0 and generics). Having been burnt by investing hours of development in promising open source technologies such as NDoc and NAnt (that have had no significant work done on them in years and hardly work at all with the new Microsoft technologies), I have decided to stick with Microsoft. But it seems not even Microsoft as it turns out is a good gamble (investment?).
Take the VS 2005 solution files for instance. The project files in VS 2005 are native XML MSBuild files. Of course making the solution file a native XML MSBuild file as well would have been far too logical and way too much to ask, so in their infinite wisdom Microsoft decided to implement yet another useless format (YAUF?), which by the way is not even XML, to define solution files. Heaven only knows why the project files are XML MSBuild project files, while the solution file is some text flat file of a proprietary, unknown, undocumented format? And a flat files of all things? Ever heard of XML? Anyway that aside, at least MSBuild has functionality built in to parse this proprietary solution file and do something useful with it. Of course M$ could have saved some of the $'s if it had simply made the solution file an XML MSBuild project in the first place or at least just XML.
So here's the thing, I have a lovely self-contained solution file that opens up in the VS 2005 IDE and builds like a dream. My developers only have to install trusty VS 2005 and everything just works - no additional downloads, no additional configuration - makes for minimal maintenance and reduces configuration hell. But alas, along comes Team Foundation Server and MSBuild. Err, we don't support .vdproj projects??? What gives? Are you completely stupid or just lacking in brain cells Microsoft? Of course like everything there is a nifty little KB workaorund for the problem. Just install the whole of VS 2005 on the build server, modify all your setup projects in notepad to change all the paths to relative paths (and hope like hell you didn't corrupt the project in the process) and then use the trusty EXEC task in MSBuild to call the VS 2005 IDE to build each setup project individually. Of course if you add new setup projects to your solution you need to add these extra EXEC tasks to the MSBuild project and of course if you ever edit the setup .vdproj, remember to open it up again in trusty notepad and change all the paths. Great Microsoft! Well Done! We love productivity tools like this one.
Ok, so if I have to use MSBuild to build everything else, except the setup projects, and then use devenv.exe (VS 2005 IDE command line) to build the setup apps each individually, why the hell don't I just build the entire solution using devenv.exe and forget about MSBuild? So I'm thinking well maybe there are other cools tasks that MSBuild has (out of the box) that I can use to do more than what my trusty .cmd file that calls devenv.exe can do? Hmmm, I start by looking for the FxCop task? Oh they don't have one... great! However, I can call csc, al and all the rest of the compiler tools sepeartely?! DOH! Yes, I want to do this why? This is why I have a solution and projects to track the dependencies, the references and files to compile in the right order and why I use MSBuild on the solution file and not the individual .cs files. Ok, so there must be more (out of the box of course)... and true enough yes there is... I can copy files, make directories, delete files and do all sorts of nifty command line type things using XML?! HUH? But my .cmd file does this already, funny enough with less lines of "code" and far less angle brackets. Ever heard of the copy command, the md command and the del command?
Anyway that aside, I decide this mismatch of technology bloopers called VS 2005, MSBuild, Team Foundation Server and .vdproj Setup and Deployment projects is not working out. So time to look for an alternative. Of course I really don't want to buy yet another installer such as InstallShield or Wise and then go through yet another learning curve and use yet another proprietary tool (with its own quirks and upgrade path issues and licence issues) and yet another proprietary scripting language...
Hello WiX. Windows Installer XML. A project "open sourced" by Microsoft and used internally by Microsoft. Of course WiX being pure XML has amazing promise, but it lacks out the box'ness. You need to edit XML, which as much as I love XML starts to make my eyes go funny and hurt my hands typing all the angle brackets. There is still no useful GUI for WiX. In fact in the true spirit of open source, the project for the WiX GUI has had no movement for ages. So What to do... Problem 1, is I have to record somewhere that developers must download and install this thing otherwise setup projects are simply not going to compile... I guess I can sort of live with this additional configuration nightmare. However, how on earth do I get these things to build in and out of the VS 2005 IDE? Hello Votive. Votive creates projects for VS 2005 that incorporate the WiX XML into the build of the solution. There are also MSBuild tasks for WiX out the box. This all sounds great from a infrastructure/build point of view, except that I have to install something extra and remember to transfer this knowledge onto future developers. So far so good.
So I fire up Visual Studio 2005; create a new WiX project and hit build. Bloop 2 errors; must specifiy PUT-GUID-HERE. Ok Tools, Create GUID, Copy, paste, Build. Same errors? Oh it doesn't automatically save on build like C# projects do, ok, no problem, click save and then build again. Oops another error:
Error 6 ICE18: KeyPath for Component: 'ProductComponent' is Directory: 'INSTALLLOCATION'. The Directory/Component pair must be listed in the CreateFolders table. C:\Development\Test\WixProject3\WixProject3\Product.wxs 12
Lovely, I have no idea what that means. I can't even get the empty WiX project to build! GRRR... Does this mean I have to read the 400 page documentation? ARG! I guess so. And anyway, since I am editing XML and have no idea what all these elements and attributes do, I guess I have no choice but to go and learn it... but honestly who has 2 or 3 days to master an installer when there is other work to be done... GRRR