Cancer Sucks

I'm having a hard time writing this blog, so let me just ask for your prayers again. My wife's cancer has returned and spread to her liver and lungs.

Beyond Tao of the Windows Installer

I was recently reading a blog posted by Andreas Hiltner where they made the complaint:

All of a sudden, InstallShield just died and rendered the whole binary project file useless. 6 hours of work down the drain. Of course we saved early and often, but I did not make backup copies of every single step.

It never fails to amaze me how setup development is treated as a second class development activity and relegated to second class processes. Coding without a version control system and build automation is frankly like jumping out of an airplane without a parachute. You might get away with it for awhile, but eventually you'll crash into the ground in a horrific way.

The Tao of the Windows Installer Rule # 7 only partially addresses this:

Rule 7: Work On a Copy
"My file server won't boot and I really need it up and running now!"
"Ok, let's re-install Windows and restore the data from backup."
"What backup ...?"

Been there? Done that? While losing a single MSI package might not be as disastrous as losing your file server, you really don't want to start from scratch because of some accidental corruption.

So, always make a copy of your package before you start work, then work on the copy. That way, it is easy to revert to a known good version if the working one becomes corrupt or has other problems you cannot easily correct.

Unfortunatly this rule assumes that you are editing your packages by hand via Orca ( you've got to be kidding me ) and that you don't have any type of project source, project files and build output ( package ). Editing built packages with ORCA would be something like making IL changes to a compiled .NET assembly and then making copies of the assembly as checkpoints. Again, you've got to be kidding me.

So what should Andreas have done? First, InstallShield can save it's project in XML format via a setting in the Product Information section. Second, the project should have been checked into a source control repository from the moment it was created. Third, build automation should have been wired up from the moment that the project was checked into source control. Now you have your parachute and it's safe to jump out of that perfectly good airplane.

Where I work I have a standard pattern that supports of all my installs. It literally doesn't take more then 10 minutes to get a first time build going for a new setup project. From there anyone on the team can use TFS Team Build to request an install build. Anyone with InstallShield can also check out the source, make changes, and if desired checkin a shelveset and ask for me to peer review it before committing it to the branch.

Managed Code Rocks

Back in my EDS days I spent a couple years on the Continental Airlines account. They were mostly a VB6 shop with a few groups exploring C# on .NET 1.0 and 1.1. I didn't really know anything about managed code back then. I remember an excited yet sarcastic comment that my manager made about managed code `solving all of our problems`. I couldn't tell if he was being a fan boy or if he was being sarcastic. Maybe both? I think it was the former since he later mentioned during a team meeting that we should all learn C#. A coworker and I stared at each other and later each other `Why?`. You see, this was an IT group and out of the 20 some people in the room, I don't think more then 4 of us actually programmed in ANY language. Regardless we continued working in VB6/COM and didn't think a whole lot else about it. Times were different back then... we owned the entire enterprise so I could actually deliver a prereq package to provide our own framework for CA support. Then our InstallScript CA's simply had to call the COM interfaces to do our dirty work. Not something I'd do in an ISV environment, but it worked for us.

At my next job I saw exactly how ugly Installer Class custom actions were. For awhile I bought into the `managed code custom actions are evil` hype that is constantly repeated by the same three or four people. Then my new manager announced that I'd be spending a week learning C#/.NET 2.0. For the life of me I really couldn't understand why I was going to spend a week learning .NET. After all, what possible place could managed code have in Setup after the hell I had just witnessed? In my mind the future was unmanaged Type 1 CA's written in InstallScript since C++ is just pure hell. I even had an expert C++/C# developer validate that opinion for me.

So I went off and I learned C#/.NET 2.0. Wow, it rocks. Once I really understood it, I came to realize that it could be easily and safely used as a platform for custom actions in MSI. Frankly, C# makes horrific things in C++ look like childs' play. Take this little quote from the WiX-Users list that I recently read:

I realise that [not using managed code] leaves you with few options, since as far as I can see
the web service is the supported API for doing this. Normally for custom
actions we recommend using unmanaged C++, but web services aren't at all
easy to use from C++.

Last September I started another job ( I know... I move around a lot ) and I wanted to implement a pattern that took user input and connected to a server to validate the data. I quickly wrote a C# class in VS2003 that was exposed as ComVisible(true) and exposed an interface for passing data to a webservice and returning the result. Then I wired this up using InstallShields CoCreateObjectDotNet() function. This function basically allows invoking ComVisble .NET classes through reflection without actually having to register the COM for interop.

In the countless times this install has been run, I have never seen or heard of this custom action failing, period. Sure, now I have to deploy a .NET framework, but I did anyways because our software requires it.

Now I've also heard the argument that our CA could fail one day in the future on a newer version of the .NET framework. After all, in the COM->.NET story the latest version of the CLR is used. When I started this story our application was written in .NET 1.1 and later ported to .NET 2.0 and tested on Vista with .NET 3.0 ( CLR 2.0 ). My CA was built using .NET 1.1 and I've never rebuilt it for 2.0. It just works as is on 2.0.

The only advantage that I could give C++ in this story would be faster instantiation and less memory usage. I won't agree that C++ is any more reliable then C#. In fact I would say that unless you have a very experienced C++ developer who will make sure that all errors are handled and memory properly allocated, free'd and buffers protected from overruns, that C++ could actually be less reliable then C#. I'd also say that unless the forementioned person worked in some third world company for dirt cheap that writing the code in C++ would be more costly then writing it in C#.

So if you have similar needs, I encourage you to explore managed code and not buy into the `managed code is evil and doesn't belong in setup` myth.

Toshiba A135-S2386 for $449.99

My wife's 3 1/2 year old Compaq X1050US ( Centrino ) finally bit the bullet. Well, the LCD display did anyways... it's now been transformed `desktop` thanks to a 19" CRT that we had sitting around. We paid about $1200 for it back in the day. Last fall I purchased a Gateway MX6920 ( Core Duo T2050 w/1GB ) for $800. I was getting ready to purchase a new Gateway MT6705 ( Core Duo T2080 w/1GB ) for $600 when I noticed the Toshiba A135-S2386 ( T2080 w/512MB ) at Bestbuy for $449.99. My sister in law also needed a new laptop so I needed two.

The problem was, they are all sold out. But wait, for some reason ( as of today ) BestBuy in Killeen and Waco have dozens of these puppies. So on my way back from Dallas I picked two of them up fo less then $1000 out the door with tax. 512MB isn't nearly enough so I've given up the 2 512MB modules from my Gateway and will be getting in 2 1GB modules from NewEgg in a couple days.

Man, hardware sure does get cheap..... Anyone in Central/North Texas who needs a good solid budget laptop should really give these two stores a call while you can.

Microsoft: Make WiX a priority

I've been following the WiX-Users list where Neil Sleightholm politely started a new thread titled `How do I submit code? Do you want my changes?`:

I have tried to submit code changes to WiX but no one seems to respond. Here is what I have done:

- Applied for a “assignment agreement”, heard nothing…
- Applied for a “assignment agreement”, heard nothing…
- Applied for a “assignment agreement”, heard from Microsoft asking me to help with a new system. I helped, submitted the “assignment agreement”, heard nothing…
- Ok I thought, you guys have better things to do than paperwork, so I worked on a code change to fix a bug in the NAnt task. I submitted a bug (1715295) and followed the advice given here to email the devs list. I did this on 9 May 07 so I don’t think I am being impatient but you guessed it, heard nothing…
- Not one to give up I tried again. This time I submitted a bug (1715298) with the code to fix it. Again, heard nothing…

So what do I have to do to get code accepted? WiX has made making installs much simpler for me and I have 2 clients using it on my recommendation. I would really like to contribute to the code but don’t want to spend the time doing it if there is no way of getting the code accepted (or rejected).

Bob Arnson (MSFT) replied:

It's all a matter of time and priority. At the moment, Rob's the only person who looks at external contributions so we can't load-balance. Your fixes look fine but they have workarounds so that's pushing them down the list too.

To which Neil replied:

Bob, Thanks for your reply but it doesn’t really answer my question. Submitting code and not hearing anything for 6 weeks is a bit demoralising. Virtually every day on this list someone writes a comment along the lines of “if you can fix this please do” but it sounds like you don’t have the capacity to accept code. It would be nice if there was a process for submitting code so at least we knew that our contributions had been received. On other open source projects I have worked on it was easier to submit code.

So my question still stands, do you really want my changes? I appreciate you all have day jobs and this is part time but the same is true for us and there is little point in submitting code if you don’t have time to look at it. The longer the delay is between submitting change and the code being reviewed the harder it is for you as our changes could be based on an old code base.

To me this is a symptom of FOSS. It's a symptom of giving a fine software engineer program management responsibilities and then giving him very little time to do it all. It's a symptom of not being responsible to concrete customers and budgets. It's a symptom of combining the control freak aspects of the `Benevolent Dictator` model with the control freak aspects of super-megacorp needing all the legal I's dotted and the T's crossed with `assignment agreements`. At the end of the day you have dozens of people wanting to help, either with design suggestions or actual code merges, but so few people in the inner circle that very little actually gets done. What should have been accomplished in months takes years.

The irony is that Rob Mensching once posted this rant against InstallAware:

Yet InstallAware the company is directly benefiting from the many, many volunteer hours people in the WiX community have put in creating, discussing, debugging, and releasing the WiX toolset. Nothing wrong with that, the license is written in such a way to enable that very thing. But I think that InstallAware is missing out on a huge opportunity by choosing not to participate in the WiX community (the very people who are most likely to want such a product) until the product proves "commercially viable". There has been absolutely no discussion about WiXAware on the wix-users mailing list.

Given how Rob says he is `100% not the target ( of a GUI designer )`, and that design suggestions and code submissions go completely unnoticed, how exactly can you be upset at InstallAware for not `participating`. ( Which really isn't true.... I've seen K-Ballo (InstallAware WiXAware lead) participating on the mailing list... he just doesn't announce who he works for. )

WiX has done great things, but there is clearly a log jam here. The solution is pretty simple to me and I've rambled on about it before:

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?

Smarter TFS Incremental Builds

Anyone who does a search for TFS Incremental Builds is bound to stumble across this MSDN page that describes controlling TFS's CoreGet with the following properites:

<PropertyGroup>
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
</PropertyGroup>


The problem that I notice with this though is that it fails when you are running the build for the first time and the workspace has never been initialized. This is normally not a huge problem except that I recently I needed to create a BuildType that involved performing a full nightly build and on demand incremental builds. I needed a way to conditionalize the behavior.

Then I realized that I could simply have my schedule task delete the build workspace if I could get my BuildType to be smart enough to prime the pump when the build didn't exist. The result is this simple change:


<PropertyGroup Condition="Exists($(SolutionRoot))">
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
</PropertyGroup>


If the directory is missing, the BuildType defaults to performing a Full Build and if it already exists, it defaults to performing an Incremental Build.

MSI 4.5 and the `Better Together` Pattern

I once designed for a previous employer a bootstrapper that supported a very complex and seamless story for chaining together dozens of setup prerequisites in different combination to support dozens of different products. They were a Product Line Development shop ( with a whole lot of custom engineering efforts also ) that aimed to bring different assets together to create new solutions very quickly. My readers who still work at this blog know just how far we took that design.

So with Merge Modules and Concurrent Installs being officially dead and evil, and each new Microsoft product needing to integrate the experience of deploying more and more reusable components, it really comes as no sup rise to me that Microsoft is finally tackling this issue.

In the "Agility Trends in Packaged Software" white paper by Robert Flaming (MSFT Windows Installer Program Manager) one little section caught my interest:

Your tools vendor may be your first choice in your Better Together path and could even be your conduit to spectrum of software providers that want to provide you a Better Together experience on their software.

We are in a bold new world, and there is a lot to digest in the white paper, but I'm already wondering what kind of standards will be established ( ICE's, Logo Certifications ectera ) to help ISV's develop micropackages that can easily be composited into a Better Together solution. I also wonder if tools vendors like InstallShield are really the best candidates to establish these practices as it could cause problems when multiple ISV's try to integrate their packages and find out that they are somehow incompatible due to design reccomendations from their competing tools vendors.

I really don't know how this will go down yet.... there is alot of information that has been shared privatly with tools vendors yet deemed to secretive to share with actual front line setup developers. Maybe 4.5 will have a strong enough contract that this problem is mitigated and maybe it'll be too loosely defined as to have the innovation come from the tools vendors and lead to exactly this contract.

Either way, if you find yourself supporting installation stories like I described, or if you see yourself selling software that might be consumed by ISV's that support this story, you really owe it to yourself to start reading over MSI 4.5.