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