Hong dan cai microsoft primary interop assemblies là gì

Hãy nâng cấp lên Microsoft Edge để tận dụng các tính năng mới nhất, bản cập nhật bảo mật và hỗ trợ kỹ thuật.

Error when you build a project in Visual Studio

• Bài viết
• 01/25/2022

Trong bài viết này

This article helps you resolve the problem where you cannot build a .NET Framework-based project in Visual Studio.

Original product version: .NET Framework 4.5 Original KB number: 2956788

Symptoms

Consider the following scenario:

• You have an application that is built by using a .NET Framework 4.0-based project in Microsoft Visual Studio.
• This application has a Visual Basic 6.0 ActiveX control.
• This control references an Office primary interop assembly file. For example, an office.dll file.
• You re-target the project to the .NET Framework 4.5.x in Visual Studio.

In this scenario, when you build the project, this build program cannot load the interop assembly for the control. Additionally, you receive an error message that resembles the following:

AxImp Error: Cannot resolve dependency to assembly 'office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.

Note

This issue only occurs on the computer that has the .NET Framework 4.0, the .NET Framework 4.5 or the .NET Framework 4.5.1, and the Microsoft Office product installed.

Cause

This issue occurs because of a design change between common language runtime (CLR) 2.0 and CLR 4.0 on how the type libraries and dependencies are loaded.

The .NET Framework 4.0 needs certain assemblies to be loaded when you resolve types from a type library that references a primary interop assembly. However, that was not the case in the .NET Framework 2.0. The ActiveX importer did not change behavior between the .NET Framework 2.0 and the Framework 4.0. This design change prevents generation of the interop assemblies. Therefore, when ActiveX importer runs in Visual Studio, the importer cannot resolve and preload all references for this ActiveX control.

Workaround

To work around this issue, create the interop assemblies by using AxImp.exe. For example, the error message that is mentioned in the section indicates that the required Microsoft office assembly is version 12.0. To resolve this issue, follow these steps:

1. Find the required Office assembly in the Global Assembly Cache (GAC).
2. Select the path of the office version that is mentioned in the error message. It will be something like C:\Windows\assembly\GAC\office\12.0.0.0__71e9bce111e9429c.
3. Run the following command from the Visual Studio command prompt to generate the new interop assemblies: aximp < Name of Ocx > /out: < Interop assembly name > /rcw:
4. Add the generated interop assemblies to your Visual Studio project by using the Add References feature.

Note

If Office primary interop assembly is not installed on the computer, the AxImp.exe tool still can resolve the types without any assistance, even when it runs from the Visual Studio build process.

More information

AxImp.exe is a command-line tool and is available with the Visual Studio. This tool accepts reference assemblies as command-line arguments. Therefore, this tool can load the additional assemblies that are expected by the .NET Framework 4.0.

Hãy nâng cấp lên Microsoft Edge để tận dụng các tính năng mới nhất, bản cập nhật bảo mật và hỗ trợ kỹ thuật.

• Bài viết
• 09/15/2021

Trong bài viết này

You can create Component Object Model (COM) wrappers by using Visual Studio features or the .NET Framework tools Tlbimp.exe and Regasm.exe. Both methods generate two types of COM wrappers:

• A Runtime Callable Wrapper from a type library to run a COM object in managed code.
• A COM Callable Wrapper with the required registry settings to run a managed object in a native application.

In Visual Studio, you can add the COM wrapper as a reference to your project.

To create a runtime callable wrapper using Visual Studio

1. Open the project for your managed application.
2. On the Project menu, click Show All Files.
3. On the Project menu, click Add Reference.
4. In the Add Reference dialog box, click the COM tab, select the component you want to use, and click OK. In Solution Explorer, note that the COM component is added to the References folder in your project.

You can now write code to access the COM object. You can begin by declaring the object, such as with an Imports statement for Visual Basic or a Using statement for C#.

To create a runtime callable wrapper using .NET Framework tools

• Run the Tlbimp.exe (Type Library Importer) tool.

This tool creates an assembly that contains run-time metadata for the types defined in the original type library.

Wrap Managed Objects in a Native Application

To create a COM callable wrapper using Visual Studio

1. Create a Class Library project for the managed class that you want to run in native code. The class must have a parameterless constructor. Verify that you have a complete four-part version number for your assembly in the AssemblyInfo file. This number is required for maintaining versioning in the Windows registry. For more information about version numbers, see Assembly Versioning.
2. On the Project menu, click Properties.
3. Click the Compile tab.
4. Select the Register for COM interop check box.

When you build the project, the assembly is automatically registered for COM interop. If you are building a native application in Visual Studio, you can use the assembly by clicking Add Reference on the Project menu.

To create a COM callable wrapper using .NET Framework tools

Run the Regasm.exe (Assembly Registration Tool) tool.

This tool reads the assembly metadata and adds the necessary entries to the registry. As a result, COM clients can create .NET Framework classes transparently. You can use the assembly as if it were a native COM class.

You can run Regasm.exe on an assembly located in any directory, and then run the Gacutil.exe (Global Assembly Cache Tool) to move it to the global assembly cache. Moving the assembly does not invalidate location registry entries, because the global assembly cache is always examined if the assembly is not found elsewhere.