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

View products that this article applies to.

This article was previously published under Q322027

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.

Back to the top

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.

Back to the top

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 (http://msdn.microsoft.com/en-us/library/aa164016(office.10).aspx)

Using the COM Add-in Shim Solution to Deploy Managed COM Add-ins in Office XP (http://msdn.microsoft.com/en-us/library/aa140200(office.10).aspx)

Back to the top

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.

Back to the top

REFERENCES

For more information about Outlook 2002 security features, click the following article number to view the article in the Microsoft Knowledge Base:

290500 (http://support.microsoft.com/kb/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 (http://support.microsoft.com/kb/290499/EN-US/ ) OL2002: Administrator Information About E-Mail Security Features

Back to the top