p&p Installers in the Vista World

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?

Comments

• Anonymous
  September 15, 2006
  The comment has been removed

• Anonymous
  September 15, 2006
  I would like to elaborate on how option b can be combined with a traditional way of delivering p&p guidance and see how that rings with people.
  
  Imagine if we installed the docs, help files, guidance packages, etc. all to your C:Program Files directory. Also into Program Files we would install a source code package that encapsulates the source code for the block(s) into user installable form.
  
  By installing the master MSI onto a system, everything becomes available to all users. They can browse the docs, run guidance packages, etc. When they want to extract the source files, they can run the "Source Code Extractor" for the block(s) and then provide a place to extract that source to. For many users this might be somewhere inside their "home" directory, or it could be in a folder like Tom suggests at the root.
  
  I think that is an interesting alternative that people should be thinking about. It has lots of advantages in a Vista/Lua environment and in semi-locked down enterprise environments because people are compiling in their own profile directory and not in the Program Files dir.
  
  Thoughts?

• Anonymous
  September 16, 2006
  My 2 cents is that I definitely prefer the idea of only the fixed files going under program files with an extractor provided for the source files. I would also prefer the extractor to default to the users Projects directory
  
  Keep up the good work fellas
  

• Anonymous
  September 16, 2006
  The comment has been removed

• Anonymous
  September 16, 2006
  We have a scenario where devs work on a terminal server. Introducing a new folder in the root of any drive will be disliked. (And it will encourage other vendors to do the same). I much like the idea of the 'source extractor' (especially as msi) assuming a msi can be run by an ordinary user/dev.  

• Anonymous
  September 18, 2006
  I do not use the default location for my project files.  Instead, I changed it in my Visual Studio 2005 preferences to point to UsersJoeSoftware Development and then organize it based on the type of code (my applications, my samples/demos, other samples/demos, app source code, etc).  Therefore, I would love to see the option of specifying where to install sample source code in the installer.  It could still default to the former mentioned path, but then be overridden to anything we want (within the 255 character limit of course).
  
  -Joe

• Anonymous
  October 10, 2006
  I really like Peter Provost's idea of having a 'source extrator'.

• Anonymous
  October 23, 2006
  The comment has been removed

• Anonymous
  November 25, 2006
  Most of our installers are having trouble in Vista. Among the reasons, the fact that we normally install

• Anonymous
  December 30, 2007
  PingBack from http://restaurants.247blogging.info/?p=724