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 (10)
  1. Rachit says:

    Thanks Tom for your comments on my blog. Looking forward to Vista friendly p&p installer.

    http://rachit.wordpress.com/2006/08/10/july-vista-winfx-gat-gax/#comments

    Thanks

  2. 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?

  3. Pablo Blamirez says:

    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

  4. Joe Kaplan says:

    I’m actually even more curious to see if you guys would consider putting together a binary-only MSI/MSM combo that could be used for integrating the EL binaries into other packages and install all of the instrumentation stuff.  I’d especially like to see you do it without the use of the xxxInstaller classes in VS, as they are ok for dev stuff, but are not really ok for pro installs.  I can also see those potentially causing UAC havoc on Vista boxes.

    Note that this is definitely something you could do using MSI with an authoring tool like WiX (pretty standard there in the big house), but the perf counters and WMI sinks are a bit nasty to do without the Installer class support, so this effort is non-trivial (event logs and sources translate to registry keys, so the permissions issues are the biggest consideration there; registry is bread and butter for MSI otherwise).

  5. 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.  

  6. Joe Fiorini says:

    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

  7. Austin says:

    I really like Peter Provost’s idea of having a ‘source extrator’.

  8. Doug Evans says:

    As a former MS Build Coordinator and current Software Architect (not MS anymore) I would love the ability to stick EVERYTHING into my source control.  I want to have control over every aspect of the development environment so that I can ensure everyone is using the same version of tools and code.  Having a package that can be installed to a location of my choosing and then having a batch file that can be executed on each machine to register all the components would be wonderful.  You would not believe the amount of work it took to get Visual Studio 6.0 integrated into source control, but once it was, BAM!  Everyone was the same.  Suddenly there were fewer errors due to different people having different versions or patches or frameworks or plugins.  Makes my life easier and helps ensure consistent code is getting checked in, compiled, and shipped.

  9. Most of our installers are having trouble in Vista. Among the reasons, the fact that we normally install

Comments are closed.

Skip to main content