Research on assembly reference mismatch 0x80131040

Time:2021-9-12

When doing plug-in programming, such a thing pops up frequentlyThe assembly manifest definition found does not match the assembly reference. (exception from HResult: 0x80131040)Often, this kind of problem is particularly difficult to solve. When one problem is solved, there will be another. We have to study how to deal with it.

Reference mismatch

Here you are prompted to load a DLL of version 4.2.0.0. First, let me see if there is a corresponding DLL under the folder and see the details of the file DLL.

The version numbers 4.6.27818.1 and 4.2.0.0 are a little too far away. Is this the problem? In fact, it is not. The version displayed here is not the same as the version of the assembly.

Assembly version

There are many versions of. Net programs, and the government has a lot of opinions on thisexplain, the version obtained through the file manager isAssemblyFileVersionThe version located by the assembly loader usesAssemblyVersion, these two things are totally different. By right clicking, we can’t see the assemblyversion. In a simpler way, we can view the assembly version through PowerShell script.

ls *.dll -r |
    ForEach-Object {
        try {
            $_ | Add-Member NoteProperty FileVersion ($_.VersionInfo.FileVersion)
            $_ | Add-Member NoteProperty AssemblyVersion (
                [Reflection.AssemblyName]::GetAssemblyName($_.FullName).Version
            )
        } catch {}
        $_
    } |
    Select-Object Name,FileVersion,AssemblyVersion

You can see that my assembly is version 4.2.0.1, not version 4.2.0.0. Therefore, the assembly cannot be loaded normally.

My own project uses nuget for package management. The referenced package version number is 4.5.3 (another version…) and the assembly version is 4.2.0.1. I searched the whole project, but I couldn’t find the reference to version 4.2.0.0 in my DLL project. I thought hard for a long time. When I dozed, I suddenly remembered whether it was the EXE problem?

Binding redirection

My main exe program is compiled using. Net framework 4.6.1, and then compiled separately. The DLL is put into a folder as a plug-in and loaded by the EXE program. It is possible that exe refers to version 4.2.0.0, or other DLL plug-ins refer to this version, resulting in version incompatibility.

There are many solutions to this situationarticleIt’s written in great detail. It’s recommended to read it. Here I use the simplest method recommended by the author, binding redirection of assembly references.

There is a premise for using this method. You need to fully understand that there will be no problems when other programs reference this program version. Generally, the change of small version number is relatively safe.

For a long time, it seems that I rarely have this problem when I write. Net framework programs because Microsoft will automatically set the programredirect, we can automatically generate binding redirection by right clicking the project and clicking.

After that, aapp.configFile, which will become when generating the programProgram name.dll.configIn the form of, it looks like this:

It can be found that this thing restricts the content of the version we refer to, and forces the version within a certain range to be redirected to a fixed version number. However, although this content already exists in the DLL, EXE will not pay attention to it. It will only look at the. Exe.config file of its main program. So what we need to do is move this part to the main program.exe.configYes.

Run again after modification, and then you will be prompted that you can’t find itSystem.Buffers.dllYes, follow the same pattern and solve the problem.

Fusion Log

Sometimes, it may not be able to solve the problem after finding and processing through this method, because the error prompt is “failed to load the file or assembly or one of its dependencies”. It may also be that there is a problem with a referenced dependency, so it is not easy to find.

Fortunately. Net provides a tool for assembly binding log, which can help us view binding problems. Generally, this thing is closed, and the system will prompt:

Warning: assembly binding logging is turned off.
To enable assembly binding failure logging, set the registry value [HKLM \ software \ Microsoft \ fusion! Enablelog] (DWORD) to 1.
Note: there are some performance penalties associated with assembly binding failure logging.
To turn off this feature, remove the registry value [HKLM \ software \ Microsoft \ fusion! Enablelog].

If debugging, you can open this registry key. Or simply use it directlyFuslogvw.exe(assembly binding log viewer), start with the administrator account, set the recorded log information in the settings, and then you can record it. For detailed usage, seehere。 You can see the detailed information, which can help us deeply analyze the problem of internal binding. (remember to turn off after use, there is performance loss.)

===Pre binding status information===
Log: displayName = system. Threading. Tasks. Extensions, version = 4.2.0.1, culture = neutral, publickeytoken = cc7b13ffcd2ddd51
 (Fully-specified)
Log: appbase= file:///C:/Temp/360zip $Temp/360$0/
Log: initial privatepath = null
Calling assembly: dependencywalker, version = 1.0.0.0, culture = neutral, publickeytoken = null.
===
Log: this binding starts with the default load context.
Log: application profile not found.
Log: use host profile: 
Log: computer configuration file using C: \ windows \ Microsoft. Net \ framework \ v4.0.30319 \ config \ machine.config.
Log: Policy post reference: system. Threading. Tasks. Extensions, version = 4.2.0.1, culture = neutral, publickeytoken = cc7b13ffcd2ddd51
Log: the same binding has occurred and failed with HR = 0x80070002.

Dependency Walker

When it comes to DLL reference, it is necessary to mention a very famous toolDependency Walker, it can check the reference of PE files, but this program has not been updated for a long time and is very unfriendly to. Net. I looked around and found several alternatives:

  1. Dependencies

This tool can be regarded as an upgraded version of dependency walker. It can view the reference information of PE files and support. Net. However, it can’t display the missing information because there is too little information.

  1. DependencyWalker.Net

This tool is specially designed for. Net. You can view the reference of assembly. I deleted several DLLs of my plug-in, and then it looks like this. It is clear at a glance and the version number is very clear.

These tools can help us find out what the DLL problem is, and may be helpful to “trying to load a program with incorrect format”, “reference mismatch” and other reference related problems.

Most of these tools deal with static references, which are generally not supported for dynamic references.

summary

Plug in programming greatly enhances the expansion ability of programs. However, when dealing with assembly references, you need to be very careful about the reference problems caused by different plug-ins. When programming, you can use different folders to isolate different plug-in DLLs, and load them through some skills (you can see the previousarticle)AndquarantineIn this way, mismatching errors can be avoided.

reference material