ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

June 13, 2007

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.

4 comments:

Christopher Painter said...

BTW, I also tried to dark the existing merge module. All of the files are extracted in GUID.GUID format which makes it practically impossible to rebuild against the original source tree that's available in build automation.

And finally I tried to use WiXAware to create the WXS and then port it over to Votive for building....

The first problem here is that WiXAware generates Wix v2 schema and Votive expects v3. I update the Wix xmlns and try to build and I get hundreds of errors saying that the File/@DiskID attribute cannot be specified in a merge module.

Ok, giving up again...

Starbounder said...

There's also Setup Factory for Windows Installer that you could try. (SFWI is out of beta now.)

Christopher Painter said...

The last time I checked, SFWI doesn't support creating merge module projects nor does it support VS integration and MSBuild support.

Lots of cool tools but frankly none of them is measuring up yet. I really hope they do soon because I am eager to try new things.

Anonymous said...

You might need to turn on the Merge Module option...

"heat.exe dir C:\directory -out sourceFile.wxs -template:module"

See...
http://installing.blogspot.com/2006_04_01_archive.html

Yeah the user stories are really not there. What this tool needs is a component catalog to reconcile everything (guid's and ID's etc) while not breaking all the component rules.

I believe I have just written a component catalog which takes the output from heat and looks up an XML database of all my components. I would like to at least get discussion happening in this area, but not sure how to go about it.