Saturday, 8. September 2007 at 6:48 am
A few questions have come in asking for a starting point for building a Windows Installer 4.5 Embedded UI.
Feature Design
As we put together the ideas behind the Embedded UI features, we aspired to provide a simple extension off the preexisting features in the Windows Installer platform.
Simple Starting Idea
When we started designing this feature, our target scenario went something like this:
An ISV has spent a lot of time building a really cool external UI for their Windows Installer based experience users have a habit of trying to invoke the .MSI file directly rather than the setup.exe bootstrapper file. Generally this ISV puts up an plain dialog “Please invoke [ProductName] from the setup.exe file next to this file.”. It wastes the users time and hurts the package’s customer satisfaction.
Over time, we added nuances to this feature but our base assumption was that the ISV was the type of ISV that was ready to invest into an external UI.
Guiding Principle: what would an external UI do?
With the simple idea that a package author just wanted to put their custom UI inside the package, most of the complexity we referenced back to our guiding principle: what would an external UI do? We even considered a “zero cost migration from external UI” requirement but it didn’t fit scenarios or the ISV persona who was already prepared to build custom code to get their custom UI experience. A little more code was acceptable as long as reuse was in reach.
Friends and Foundations
One of the other early tests we had for ourselves was whether we thought the friends of Windows Installer could use this feature with the foundations already in place. Some of our bigger ISV and Tools Vendor friends already had custom external UI handlers so we wanted the cost for them to be low to build from their foundation. For smaller or newer ISV or Tools Vendors, we scouted our documentation and samples for a viable starting point for their foundation.
A Starting Point
For an ISV without a preexisting starting point, here’s what we thought you’d could build your foundation from.
First think of DLL custom action
When custom actions are needed, DLL custom actions are the way to do. They provide the capacity for the maximum integration with our architecture, including message passing for UI and logging, ability to read the database in the session, and the ability to request being executed NoImpersonated. Further most of the tools provide some starting framework to get an ISV off the ground with a DLL custom action. For us, considering the Embedded UI handler as a specialized version of a DLL custom action allowed us to reuse our custom action sandbox as the embedded UI sandbox.
Second think of external UI message processing
Once the Embedded UI DLL has been booted, it needs to do it’s work. The next thing a UI handler will need is to process messages. Although we do not currently have a external UI sample in the Windows Installer portion of the Platform SDK, we do have some code samples in the MSDN documentation. Of these, there is sample code for MsiSetExternalUI and MsiSetExternalUIRecord. Of the messages, progress is the one that will occur most frequently so we have a sample for that. Once the progress sample is in place, the work remaining is to expand the number of case statements handled to match the list of message types from INSTALLUI_HANDLER_RECORD. These case statements will each need to decide whether further parsing is required and we’ve documented that too at Parsing Windows Installer Messages. Sometimes the message parsing is going to require communicating a message back to the Windows Installer which you can learn to do with Returning Values from an External UI Interface Handler.
Third switch to your favorite User Interface design environment
The Windows Installer UI tables are from the Wizard 97 era of UI guidelines. User Interface design has some a long way in the 10 years since and the Windows Installer UI tables have not tried to keep up all that much. The Windows Installer team has advised ISVs seriously consider building their own favorite UI when they reach the limits of the Windows Installer.
How about a sample?
Sorry, we don’t have one yet but we do have it in the list of feedback that we plan to work on after we finish the engine work itself.
[Author: Robert Flaming]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.
Original post by Windows Installer Team