我试图在 C# Windows 窗体应用程序 (Visual Studio 2005) 中运行一些单元测试，但出现以下错误：
System.IO.FileLoadException：无法加载文件或程序集“Utility，Version=1.2.0.200，Culture=neutral，PublicKeyToken=764d581291d764f7”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。 （HRESULT 异常：0x80131040）**
在 x.Foo.FooGO()
位于 Foo.cs 中的 x.Foo.Foo2(String groupName_)：第 123 行
位于 FooTests.cs 中的 x.Foo.UnitTests.FooTests.TestFoo()：第 98 行**
System.IO.FileLoadException：无法加载文件或程序集“Utility，Version=1.2.0.203，Culture=neutral，PublicKeyToken=764d581291d764f7”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。 （HRESULT 异常：0x80131040）
我查看了我的参考文献，我只引用了 Utility version 1.2.0.203 （另一个是旧的）。
关于如何找出试图引用此 DLL 文件的旧版本的内容，有什么建议吗？
此外，我认为我的硬盘上根本没有这个旧程序集。
有没有任何工具可以搜索这个旧版本的程序集？
I am trying to run some unit tests in a C# Windows Forms application (Visual Studio 2005), and I get the following error:
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)**
at x.Foo.FooGO()
at x.Foo.Foo2(String groupName_) in Foo.cs:line 123
at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I look in my references, and I only have a reference to Utility version 1.2.0.203 (the other one is old).
Any suggestions on how I figure out what is trying to reference this old version of this DLL file?
Besides, I don't think I even have this old assembly on my hard drive.
Is there any tool to search for this old versioned assembly?
发布评论
评论（30）
.NET 程序集加载程序：
该程序集与所请求的内容不匹配，因此您会收到此错误。
简而言之，它找不到引用的程序集。通过将其放入 GAC 或应用程序路径中，确保它可以找到正确的程序集。
运行以下命令将程序集 dll 文件添加到 GAC：
另请参阅 https://learn.microsoft.com/archive/blogs/junfeng/the- located- assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the- assembly-参考。
The .NET Assembly loader:
This assembly does not match what was requested and therefore you get this error.
In simple words, it can't find the assembly that was referenced. Make sure it can find the right assembly by putting it in the GAC or in the application path.
run below command to add the assembly dll file to GAC:
Also see https://learn.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference.
您可以采取一些措施来解决此问题。首先，使用 Windows 文件搜索在硬盘驱动器中搜索程序集 (.dll)。获得结果列表后，请执行“查看”->“选择详细信息...”，然后检查“文件版本”。这将在结果列表中显示版本号，以便您可以查看旧版本可能来自哪里。
另外，就像 Lars 所说，检查您的 GAC 以查看其中列出的版本。 这篇 Microsoft 文章指出，在 GAC 中找到的程序集在构建过程中不会在本地复制，因此您可能需要在重建全部之前删除旧版本。 （请参阅我对这个问题的回答，了解有关创建批处理文件的说明 。
如果您仍然无法弄清楚旧版本的来源，您可以使用 Visual Studio 附带的 fuslogvw.exe 应用程序来获取有关绑定失败的更多信息 Microsoft 在此处提供了有关此工具的信息。请注意，您必须通过将
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog注册表项设置为 1 来启用日志记录。You can do a couple of things to troubleshoot this issue. First, use Windows file search to search your hard drive for your assembly (.dll). Once you have a list of results, do View->Choose Details... and then check "File Version". This will display the version number in the list of results, so you can see where the old version might be coming from.
Also, like Lars said, check your GAC to see what version is listed there. This Microsoft article states that assemblies found in the GAC are not copied locally during a build, so you might need to remove the old version before doing a rebuild all. (See my answer to this question for notes on creating a batch file to do this for you)
If you still can't figure out where the old version is coming from, you can use the fuslogvw.exe application that ships with Visual Studio to get more information about the binding failures. Microsoft has information about this tool here. Note that you'll have to enable logging by setting the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogregistry key to 1.我现在就要让大家大吃一惊。 。 。
从 .config 文件中删除所有
I am going to blow everyone's mind right now . . .
Delete all the
<assemblyBinding>references from your .config file, and then run this command from the NuGet Package Manager console:我自己也遇到了这个问题，我发现这个问题与其他人遇到的问题有所不同。
我的主项目引用了两个 DLL：CompanyClasses.dll 和 CompanyControls.dll。我收到一个运行时错误：
问题是，我的系统上没有任何版本号为 1.4.1 的 CompanyClasses.dll 文件。 GAC 中没有，应用程序文件夹中没有……任何地方都没有。我搜索了整个硬盘。我拥有的所有 CompanyClasses.dll 文件都是 1.4.2。
我发现真正的问题是 CompanyControls.dll 引用了 CompanyClasses.dll 的 1.4.1 版本。我刚刚重新编译了 CompanyControls.dll（在引用 CompanyClasses.dll 1.4.2 后），这个错误就消失了。
I just ran into this problem myself, and I found that the issue was something different than what the others have run into.
I had two DLLs that my main project was referencing: CompanyClasses.dll and CompanyControls.dll. I was getting a run-time error saying:
Trouble was, I didn't have any CompanyClasses.dll files on my system with a version number of 1.4.1. None in the GAC, none in the app folders...none anywhere. I searched my entire hard drive. All the CompanyClasses.dll files I had were 1.4.2.
The real problem, I found, was that CompanyControls.dll referenced version 1.4.1 of CompanyClasses.dll. I just recompiled CompanyControls.dll (after having it reference CompanyClasses.dll 1.4.2) and this error went away for me.
以下将任何程序集版本重定向到版本 3.1.0.0。我们有一个脚本将始终更新 App.config 中的此引用，因此我们永远不必再次处理此问题。
通过反射，您可以获取程序集 publicKeyToken 并从 .dll 文件本身生成此块。
请注意，如果没有 XML 命名空间属性 (xmlns)，这将无法工作。
The following redirects any assembly version to version 3.1.0.0. We have a script that will always update this reference in the App.config so we never have to deal with this issue again.
Through reflection you can get the assembly publicKeyToken and generate this block from the .dll file itself.
Note that without an XML namespace attribute (xmlns) this will not work.
如果您使用的是 Visual Studio，请尝试“干净的解决方案”，然后重建您的项目。
If you are using Visual Studio, try "clean solution" and then rebuild your project.
其他答案对我不起作用。如果您不关心版本，而只想运行应用程序，则右键单击引用并将“特定版本”设置为 false...这对我有用。
The other answers wouldn't work for me. If you don't care about the version and you just want your app to run then right click on the reference and set 'specific version' to false...This worked for me.
就我而言，此错误是在运行 ASP.NET 应用程序时发生的。
解决方案是：
清理不起作用，重建不起作用，所有引用都很好，但事实并非如此t 编写其中一个库。删除这些目录后，一切正常。
In my case, this error occurred while running an ASP.NET application.
The solution was to:
objandbinfolders in the project folderClean didn't work, rebuild didn't work, all references were fine, but it wasn't writing one of the libraries. After deleting those directories, everything worked perfectly.
我添加了一个 NuGet 包，却发现我的应用程序的黑盒部分引用了旧版本的库。
我删除了该软件包并引用了旧版本的静态 DLL 文件，但 web.config 文件从未从： 更新
为卸载该软件包时应恢复到的内容：
I added a NuGet package, only to realize a black-box portion of my application was referencing an older version of the library.
I removed the package and referenced the older version's static DLL file, but the web.config file was never updated from:
to what it should have reverted to when I uninstalled the package:
我刚刚遇到这个问题，问题是我的应用程序调试目录中有 .dll 的旧副本。您可能还想检查那里（而不是 GAC）以查看是否看到它。
I just ran across this issue and the problem was I had an old copy of the .dll in my application debug directory. You might want to also check there (instead of the GAC) to see if you see it.
您可能在 assemblyBinding 中拥有错误的块版本，请尝试：
Is possible you have a wrong nugget versions in assemblyBinding try:
就我而言，它是 C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ 目录中旧版本的 DLL。您可以删除或替换旧版本，也可以删除并添加回项目中对 DLL 的引用。基本上，无论哪种方式都会创建一个指向临时 ASP.NET 文件的新指针。
In my case it was an old version of the DLL in C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ directory. You can either delete or replace the old version, or you can remove and add back the reference to the DLL in your project. Basically, either way will create a new pointer to the temporary ASP.NET Files.
我想补充一点，我正在创建一个基本的 ASP.NET MVC 4 项目，并通过 NuGet 添加了 DotNetOpenAuth.AspNet。在我引用 Microsoft.Web.WebPages.OAuth 的不匹配 DLL 文件后，这导致了相同的错误。
为了解决这个问题，我做了一个
Update-Package并清理了解决方案以进行完全重建。这对我有用，是一种懒惰的方式，但时间就是金钱:-P
I would like to just add that I was creating a basic ASP.NET MVC 4 project and added DotNetOpenAuth.AspNet via NuGet. This resulted in the same error after I referenced a mismatching DLL file for Microsoft.Web.WebPages.OAuth.
To fix it I did a
Update-Packageand cleaned the solution for a full rebuild.That worked for me and is kind of a lazy way, but time is money:-P
对我们来说，问题是由其他原因引起的。 DevExpress 组件的许可证文件包括两行，其中一行用于未安装在该特定计算机上的旧版本组件。从许可证文件中删除旧版本解决了该问题。
令人烦恼的是，错误消息没有指出导致问题的引用。
For us, the problem was caused by something else. The license file for the DevExpress components included two lines, one for an old version of the components that was not installed on this particular computer. Removing the older version from the license file solved the issue.
The annoying part is that the error message gave no indication to what reference was causing the problems.
如果您尝试使用反射进行后期绑定，并且您要绑定的程序集具有强名称或其公钥标记已更改，则会引发完全相同的错误。即使实际上没有找到任何具有指定公钥令牌的程序集，错误也是相同的。
您需要添加正确的公钥令牌（可以在 dll 上使用 sn -T 获取它）来解决错误。希望这有帮助。
This exact same error is thrown if you try to late bind using reflection, if the assembly you are binding to gets strong-named or has its public-key token changed. The error is the same even though there is not actually any assembly found with the specified public key token.
You need to add the correct public key token (you can get it using sn -T on the dll) to resolve the error. Hope this helps.
我在 Team Foundation Server 的构建服务上构建时遇到此错误。事实证明，我的解决方案中有多个项目使用通过 NuGet 添加的同一库的不同版本。我使用 NuGet 删除了所有旧版本，并添加了新版本作为所有人的参考。
Team Foundation Server 将所有 DLL 文件放在一个目录中，当然同一时间只能有一个特定名称的 DLL 文件。
I got this error while building on Team Foundation Server's build-service. It turned out I had multiple projects in my solution using different versions of the same library added with NuGet. I removed all old versions with NuGet and added the new one as reference for all.
Team Foundation Server puts all DLL files in one directory, and there can only be one DLL file of a certain name at a time of course.
我的问题是将源代码复制到新机器而不拉取任何引用的程序集。
我没有采取任何措施来修复该错误，因此我匆忙地完全删除了 BIN 目录。重建了我的源代码，从那时起它就可以工作了。
My issue was copying source code to a new machine without pulling over any of the referenced assemblies.
Nothing that I did fixed the error, so in haste, I deleted the BIN directory altogether. Rebuilt my source code, and it worked from then on out.
我的情况与内森·贝德福德的帖子非常相似，但略有不同。我的项目也以两种方式引用了更改后的 dll。 1) 直接方式和 2) 通过引用组件（类库）间接方式，该组件本身引用了已更改的 dll。现在，我的组件 (2) 的 Visual Studio 项目引用了更改后的 dll 的正确版本。然而，组件本身的版本号没有改变。因此，项目新版本的安装无法替换客户端计算机上的该组件。
最终结果：直接引用 (1) 和间接引用 (2) 指向客户端计算机上已更改 dll 的不同版本。在我的开发机器上它运行良好。
解决方案：删除应用程序；删除应用程序文件夹中的所有DLL；重新安装。就像我的情况一样简单。
Mine was a very similar situation to the post by Nathan Bedford but with a slight twist. My project too referenced the changed dll in two ways. 1) Directly and 2) Indirectly by referencing a component (class library) that itself had a reference to the changed dll. Now my Visual studio project for the component(2) referenced the correct version of the changed dll. However the version number of the compnent itself was NOT changed. And as a result the install of the new version of the project failed to replace that component on the client machine.
End result: Direct reference (1) and Indirect reference(2) were pointing to different versions of the changed dll at the client machine. On my dev machine it worked fine.
Resolution: Remove application; Delete all the DLLS from application folder; Re-install.Simple as that in my case.
在尝试了上述许多解决方案但没有解决之后，最终需要确保在 Visual Studio 的应用程序中打开“自动生成绑定重定向”。
有关启用自动绑定重定向的更多信息可以在此处找到：https:// /learn.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection
After trying many of the above solutions with no fix, it came down to making sure 'Auto-generate binding redirects' was turned on within your application in Visual Studio.
More information on enabling automatic binding redirection can be found here: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection
我会让某人从我的愚蠢中受益。我对一个完全独立的应用程序有一些依赖（我们称之为 App1）。 App1 中的 dll 被拉入我的新应用程序 (App2) 中。每当我在 APP1 中进行更新时，我都必须创建新的 dll 并将它们复制到 App2 中。出色地。 。我厌倦了在 2 个不同的 App1 版本之间进行复制和粘贴，因此我只是在 dll 中添加了一个“NEW_”前缀。
出色地。 。 。我猜测构建过程会扫描 /bin 文件夹，当它错误地匹配某些内容时，它会抛出与上面提到的相同的错误消息。我删除了我的“new_”版本，它构建得非常漂亮。
I'll let someone benefit from my shear stupidity. I have some dependencies to a completely separate application (let's call this App1). The dll's from that App1 are pulled into my new application (App2). Any time I do updates in APP1, I have to create new dll's and copy them into App2. Well. . .I got tired of copying and pasting between 2 different App1 versions, so I simply added a 'NEW_' prefix to the dll's.
Well. . . I'm guessing that the build process scans the /bin folder and when it matches something up incorrectly, it barfs with the same error message as noted above. I deleted my "new_" versions and it built just dandy.
我的 app.config 包含
npgsql。不知何故，在用户的计算机上，我的 app.exe.config 丢失了。我不确定这是一个愚蠢的用户、安装程序故障还是防病毒软件出了问题。替换文件解决了问题。
My app.config contains a
for npgsql. Somehow on the user's machine, my app.exe.config went missing. I am not sure if it was a silly user, installer glitch, or wacked out anti-virus yet. Replacing the file solved the issue.
我刚刚找到了出现此错误的另一个原因。我从特定库的所有版本中清除了 GAC，并参考与可执行文件一起部署的特定版本构建了我的项目。当我运行该项目时，在搜索新版本的库时遇到此异常。
原因是发布商政策。当我从 GAC 卸载库的版本时，我也忘记卸载发布者策略程序集，因此程序集加载器没有使用本地部署的程序集，而是在 GAC 中找到了发布者策略，该策略告诉它搜索更新的版本。
I just found another reason why to get this error. I cleaned my GAC from all versions of a specific library and built my project with reference to specific version deployed together with the executable. When I run the project I got this exception searching for a newer version of the library.
The reason was publisher policy. When I uninstalled library's versions from GAC I forgot to uninstall publisher policy assemblies as well so instead of using my locally deployed assembly the assembly loader found publisher policy in GAC which told it to search for a newer version.
对我来说，“Local.testtesttings”文件中的代码覆盖率配置“导致”了问题。我忘记更新那里引用的文件。
To me the code coverage configuration in the "Local.testtesttings" file "caused" the problem. I forgot to update the files that were referenced there.
只需删除项目 bin 文件夹的内容并重建解决方案即可解决我的问题。
Just deleting contents of your project's bin folder and rebuild the solution solved my problem.
我在运行单元测试用例时遇到了同样的问题。
该错误清楚地表明问题是：当我们尝试加载程序集时，.NET 程序集加载器尝试根据其清单数据（引用的程序集名称、公钥标记、版本）加载其引用的程序集。
要检查清单数据：
Utility, Version=1.2.0.200和Utility, Version=1.2.0.203）。实际上，引用的程序集是Utility, Version=1.2.0.203(new version)，但由于清单甚至包含Utility, Version=1.2.0.200(old version)，.NET 程序集加载器尝试查找此版本控制的 DLL 文件，但找不到，因此引发异常。要解决此问题，只需将每个项目相关程序集分别拖动到 ILDASM 窗口，然后检查哪个相关程序集保存了旧程序集版本的清单数据。只需重建此依赖程序集并将其引用回您的项目即可。
I faced the same problem while running my unit testcases.
The error clearly states the problem is: when we try to load assembly, the .NET assembly loader tries to load its referred assemblies based on its manifest data (referred assembly name, public key token, version).
To check manifest data:
Utility, Version=1.2.0.200andUtility, Version=1.2.0.203). In reality, the referred assembly isUtility, Version=1.2.0.203(new version), but since the manifest contains evenUtility, Version=1.2.0.200(old version), .NET assembly loader tries to find out this versioned DLL file, fails to find and so throws exception.To solve this, just drag each of the project dependent assemblies to the ILDASM window separately and check which dependent assembly holds the manifest data with the old assembly version. Just rebuild this dependent assembly and refer it back to your project.
清理并重建解决方案可能不会替换输出目录中的所有 dll。
我的建议是尝试将文件夹从“bin”重命名为“oldbin”或“obj”重命名为“oldobj”
，然后尝试再次构建解决方案。
如果您使用任何第三方 dll，则在成功构建后，您需要将其复制到新创建的“bin”或“obj”文件夹中。
希望这对你有用。
clean and rebuild the solution might not replace all the dll's from the output directory.
what i'll suggest is try renaming the folder from "bin" to "oldbin" or "obj" to "oldobj"
and then try build your silution again.
incase if you are using any third party dll's those you will need to copy into newly created "bin" or "obj" folder after successful build.
hope this will work for you.
此类问题的一般答案是像其他答案一样使用绑定重定向。然而，这只是问题的一部分 - 您需要知道您正在使用的程序集文件的正确版本。 Windows 属性并不总是准确，nuget 也不总是准确。
获取正确版本信息的唯一方法是分析文件本身。一种有用的工具是 dotPeek。根据我的经验，dotPeek 中列出的程序集名称始终是准确的。
例如，该文件的正确绑定如下：
Windows 资源管理器表示该文件是 4.6.26515.06，nuget 表示它是 5.0.0.0 文件。 dotPeek 说它是 4.2.1.0，这是在我们的软件中正常运行的版本。另请注意，公钥和文化很重要，dotPeek 也显示了此信息。
A general answer to this kind of issue is to use binding redirects as in other answers. However, that's only part of the problem - you need to know the correct version of the assembly file that you're using. Windows properties is not always accurate and nuget is also not always accurate.
The only way to get correct version info is to analyse the file itself. One useful tool is dotPeek. The assembly name listed in dotPeek is always accurate in my experience.
So for example, the correct binding for this file is the following:
Windows explorer says the file is 4.6.26515.06, nuget says its a 5.0.0.0 file. dotPeek says it is 4.2.1.0 and that is the version that works correctly in our software. Also note that the public key and culture are important and dotPeek also show this information.
这是我解决此问题的方法。
好的，所以在这个例子中，我的.dll肯定是2.0.5022.0（所以异常版本号是错误的）。
所以，在这个例子中，我将
用这个替换这个... ...
工作完成！
Here's my method of fixing this issue.
Okay, so in this example, my .dll is definitely 2.0.5022.0 (so the Exception version number is wrong).
So, in this example, I would replace this...
... with this...
Job done !
该问题已经有了答案，但如果同一解决方案中不同版本的 NuGet 包出现问题，您可以尝试以下操作。
打开 NuGet 包管理器，您会看到我的服务项目版本与其他版本不同。
然后更新包含旧版本包的项目。
The question has already an answer, but if the problem has occurred by NuGet package in different versions in the same solution, you can try the following.
Open NuGet Package Manager, as you see my service project version is different than others.
Then update projects that contain an old version of your package.
没有解决方案对我有用。我尝试了清理项目解决方案、删除 bin、更新包、降级包等等...两个小时后，我从带有程序集的项目中加载了默认的 App.config，并且在那里我将错误的参考版本从： 更改
为：
之后我清理了项目，再次构建它并且它起作用了。没有警告就没有问题。
No solution worked for me. I tried clean project solution, remove bin, update package, downgrade package and so on... After two hours I loaded default App.config from project with assemblies and there I changed wrong reference version from:
to:
After this I cleaned project, build it again and it worked. No warning no problem.