You cannot load a .NET Framework 2.0 assembly from Visual Basic for Applications in Word 2003 and earlier versions, or in Excel 2003 and earlier versions

You have add-ins or macros that use Microsoft .NET Framework 2.0 assemblies. If you run these add-ins or macros from Microsoft Visual Basic for Applications (VBA) in Microsoft Office Word 2003 or earlier versions, or in Microsoft Office Excel 2003 or earlier versions, these assemblies do not initialize correctly. Additionally, these assemblies return an error.

For example, you may receive an error message that resembles the following:Note This issue does not occur in Microsoft Office Word 2007 or in Microsoft Office Excel 2007.

The .NET Framework 2.0 includes a lockback policy. This policy prevents the .NET Framework 2.0 common language runtime (CLR) from initializing when the .NET Framework 2.0 is hosted in either the Word process space or the Excel process space. The policy restriction limits Word and Excel from loading versions of the .NET Framework that are later than version 1.1. Therefore, the .NET Framework 2.0 assemblies cannot load.

The policy restriction was added for compatibility with Microsoft Visual Studio Tools for the Microsoft Office System (VSTO). VSTO was specifically coded to work with the .NET Framework 1.1.

Officially, executing managed code inside Word or inside Excel is discouraged unless you use a supported runtime environment that handles multiple vendor components, such as the VSTO runtime. Some vendors offer managed code components that use COM Interoperability. Therefore, these components load inside Word or inside Excel without using the VSTO runtime engine. However, these components do not run in isolation. These components can adversely affect Office abilities. We strongly suggest that you consider the effects of such use before you include these types of components in your add-in projects or in your macro projects that run in Word or in Excel.

If your custom solution must use the managed .NET Framework 2.0 components without using the VSTO runtime, consider one of the following options to reduce the effect of the lockback policy.

Clients that are running Microsoft Office 2003

VSTO 2003 was introduced to add managed code support in Office 2003. VSTO was designed to use the .NET Framework 1.1. Later, Microsoft introduced the .NET Framework 2.0. However, the .NET Framework 2.0 can cause compatibility issues with VSTO 2003. Therefore, the .NET Framework 2.0 CLR was prevented from loading in Word or in Excel unless those Office products had an updated version of the VSTO runtime engine. That update was provided to Office 2003 clients in a downloadable update. The update was included in the Office 2003 Service Pack 3 (SP3) update.

For more information about how to obtain this update for Office 2003, click the following article number to view the article in the Microsoft Knowledge Base:

Clients that are running Office 2000 or Office XP

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: Microsoft does not provide a managed runtime for Microsoft Office 2000 or for Microsoft Office XP (2002). Therefore, Microsoft does not offer an update to these clients. Without a host runtime to enforce component isolation, components that different vendors produce can interfere with other components. These components can cause problems for the client. These components can also cause application instability or runtime errors. Therefore, Microsoft discourages using managed code in Office 2000 or in Office XP. Be careful when you try to introduce managed code into these Office versions. These Office versions were designed and tested before the .NET Framework was created.

If you have a solution that must use managed code in Word 2000, in Word 2002, in Excel 2000, or in Excel 2002, you can manually configure the client system to bypass the lockback policy and to enable the .NET Framework 2.0 CLR to load those versions. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate and then right-click the following registry key:
   HKEY_CLASSES_ROOT\Interface
3. Point to New, and then click Key.
4. Enter {000C0601-0000-0000-C000-000000000046} as the name for the new registry key.
5. In the right side, double-click the default registry entry, enter Word/Excel .NET Framework 2.0 Lockback Bypass Key in the Value data box, and then click OK.
6. Close Registry Editor.

Note Setting this bypass key can cause compatibility problems for solutions that are designed by using VSTO 2003. As long as this client remains on Office 2000 or on Office XP, this should not be a problem. However, if the client upgrades to Office 2003, the client must install the full update that was mentioned earlier to be supported by Microsoft. It becomes your responsibility to make sure that this configuration is correct if you manually set this bypass key.

This behavior is by design.

A note to developers

Developers who build add-in solutions or macro solutions for Word or for Excel must be aware of the limitations of including managed components in their solution. Try to use native components when you can. Additionally, consider targeting your solution to versions of Office that run the VSTO 2005 runtime, the VSTO 2005 SE runtime, or the VSTO 2008 runtime. If your solution must use managed components that COM Interoperability exposes, you should consider wrapping those components in a native host. The native host provides assembly isolation and garbage collection so that your solution does not interfere with other managed components in the same host process space.

For more information about how to make a COM shim for managed code, click the following article number to view the article in the Microsoft Knowledge Base: If your solution is designed to use VSTO 2005, and you must ensure compatibility with un-patched Office 2003 clients, Microsoft offers a setup prerequisite package that you can include in your project setup. This prerequisite package includes everything that you must have to correctly configure the client even if the client is not running Office 2003 SP3.

For more information about how this setup option for VSTO 2005, click the following article number to view the article in the Microsoft Knowledge Base:

For more information, visit the following Microsoft Web site: