Loading Addins

All managed shared add-ins are loaded into the same application domain. This means that if one add-in crashes it could crash all your add-ins that are running. One workaround for this problem is to create a C++ shim (an unmanaged DLL), which enables you to create a separate application domain in which the add-in is loaded. You need to create a separate shim for each add-in you load. This isn't necessary with VSTO add-ins, because they use an add-in loader that acts as a generic shim. Outlook add-ins use a loader provided by VSTO called AddinLoader.dll. Outlook checks the registry for information about the add-in's application manifest and then loads the appropriate add-in from the location specified in the manifest.

The AddinLoader.dll loader starts the common language runtime and the VSTO runtime, and then it loads the assembly for the add-in. The add-in is not loaded into the default application domain; instead, each add-in is loaded into a separate application domain. Because this isolates individual add-ins, it significantly improves the stability of add-ins created with VSTO (misbehaving shared add-ins will not bring down your VSTO add-in).

0 0

Post a comment