Unable to load a .NET 2.0 Assembly from VBA in Word/Excel (2000, 2002, and 2003)
Summary
The Microsoft .NET 2.0 Framework includes a lockback policy that intentionally prevents the .NET 2.0 CLR from being initialized to run when hosted in either the Microsoft Word or Microsoft Excel process space, unless that version of Word or Excel is Office 2007. This restriction was put into place for compatibility with the Microsoft Visual Studio Tools for Office (VSTO) version 2003, which was specifically coded to work with the .NET 1.1 Framework. The policy restriction limits Word and Excel from loading versions of the .NET Framework greater than version 1.1, which thereby prevents them from being able to load .NET 2.0 assemblies. If you have addins or macros that are coded to use .NET 2.0 assemblies, and run in either Word or Excel, these components may fail to initialize properly and/or may return an error.
More Information
Officially, managed code execution inside of Microsoft Word or Microsoft Excel is discouraged unless you are using a supported runtime environment that is designed to handle multiple vendor components, such as the Visual Studio Tools for Office (VSTO) runtime. Some vendors may offer managed code components using COM Interoperability. This makes it possible for such components to load inside of Word or Excel without using the VSTO runtime engine. However, such components do not run in isolation and can negative impact Office abilities. So we strongly suggest you judge the impact of such use before including those types of components in you addin or macro projects that will run in Word or Excel.
Should your custom solution require the use of managed .NET 2.0 components without using the VSTO runtime, you can consider one of the following options to mitigate the lockback policy:
Clients running Office 2003
VSTO 2003 was introduced to add managed code support in Office 2003, and was designed to use the .NET 1.1 Framework. Later, Microsoft introduced the .NET 2.0 Framework, which could cause compatibility issues with VSTO 2003. So the decision was made to prevent the 2.0 Common Language Runtime (CLR) from loading in Word or Excel unless those Office products had an updated version of the VSTO runtime engine.
The updated runtime is normally obtained by the VSTO project setup the developer provides, but it can be obtained and installed directly using this Office 2003 update:
https://support.microsoft.com/?id=907417Note: The patch needs to be installed separately. It is not included in any Office 2003 Service Packs or Office Update downloads.
Clients running Office 2000 or Office XP (2002)
Microsoft does not provide a managed runtime for these earlier Office versions, and therefore does not offer an update to these clients. Microsoft discourages the use of managed code in these versions because without a host runtime to enforce component isolation, it is possible for components made by different vendors to interfere with other and cause problems for the client which could result in application instability or runtime errors. Microsoft recommends caution when attempting to introduce managed code into these Office versions since they were designed and tested before .NET Framework came into being.
Nonetheless, if you have an solution that demands the use of managed code in Word 2000, Word 2002, Excel 2000, or Excel 2002, you can manually configure the client system to bypass the lockback policy and allow the .NET 2.0 Framework CLR to load those versions. To do this, you can follow the steps below.
Steps to Set Word/Excel .NET 2.0 Lockback Bypass Key
1. On the target computer, start Registry Editor (regedit.exe).
2. Navigate to the following registry key: HKEY_CLASSES_ROOT\Interface
3. Right-click the Interface key and in the dropdown menu, choose New | Key.
4. Name the new subkey to be: {000C0601-0000-0000-C000-000000000046} .
5. Set the default value for this new key to: Word/Excel .NET 2.0 Lockback Bypass Key.
6. Close Registry Editor.Warning: Setting this bypass key could cause compatibility problems for solutions designed using VSTO 2003. As long as this client remains on Office 2000 or Office XP (2002), this should not be a problem. However, if the client upgrades to Office 2003, they must install the full patch mentioned above to be supported by Microsoft. It becomes your responsibility to ensure this configuration is correct if you manually set this bypass key.
A Note to Developers
Developers building addin or macro solutions for Word or Excel need to be aware of the limitation of including managed components with their solution. Try to use native components when possible, and consider targeting your solution to versions of Office capable of running with the VSTO 2005, VSTO 2005 SE, or VSTO 2008 runtimes. If your solution requires the use of managed components exposed by COM Interoperability, you should consider wrapping those components in a native host that can provide assembly isolation and garbage collection so that your solution does not interfere with other managed components that another vendor may attempt to load into the same host process space.
For more information on making a COM shim for managed code, view the following article in the Microsoft Knowledge Base:
https://support.microsoft.com/?id=830468
If your solution is designed to use VSTO 2005 and you need to ensure compatibility with un-patched Office 2003 clients, Microsoft offers a setup pre-requisite package that you can include in your project setup. This pre-requisite package includes everything needed to get the client configured correctly even if they are not running Office 2003 SP3.
For more information on how this setup option for VSTO 2005, view the following article in the Microsoft Knowledge Base:
https://support.microsoft.com/?id=908002
Comments
Anonymous
February 15, 2008
Managed code exported via COM Interop may not load correctly inside of Word or Excel VBA if the assembliesAnonymous
February 15, 2008
Managed code exported via COM Interop may not load correctly inside of Word or Excel VBA if the assemblies