Shimming: A Solution to the Problems with MsCoree.dll

Despite the gloomy picture painted for COM add-ins being loaded by mscoree.dll, a solution resolves these three problems. The solution involves writing a custom CLR host DLL called a shim DLL (written in C++) to be the loader for the CLR and the COM add-in instead of relying on mscoree.dll. A new shim DLL must be created for each COM add-in you are going to deploy. Using a shim DLL leads to a number of advantages:

• Integration with the Office security system The shim DLL will now be the InProcServer32 for the COM add-in, allowing you to sign the shim and trust it on the users' machines that will guarantee that your COM add-in can load irrespective of whether Trust all installed add-ins and templates is checked. Of course, the COM add-in is only guaranteed to load if the user has trusted the certificate used to sign the custom shim DLL.

• Reliability Because the shim DLL is now the InProcServer32 for the COM add-in, if something should go wrong with that COM add-in, the Office application will block only the shim DLL corresponding to that COM add-in, leaving other managed COM add-ins unblocked.

• Isolation The shim DLL can create an AppDomain into which the COM add-in will be loaded instead of loading the COM add-in into the default AppDomain.

If you are building a managed COM add-in for Outlook 2003, consider using the new VSTO Outlook Add-in project. Building an add-in in this way resolves the problems with mscoree.dll as well as some other Outlook-specific issues with add-ins described in Chapter 24.

Microsoft has provided a Visual Studio COM add-in shim wizard project that works with Visual Studio 2003. It is available at http://msdn.microsoft.com/office/default.aspx?pull=/library/enus/dno2k3ta/html/ODC_Office_COM_Shim_Wizards.asp. At the time this book was written, no wizards were available for Visual Studio 2005. However, you can use the C++ COM shim project generated by this wizard in Visual Studio 2003 and import it into Visual Studio 2005.