RobMensching.com /Blog
when setup isn't just xcopy

Defining "fun" on a Sunday night alone.

Jenny is out of town tonight so I've been catching up on my "concept reading". After grilling dinner (teriyaki chicken) and eating while skimming through the Ruby on Rails site I decided it was time to put something "fun" on the Media Center before continuing my MVC vs. MVP conceptual dive.

Now I have a pretty large and fairly varied music collection (skewed heavily in count towards electronic music) so there is a lot of different stuff to pick from.  However, as soon as I thought "fun" the word "swing" popped into my head. So the next challenge for me was to narrow down what swing album to kick things off with.

Big Bad Voodoo Daddy Live was the obvious pick after a quick glance at my swing music collection. It helps that they show up near the top of the list starting with "B". But seriously, this is a live CD (as one might guess by the album title) that really does do a great job capturing the energy that is the Big Bad Voodoo Daddy.

The whole set is spectacular.  They roll so smoothly from one song to the next.  They do a great job featuring some great oldies mixed in with a their own original music. The way they transition into their rendition of "I Wanna Be Just Like You" (from the Jungle Book) is one of my favorites moments on the album.  But the real kicker is when The Kid (the band's killer in-control trumpet player, he really is amazing to watch live) croons a couple lines near the end of the first encore of "Goodbye". Don't skip ahead. Listen to the whole album. It makes the moment that much sweeter.

Every time I listen to the Big Bad Voodoo Daddy Live album it takes me back to the night Jenny and I saw these guys play Benaroya Hall. The album lacks some of the cool insights Scotty Morris shared with our audience about the band and the music they play but the album probably flows better without the history lessons. In any case, the Big Bad Voodoo Daddy Live is how I've decided to define "fun" tonight and I'm already smiling...

 

Zataoca: Custom actions are (generally) an admission of failure.

The title of this blog entry is a concept that I kept trying to sneak into one of my earlier posts on this "Zen and the Art of Custom Actions" thread.  I finally gave up trying to make it a bullet point and now here we are.  What convinced me that there was a full topic to be covered was when I realized I meant two things when I said "Custom actions are (generally/typically) an admission of failure."

First, as a setup developer you really shouldn't have to write any custom actions*.  I know a lot of people think writing custom actions is more fun than simply declaring everything that needs to be installed.  However, custom actions are invariably more error prone than the native engine functionality.

There are three common reasons custom actions are introduced.

a.  The setup developer wrote a custom action that was already supported by the underlying engine.  This is essentially reinventing the wheel with a less stable solution.  Invariably this comes down to lack of documentation or lack of effort on the developer's part.  Either way a failure to use the most optimal solution.

b.  The setup developer wrote a custom action to address some complexity in his or her application.  As I have noted a great many times before, setup is "where the rubber meets the road" for the first time for most applications.  When issues arise often there is pressure to just solve the problems in setup rather than go back and fix/simplify the application.  Often deciding to complicate setup will lead to more fragile solutions than if the application had just been updated.  Either way the failure is often rooted in a poor design.

c.  The setup developer wrote a custom action to configure some platform because the platform technology didn't provide installation primitives for itself.  This one is just sad and, unfortunately, happens more often than not.  My favorite platform to pick on is the Internet Information Services or IIS.  The ever popular platform for ASP.NET that hosts a great many web sites around the globe provides basically no mechanisms to enable install, uninstall, rollback, upgrade and patching of web sites, virtual directories, app pools, etc.  The platform failed the setup developer.

There is a variation on c. where the setup developer wrote a custom action because his or her authoring environment doesn't support all the functionality of the installation engine.  In this case, I would encourage the setup developer to find a better authoring environment.

The second reason I say, "Custom action are an admission of failure" is that if you have a custom action then you are far more likely to have installation failures.  Having written a great number of custom actions for the WiX toolset (to try and help address c. above) I can assure you that getting the code right in all cases (especially patching) is extremely difficult.  If you look at the last bugs in WiX v2, you'll find they have all been custom action issues.  An installation package with no custom actions is far less likely to fail than a package with custom actions.

So, ultimately, I would encourage all setup developers to be very skeptical about custom actions and continually work to reduce the amount of custom code in your installation package.  There are few setup experiences more stable than an application that simply needs a bunch of files installed.  Get in the habit of questioning the value of every setup requirement beyond copying files and you may be surprised how stable things can be.  You'll also be quite a few steps down the path of Zen and the Art of Custom Actions.

 

* Note: when I talk about custom actions in this blog entry (and most blog entries) I do not mean the simple Type 51 property assignment operations that are technically defined as a custom action in the Windows Installer.  Type 51 custom action are rarely the cause of an installation failure (although you can certainly cause failures by assigning the wrong thing to the wrong place at the wrong time).

 

Zataoca: Classes of Custom Actions

Continuing the Zen and the Art of Custom Actions thread, I thought I'd post a mostly formed thought.  When I'm presented with the need to write a custom action I often mentally classify the work into one of three or so different buckets.  Now, I'm not sure the ideas presented here in capture exactly everything the way I want but it seems like a decent place to start discussion.  So, on with the classifications.

1.  Internal-only custom actions.  This class of custom actions operates purely on data available inside the MSI database.  Assigning a Property the value of another Property is a simple internal-only custom action.  A custom action that reads some table in the MSI and populates some other table with temporary rows is also an internal-only custom action.  Internal-only custom actions are usually easier to design and implement because their data is contained completely within the MSI itself.  Since internal-only custom actions do not interact with the "outside world" (i.e. anything on the machine) they usually have very few dependencies.

2.  Read-only custom actions.  This class of custom actions reaches out on to the machine to gather data for some other process of the install.  Usually, read-only custom actions access some data store (registry, SQL database, file system) and populate a Property or some table inside the MSI for later processes to act on.  These custom actions are usually a bit more complex than the internal-only custom actions because you have to think about what user context you are accessing the machine with (Local System or the installing user that is elevated or not).  Read-only custom actions also have to be robust to handle whatever circumstances they might find on a user's machine.  Basically, there are a lot more unknowns when you start to reach outside of the MSI database and the code often has more dependencies that can fail.

3. System modification custom actions.  This class of custom actions is by far the most complex custom action to write.  These are the custom actions that go out and change some state on the machine.  They do all kinds of things from creating registry keys (bad, use the Registry table) to writing ACLs (yeah, I know the LockPermissions table sucks) to updating the IIS metabase (that's what the standard WiX IIS CustomActions do) to talking to SQL Server (WiX SQL CustomActions can do much of that) to changing any other number of bits on the user's machine.  System modification custom actions are difficult because they not only have to consider the context they are operating in, they usually have to be deferred (which is a fascinating set of future topics).  On top of that, system modification custom actions need to think about what they do to the machine when installing, uninstalling, repairing, patching and rolling back all of those operations.  Needless to say, designing, developing and testing system modification custom actions is a very onerous process.  I dread having to write a custom action that modifies the system state.

Anyway, that's the three major classifications of custom actions that I typically consider.  There are probably different ways to split the classifications.  For example, launching a program at the end of the install is something that I would consider a read-only custom action or a system modification custom action depending on whether the launched application modifies system state.  In any case, these buckets tend to capture most of the concerns I immediately think about when the need for a custom action arises.

We'll talk about custom actions more later.  Eventually, I'll even get around to writing code or dissecting existing custom action code.

 

SDD before TDD?

David Aiken has an interesting blog post about adopting TDD (Test Driven Development, for those of you have been living in a cave) for his next project.  In said blog post, David suggests that before even writing tests that one should write the setup logic:

First,  I'm adopting a TDD approach. So you would think my first piece of code was a test. WRONG! My first piece of code is the installer!

Installer? - there is nothing to install. Correct. But there is still an installer project, which compiles and builds and installs pretty much nothing. (It actually installs a DLL from the 1st project - the DLL contains an empty class otherwise you cannot build an installer). I've decided to use WIX as the installer technology (the same as we used for DinnerNow)

David's line of thinking goes right along with my philosophy that setup should be integrated directly into the development process.  Maybe we should call this process of writing the setup project up front SDD for Setup Driven Development.  <smile/>

The same way that TDD encourages the development of code that can be better unit tested, SDD would encourage the development of code that can be better deployed.  I argue quite often that many of the problems developers face in setup were caused by poor design or implementation decisions early in the development lifecycle.  Setup Driven Development would flush out deployment complications as soon as they were introduced into the application.  Seeing the deployment issues right away better enables the developer to make a decision to address the issue by writing complex setup logic or by simplify the application's deployment needs.  I would often encourage the latter.

Hmm, maybe this Setup Driven Deployment idea isn't so crazy after all...