所在的程序集的清单定义与程序集引用C＃Dll地狱不匹配

本文介绍了所在的程序集的清单定义与程序集引用C＃Dll地狱不匹配的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 我在一个大型项目中，我在这里。我有一个dll补丁，我试图放入大会，以便我可以覆盖项目中的建立的dll。我将.dll添加到StartProject并替换现有的。但是我收到以下错误，我不知道为什么会这样。我已经尝试将特定版本更改为False，并且每个dll的运行时版本看起来都相同。这个dll和其他dll之间的属性的唯一区别是使用一个名为SpecificVersion的选项 - 但是这样做也被设置为false。

失败的处理：System.IO.FileLoadException：无法加载文件或程序集 XXX.XXX.XXX，Version = XXXX，Culture = neutral，PublicKeyTok en = 5353c9f66d4ed1ec'或其一个依赖项。找到的程序集的清单定义与程序集引用不匹配。 （来自HRESULT的异常：0x80 131040）文件名：XXX.XXX.XXX，版本= XXXX，文化=中立，P ublicKeyToken = xxxxxxxxxxxxxxx $ XXX $ XXX。 XXX.XXX.XXX.XXX.XX（.....）

我在看fuslogvw失败输出绑定，我得到以下。对不起，重新修复。

===预绑定状态信息=== 日志：用户= X LOG：DisplayName = DataObjects，Version = 0.4.1060.0，Culture = neutral，PublicKeyToken = 5353c9f66d4ed1ec （完全指定）日志：Appbase = file：// X / lib / LOG：Initial PrivatePath = NULL 日志：Dynamic Base = NULL 日志：Cache Base = NULL 日志：AppName = Program.exe 调用程序集：Storage，Version = 1.0 .0.0，Culture = neutral，PublicKeyToken = null。 === 日志：此绑定在默认加载上下文中启动。 日志：使用应用程序配置文件：配置日志：使用主机配置文件：日志：从C：\Windows\Microsoft.NET\Framework64\v4使用机器配置文件.0.30319\config\machine.config。 LOG：Post-policy reference：DataObjects，Version = 0.4.1060.0，Culture = neutral，PublicKeyToken = 5353c9f66d4ed1ec 日志：GAC查找失败。 日志：尝试下载新的URL文件：///X/DataObjects.DLL。 日志：装配下载成功。尝试设置文件：X\DataObjects.dll 日志：输入源代码设置阶段。 日志：汇编名称是：DataObjects，Version = 1.0.0.0，Culture = neutral，PublicKeyToken = 5353c9f66d4ed1ec WRN：比较汇编名称导致不匹配：主版本 ERR：汇编引用不符合发现的汇编定义。 ERR：运行源设置阶段失败，hr = 0x80131040。 ERR：无法完成装配设置（hr = 0x80131040）。探测终止

解决方案

SpecificVersion只有在构建项目时才会起作用。在运行时，CLR坚持查找确切的匹配。换句话说，当项目最初构建时使用的引用程序集的[AssemblyVersion]必须是与运行时发现的[AssemblyVersion]的精确匹配。不匹配是非常危险的，当程序尝试执行程序中的代码，从代码测试中显着改变时，导致true DLL Hell。

所以如果你创建一个补丁然后你必须确保在AssemblyInfo.cs源代码文件中声明的[AssemblyVersion]属性与原始文件匹配。确保不要让它自动增加，使用 [1.0。*] 非常受欢迎，并将始终导致此运行时错误。

您的程序集也是强名，PublicKeyToken值也必须匹配。请确保使用相同的私钥签名。

在应用程序中使用< bindingRedirect> 元素。 exe.config文件是强制CLR接受版本不匹配的一种方式。

编辑后：是的，汇编版本中显然存在严重不匹配。该应用程序是使用DataObjects版本0.4.1060.0构建的，但发现版本1.0.0.0

I'm in dll hell here with a large project. I have a dll patch which I'm trying to put into the assembly such that I can overide the built dlls in the project. I'm adding the .dll to the StartProject and replacing the existing one, but I get the following error and I don't know why this is the case. I've tried changing the specific version to False and the runtime versions all look identical for each of the dll's. The only difference in properties between this dll and the others is the use of an option called SpecificVersion - but this is set to false anyway.

Failed processing: System.IO.FileLoadException: Could not load file or assembly XXX.XXX.XXX, Version=X.X.X.X, Culture=neutral, PublicKeyTok en=5353c9f66d4ed1ec' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80 131040) File name: 'XXX.XXX.XXX, Version=X.X.X.X, Culture=neutral, P ublicKeyToken=xxxxxxxxxxxxxxx' at XXX.XXX.XXX.XXX.XXX.XX(.....)

I'm looking at the fuslogvw failure output for binding and I get the following. Sorry for Redacting again.

=== Pre-bind state information === LOG: User = X LOG: DisplayName = DataObjects, Version=0.4.1060.0, Culture=neutral, PublicKeyToken=5353c9f66d4ed1ec (Fully-specified) LOG: Appbase = file://X/lib/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = Program.exe Calling assembly : Storage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. === LOG: This bind starts in default load context. LOG: Using application configuration file: Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Post-policy reference: DataObjects, Version=0.4.1060.0, Culture=neutral, PublicKeyToken=5353c9f66d4ed1ec LOG: GAC Lookup was unsuccessful. LOG: Attempting download of new URL file:///X/DataObjects.DLL. LOG: Assembly download was successful. Attempting setup of file: X\DataObjects.dll LOG: Entering run-from-source setup phase. LOG: Assembly Name is: DataObjects, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5353c9f66d4ed1ec WRN: Comparing the assembly name resulted in the mismatch: Major Version ERR: The assembly reference did not match the assembly definition found. ERR: Run-from-source setup phase failed with hr = 0x80131040. ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

解决方案

SpecificVersion only matters when you build your project. At runtime, the CLR insists on finding an exact match. In other words, the [AssemblyVersion] of the reference assembly that was used when the project was originally built must be an exact match with the [AssemblyVersion] it finds back at runtime. A mismatch is very dangerous, causing true DLL Hell when the program tries to execute code in the assembly that substantially changed from the code it was tested against.

So if you create a patch then you must be sure that the [AssemblyVersion] attribute as declared in the AssemblyInfo.cs source code file matches the original. Do make sure that you don't let it increment automatically, using [1.0.*] is pretty popular and will always cause this runtime error.

Your assembly is also strong-named, the PublicKeyToken value must match as well. Be sure to sign it with the same private key.

Using a <bindingRedirect> element in the app.exe.config file is a way to force the CLR to accept a version mismatch.

After edit: yes, there's clearly a gross mismatch in the assembly version. The app was built with DataObjects version 0.4.1060.0 but found version 1.0.0.0