Link with information about Windows Installer custom action guidelines

Heath Stewart has posted an item on his blog that I wanted to link to here so that hopefully more setup developers will find it.  The post, located at https://blogs.msdn.com/heaths/archive/2007/04/20/custom-action-guidelines.aspx, provides a set of high-level guidelines for creating custom actions if you find that they are necessary for your MSI-based setup.

Included in these guidelines are items such as the following:

• Schedule custom actions that change machine state as deferred custom actions.  This is important in order to be able to correctly support rollback, plus it is necessary to avoid UAC elevation issues as I described in this blog post
• Architect custom actions to be driven by custom MSI tables
• Limit the dependencies needed for custom actions (such as managed code or script)
• Provide rich logging to make it easier to debug custom action failures

If you are a setup developer working with custom actions in an MSI-based setup, I encourage you to take a look at Heath's post for more detailed information about guidelines for creating custom actions.

Comments

• Anonymous
  April 23, 2007
  Well if MSI is going to be stuck in early 1990's thinking, maybe it's time to stop using the SDK.

• Anonymous
  April 23, 2007
  Hi Christopher - I'm not sure how these guidelines qualify as early 1990's thinking, so could you please clarify your statement?

• Anonymous
  April 24, 2007
  The Windows API has evolved over many iterations over many years.  While there are have been many stops along the way, the three basic technologies are:

1. Win32
2. COM
3. .NET Basically when making such statements to exclude the use of COM and .NET ( ala activescript is evil, managed code is evil, all dependencies are bad ) you are telling everyone to throw away 10+ years worth of progress and roll their own everything using the lowest level API and language possible.   This is early 1990's thinking.   Windows Installer really should spend the energy to create bulletproof hosting models for COM and Managed Code Classes to facilitate the modern development languages. I have no interest poking around in C++ using 15 year old API's because someone at Microsoft is afraid of dependencies.   I fully expect the SDK to provide a story for implementing an interface on a class and wiring it up as a custom action.  Beyond that I expect a built-in interop layer that presents MSI session information to my code so that I can easily write fully transactional datadriven custom action patterns using modern languages and frameworks.

• Anonymous
  April 24, 2007
  Hi Christopher - Thanks for the clarifying post, I understand better the point you're trying to make now.  I think Rob addressed this on some level in his blog post at http://www.robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx.  This is at least in part a strategic investment decision on the part of the Windows Installer team.  Given finite resources, they would prefer to invest in eliminating the need for custom actions in more cases as opposed to making it easier (and therefore more highly encouraged) to create custom actions in the first place.  This is based on data that they've gathered over the years about the root causes of setup failures, etc.  That being said, of course there will always be cases where custom actions are needed. In general though, I'm not sure I agree with your assessment about dependencies and setup.  I don't think it is fair to simply say that someone at Microsoft is afraid of dependencies.  This is something that should be in the mind of all developers as they work on their applications and setups, and should not be adopted lightly. For example, I would almost always choose to have a setup that minimizes the dependencies it needs to get itself installed compared to a setup that requires more dependencies in order to be able to install because in my experience, the more possible points of fragility, the more often the setup is going to fail, which causes more support calls, more tricky debugging (that can end up crossing the boundary into the dependency itself as opposed to being a bug in your custom action code), etc.

• Anonymous
  April 25, 2007
  The comment has been removed

• Anonymous
  November 11, 2010
  The comment has been removed

• Anonymous
  November 12, 2010
  Hi Holiday Packages in India - Rob's blog post at www.robmensching.com/.../Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx outlines some of the issues that can be faced when using managed code in custom actions.  That post was written in 2007 though, and there has been some work done to address these issues since then.  You can find more information in the follow-up blog post at robmensching.com/.../Deployment-Tools-Foundation-joins-the-WiX-toolset.aspx.