dilettante
Nov 12th, 2008, 09:38 PM
Windows 7: Deploying Your Application with Windows Installer (MSI) and ClickOnce (http://channel9.msdn.com/pdc2008/PC42/) had an interesting section on the new per-user install support in Installer 5.
You can find this starting at slide 30 of the downloadable PowerPoint deck and at about 50 minutes into the multimedia capture of the presentation.
Lots of this can be done using earlier versions of Installer, such as those in XP SP2+ and Vista. However it isn't quite as graceful as the support provided in Installer 5 and of course the older packaging tools don't all support it directly.
The aim of per-user installs is to let users install a broad range of applications (though clearly not everything) without admin rights (or elevation on Vista or later OSs). Some things do need to be installed per-machine, and of course per-user installs can be wasteful on machines with multiple users.
Every user must install and then have a copy of the application. Each user must do updates or uninstalls as well. There is no shared data, etc.
However for many kinds of applications and scenarios these are not onerous limitations. The main reason we aren't comfortable with per-user installs is that there isn't a lot of software prepared for a proper per-user install. A secondary reason may be that previous versions of Installer do not support per-user vs. per-machine as a clean install-time option.
One thing that has been lacking is a predefined, approved installation location for per-user installs. Microsoft is addressing that with Windows 7 and MSI 5.
For a per-user install the hard-wired Installer Property ProgramFilesFolder will automatically be redirected to [LocalAppData]\Programs. This means if you created a package for per-mchine installs but run msiexec.exe with ALLUSERS=2 and MSIINSTALLPERUSER=1 anything you had directed to the ProgramFilesFolder will be placed in this new location.
We can (and do) the same thing today, but it requires that we either create two separate MSIs or include a Custom Action to move the files after they are in place or perhaps define a custom Property to use in the Target and run a Custom Action to set it before files are copied. All sort of messy.
Even with MSI 5 we have to worry about the impact of per-user component registration (http://blogs.msdn.com/cjacks/archive/2007/02/21/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista.aspx) for anything using COM. In some cases where you don't expect the user to ever elevate your program this may be fine. Where possible it is better to use registration-free COM instead for per-user installs though.
The good news is that Windows 7 and MSI 5 will improve things. The not-so-bad news is we can do this now (XP, 2003, Vista, 2008) as long as we're willing to get tricky or release two MSIs. Even better, we now have an "official" place to do those per-user installs instead of just dumping them under LocalAppData - which is where most programs install per-user now.
You can find this starting at slide 30 of the downloadable PowerPoint deck and at about 50 minutes into the multimedia capture of the presentation.
Lots of this can be done using earlier versions of Installer, such as those in XP SP2+ and Vista. However it isn't quite as graceful as the support provided in Installer 5 and of course the older packaging tools don't all support it directly.
The aim of per-user installs is to let users install a broad range of applications (though clearly not everything) without admin rights (or elevation on Vista or later OSs). Some things do need to be installed per-machine, and of course per-user installs can be wasteful on machines with multiple users.
Every user must install and then have a copy of the application. Each user must do updates or uninstalls as well. There is no shared data, etc.
However for many kinds of applications and scenarios these are not onerous limitations. The main reason we aren't comfortable with per-user installs is that there isn't a lot of software prepared for a proper per-user install. A secondary reason may be that previous versions of Installer do not support per-user vs. per-machine as a clean install-time option.
One thing that has been lacking is a predefined, approved installation location for per-user installs. Microsoft is addressing that with Windows 7 and MSI 5.
For a per-user install the hard-wired Installer Property ProgramFilesFolder will automatically be redirected to [LocalAppData]\Programs. This means if you created a package for per-mchine installs but run msiexec.exe with ALLUSERS=2 and MSIINSTALLPERUSER=1 anything you had directed to the ProgramFilesFolder will be placed in this new location.
We can (and do) the same thing today, but it requires that we either create two separate MSIs or include a Custom Action to move the files after they are in place or perhaps define a custom Property to use in the Target and run a Custom Action to set it before files are copied. All sort of messy.
Even with MSI 5 we have to worry about the impact of per-user component registration (http://blogs.msdn.com/cjacks/archive/2007/02/21/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista.aspx) for anything using COM. In some cases where you don't expect the user to ever elevate your program this may be fine. Where possible it is better to use registration-free COM instead for per-user installs though.
The good news is that Windows 7 and MSI 5 will improve things. The not-so-bad news is we can do this now (XP, 2003, Vista, 2008) as long as we're willing to get tricky or release two MSIs. Even better, we now have an "official" place to do those per-user installs instead of just dumping them under LocalAppData - which is where most programs install per-user now.