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.

Reminder: Vista Beta's Expire Soon

Time sure does fly... it seems like just yesterday I bought my Gateway MX6920 and started a new job. I suddenly remembered that my Vista RC2 will be expiring 5/31/2007.

So I'm trying to decide whether I should go back to XP MCE that came with my laptop or upgrade to Vista Home Premium.

But there is one thing I sure don't get. Why is it more expensive to buy direct from Microsoft via Digital Locker then it is to just go to Best Buy and pick up a copy. For that matter, Microsoft lists vendors on their website that are $45 cheaper then doing a digital download and of course I can go to Frys and pick up a system builder copy for even cheaper.

IS SABLD should be free

I originally meant to write about this blog 6 months ago. However, for some reason it ended up in my drafts list never to bubble up again until now.

I really wish that Macrovision would release the InstallShield Stand Alone Build Engine without any licensing restrictions or with some type of resellers program. I think this would be inline with Microsoft's MSBuild technology.

When I engage with potential clients, I frequently encounter customers who want to outsource their small installs but they are afraid to go with InstallShield because of the initial tools investment. They will actually go down the path of reinventing the wheel with lesser tools because of their understimating of the amount of work involved.

The reality is that these customers typically only need to be able to build their project, `own` their source as a work for hire and occasionaly bring in an outside consultant for maintenance without the full blown expense of InstallShield.

TIP: Parallel IS12/2008 Builds Using TFS

So let's say your rolling with TFS/MSBuild using VS2005 solution integration and everything is building just fine. Suddenly a new version of InstallShield comes out.

Your really curious to try it out but your afraid of introducing instability to your production builds. Try this.... Parallel Builds.

InstallShield Stand Alone Build can be installed safely side by side. Install the latest SAB on your build box ( or bring up another build box with SAB 2008 )

Branch the project contain your .SLN/.ISPROJ/.ISM. In the branch, checkout the .ISPROJ file and modify the Import Project statment to point to $(MSBuildExtensionsPath)\Macrovision\IS2008\Macrovision.InstallShield.targets.

Go to TeamBuildTypes and clone your build type to a new name. For example Client becomes Client-2008. Update the workspacemappings.xml to point to your new branch in TFS source control. Modifiy your newly cloned TFSBuild.proj and update the DropLocation property aswell as the Description and BuildMachine ( if changed ) project extensions.

Finally check it all in and do a build. If you did it right, your build should run like always but in a seperate build space, use the new SAB 2008, automatically upgrade the ISM source to 2008 schema and drop the build in your archives in a side by side location.

Now you can safely regression test your installation without committing to using IS2008 since your project source is still in IS12 format. If you make changes to your project, just merge them to the 2008 branch and rebuild. When you are confident that everything is good to go you can update the .ISPROJ file on your main branch and start doing dev using IS2008.

TFS and InstallShield just makes it too easy...

InstallShield 2008 Stand Alone Build Download

The KB article listing the availablity of IS2008 SAB can be found here.

You can download the installer directly here.