Outlook Shutdown and VSTO Add-ins
Just back from Amsterdam. My TechEd talk on VSTO Outlook Add-in Support was the usual curate's egg. Some people liked it, and welcomed the technical detail. Others - curiously for a 'technical education' conference, felt that it was _too_ technical and complained that I hadn't cracked enough jokes. Oh well, takes all sorts I suppose <sigh>. Anyway, continuing the theme, some more technical details follow...
Under some circumstances, when Outlook is hosting COM add-ins, Outlook doesn’t shut down cleanly - the add-in’s OnDisconnection method doesn’t get called if the add-in has outstanding variables that are still holding Outlook objects. This is effectively a deadlock: the add-in will keep holding references until it gets an OnDisconnection call, but Outlook never makes the OnDisconnection call because the add-in is still holding references. This is a problem with traditional IDTExtensibility2 add-ins, and we have addressed the problem with VSTO IStartup add-ins.
The VSTO AddinLoader.dll and the VSTO runtime itself are very largely host-agnostic. That is, they consist almost entirely of functionality that is generic and can be re-used across multiple host applications. The only application-specific functionality in AddinLoader.dll is a workaround for the Outlook shutdown problem.
AddinLoader listens to Outlook’s Explorer.Close, Inspector.Close and Application.Quit events. When there are no Explorers/Inspectors open or when Application.Quit is raised, it calls the Shutdown method on the IStartup add-in, and then unloads the AppDomain thereby cleaning up the references that are making Outlook not shut down cleanly. This covers the vast majority of Outlook add-ins.
However, there is another problem with Outlook’s shutdown behavior. Outlook is often automated externally without showing any UI. For example, ActiveSync does this. In this situation, the count of Explorers and Inspectors starts at zero, so it may never go above zero, but even if it does, when it returns to zero it is no longer safe to assume that this indicates that Outlook is shutting down. To further complicate the issue, Outlook may start without UI through automation, but then the user may interactively launch Outlook – which merely makes the current running instance of Outlook show its UI.
To mitigate (but not completely fix) these problems, we keep track of add-ins that want to load, and support a ‘dormant’ add-in state where the add-in is not loaded but we are aware that it might need to be loaded. This is the behavior:
1. Outlook starts (with or without UI).
2. AddinLoader is loaded for each add-in.
3. If (UI is present), we load the add-in, and proceed normally.
4. Else (UI is not present), we don't load the add-in, but we remember that this add-in tried to load. That is, we put the add-in into the ‘dormant’ state. The unmanaged AddinLoader component itself remains loaded, but no managed code is loaded yet, and no AppDomain is created yet.
5. Each instance of AddinLoader sinks the NewExplorer and NewInspector events. These will fire when Outlook shows any UI. When we get a NewExplorer/NewInspector event, we load the 'dormant' add-in, and proceed normally.
6. AddinLoader also sinks the ExplorerClose and InspectorClose events. These fire when Outlook windows are closing. When we get one of these events, if the count of Explorers and Inspectors is zero (meaning that there is no UI), we unload the add-in, again returning it to the ‘dormant’ state (so that we can load it again later, if required).
7. When we unload the add-in, we also tear down the AppDomain – in fact, this is how we unload the add-in assembly itself.
This ‘dormant state’ functionality extends our shutdown support to cover an additional category of add-ins that cannot function without UI.