The located assembly's manifest definition does not match the assembly reference
我尝试在C Windows窗体应用程序(Visual Studio 2005)中运行一些单元测试，但得到以下错误：
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)
我看了一下我的参考文献，我只参考了
有没有关于如何找出引用这个旧版本的dll文件的方法的建议？
此外，我想我的硬盘上甚至没有这个旧的程序集。有没有工具可以搜索这个旧版本的程序集？
.NET程序集加载程序找不到1.2.0.203，但找到了1.2.0.200。此程序集与请求的不匹配，因此会出现此错误。简单来说，它找不到引用的程序集。通过将它放入GAC或应用程序路径，确保它可以找到正确的程序集。另请参阅http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx。
您可以做一些事情来解决这个问题。首先，使用Windows文件搜索搜索硬盘中的程序集(.dll)。一旦您有了一个结果列表，请执行查看->选择详细信息…然后检查"文件版本"。这将在结果列表中显示版本号，以便您可以看到旧版本的来源。
同样，正如拉尔斯所说，检查你的GAC，看看那里列出了什么版本。此Microsoft文章指出，在GAC中找到的程序集在生成期间不会在本地复制，因此在执行全部重新生成之前，可能需要删除旧版本。(有关创建批处理文件为您执行此操作的说明，请参阅我对此问题的回答)
如果仍然无法确定旧版本的来源，可以使用Visual Studio附带的fuslogvw.exe应用程序获取有关绑定失败的更多信息。Microsoft在此提供有关此工具的信息。注意，您必须通过将
我自己也遇到了这个问题，我发现这个问题与其他人遇到的问题不同。
我的主要项目引用了两个DLL：companyclasses.dll和companycontrols.dll。我收到一个运行时错误消息说：
Could not load file or assembly
'CompanyClasses, Version=1.4.1.0,
Culture=neutral,
PublicKeyToken=045746ba8544160c' or
one of its dependencies. The located
assembly's manifest definition does
not match the assembly reference
问题是，我的系统中没有版本号为1.4.1的companycasses.dll文件。GAC中没有，应用程序文件夹中没有…任何地方都没有。我搜索了整个硬盘。我所有的companycasses.dll文件都是1.4.2。
我发现，真正的问题是companycontrols.dll引用了companycasses.dll的1.4.1版本。我只是重新编译companycontrols.dll(在它引用companyclasses.dll 1.4.2之后)，这个错误对我来说已经消失了。
下面将所有程序集版本重定向到3.1.0.0版本。我们有一个脚本会在app.config中始终更新此引用，因此我们不再需要再处理此问题。
通过反射，您可以获取程序集publickeytoken并从.dll文件本身生成此块。
1 2 3 4 5 | <dependentAssembly> <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" /> </dependentAssembly> </assemblyBinding> |
请注意，如果没有XML命名空间属性(xmlns)，这将不起作用。
如果您使用的是Visual Studio，请尝试"清理解决方案"，然后重新生成项目。
其他的答案对我不起作用。如果你不关心版本，只想让你的应用运行，然后右键点击引用，将"特定版本"设置为假…这对我很有效。
我刚刚遇到这个问题，问题是我的应用程序调试目录中有一个.dll的旧副本。您可能还需要检查那里(而不是GAC)以查看是否看到它。
我添加了一个nuget包，结果发现我的应用程序的黑匣子部分引用了库的一个旧版本。
我删除了包并引用了旧版本的静态dll文件，但web.config文件从未从以下位置更新：
1 2 3 4 | <dependentAssembly> <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" /> </dependentAssembly> |
当我卸载包时，它应该还原为：
1 2 3 4 | <dependentAssembly> <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" /> </dependentAssembly> |
在我的例子中，它是C:windowsmicrosoft.netframework~ emporary asp.net filesdirectory中的旧版本的dll。您可以删除或替换旧版本，也可以删除并添加对项目中dll的引用。基本上，任何一种方法都将创建指向临时ASP.NET文件的新指针。
在我的示例中，此错误是在运行ASP.NET应用程序时发生的。解决办法是：
Clean不起作用，Rebuild不起作用，所有引用都很好，但它不是在编写一个库。删除这些目录后，一切工作都很顺利。
我现在要把每个人的思想都打乱了。…
从.config文件中删除所有
1 | Get-Project -All | Add-BindingRedirect |
对我们来说，这个问题是由别的东西引起的。devexpress组件的许可证文件包括两行，一行用于此特定计算机上未安装的旧版本组件。从许可证文件中删除旧版本解决了该问题。
令人恼火的部分是，错误消息没有指出是什么引用导致了问题。
我的情况与内森·贝德福德的那篇文章非常相似，但有点扭曲。我的项目也以两种方式引用了更改后的dll。1)直接引用和2)间接引用组件(类库)，该组件本身引用了更改后的dll。现在，组件(2)的Visual Studio项目引用了更改后的dll的正确版本。但是，组件本身的版本号没有更改。因此，安装新版本的项目未能在客户端计算机上替换该组件。
最终结果：直接引用(1)和间接引用(2)指向客户端计算机上更改的dll的不同版本。在我的开发机器上，它工作得很好。
解决方法：删除应用程序；从应用程序文件夹中删除所有DLL；重新安装。与我的情况一样简单。
如果尝试使用反射延迟绑定，或者绑定到的程序集具有强名称或更改了其公钥标记，则会引发完全相同的错误。即使没有使用指定的公钥标记找到任何程序集，错误也是相同的。
您需要添加正确的公钥令牌(可以使用dll上的sn-t获取它)来解决错误。希望这有帮助。
我的问题是将源代码复制到一台新机器上，而不将任何引用的程序集拖过来。
我所做的一切都没有纠正错误，所以我匆忙地删除了bin目录。重新构建了我的源代码，从那时起它就开始工作了。
我的app.config包含
1 | <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/> |
对于NPGSQL。不知怎么的，在用户的计算机上，我的app.exe.config丢失了。我不确定这是一个愚蠢的用户，安装故障，还是搞糟了反病毒。替换文件解决了问题。
我想补充一点，我正在创建一个基本的ASP.NET MVC 4项目，并通过nuget添加了dotNetOpenAUTH.asp net。在我引用了与Microsoft.Web.WebPages.OAuth不匹配的dll文件后，这导致了相同的错误。
为了修复它，我做了一个
这对我很有用，而且是一种懒惰的方式，但时间就是金钱。-p
我会让别人从我的剪式愚蠢中获益。我对一个完全独立的应用程序有一些依赖性(让我们称之为App1)。来自该app1的dll被拉入我的新应用程序(app2)。每当我在app1中进行更新时，我必须创建新的dll并将其复制到app2中。好。…我厌倦了在两个不同的APP1版本之间复制和粘贴，所以我只是在DLL中添加了一个"new_uu"前缀。
好。…我猜想构建过程会扫描/bin文件夹，当它不正确地匹配某个内容时，它会以上面提到的相同错误消息出错。我删除了我的"新版本"，它只是建立了花花公子。
在Team Foundation Server的构建服务上构建时，我得到了这个错误。结果发现，我的解决方案中有多个项目使用了同一个库的不同版本，并添加了nuget。我删除了所有有nuget的旧版本，并添加了新版本作为所有版本的参考。
Team Foundation Server将所有DLL文件放在一个目录中，并且在某个时间只能有一个特定名称的DLL文件。
对我来说，"local.testtestings"文件中的代码覆盖率配置导致了"问题"。我忘了更新那里引用的文件。
我刚刚找到了另一个为什么会出现这个错误的原因。我从特定库的所有版本中清除了GAC，并参考与可执行文件一起部署的特定版本构建了我的项目。当我运行这个项目时，我得到了这个异常，搜索库的新版本。
原因是发布者策略。当我从GAC中卸载库的版本时，我也忘记了卸载发布者策略程序集，所以程序集加载程序没有使用本地部署的程序集，而是在GAC中找到了发布者策略，GAC告诉它搜索较新的版本。
清除并重新生成解决方案可能无法替换输出目录中的所有dll。
我建议将文件夹从"bin"重命名为"oldbin"或"obj"重命名为"oldobj"。
然后再次尝试建立你的意识。
如果您使用的是任何第三方DLL，则在成功构建后，需要将其复制到新创建的"bin"或"obj"文件夹中。
希望这对你有用。
只需删除项目的bin文件夹的内容并重新生成解决方案就解决了我的问题。
这是我解决这个问题的方法。
好的，在这个例子中，my.dll绝对是2.0.5022.0(所以异常版本号是错误的)。
所以，在这个例子中，我将替换这个…
1 | <Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" /> |
…用这个…
1 | <Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" /> |
工作完成了！
如果您遇到类似"定位的程序集的清单定义与程序集引用不匹配"这样的错误，并且您已通过VS中的"项目>管理nuget包和更新"选项卡进行了更新，那么首先可以尝试在检查nuget gallery页中的版本并运行以下com之后安装该程序包的另一个版本。来自包管理器控制台的命令：
1 2 3 | PM> Install-Package YourPackageName -Version YourVersionNumber //Example PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0 |
虽然答案与讨论中的包没有直接关系，而且是被问到的，但它是一种通用的，仍然相关，希望它能帮助人。
在我的例子中，问题出在椅子和键盘之间：—)
1 2 3 4 | Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) |
两个或多个不同的程序集希望使用不同版本的DotNetOpenAuth库，这不是问题。此外，在我的本地计算机上，nuget会自动更新web.config：
1 2 3 4 5 6 7 8 | <dependentAssembly> <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" /> </dependentAssembly> <dependentAssembly> <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" /> </dependentAssembly> |
然后我意识到我忘记了将新web.config复制/部署到生产服务器。因此，如果您有手动部署web.config的方法，请检查它是否已更新。如果生产服务器的web.config完全不同，则必须在使用nuget之后同步合并这些dependentassembly部分。
我也犯了同样的错误…在我的案例中，解决方法如下：
- 最初安装应用程序时，这里的人在应用程序中使用了Microsoft Enterprise Library 4.1。
- 在前一周，我的机器在今天构建该应用程序之后被格式化，然后它给了我一个错误，即企业库程序集丢失。
- 然后我安装了微软企业图书馆5.0，作为第一个搜索条目，我在谷歌上找到了它。
- 然后，当我构建应用程序时，它给了我上面的错误，即定位的程序集的清单定义与程序集引用不匹配。
- 经过大量的搜索工作和分析，我发现应用程序引用的是4.1.0.0&bin文件夹中的dll是5.0.0.0版本
- 然后我安装了Microsoft Enterprise Library 4.1。
- 删除了上一个引用(5.0)，并添加了4.0引用。
- 构建了应用程序&voila…它起作用了。
从文件夹位置手动删除旧程序集，然后添加对新程序集的引用可能会有所帮助。
在我的单元测试项目中，同样的错误出现在我的面前，导致了一些失败的测试。我仔细检查了我在程序集资源管理器中使用的程序集的版本，并检查了运行时/DependentAssembly标记的内容，发现我使用的程序集的另一个版本仍在那里被引用。因为这是我的测试项目app.config中唯一的指令，所以我只是尝试删除整个app.config文件，重新构建解决方案，然后就成功了！我没有其他引用错误：)
在这篇文章中提到过类似的问题"关于如何找出引用这个旧版本的dll文件的方法有什么建议吗？"
需要哪个程序集仍然引用旧的OData客户机6.15.0，ILDASM帮助我缩小范围(没有基本代码访问，只有通过服务器上部署的pkg)。
下面的屏幕截图用于快速总结。
developerPackage如果没有ildasm.exehttps://www.microsoft.com/net/download/visual-studio-sdks
我的问题是有旧的dll的dployed在新的版本中被删除。为了解决这个问题，我只选中了这个框，在发布时删除目的地的其他文件。删除目标中的其他文件
问题已经有答案，但如果同一解决方案中不同版本的nuget包出现问题，可以尝试以下操作。
打开nuget包管理器，您会发现我的服务项目版本与其他版本不同。
然后更新包含旧版本包的项目。
好的，再来一个答案。我以前创建的应用程序是64位的，并相应地更改了输出路径(project/properties/build/output/output path)。最近我将应用程序改为32位(x86)，创建了一个新的输出路径。我创建了一个指向编译后的.exe的快捷方式。不管我对源做了什么更改，它都会得到清单不匹配错误。经过大约一个小时的挫折，我碰巧检查了.exe文件的日期/时间，发现它是旧的，显然引用了旧的.dll文件。我正在将应用程序编译到旧的目录中，而我的快捷方式引用的是新的。将输出路径更改为.exe应到达的位置，运行快捷方式，错误消失。(拍打前额)
在assemblyinfo.cs文件中的assemblyversion中，使用固定版本号而不是指定*。*将更改每次编译的版本号。在我的例子中，这就是这个例外的问题。
如果同时使用带有assemblyversion标记的assemblyinfo.cs和具有不同值的.csproj文件，也会发生这种情况。通过匹配assemblyinfo或同时删除部分，问题就消失了。
我在尝试更新网站的一个dll文件时遇到了类似的问题。
当我简单地通过ftp将这个dll文件复制到bin文件夹中时，发生了这个错误。
我通过以下方式解决了这个问题：
在运行单元测试用例时，我遇到了同样的问题。
错误清楚地说明了问题是：当我们尝试加载程序集时，.NET程序集加载程序尝试基于其清单数据(引用的程序集名称、公钥标记、版本)加载其引用的程序集。
要检查清单数据：
要解决这个问题，只需分别将每个依赖项目的程序集拖到ildasm窗口，并检查哪个依赖程序集保存旧程序集版本的清单数据。只需重新构建这个依赖程序集并将其引用回您的项目。
我在开始使用InstallShield之后遇到了这个问题。尽管建造顺序表明安装工程是最后一个，但它的建造是不正常的。
我通过让其他项目依赖它来纠正这个问题——这迫使安装在最后进行，从而消除了我的装配不匹配。我希望这有帮助。
我得到的是：
Could not load file or assembly 'XXX-new' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
因为我把大会的名称从以东十一〔1〕改为以东十一〔2〕。将名称还原为原始名称修复了错误。
我在使用内部包存储库时遇到了这个问题。我已将主包添加到内部存储库，但没有添加包的依赖项。确保将所有依赖项、依赖项的依赖项、递归等添加到内部存储库中。
我今天也遇到了同样的问题，在修改实体框架之后，我无法执行添加迁移。
我的解决方案中有两个项目，我们称它们为"客户机"和"数据"，这是一个类库项目，包含了我的EF模型和上下文。客户端引用了数据项目。
我已经签署了两个项目，然后对一个EF模型进行了更改。删除签名后，我可以添加迁移，然后可以重新签署项目。
我希望这对某些人有用，避免他们长期受挫。
由于引用的程序集与我正在生成的程序集同名，我收到了此错误消息。
这已编译，但它用当前项目程序集覆盖引用的程序集-因此导致错误。
为了修复它，我更改了项目的名称，并通过右键单击项目并选择"属性"来更改可用的程序集属性。
右键单击vs中的引用，将"特定版本"属性设置为true。
尝试将缺少的内容添加到全局程序集缓存中。