Systematically Releasing Objects

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

All Outlook add-ins should systematically release their references to Outlook objects when they are no longer needed. Failing to systematically release reference to Outlook objects can prevent Microsoft Office Outlook 2003 from shutting down properly.

Add-ins for Outlook 2003

When an Outlook 2003 add-in that implements the IDTExtensibility2 interface keeps references to Outlook objects, Outlook 2003 does not call the IDTExtensibility2.OnDisconnection method. The add-in does not get unloaded, and even though Outlook may not be visible, the Outlook process is still running.

To overcome this problem for add-ins written for Outlook 2003, you can follow these guidelines in your add-in code:

  • Provide the required scope, but not a scope wider than necessary, for instance variables. This allows the Common Language Runtime to garbage-collect the instance variable when the variable falls out of scope.

  • Other than the Application object, declare each Outlook object as a new variable. This practice helps to keep track of the Outlook objects you have created, so that you can systematically release them at a later time (see the next bullet point). For example, replace the following line of code:

    Set myNewFolder = myContactsFolder.Folders.Add("My New Contacts")
    
    myNewFolder = myContactsFolder.Folders.Add("My New Contacts");
    

    By declaring an extra Folders object, myFolders, as in the following code:

    Imports Outlook = Microsoft.Office.Interop.Outlook
    Dim myFolders As Outlook.Folders
    Set myFolders = myContactsFolder.Folders
    Set myNewFolder = myFolders.Add("My New Contacts")
    
    using Outlook = Microsoft.Office.Interop.Outlook;
    Outlook.Folders myFolders;
    myFolders = myContactsFolder.Folders;
    myNewFolder = myFolders.Add("My New Contacts");
    
  • Use System.Runtime.InteropServices.Marshal.ReleaseComObject to release an Outlook object when you have finished using it. This is particularly important if your add-in attempts to enumerate more than 256 Outlook items in a collection that is stored on a Microsoft Exchange Server. If you do not release these objects in a timely manner, you can reach the limit imposed by Exchange on the maximum number of items opened at any one time.

  • Set a variable to Nothing in Visual Basic (null in C#) to release the reference to the object.

For more information about this problem that affects managed add-ins written for Outlook 2003 using Visual Studio .NET, see KB 317109: Office application does not quit after automation from Visual Studio .NET client.

Add-ins for Outlook 2007

If your add-in is written for Outlook 2007, or if you use Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System to write add-ins for Outlook 2003, the shut-down problem described earlier does not apply. Outlook 2007 always calls the OnDisconnection method in an add-in, even if the add-in still has references to Outlook objects.

If you develop your add-in using Visual Studio 2005 Tools for Office or Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System Second Edition, your add-in implements the IStartup interface and uses the loader provided by Visual Studio 2005 Tools for Office or Visual Studio 2005 Tools for Office SE, AddinLoader.dll. AddinLoader.dll implements a workaround to ensure that Outlook shuts down properly even when add-ins are loaded. Visual Studio 2005 Tools for Office and Visual Studio 2005 Tools for Office SE keep track of the inspectors and explorers that are open in Outlook. It assumes that when no inspectors or explorers are open, Outlook has closed. In this case, Visual Studio Tools for Office unloads the application domains in which Visual Studio Tools for Office add-ins have been loaded and releases their references to any Outlook objects. In most cases, Outlook shuts down cleanly, unless an add-in has created an instance of Outlook without opening any inspectors or explorers. In the latter case, the add-in must release all references to Outlook objects and call Application.Quit to shut down that instance of Outlook properly. For more information about how Visual Studio 2005 Tools for Office supports unloading Outlook add-ins, see Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office.