Do we need a new Windows Installer?

Several years ago, one of the big complaints about windows was that there was no operating system 'approved' method of installing programs.  Linux enthusiasts of the Redhat persuasion had their RPMs, the BSDs had their 'ports' collection, and all of the unix variants supported the lowest common denominator, "make && make install".  What did windows have?  Well, we had third party solutions like InstallShield and Wise Installer (the two most popular, though there were plenty of products in the tertiary market).  Application developers learned a third party 'custom' language such as InstallScript and the many idiosyncrasies that went along with them.  (InstallScript was a quaint mix between a C style syntax, Pascal syntax, and in its later iterations, a faintly VB-esque pseudo-OO programming model. Oh, and my personal favorite: sometimes a non-zero return value meant true.  Other times it meant false.  Still other times it signified an error condition.)

I keep wandering off subject, don't I?

About the same time Windows was in search of an installer solution, Office 2000 was in development.  Office has a particular niche in the configurability arena, as it supports just about every language imaginable, with various product configurations.  Just off the top of my head, I think I recall Office (Academic), Office Professional, Office Small Business Edition, Office Premium, MSDN Office Premium, and several others that I am certain that I am forgetting.  Let's not leave out the fact that there's also each product sold separately as Word, Excel, and Access.  Multiply that by a couple dozen supported languages, and you've got yourself a configuration management nightmare.

Now add the requirement that corporate administrators must be able to configure the installation package according to business requirements, automating deployment and sometimes customizing the installed application.

Enter the Microsoft Office Installer, the basis for what was to become Windows Installer. Originally designed by the MS Office team, the Office Installer enabled the office team to fulfill complex configuration issues.  Based on its own internal proprietary database, the act of making an MSI package basically means packaging a set of file, registry, and custom action objects into a database format, and generating meta data about these objects.  This meta data is also stored in the MSI.

So - You might be asking me what the big deal is- Where is this broken?

Well, unless you are actually deploying Microsoft Office, several things:

1.  We are taking a highly procedural group of actions (Collect User Information, Validate Information, perform Pre-Installation Checks, Copy (and possibly  register) Files, perform Post Installation Checks, and finally, Uninstall application).  In all but the most extreme cases, the order of these is almost always known at installation design time. 
2.  So, we take this procedural set of actions that fit into a procedural methods (think scripting languages), and we shoehorn them into what's basically a DBMS. Because the human mind has difficulty with this mapping, we must develop tools to do this mapping for us.  Our toolsets basically re-map the DBMS into a procedural model at design time.  That's just how we think.
3.  Ok, it's deployment time - what do we do again?  An extra ice cream cone goes to anyone who said that the Windows Installer once again generates a procedural script based on user input and information in the MSI database.

So we go Procedural (Design Phase) -> Procedural & MSI - DBMS iterations (Implementation Phase) -> MSI - DBMS (Final Packaging) -> Procedural (Final Deployment).  Notice that we are only using the MSI DBMS for storage?  Any time that we actually do anything useful with the MSI, it is converted to a procedural model.

Don't think that producing an MSI is that difficult?  You're probably not doing things correctly then. Hell, the windows installer has its own SDK. If you haven't spent time with the SDK and the tools, you are probably missing something that you are 'supposed' to be doing.  Either that, or XCopy would probably pretty much work for you anyways. Does it matter that you might not be doing it correctly?  Probably not, as long as your app installs and uninstalls.

Is MSI an amazing technology?  Yes - but it's really too complicated.  It was designed for the worst case scenario, MS Office.  How many of us are developing a solution that complex?

I'm getting a headache just thinking about all of this.  No wonder we all find the dream of xcopy deployment so wonderful.  (XCopy is broken, too.  Ok, maybe not broken, but it's so limited as to be virtually useless. I'll save that rant for a different day.)

Oh - as an aside, another major architectural problem with windows installer is that it has no native multi-lingual support.  All such support is currently hacked on, er tacked on 'after the fact'.  Pretty major oversight, and one I would have least expected from the MS Office team.

I'll continue with this a bit later, but first I'd like to see what a few others have to say...  Anyone?