Using a Separate Application Domain to Avoid Crashing
Managed add-ins that implement the IDTExtensibility2 interface are loaded into the same default application domain. When an add-in in the application domain crashes, it can cause other add-ins in the same application domain to fail as well.
To work around this problem, you can create a shim for the add-in, so that the add-in can be loaded in its own application domain. A shim is an unmanaged dynamic link library written in C++. When you use a shim, you register the shim instead of the add-in. Outlook loads the shim, and the shim loads the add-in for which it was built. You must build and register a separate shim for each add-in. For more information about developing shims for managed add-ins, see Isolating Office Extensions with the COM Shim Wizard.
Another alternative to load your add-in into a separate application domain is to develop your add-in using Microsoft Office development tools in Microsoft Visual Studio 2010. Add-ins developed by Office development tools in Visual Studio 2010 do not implement the IDTExtensibility2 interface but use the IStartup interface. They use a loader provided by Office development tools in Visual Studio 2010, AddinLoader.dll, which acts like a generic shim. Outlook looks in the registry for add-ins created with Office development tools in Visual Studio 2010. If Outlook finds add-ins created with Office development tools in Visual Studio 2010, Outlook starts AddinLoader.dll, which then starts the Visual Studio Tools for Office Runtime and relays the application manifest to the Visual Studio Tools for Office Runtime. The Visual Studio Tools for Office Runtime then loads each Office development tools in Visual Studio 2010 add-in in a separate application domain. For more information about how Office development tools in Visual Studio 2010 loads an add-in, see Architecture of Application-Level Add-Ins.