Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Custom actions that should be standard actions

Custom actions that should be standard actions

  • Comments 16

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:

  1. Install kernel mode drivers
  2. Add/remove a line from a text file that is not in INI file format (such as a .NET Framework .config file)
  3. Create user accounts
  4. Change ACLs (since the LockPermissions table does not honor existing ACL’s)
  5. Create a virtual directories in IIS
  6. Create web sites in IIS
  7. Create SQL server databases
  8. List SQL server databases
  9. Create SQL server user accounts
  10. Validate PIDKEY values
  11. To display billboards
  12. 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)
  13. Post data to an HTTP server to post information to a organization's web server to record user registration information or other data
  14. Set ALLUSERSPROFILE and USERPROFILE variables in different operating systems
  15. Install a Plug and Play device driver (http://www.installshield.com/news/newsletter/0312-articles/plug.asp?ISCS12NL=16702602)
  16. 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:

  1. Marking folders as hidden (and not just files)
  2. Create user groups
  3. NGEN (pre-JIT) .NET Framework assemblies
  4. Perfomance counter registration
  5. 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!

  • I find myself writing code to read a setting from an INI file that is not in the Windows folder, and update a property based on that; this is particularly frequent when updating legacy components.

    Just my two bits...

Page 2 of 2 (16 items) 12
Leave a Comment
  • Please add 8 and 4 and type the answer here:
  • Post