Burning In Hell With Heat

Ok, I really, really, really keep trying to give WiX a try but I'm not exactly sure why. I have an ASP.NET website installer that I wrote and maintain in InstallShield that I've been wanting to split out to give some of the responsibility back to the ASP.NET developer. To do this, I've moved the components/directories/files out to a Merge Module and the main InstallShield project just handles the UI, consumption of the merge module and creation of the VDIR/XML XPath resources. I want to refactor the merge module to use WiX instead of VDRPOJ.

So I decided to give Heat another try. The goal is to harvest a directory and insert into a merge module project in Votive. Now heat says it's simple, let's see if it is.

First I started by running the command:

(Foo is a directory structure with apx 200 folders and 3700 files )

heat dir Foo -out Foo.wxs

A few seconds later I have Foo.wxs and I'm thinking: Cool! It didn't throw an exception like the last time I tried this.

Then I notice two things... first all of my components ( thousands of them ) have a GUID attribute of "PUT-GUID-HERE". Oh my,that's going to be fun.

Then I notice all of my files have a absolute path for their Source attribute. Well hell, that's not going to work in a build automation environment.

For the first problem I ask the WiXUsers list and I'm told about an undocumented -GG argument to heat. It sure would have been nice if /? told me about that one. So I quickly rerun heat and problem one is gone.

Then I do a search and replace to fix the absolute path problem. Cool, that one is gone. Now it's time to go create a Merge Module project in Votive and paste my components in and build my merge module.

You guessed it... didn't work. It seems that Heat created all of these Fragment elements around the DirectoryRef/Component/File elements and WiX doesn't actually like that when I paste it in as belonging to MergeRedirectFolder Directory element.

So I run a search and replace to get rid of Fragment elements. Now I find out that DirectoryRef is incorrect also. So I perform yet another search and replace to change DirectoryRef to Directory.

Now I'm getting to a new error message:

The Class/@Server attribute was not found; it is required.

It seems Heat examined the properties of my .NET assemblies and only half authored the required attributes. For the moment I decide to just ignore the properties and treat my assemblies as XCOPY. I go through and chop off all of the offending elements.

Yup, you guessed it again... it still doesn't work. Now I'm being told that I have duplicate Directory elements. It seems that Heat didn't normalize my components by their associated directory. It just created a duplicate Directory element for each component.

Meanwhile something else is very annoying.... Ctrl+Break doesn't actually work at killing the build. I have to break out Task Manager and kill candle. Even after it's killed Visual Studio remains unresponsive as it continues to somehow process build error messages that were received from candle.

Ok, it's getting too hot in here even for this Texan. Consuming a directory structure and dropping it into a merge module really shouldn't be this freaking difficult. Even the POS VDPROJ can easily do this simple task.

Now someone can feel free to post a comment talking about how I'm being snarky or that I simply don't understand WiX enough, but it would be a lot more beneficial to actually start considering real world user stories.

I'm still waiting for the day where some tool comes by that solves all of these problems and makes real world use cases simple. Until then I'll be using InstallShield. Sure it might cost $2000 but the alternative is anything but free regardless of what the license agreement says.