Outlook 2002 COM add-ins are not trusted if they are created in Visual Studio .NET

Article translations Article translations
Article ID: 322027 - View products that this article applies to.
This article was previously published under Q322027
This article has been archived. It is offered "as is" and will no longer be updated.
Expand all | Collapse all

Symptoms

If you use Visual Studio .NET to develop an Outlook 2002 Component Object Model (COM) add-in, and then you try to register the add-in in the Outlook Security Settings folder, one of the following symptoms may occur:
  • If you register the DLL that you created, the COM add-in is not trusted. -or-

  • If you register Mscoree.dll, all of the Outlook COM add-ins that you developed using Visual Studio .NET are trusted.

Cause

This problem occurs because COM add-ins that are developed by using Visual Studio .NET do not generate a typical COM DLL for the COM add-in. Instead, a .NET DLL, or assembly, is generated. This .NET DLL interacts with the Microsoft universal runtime file (Mscoree.dll).

The Mscoree.dll file acts as a COM wrapper for the .NET assemblies. If you trust the COM add-in with respect to the Outlook Security Settings public folder on the Exchange computer, and you trust the actual COM add-in DLL (assembly), the add-in is not trusted. You have to trust the actual in-process implementation of the add-in assembly, which is Mscoree.dll. However, if you trust this DLL, all of the COM add-ins that you used Visual Studio .NET to develop are trusted.

Resolution

To resolve this problem, create an unmanaged proxy DLL that acts as a proxy shim to the universal runtime file implementation of your managed COM add-in DLL. Make sure that the InprocServer32 value points to your proxy DLL, instead of the Mscoree.dll file. Then you can trust the shim DLL in the Outlook Security Settings public folder.

For additional information about how to create a proxy or shim file to trust COM add-ins, view the following Microsoft MSDN Web sites:
Deployment of Managed COM Add-Ins in Office XP

Using the COM Add-in Shim Solution to Deploy Managed COM Add-ins in Office XP

Workaround

To work around this problem, use one of the following methods:
  • Use Microsoft Visual Basic version 5.0 or Microsoft Visual Basic version 6.0 to create the COM add-in. -or-

  • Do not trust the COM add-in in the Outlook Security Settings folder. Use user-level security settings instead. Note that this method may increase the risk to users, which you may not want to do.

References

For more information about Outlook 2002 security features, click the following article number to view the article in the Microsoft Knowledge Base:
290500 Description of the developer-related e-mail security features in Outlook 2002
For additional information about customizing the security settings and registering trusted COM add-ins in the Outlook Security Settings folder, click the article number below to view the article in the Microsoft Knowledge Base:
290499 OL2002: Administrator Information About E-Mail Security Features

Properties

Article ID: 322027 - Last Review: October 26, 2013 - Revision: 3.0
Applies to
  • Microsoft Outlook 2002 Standard Edition
  • Microsoft Visual Studio .NET 2002 Enterprise Architect
  • Microsoft Visual Studio .NET 2002 Enterprise Developer
Keywords: 
kbnosurvey kbarchive kbdll kbaddin kbprb KB322027

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com