Good Practices for ActiveX Updates

One of the most important activities we do in the software industry is service our customers through software updates. Like any other binary software, ActiveX controls often need to be updated with bug fixes and new functionality. So what is the best way to get updates to our customers?

Steve, from our Silverlight team, and I were just chatting about good update practices for ActiveX controls, and we want to share them with you. Most of these practices are already in common use among ActiveX controls; we thought it would be helpful to list them all in one place.

These good practices can be broken down into three steps:

  • Add detection logic to your ActiveX control to check for updates
  • Build an update executable and launch it out of Protected Mode to install the update
  • Give end users and IT Admins the choice to make updates

1. Add detection logic to your ActiveX control to check for updates

The best way to distribute an update is to have your ActiveX control download and install it. This update process should be kicked-off by checking the server for updates when your control is loaded in IE.

As you know, designing for great performance is important, and there are a few practices worth sharing that Silverlight follows to give the user the most visually responsive experience possible. First, complete the server check on a worker thread instead of on IE’s main UI thread, where your ActiveX control gets loaded. Following the same design principle, asynchronously check for updates quickly but not immediately. You might also want to check for the latest version only once a day or once a week instead of at every time your control gets loaded in IE.

For improved performance on the server-side, it’s a good idea to have the capability to communicate with your ActiveX control to manage its requests and downloads. Specifically, your server can tell your ActiveX control to download an update immediately or “try again” later when the server is not under a heavy load.

2. Build an update executable and launch it out of Protected Mode to install the update

When IE is in Protected Mode on Windows Vista, ActiveX controls running in the IE process cannot install updates themselves. This is because IE and ActiveX controls do not have write access to most locations in the file system or registry under Protected Mode. As a result, it’s best to use a separate executable to download and install the update. You can further protect users against "man-in-the-middle" attacks by using an SSL connection to download updates. For more information on Protected Mode see the technical article Understanding and Working in Protected Mode.

Similar to the initial install process, your executable will need administrative privileges to install updates for all users on the machine.  To request administrative privileges on Windows Vista, create an application manifest for your executable with the following requested execution level:


Note that Windows Vista will see the requested execution level and display a User Account Control (UAC) dialog so the user can elevate the update executable out of Protected Mode. For more information see the section Step Six: Create and Embed an Application Manifest with Your Application in the technical article Windows Vista Application Requirements for User Account Control Compatibility

3. Give end users and IT Admins the choice to make updates

It’s a good idea to notify users when updates are available, and let them choose to install them. Notifying users gives them more control over the update experience and also gives them context for the UAC dialog that will follow if they choose to install the update.

Microsoft Silverlight Update Dialog

Following the same principle of giving users control and context, it’s not a good idea to automatically install updates or even give the user this option. Automatically installing updates doesn’t give the user control and doesn’t give them context for the UAC prompt as mentioned above.

If your ActiveX control is used in corporate environments, it is good practice to give the IT Admin a way to turn-off your update mechanism through Group Policy so that they can control update deployment. With that said, you don’t want to give end users this option because it will make their computer more vulnerable to attack.

The on/off switch for updates can be as simple as your ActiveX control reading a registry key that the IT Admin writes through Group Policy. It’s a good idea to give IT Admins an .adm file so they can easily configure Group Policy. For more information see the section How to Write a Simple .Adm File for Registry-based Group Policy in the technical article Using Administrative Template Files with Registry-Based Group Policy.

Note on checking for latest version during install

Checking the server for updates and launching an update executable are also good practices to do when your ActiveX control is being installed. The server check can be used to ensure that the latest version is being installed.

The best time to perform the server check during install in the DllRegisterServer phase. Following the above performance design principle, add a timeout to the server check and fail the install if no response is received before the timeout. In the unlikely event that the user is installing an older version of your control, you can use the update executable mentioned above to download and install the latest version.

If you would like to read more on ActiveX control best practices, check out the MSDN article on ActiveX Security: Improvements and Best Practices.

Marc Silbey
Program Manager
Internet Explorer

Steve Herndon
Lead Program Manager