I am in the process of reinstalling all of the applications after reinstalling my development workstation. I had envisioned using the Business Desktop Deployment 2007 accelerator, but I got too impatient. With hopes of getting towards an automated rebuild at some point I am approaching application installations by trying to execute them in an unattended fashion. This means writing up Install.cmd files for each application with the appropriate switches and post-install actions to make the result the way I want (e.g. get rid of unnecessary shortcuts, pre-configure certain options). Throughout this process I am continuously amazed at how little progress we, as an industry, have made at converging on a standard way of installing and uninstalling applications. When I first saw the work of the Windows Installer team many years ago I rejoiced in the fact that a standard might emerge. To that point InstallShield seem to dominate and their tools were, at best, buggy (I can't comment on the present day as it has been a while since I've seen them). As I work through the list of applications today, all pretty common sets, I am noticing a variety in how things work. While a lot of applications have moved towards Windows Installer, some of them have done really crazy things to them.
Take, for instance, the Microsoft ISA Server Firewall Client. They have baked the MS_FWC.MSI file name somewhere in the Windows Installer Packager which prevents me from renaming it. All I want to do is rename it to something with a version number.
Another example of questionable behaviour is the Save as PDF/XPS add-on for Office 2007. The Office team did a great job at building a unified installer for their core application, taking care to bake the customization tools in to the setup. But when it came to the add-ons it seems to have fallen flat. Office 2007 has a folder called Updates where I can place patches that will get automatically installed. You would think that would apply to add-ons as well? Sorry, that isn't the case. Instead they have chosen to build their own setup package, which while it is an MSI, has files not compressed in with the MSI. There are several DLLs hanging around externally from the MSI which means the most compact way to keep it around is to leave it in the inconsistently implemented self-extracting package.
The Silverlight Player faces similar challenges where they don't expose a compact MSI file that can be easily distributed. Instead they expose a /silent parameter on the executable. How are we supposed to gain penetration in corporate environments if it's a weird installation. What happened to the push for AD-based deployments? It seems like Microsoft is self-defeating in some cases.
Where are the Designed for Windows guidelines when you need them? It seems like there are some points missing that should be there for all future releases. If I were writing the guidelines there are four points that I would add as requirements:
- Installation packages have to use the Windows Installer technology
- Patches have to use the Windows Installer patch technology
- Installation options should be exposed through Windows Installer properties and/or transform files
- Silent/unattended installations have to be supported
Hopefully we will see some progress with Windows Installer 4.5. The right thing to do is to make it mandatory that all Microsoft products ship using the best practices. Have the folks who run the download center on microsoft.com be the gate to ensure that it is supported. Make it easy for developers internally by templating installations and funding WiX development.