I recently met a Program Manager who joined Microsoft late last year after working at InstallShield for a while. We got to talking about some of the difficulties involved in creating an MSI-based setup and the lack of solid, documented best practices and even things that would make it easier to build and test setups such as more comprehensive ICE validation test suites.
One of the interesting discussions we had was to compare lists of actions that are commonly needed in a setup that are not available as MSI standard actions and have to be implemented as custom actions. Here is his list:
- Install kernel mode drivers
- Add/remove a line from a text file that is not in INI file format (such as a .NET Framework .config file)
- Create user accounts
- Change ACLs (since the LockPermissions table does not honor existing ACL’s)
- Create a virtual directories in IIS
- Create web sites in IIS
- Create SQL server databases
- List SQL server databases
- Create SQL server user accounts
- Validate PIDKEY values
- To display billboards
- An MSI package cannot use mapped drives when an administrator installs an MSI package through a remote session to a terminal server (http://support.installshield.com/kb/view.asp?articleid=q108613)
- Post data to an HTTP server to post information to a organization’s web server to record user registration information or other data
- Set ALLUSERSPROFILE and USERPROFILE variables in different operating systems
- Install a Plug and Play device driver (http://www.installshield.com/news/newsletter/0312-articles/plug.asp?ISCS12NL=16702602)
- User profile creation when a new user logs in
In addition, he made the good point that for every custom action, a setup author has to essentially create 3 custom actions (install, rollback, uninstall) and potentially a 4th (uninstall rollback).
Of the things on this list it was interesting to see that in my experience on the Visual Studio and .NET Framework setup team, we ended up writing custom actions or equivalent code to do items 1, 2, 3, 4, 5, 6, 10, 11, 13 and 16. Also, the team is working on new custom actions for the SQL items (7, 8, 9).
In addition to the above, I would add the following to the list based on my experience:
- Marking folders as hidden (and not just files)
- Create user groups
- NGEN (pre-JIT) .NET Framework assemblies
- Perfomance counter registration
- MOF compilation
I’m curious if there are other common custom actions that folks are using that would be useful to have available as standard actions.
For .NET Framework setup developers, I would also like to know if anyone is attempting to implement NGEN functionality within your setup, and if so if you have any feedback about your experiences doing so.
Thanks in advance!