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