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):
There are also some variations around exactly how the customizable content gets installed and uninstalled:
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?
I really like Peter Provost's idea of having a 'source extrator'.
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.
Most of our installers are having trouble in Vista. Among the reasons, the fact that we normally install
PingBack from http://restaurants.247blogging.info/?p=724