Application Shutdown Changes in Outlook 2007 Service Pack 2 Beta

rgregg — Mon, 27 Oct 2008 22:17:36 GMT

As part of the performance improvements we’ve made for Outlook 2007 SP2 beta, we’ve changed the way Outlook manages the lifecycle of the application. In the past, Outlook followed the best practices for Component Object Model (COM) servers and allowed clients of the Outlook server to control the lifecycle of Outlook. This caused a significant end-user side effect: often the user could not close Outlook because of lingering external references. This is confusing and frustrating for our users, and many users would often use Task Manager to terminate the Outlook process.

As a result of strong and long-standing customer feedback about the need to close Outlook and have Outlook stop running, Service Pack 2 changes the way Outlook closes, ensuring that the user’s intent to close Outlook is respected. These changes mean the way the Outlook COM server shuts down has changed significantly, which may impact solutions using the Outlook object model outside of the Outlook process.

Impact for Add-ins: None

If you’ve written an in-process add-in for Outlook this change does not affect you. The lifecycle of in-process add-ins and in-process COM references in Outlook 2007 has always been the same as the lifecycle of the application. When the user closes the last Outlook window and Outlook starts to shut down, add-ins are disconnected and references are released.

Add-ins can use the Quit event on the Application object to determine when Outlook will be closing down. After the Quit event is raised, add-ins will have their OnDisconnection method called, and then the add-in and Outlook will close.

Impact for Cross Process Solutions

Before Outlook 2007 SP2, Outlook would check for external (out of process) references on the COM Server objects and wait for those references to be released before Outlook would close. This would enable solutions that were depending on Outlook data to keep Outlook running until the references were released. This is common behavior for COM servers, but is unexpected behavior for end users, who expect that an application will close when they close the last window of the application (or at least reasonably soon after they close the last window).

Starting with Outlook 2007 Service Pack 2, Outlook will ignore external COM references when determining if Outlook should exit. When a user closes the last Outlook window, Outlook will start exiting the process: this involves raising the Quit event on the Application object, disconnect all add-ins, disconnecting external references, persisting in-memory changes to the disk, and then exiting. All external COM references will be disconnected immediately after the Quit event is raised on the Application object.

Because of the way COM works, when Outlook releases the external references, those objects become disconnected objects in cross process solutions. When a solution attempts to use the disconnected reference, an error will result from any call to the object (RPC_E_DISCONNECTED). Solutions that are not designed to handle this error may crash or otherwise misbehave. This will occur any time a solution attempts to use an object reference after Outlook has closed.

To work correctly with the new behavior in Outlook, your solution should listen for the Quit event on the Application object. When that event is raised, stop any work in progress using Outlook data, and release all Outlook references. Any remaining references after the solution returns from the Quit event will be disconnected.

While handling the Quit event, a solution should return from the event as quickly as possible. While a solution is working in the Quit event, Outlook may appear hung to the user and the operating system and the user may forcibly terminate Outlook instead of waiting for it to finish closing.

If your solution needs to access data from Outlook after the process has shutdown, it can do so by starting the process up again in UI-less mode by calling CoCreateInstance(). However, you should attempt to design your solution such that data from Outlook is only collected while Outlook is running. I’ll be blogging about an example of how to design a solution that works this way in an upcoming blog post.

Special Cases

While the text above describes the default, we realize that there are customers and solutions which will be negatively impacted by this change until the solution can be updated. To restore the old behavior, administrators can set a registry key to force Outlook to wait for all external references to be released before closing.

This registry key applies to Outlook 2007 SP2 beta, the registry key may change for the final release of SP2.

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\Shutdown]
“AllowShutdownWithExternalReferences”=dword:00000000

We’ve also done work to ensure that when a solution uses CoCreateInstance and Outlook isn’t running, the right things happen. In those cases, Outlook will remain running in “headless mode” without any visible user interface. If the user launches Outlook, a new Outlook window will appear in the same session Outlook was already using. If the user closes that window, even though the process was started by a solution, Outlook will exit in the same manner as it would if the application was started by the user.

Summary

As part of a larger overall performance improvement effort in Outlook 2007 Service Pack 2, the team has invested a significant amount of time to improve the experience around closing Outlook. We’ve also made changes to ensure that Outlook boots faster and is more responsive all around.

I’m interested in your feedback on this new shutdown logic, and any thoughts or questions about how we can continue to improve this experience in the next Outlook release. Please leave a comment on this post and let me know what you have to say.

Use the Right Events for the Right Cases

rgregg — Wed, 27 Aug 2008 21:25:00 GMT

One of the problems I often hear about from Outlook developers is that the sequencing of a particular event isn’t ideal for what they are trying to do. While sometimes this can be a hole in the Outlook platform, more often than not it’s because the developer isn’t using the best event for the scenario they are trying to build. Outlook often has multiple events that fire related to particular actions in the UI, and choosing the right event is important to ensure data consistency.

For example, recently I was helping a partner team who wanted to examine the contents of a meeting request when the user has actually sent the request. During this event, they would compare the state of the meeting in their system against the meeting that the user was sending, and fix up any inconsistencies in their database. The developer had found the AppointmentItem_Send event in the object model, and naturally presumed that was the right event to use. However, they started to notice that inconsistencies were occurring between items in Outlook and their database. Multiple-client issues aside, the problem is because of the event they used.

The Item_Send event fires when the user clicks the Send button on sendable items (Meeting requests, e-mail messages, etc). However, there are cases where the user can back out of sending the item after they click the send button. In this particular case, when a meeting is changed, the user is sometimes given a choice to send the updates to added/removed recipients, or to all recipients. If the user clicks cancel on this dialog, the send is canceled even though the Send event has fired.

To work around this issue, I instructed the developer to listen for the Application_ItemSend event instead. This event fires after the user has committed to sending the message and ensures that the recipients on the item reflect the state of the item after the inspector has been closed.

Likewise, there is a Close event on each of the item classes, as well as a Close event on the Inspector object. To ensure that you inspect the contents of the item after all edits have occurred, catching the Inspector_Close event will provide you with the best chance to see that information. After Item_Close has fired, there is still a chance the user will back out of the changes (for example, if they click No to save their changes).