PRB: Macro Warning Occurs in an Office Application When You Load a .NET Add-In

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:

• When the add-in is loaded in an Office application, if the Macro Security setting is set to High, the add-in may be disabled or silently unloaded (or both) without a prompt.
• When the add-in is loaded in an Office application, if the Macro Security setting is set to Medium, you may receive the following warning message:
  <path>\Mscoree.dll contains macros.
  
  Macros may contain Viruses. It is always safe to disable macros, but if the macros are legitimate, you might lose some functionality.
  In this warning dialog box, you can either click Enable Macros or Disable Macros.

The problem applies to all Office applications but may not occur, depending on other options that the user selects for a particular application, or if the Macro Security setting is set to Low.

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.

This 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.

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: 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.

For 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: