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.

Deployment Engineer Available

I would like to publically say that I'm interested in communicating with fellow Austinites ( and others from around the world if remote work is possible ) who may be aware of organizations that could benefit from my assistance in the areas of build and deployment automation. I am willing to do 50% travel is necessary. Please email me offline at chrpai@yahoo.com.

Thanks,
Christopher Painter

Austin .NET Deployment Brown Bag

I've started the processs of planning a .NET Deployment Brown Bag lunch with focus on Windows Installer / InstallShield techniques. If this interests you, please email me at chrpai@yahoo.com for more details.

Deploying a Vista SideBar Gadget

Bob Crawford recently asked on InstallShield Community:

Hi, we are developing a Vista application with a companion Sidebar gadget. We would like to install/uninstall the gadget along with the application. Does Installshield 2008 have this kind of support for Sidebar gadgets?

I havn't done this yet so I decided to start Googling. This interesting MSDN Lab came up:

Windows Vista: Creating a Simple Sidebar Gadget Virtual Lab

After registering you can download a PDF that walks through the process of creating a manifest for your gadget. From there it's a matter of giving the directory a name that ends with `.gadget` ( known as development packaging and seemingly implied not to be used for production ) or zipping / cabbing the directory and giving the compressed file a .gadget extension.

From there gadgets are deployed in true .NET ( and Java ) style.... XCOPY to C:\Program Files\Windows Sidebar\Gadgets. You simple create a component, add the .gadget file as the key file, set the directory and associate it to a feature.

So in short, yes InstallShield 2008 supports deploying SideBar gadgets.

WiX / WiXAware ... thinking about the future

I've decided to spend yet another evening looking at WiX and I really do like it conceptually. While I am still disappointed that a lot of problems that WiX and other setup tools are solving aren't being solved by the Windows Installer team instead, I am slowly coming to accept this as a fact of life.

I really like Votive's ability to integrate in a solution, support MSBuild and show the XML in your WiX project. But I dislike it's limitations in not having any kind of designer view.

I also really like the concept that WiXAware has where you can switch between a GUI and an Editor. The View Designer | View Code story is definitely the place to go. But I dislike the fact that it's waproj isn't MSBuild and it doesn't support VS integration. I also dislike the fact that it seems to throw an exception just about everywhere I click and I dislike the fact that it doesn't support fragments.

But what if Microsoft just threw a bunch of money at InstallAware and bought them? What if Microsoft was to tell Rob Mensching that he had a staff of developers and that they wanted to transform WiX into a full fledged open source enterprise installation authoring tool capable of competing with InstallShield toe to toe?

And what if all of this was to be targeted for Visual Studio Orcas so that when you bought Visual Studio you'd be completely covered for deployment?

The other day I was skimming through a Microsoft Learning Course... #4339 Upgrading from Microsoft VB 6.0: Deploying .NET Framework Applications. The course was very VDRPOJ centric and a lesson introduction claimed:

Unlike the traditional deployment which involves creating script-based setup programs, Visual Studio 2005 deployment uses Windows Installer to create installers which give you complete control over the installation process.

Wow, that's a really bold claim to say VDPROJ gives you complete control over the installation process.

But WiX meets WiXAware meets Orcas..... now that could be one hell of a system. That could really get me rethinking what tools that I use. In fact, if it wasn't for the fact that I live in Texas, that's one project that I wouldn't mind working on.

7 Months to publish 2 KB articles

Last year the Windows Installer team blogged about 4 upcoming KB articles. Now I understand why they published them as a preview, it's taken Microsoft 7 1/2 months to publish just 2 of the 4 articles.

Yes, over 7 months. Man it feels like Office Space.

What could possibly take so long to write these? The first one about DEP is only 9 sentences.

The second one caused by cached MSI's losing their digital signature is only 7 sentences and it doesn't even go into explaining why the behavior occur. It simply documents a `work around` that tells the user to click Allow.

Now I know the MSI team has some very smart and capable contributors and leaders, but I can only imagine what must be going on behind the scenes within Microsoft that it takes 7 months to publish two simple KB articles. Now imagine trying to give us something we really need like XML search/write functionality.

It's no wonder that they have seemingly abdicated the throne to WiX which can operate in the relatively unrestricted world of FOSS with nothing more then Jersey Mike's sandwichs for funding.

Working Around VDPROJ and Horrible EULAs

I recently read several blog articles and newsgroup postings of interest when put together.

The first was from Aaron Stebner ( MSFT ) talking about YEt Another Hack ( sarcasm `YEAH` /sarcasm ) describing how to do some crazy postbuild step to get a VDPROJ installer to do something as simple as set the In-Script Execution Context for a custom action. I'm sorry, but I've been down this road before. In no time at all you will have dozens of these build automation hacks just to get a tool set to do something that it specifically wasn't designed to do despite that it's painfully obvious that it should.

Then I read this posting from Phil Wilson...

The design of installer class methods does not pass the MSI handle through to managed code, mainly because the design (as a deferred custom action all) means that there's not actually much you can do with it.

Based on this and what little support for custom action attributes VDPROJ exposes, it seems pretty obvious what Microsoft ( Visual Studio Team ) wanted to design Visual Studio to support.

Finally I read a story over on SlashDot entitled Microsoft vs TestDriven.NET. It seems that the author ( Jamie Cansdale ) of TestDriven.NET royally offended Microsoft by coming up with extending Visual Studio Express editions with Unit Test Add-In's. A response from the VSE team can be read here.

So setting the threshold level to 5 on SlashDot ( as I always do ) I discovered this gem:

It seems that Microsoft is claiming a EULA violation on the basis:

...you may use the software only as expressly permitted in this agreement. In doing so you must comply with any technical limitations in the software that only allow you to use it in certain ways... You may not work around technical limitations in the software.

So I ask you, if VDPROJ specifically didn't provide for immediate context CA's, ServiceControl/ServiceInstall support and a host of other things, and assuming that Microsoft's bizarre EULA is enforceable, isn't writing articles that encourage developers to work around these ( obvious ) limitations simply an invitation to disregard their own EULA?

Just like teaching developers how to modify .NET Framework Redistributables to run silently even when their own EULA says that you may not.

BTW, did I mention that Microsoft yanked the MVP status of Jamie? Also of interest is that Jamie wrote the Installer for TestDriven.NET using all Microsoft tools including WiX.

Times like this makes me really happy that I don't owe anything to Microsoft... I prefer to have an unbiased outside opinion without worrying about things like will I get shunned from some conference, lose MVP status or worse, lose my lively hood.

Days like this, I miss my Amiga.