Custom actions that should be standard actions

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 (https://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 (https://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!

Comments

• Anonymous
  June 06, 2004
  The comment has been removed
• Anonymous
  June 06, 2004
  There needs to be a built-in action for installing server controls in the VS.NET toolbox, and a server control deployment project in general.
  
  Server control development is one of the most overlooked development scenarios in VS.NET. And it shouldn't be.
• Anonymous
  June 06, 2004
  The comment has been removed
• Anonymous
  June 07, 2004
  The comment has been removed
• Anonymous
  June 11, 2004
  Ah - the dreaded EULA printing functionality, I forgot about needing a CA to do that because in Visual Studio we used an external UI handler and therefore wrote Win32 code to accomplish that. This is definitely something that needs to be eventually supported by native Windows Installer UI.
  
  I also really like the idea for the future blog topic about features that we would like to see built into Windows Installer. I've got a big mental list of stuff, stay tuned as I get them down in writing and polish them.
  
  Thanks for reading!
  
  
• Anonymous
  October 01, 2005
  A simple XSL action where the stylesheet can be an embedded resource or can be an external (installed or existing) xsl file.
  
  Would also be useful to allow automatic substitution of installer properties in the stylesheet before applying the transform.
  
  This will help to deal with all sorts of xml configuration files.
  
• Anonymous
  October 12, 2005
  The comment has been removed
• Anonymous
  November 04, 2005

1. I agree with the previous comments about persistent property values and text file edits.
   2. Feature dependencies - If you wish to support user advertisement then it is often necessary to have more complicated feature dependencies than the built-in "installing child means installing parent". You will note that the Office team have included a custom table for this purpose (we normally use a custom action).
   
   We also regularly have to use custom actions for configuring security where the LockPermissions table cannot be used.
   
   Although not related to custom/standard actions, I think something needs to be done about handling MSI dependencies. Chained installs and/or requiring setup.exe does not cut it in the corporate environment !

• Anonymous
  November 04, 2005
  Steven, I think that with regards to point 16 Aaron wants the user profile setup to occur before the application icon is selected. Currently this can be hacked using ActiveSetup to do the work (either by called msiexec to initiate a user repair or by blasting the stuff in manually).
  
  Note that user repairs have to be avoided on terminal servers (only one MSI installation allowed at a time).

• Anonymous
  March 15, 2006
  "Let’s take one last example: You need to edit the hosts file. On uninstall what do you do? Remove the edit? If so, you may have caused grief with another install that requires the same change."
  
  But there is a (large?) class of installs where the file to be edited is simply deleted on uninstall. So a Standard Action to do edit a file to e.g. edit INSTALLDIR would be extremely usefull.

• Anonymous
  April 17, 2006
  I'd like to see a custom action that simply lets you create a shortcut to the virtual directory that your setup package just created. I created my own to do this, but I wish it did that for me.

• Anonymous
  May 08, 2006
  The comment has been removed

• Anonymous
  September 30, 2011
  I was looking of implementing copying files based on some condition (I my case I have to decide what kind of hardware platform it is - blade server type). This also looks like more common scenario (Copying files based on condtion).

• Anonymous
  September 30, 2011
  The comment has been removed

• Anonymous
  March 26, 2012
  The comment has been removed

• Anonymous
  March 06, 2015
  The comment has been removed

• Anonymous
  March 06, 2015
  Hi Michael - I don't believe the current version of Windows Installer supports creating that type of shortcut (msdn.microsoft.com/.../aa371847(v=vs.85).aspx).  In the past, I've written a wrapper .exe that has the requireAdministrator privilege in its manifest to accomplish this type of thing.