Outlook 2002 COM add-ins are not trusted if they are created in Visual Studio .NET (322027)
The information in this article applies to:
- Microsoft Outlook 2002
- Microsoft Visual Studio .NET (2002), Enterprise Architect Edition
- Microsoft Visual Studio .NET (2002), Enterprise Developer Edition
This article was previously published under Q322027 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:
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
Modification Type: | Minor | Last Reviewed: | 3/15/2006 |
---|
Keywords: | kbDLL kbAddIn kbprb KB322027 |
---|
|