I went through Ryan’s MSDN article, where we can learn how Microsoft Office Outlook 2007 Service Pack 2 has changed the way that the Outlook process shuts down. Customers developing Outlook solutions that run outside of the Outlook process should understand these changes and the impact on their solutions.
Prior to Outlook 2007 SP2, Outlook followed the best practices for Component Object Model (COM) servers and allowed clients of the Outlook COM server to control the shutdown of the Outlook process. This caused a significant end-user side effect: often the end user could not close Outlook because of lingering external references from Outlook.
As a result of customer feedback about the need to close Outlook and have Outlook stop running, Outlook 2007 SP 2 changes the way Outlook closes, ensuring that the intent of the end user─to close Outlook─is respected. These changes significantly affect the way that the Outlook COM server shuts down, which can impact solutions using the Outlook object model outside of the Outlook process.
Impact for Add-ins
If your solution is an in-process COM add-in, or if you used Microsoft Visual Studio Tools for Office to write an add-in for Outlook, this change does not affect the way that Outlook and your add-in work together. The lifetime of in-process add-ins and in-process COM references to Outlook objects in Outlook 2007 is the same as the lifetime of the Outlook process. When the user closes the last Outlook window and Outlook starts to close, Outlook disconnects add-ins and releases all of their references to Outlook.
Add-ins can use the Quit event on the Application object to determine when Outlook closes down. After Outlook raises the Quit event, the OnDisconnection method of the IDTExtensibility2 interface of the add-in or the Shutdown method of the ThisAddin class of the Visual Studio Tools for Office add-in will be called, the add-in will be unloaded, and Outlook will close.
Impact for Solutions
In versions of Outlook earlier than Outlook 2007 SP2, before Outlook closed, Outlook would check for external, out-of-process references on its COM server and wait for those references to be released. This allowed out-of-process solutions that depended on Outlook data to keep Outlook running until the references were released. This is a common behavior for COM servers; however, this is unexpected behavior for end users, who expect that an application will close when they close the last window of the application.
By default, Outlook 2007 SP2 ignores external COM references when determining if it should close. When an end user closes the last Outlook window on the user’s computer, Outlook starts closing down the process: first raising the Quit event on the Application object, then disconnecting add-ins and external references, followed by flushing internal caches to disk, and finally exiting its process.
Because of the way COM works, when Outlook releases external references, these referenced objects become disconnected objects in cross-process solutions. Without being aware that previously referenced objects have been disconnected by Outlook, a solution that attempts to use any of these object references will receive an error, RPC_E_DISCONNECTED. Solutions that are not designed to handle this error may stop responding or respond unexpectedly. This occurs when a solution attempts to use an object reference to Outlook after Outlook has closed and disconnected all previous references to the object.
To work properly with the new behavior in Outlook, a solution should listen for the Quit event on the Application object. When that event is raised, the solution should stop any work in progress that uses Outlook data, and release all references to Outlook. Any remaining references after the solution returns from the Quit event will be disconnected. The solution should no longer use any of these disconnected references since any operation will result in an error. If the solution subsequently needs to access data from Outlook, it can request a new instance of the Application object by using the CoCreateInstance function, which will start Outlook without any user interface as described below. However, this should be avoided because the end user has closed Outlook.
Note: The solution should be aware of the Windows shut-down events, and should not attempt to invoke a new instance of Outlook if Outlook is shutting down because Windows is shutting down.
While a solution is handling the Quit event, Outlook can appear to have stopped responding to the end user and the operating system. The end user may forcibly terminate Outlook instead of waiting for it to finish closing. Therefore, the solution should handle and return from the Quit event as quickly as possible.
As a result of this change, solutions may work differently on Outlook 2007 SP2. Solutions providers may need to update their solutions so that they work properly with the new behavior in Outlook 2007 SP2.
Le Café Central de DeVa - Deva Blogs!! 