Writing .NET Code for Outlook: VB.NET, C# samples
Writing code using VB.NET and C# (and other .NET languages) requires attention to some issues not faced by VBA and VBScript programmers.
To pick up best practices and avoid common mistakes, read this series of articles by Matt Staehle, who works on Microsoft's Messaging Developer Support Team, on working with the Outlook object model in .NET languages:
Shutdown and memory issues
Because of the way .NET languages release objects, a common problem is that Outlook does not shut down after hosting a .NET add-in or being accessed by an external .NET application. (VSTO applications are less affected by this shutdown issue than "shared" add-ins or external applications.) Memory issues can also require you to release objects aggressively and force the .NET garbage collector to clean them up. For example, you likely will run out of RPC handles if you are iterating large numbers of items on an Exchange server. See:
This object release issue can also affect what happens when you make changes to an individual item and then access that item again later in the session. Unless the item has been fully released, the changes made earlier may be ignored.
Event handler issues
The other side of the object release issue is that if you write code so that the .NET garbage collector releases an object when you don't expect it, any event handler attached to that object stops working. The usual solution is to declare the object at the class level. See:
C# samples by Helmut Obertanner:
Additional C# samples:
For building Outlook add-ins with .NET languages, two different approaches are possible. One is the traditional COM add-in using the shared or IDTExtensibilty2 architecture. If you are creating add-ins exclusively for Outlook 2003 or Outlook 2007, consider using Visual Studio 2005 Tools for Office instead.
Also note that writing server side code in ASP.NET using the Outlook object model is unsupported. Outlook is not suitable for automation by server-side code. Any Outlook automation code should be handled in client-side Jscript or VBScript.
Handling multiple Outlook versions
There are no simple solutions to the issue of building a .NET solution that works with multiple versions of Outlook. These articles review the issues and suggest possible approaches:
If you want to be able to trust an add-in so with respect to Outlook security, you'll need to create a shim, which also has other benefits. See:
PIAs (primary interop assemblies)
Programming with the Outlook object model in .NET languages makes use of COM interop. A key component is the primary interop assembly (PIA) for Outlook, as well as the one for Office. Starting in Outlook 2003, PIAs are included with Outlook. For earlier versions, you must download or build the PIAs. See:
Add-in Express for Office and .net -- All-in-one platform for efficient development of Outlook plug-ins that work for all versions, from Outlook 2000 to Outlook 2010, both x86 and x64, with a single code base.
Add-in Express for Office and VCL -- Visual RAD toolkit for developing version-independent plug-ins for Outlook 2000 - 2010 in Delphi 5 - 2010.
OutlookCode.com .NET forum -- discuss issues related to writing Outlook code in VB.NET and C#
OUTLOOK-DEV discussion list