Freigeben über

Additional Shutdown Changes for Outlook 2010 Beta

  • Artikel

As part of Outlook 2010 and Outlook 2007 SP2, the Outlook team has taken a new and harder stance on performance. We strived to make these versions of Outlook the fastest, most performant versions released. To accomplish this, we’ve been making some significant changes to the way Outlook works across the board and in shutdown specifically. Over the course of the last year, we’ve focused on ensuring Outlook shuts down properly when the user closes the application.

Background

Outlook often has issues shutting down on command. Even when it did shutdown, it often took much longer than expected. Our goal for this release is to ensure Outlook always shuts down and put this issue to rest. With this release we want to put this issue to rest. To facilitate that, we started making a series of changes that ensure Outlook shuts down quickly and consistently.

In Outlook 2007 SP2, we added a new design to MAPI providers where we only do the minimal work necessary to prevent data loss before Outlook exits and will sidestep some of the normal shutdown logic. Outlook SP2 also prevents external COM add-ins from keeping Outlook running after the user closed Outlook. The big pain point was that all MAPI Providers had to opt-in to the design and support the new behavior because of compatibility concerns of this change in a service pack.

In Outlook 2010 Technical Preview, the design was modified so that a MAPI provider needed to opt-out of the new shutdown method. If a MAPI provider does not implement the fast shutdown API, Outlook 2010 will still shut down using the fast method.

These changes have done a lot to ensure that Outlook always shuts down and is able to shut down quickly, as the user intended. Since the technical preview release, we continued to monitor the feedback from beta testers and users to determine how effective these changes have been. Looking through the data we’ve collected, it’s become clear that there is another significant source of shutdown pain: Outlook add-ins. We found that add-ins would perform expensive operations and network I/O during shut down events. Because of that impact, we expanded our investment in improving Outlook’s shutdown behavior by creating a fast shutdown model for add-ins as well.

Add-in Shutdown Changes in Outlook 2010 Beta

Starting with the Outlook 2010 Beta, Outlook, by default, will not signal add-ins that it is shutting down. Specifically, the beta version will no longer call OnBeginShutdown and OnDisconnection methods of the IDTExtensibility2 interface when Outlook is shutting down with fast shutdown. If you have a Visual Studio Tools for Office (VSTO) add-in, you will not see the ThisAddin_Shutdown method called.

The impact to an add-in from this change depends on what the add-in was doing during these events. In most add-ins, these events are used to release references to Outlook COM objects and clean memory that was allocated during the session. In these cases, the impact to the add-in will be minimal. Outlook will release the remaining COM object references and shutdown, and Windows will reclaim the allocated memory when the process exits.

For some add-ins, the change is more impactful. If an add-in uses these events to commit data (for example, storing user settings or reporting usage to a web server) this will no longer occur. Depending on the scenario, this may or may not have a user visible impact. Add-ins will either need to be modified to be compatible with this new behavior, or an IT administrator will need to use group policy to restore the original behavior for the specific add-in.

These methods can and will be called in other scenarios, such as if the add-in is manually disconnected or if slow shutdown is enabled through group policy, so it is important that developers continue to code as though these methods would be called. More information about best practices is listed below.

Reasons for this Change

This change has a pretty significant impact and is not a change we made lightly. Looking over the data we’ve collected in the last year, it became clear we needed to do more to help shutdown faster. The data from Outlook 2007 SP2 indicated that if the user had “misbehaving” add-ins installed, the average delay to shutdown was 13 seconds. For Outlook 2010 technical preview, the data shows an average delay of 15-20 seconds.

As part of our add-in compatibility testing, we’ve examined what add-ins are doing in their shutdown/disconnect events. While a majority of add-ins are performing simple tasks like releasing references, several add-ins we’ve identified are making web service calls or other “long running” operations synchronously during these events.

The benefit of making this change is that for the majority of add-ins and customers, Outlook will work significantly better than it has in the past when shutting down. This change improves our ability to respond to the user’s intent and exit quickly, letting the user move on to the next task or shutdown their computer.

For Developers: Best Practices for Add-in Shutdown

For add-in developers, the new world of Outlook shutdown can seem a little tricky to operate in. It is important that developers follow the best practices for add-in shutdown to ensure that our shared users continue to benefit from a fast and responsible Outlook shutdown experience.

Practice #1: Continue to Release References in OnDisconnection

It is important that you continue to write code in OnDisconnection or ThisAddin_Shutdown to release any remaining COM references to Outlook objects. In Outlook 2003 and Outlook 2007 pre-SP2, these references can prevent Outlook from shutting down. Even in Outlook 2010 you should continue to release references and allocated memory in these events because there are scenarios where slow shutdown will be used or the user could manually disconnect your add-in through the COM Add-ins dialog.

Practice #2: Detecting when Outlook is shutting down

If you need to detect that Outlook is shutting down, you can use the Application.Quit event in the Outlook object model to receive a notification that the process is shutting down. You should respond quickly to this event and return control back to Outlook as quickly as possible. Add-ins should focus on not having a perceivable impact on Outlook shutdown when compared with shutdown when the add-in is not running.

If you have long running or indeterminate length running operations to perform at shutdown, consider the following questions:

  • Does this need to happen when Outlook shuts down? What happens if Outlook crashes and this code doesn’t run?
  • Can the operation be made to be “pay for play” where changes are committed when the user makes the change instead of being saved for later?
  • Can the work be done on a background thread instead of synchronously during a quit event? (Note: you cannot make OM calls from a background thread, but can use MAPI directly if properly initialized)

Explicitly, you should not do network I/O during any quit event. This includes saving data to a network share, writing data to an Outlook online-mode store, or calling web services during Application.Quit, OnBeginShutdown or OnDisconnection.

In using the Application.Quit event, you should not perform any release of Outlook COM objects or allocated memory in the Outlook process space. This will be done for you by Outlook and Windows when the process exits.

One case we’ve seen internally as we started looking at what add-ins were doing during shutdown was where an add-in was reporting usage information back to a web service in the shutdown events. Instead of recording this data directly to the web service during shutdown, we altered the code to instead report the previous session usage information on a background thread sometime during the next Outlook boot. This way the data can still be uploaded, but Outlook is never blocked by the work.

Another alternative, if you have another executable that is already part of your solution, is to move work out of the add-in and into your executable. This way the work can be done regardless of if Outlook is running, and without blocking Outlook’s ability to start up or shut down quickly.

Practice #3: Test shutdown using both the fast and old methods

As a developer, you should ensure that your add-in has a negligible impact on Outlook’s user experience. This includes testing the impact your add-in makes to Outlook’s boot time, the general user experience while using Outlook, common scenarios (like composing a new message, replying to a message, folder switch, sending mail, etc) and shut down. Specifically, developers should test the difference between the shutdown times of outlook when changing the registry settings for the add-in that control how Outlook shuts down.

For IT Administrators

If you have internal add-ins or solutions that cannot be updated to support the new design, you can deploy group policy to your users to revert the behavior. There are two methods for enabling shutdown notifications to Outlook add-ins in Outlook 2010 Beta:

  • Selectively for individual add-ins (the preferred approach): While this cannot be deployed through group policy, it can be enabled as part of add-in deployments and is useful if backwards compatibility is required for specific add-ins.
  • Globally for all add-ins: this is recommended for organizations with a large number of internal solutions or desktops that need to deploy this setting to ensure compatibility during a rollout of Outlook 2010.
Individual Add-in Setting

By using this setting Outlook will selectively provide shutdown notifications to the specified add-in without notifying all add-ins. This setting is configured per add-in through the add-in registration in either HKCU or HKLM registry hives, by adding an additional value to the add-in registration:

HKCU\Software\Microsoft\Office\Outlook\Add-ins\<ProgID>
[RequireShutdownNotification]=dword:0x1

Setting this value to 0x1 will enable the add-in to receive the blocked callbacks during Outlook shutdown. This will have an impact to the performance of Outlook shutdown that should be evaluated as part of a deployment. This setting should only be used if an add-in has significant compatibility issues with Outlook 2010’s new shutdown design.

Global Setting

This setting can be used to change the new shutdown design to match the design used by Outlook 2007. This setting can be deployed through group policy either per user or per machine.

HKCU\Policies\Microsoft\Office\Outlook\14.0\Options\Shutdown
[AddinFastShutdownBehavior]=dword:0x1

Setting AddinFastShutdownBehavior to 1 will enable shutdown notifications for all add-ins. Setting the value to 0 will use the default behavior.

These two settings provide administrators complete control over the effect this new behavior has on custom solutions and add-ins used in the enterprise. During evaluation of Outlook 2010 beta, it is important that organizations test any custom solutions using Outlook add-ins to ensure compatibility with this change.

Comments

  • Anonymous
    October 05, 2009
    These changes are good for everybody! I like how you still provided backwards compatibility, but of course left a "trail" via the registry settings so that any add-ins that rely on the old method will be exposed - for good or bad.