p&p Installers in the Vista World

  • Article

Yesterday I took the plunge and installed Windows Vista RC1 and Office 2007 Beta 2 Technical Refresh. Unfortunately my notebook is over 2 years old and pretty sluggish (it gets a whopping 1.0 "Windows Experience Index" score) so I'm missing out on most of the snazzy stuff, but so far it seems to be running pretty well. The real test will be how I feel about it this time next week :-)

While there are a few very visible new things in Vista that attract lots of attention, there are a plethora of small changes everywhere you look. Hopefully most of these are changes for the better, but they may well change the way you work - whether you are an end user, or a developer. We're starting to discover this ourselves in the p&p team, as it turns out that the way we have been building installers for most of our deliverables is not necessarily Vista-friendly. Most visibly and painfully, some of our installers don't work at all unless you jump through a few hoops to get the installer to run under full elevated privileges. This is obviously something we will need to deal with in our next releases - but it may just be the tip of the iceberg.

Currently, like almost all Windows applications, our deliverables install by default to a folder under C:\Program Files. On the surface this seems logical, until you consider that a lot of what we install isn't program files at all - it's source code that is designed to be modified in Visual Studio. However other things that we install are real program files, such as tools and things that need registering like HxS documentation and binary guidance packages. Since these files are not to be messed with, Program Files is the right place to put them - and it seemed simpler to put everything in one place instead of scattering stuff across the filesystem.

However, the plot thickens with Windows Vista's new User Account Control functionality, which puts additional protection around key tasks and resources so you need administrator privileges and must explicitly grant permission for each access (even if you are already an administrator). Writing files into C:\Program Files is one such task governed by UAC - so in the brave new world you definitely don't want to be sticking source code in there unless you want to be pestered so bad you'd think you had suddenly acquired 4 children.

Another problem with the current approach (which has existed long before Vista) is that MSIs tend to get quite stroppy if you add, remove or modify things that it so carefully installed (my wife is much the same with regards to kitchen organization). As a result, you can end up with files left over after uninstallation, problems when reinstalling and seemingly random behaviors if you dare touch the Repair button.

Clearly we can do better - but figuring out what this should be has been harder than I would have expected. Here are the main options we have discussed (note all path names here are defaults, everything should of course be customizable):

  1. Install everything under a new common folder under the root drive folder (eg c:\patterns and practices) - note that UAC won't kick in here.
  2. Install “fixed” content (eg tools and HxS) under Program Files, and install customizable content (eg source code) under a new common folder under root (c:\patterns and practices)
  3. Install “fixed” content under Program Files, and install customizable content in the default VS projects folder (eg c:\Users\username\Documents\Visual Studio 2005\Projects under Vista, or c:\Documents and Settings\username\My Documents\Visual Studio 2005\Projects on XP).

There are also some variations around exactly how the customizable content gets installed and uninstalled:

  1. All content gets installed using regular MSI actions. Anything that was installed will ultimately get uninstalled, but changes may result in orphaned files
  2. All content gets installed by the MSI, but the customizable content is done with a special action so that there is no attempt to uninstall the code
  3. Only the fixed content gets installed by the MSI. Customizable content is kept in an archive and a script is provided to extract the customizable content after installation is complete. Users can extract the original source to different locations as many times as they want without having to use the installer - but we couldn't easily install Start Menu shortcuts to the code like we do today.

Just to make this even more exciting, there's one more constraint we need to add to the mix. Believe it or not, in this day of age there are still critical APIs that require that paths have no more than 255 characters. Considering that c:\Documents and Settings\username\My Documents\Visual Studio 2005\Projects is already 75 characters, and we then go on to invent deliverable names like Microsoft Enterprise Library January 2006 and assembly names like Microsoft.Practices.EnterpriseLibrary.Logging.Database.dll, we need to be very careful not to break the bank!

I'd love to hear some thoughts on this. Do any of these alternatives stand out as being the right solution? Are there any fantastic options that we haven't thought of? Have any of you needed to solve a similar problem for any of your projects?