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:
Run-time error: '-2147024894' (80070002)': File or assembly name AssemblyName, or one of its dependencies, was not found.
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:
907417Â
(http://kbalertz.com/Feedback.aspx?kbNumber=907417/
)
Description of the update for
Office 2003: November 8, 2005
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:
322756Â
(http://kbalertz.com/Feedback.aspx?kbNumber=322756/
)
How to back up and restore the registry in Windows
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:
- Click Start, click Run,
type regedit, and then press ENTER.
- Locate and then right-click the following registry key:
HKEY_CLASSES_ROOT\Interface
- Point to New, and then click
Key.
- Enter {000C0601-0000-0000-C000-000000000046} as the name for the new registry
key.
- 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.
- 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:
830468Â
(http://kbalertz.com/Feedback.aspx?kbNumber=830468/
)
Managed add-ins fail or behave
unexpectedly after you install a managed COM add-in that includes a custom
application configuration file in Office 2003, in Office XP, and in Office 2000
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:
908002Â
(http://kbalertz.com/Feedback.aspx?kbNumber=908002/
)
FIX: Add-ins, smart documents, or smart tags that you create by using
Microsoft Visual Studio 2005 do not run in Office
For more information, visit the following Microsoft Web
site: