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
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.
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.
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.
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.