Article ID: 316724 - Last Review: December 15, 2003 - Revision: 4.3 PRB: Macro Warning Occurs in an Office Application When You Load a .NET Add-InThis article was previously published under Q316724 SYMPTOMS When a Microsoft Office application loads a Component
Object Model (COM) add-in or a smart tag recognizer add-in that is created with
Visual Studio .NET, you may experience one of the following problems:
CAUSE Microsoft Office security is designed to use digital
signatures to verify the integrity of the components that it loads. When the
Macro Security setting of an application is set to
High, only digitally signed components are loaded. When the
Macro Security setting is set to Medium, you
are prompted to select whether to load unsigned add-in components. Managed languages in the Microsoft .NET Framework (such as Microsoft Visual Basic .NET and Microsoft Visual C# .NET) are loaded and are run by using the common language runtime. When your custom component is registered for COM Interop, the COM InprocServer32 key points to the common language runtime (Mscoree.dll), not your custom assembly. Because Office checks the signature of the component that is listed under the InprocServer32 key, and because Mscoree.dll is not digitally signed, you may experience the problems that are listed in the "Symptoms" section of this article. If the add-in is installed locally, and if you click to select the Trust all installed add-ins and templates check box in the Macro Security dialog box, you may not experience these problems. However, this option is not available in all Office applications and must not be considered a workaround for all users. STATUSThis
behavior is by design. However, Microsoft is investigating
options to safely identify the common language runtime and to check the digital
signature of the custom assembly in future versions of Office. MORE INFORMATION Developers who use .NET assemblies as Office add-ins can
design their packages to use a shim that is digitally signed. This can then
initialize the common language runtime and can load the assembly to execute the
code for the add-in. This adds an extra layer to the add-in design for
deployment but is the only method that offers enough security to trust the
add-in in existing versions of Office. For more information about how to create and deploy a shim for your COM add-in or smart tag add-in, visit the following Microsoft Developer Network (MSDN) Web sites:
Deployment of Managed COM Add-Ins in Office XP Because of performance and compatibility, developers may also
consider using an unmanaged language (such as Active Template Library [ATL]) to
develop COM add-ins in Visual Studio .NET. http://msdn.microsoft.com/en-us/library/aa164016(office.10).aspx (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 (http://msdn.microsoft.com/en-us/library/aa140200(office.10).aspx) Using the Smart Tag Shim Solution to Deploy Managed Smart Tags in Office XP http://msdn.microsoft.com/en-us/library/aa163615.aspx (http://msdn.microsoft.com/en-us/library/aa163615.aspx) REFERENCESFor additional information about building Office solutions by
using Visual Studio .NET, click the article number below to view the article in
the Microsoft Knowledge Base: 311452
(http://support.microsoft.com/kb/311452/EN-US/
)
INFO: Developing Microsoft Office Solutions with Visual Studio .NET
| Article Translations
|
Back to the top
