UAC in MSI Notes: Challenges for a Beautiful Custom Action

This is the fourteenth in a series of notes about UAC in MSI. Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team. The previous entries

1. Introduce...
   1. ...the UAC in MSI Notes series
   2. ...my view of the root problem
   3. ...the conflicting per-user definition
   4. ...it'll be just like Managed Installs
   5. ...the jagged edge to user
   6. ...my relief providing framework
2. Architecture Insights
   1. The "Saw Tooth" Diagram
   2. Credential Prompt and Permissions
3. Common Package Mistakes
   1. The AdminUser Mistake
   2. Modify System with InstallUISequence Custom Action
   3. Modify System with InstallExecuteSequence Custom Action Outside of Script
   4. The NoImpersonate Bit Mistake
4. Deeper Architecture Insights
   1. My "Four Square" Diagram

This entry will talk about insights that I use to explain to customers the UAC in MSI functionality: custom action challenges for a beautiful custom action.

Why are Custom Actions so Difficult?

When talking about UAC in MSI, customers often remark at the complexity of writing a high quality custom action relative to other code on Windows.  These customers will point to the dot net framework or the UI investments and say over time, it's much more simple to write code in other parts of the platform.  These customers are not wrong but they are also looking at the programming darlings.  There are difficult areas in the spectrum of Microsoft technologies that are difficult to work with.  Drivers and MSN services are two I'd found particularly finicky were you a programmer used working with a programming darling such as the dot net framework.

That being said, setup does present some real challenges.  First, you have to be diligent with your dependencies as lack of prerequisites can blow-up the simplest custom action.  Second, a data driven world does not directly map to a procedural programmers experience or training.  Third, more than likely the underlying stores you are trying to address during setup didn't think through the constraints the way you are going to need to.  Forth, security and robustness are an unavoidable consideration and these are programming qualities it's tough to get right.  These conditions make programming custom actions challenging.

I sometimes go into a diatribe about the perceived value of solving this problem and that most businesses do not invest but usually I just sound cranky as it's not something anyone has a magic bullet to fix.

Where's the Whitepaper with Custom Action Guidelines?

Eventually customers that are trying to understand how to write high quality custom actions ask: where's your whitepaper with Custom Action Guidelines?  Regretfully I say we don't have one.  Windows Installer development will tell you that what you need to know is in the Windows Installer SDK.  Read it carefully, follow it's guidelines, and you'll do fine.

Customers reply: how can it be that the SDK is complete if so many people are having problems writing custom actions?   If a customer has relied on one of the Windows Installer partner tools vendors, they usually have little problems.  The tools vendors have done a great job creating easy to use products that one can ramp up quickly and feel proficient in no time.  The challenge comes when they traverse from the comfortable confines of the tools vendors environment and go it alone.  Few take the time required to load all the context they need out of the SDK to step up to the challenge.

Customers then wonder: shouldn't this be a stronger concern from the Windows Installer team? We are a highly leveraged technology team.  We have about 10 engineers between dev, test, and PM on a technology that installs about 90% of the corporate ready software and above 40% of all PC software.  We have a lot of strong concerns and, yes, quality of custom actions is very high on the list.  By and large, we focus on features in the core of the technology and we rely on our partner tools vendors to take those core features to the masses.  There are a number of vendors that have made a nice little business out of tools on top of Windows Installer and we are very grateful to them for joining package developers and consumers through our technology.  If you believe you will need custom actions in your package, we advise you add a set of criteria you will use to choose your tools vendor.

A Beautiful Custom Action

Given we haven't produced definitive documentation, I will sometimes rattle through the aspects of high quality custom actions.  Given this is not engineering guidance, I'll borrow a phrase from art and call these my top tem qualities of a Beautiful Custom Action.

1. Data Driven: all the behavior in the custom action should be transparent given the a view on the data
2. Component Grouped: all the data operated on by the custom action should be grouped in a component as components are the unit of reasoning for Windows Installer.
3. Feature Selected: all the components operated on by your custom action should be connected to features that the user can select and deselect
4. Respect Existing User Choices such as Install Location: the selected features connected to the component grouping of the custom action data should respect the existing user choices.
5. Provide for User Choice: where appropriate enable the user to make choices relative to the custom action data.
6. Integrate with User Feedback: existing actions provide prerequisite checking during initialization, disk costing during feature selection, progress while action is executing, and logging of events from action.
7. Provide Developer and Administrator Guidance: standard actions make their behavior transparent for both developers that are providing the package and administrators that are using the package.
8. Data Marshaled Based Off Selections: selections are analyzed, active data is derived, and actionable data is marshaled from the database into the custom action through the CustomActionData property
9. All System Changes Occur in Transaction: all changes that occur to the system occur in the transaction such that they can be rolled back.
10. All State Transitions Have Behavior: state transitions beyond install have behavior such as uninstall, repair, admin install, advertising, patching, and patch uninstall.

The White Box Standard a beautiful custom action will make it easy to make connect the data to the behavior and integrated to the existing user touch points already used by standard actions.

Comments

• Anonymous
  September 24, 2006
  PingBack from http://blog.devinstall.com/?p=6
• Anonymous
  September 26, 2006
  Windows Vista introduces a security concept called User Account Control (UAC) which has multiple impacts