找到的程序集的清单定义与程序集引用不匹配答案

【问题标题】：The located assembly's manifest definition does not match the assembly reference找到的程序集的清单定义与程序集引用不匹配
【发布时间】：2025-11-21 21:20:05
【问题描述】：

我正在尝试在 C# Windows 窗体应用程序 (Visual Studio 2005) 中运行一些单元测试，但出现以下错误：

System.IO.FileLoadException：无法加载文件或程序集“实用程序，版本=1.2.0.200，文化=中性，PublicKeyToken=764d581291d764f7”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。（HRESULT 异常：0x80131040）**

在 x.Foo.FooGO()

在 x.Foo.Foo2(String groupName_) in Foo.cs:line 123

在 x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**

System.IO.FileLoadException：无法加载文件或程序集“实用程序，版本=1.2.0.203，文化=中性，PublicKeyToken=764d581291d764f7”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。（HRESULT 异常：0x80131040）

我查看了我的引用，我只有一个对Utility version 1.2.0.203 的引用（另一个是旧的）。

关于我如何找出试图引用此 DLL 文件的旧版本的任何建议？

此外，我认为我的硬盘上什至没有这个旧组件。有什么工具可以搜索这个旧版本的程序集吗？

【问题讨论】：

就我而言，这是因为我有两个项目加载了不同版本的同一个 DLL。（希望这对某人有所帮助！）

标签： c# reference compiler-errors dependencies version

【解决方案1】：

.NET 程序集加载器：

找不到 1.2.0.203
但确实找到了 1.2.0.200

此程序集与请求的内容不匹配，因此您收到此错误。

简单来说，就是找不到被引用的程序集。确保它可以通过将其放入 GAC 或应用程序路径中找到正确的程序集。另见https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference。

【讨论】：

但是当我查看项目的引用时，它指向 1.2.0.203 ...似乎没有任何东西指向 1.2.0.200
完全正确 - 它正在寻找 1.2.0.203，但它找到 1.2.0.200。找出该文件的位置并将其替换为正确的版本。
我在这里问了一个类似的问题并得到了一个可行的解决方案：*.com/questions/4187907/…
查看引用版本，然后在packages.config和Web.config中查看是否相同
这条消息每次都让我感到困惑。好像写反了。我希望它抱怨您要求加载的版本，而不是它找到的版本。很高兴我不是唯一一个弄错的人！

【解决方案2】：

您可以采取一些措施来解决此问题。首先，使用 Windows 文件搜索在您的硬盘驱动器中搜索您的程序集 (.dll)。获得结果列表后，执行查看->选择详细信息...，然后检查“文件版本”。这将在结果列表中显示版本号，以便您查看旧版本的来源。

另外，就像 Lars 所说，检查您的 GAC 以查看其中列出的版本。 This Microsoft article 指出，在 GAC 中找到的程序集在构建期间不会在本地复制，因此您可能需要在全部重新构建之前删除旧版本。（请参阅我对this question 的回答，了解有关为您创建批处理文件的说明）

如果您仍然无法确定旧版本的来源，您可以使用 Visual Studio 附带的 fuslogvw.exe 应用程序来获取有关绑定失败的更多信息。 Microsoft 有关于此工具的信息here。请注意，您必须通过将 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog 注册表项设置为 1 来启用日志记录。

【讨论】：

不要忘记文件版本不是程序集标识的一部分。程序集版本是，但不必与文件版本相同！
如果使用 fuslogvw 服务阅读blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx
搜索文件名解决了我的问题。我的 Temporary ASP.Net 文件夹中有一个旧版本的 dll，而 InstallShield 正在使用它而不是最新版本！清洁解决方案，重建，重新启动PC什么也没做。在本地运行良好，每次部署时都会爆炸。
刚建好后，我的网站就可以正常工作了，但是过了一会儿，这个问题就出现了。
我编辑了这个答案来改用汇编版本。

【解决方案3】：

我刚刚遇到了这个问题，问题是我的应用程序调试目录中有一个旧的 .dll 副本。您可能还想检查那里（而不是 GAC），看看您是否看到它。

【讨论】：

我们只是迁移到另一台服务器时遇到了这个问题，因为我们保留了备份。删除备份副本后工作。谢谢:)

【解决方案4】：

我自己也遇到了这个问题，我发现这个问题与其他人遇到的不同。

我的主项目引用了两个 DLL：CompanyClasses.dll 和 CompanyControls.dll。我收到一个运行时错误消息：

无法加载文件或程序集 'CompanyClasses，版本=1.4.1.0，文化=中性， PublicKeyToken=045746ba8544160c' 或它的依赖项之一。位于程序集的清单定义确实与程序集引用不匹配

问题是，我的系统上没有任何版本号为 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 之后），这个错误对我来说就消失了。

【讨论】：

+1 当我的一个 DLL 引用旧版本的 Caliburn Micro 时，我也发生了类似的事情。
我也是，你的经历启发了我去哪里寻找，我的问题得到了解决。
另一种选择是打开CompanyControls项目，右键单击CompanyClasses.dll参考 --> 属性 --> SpecificVersion = false
这在 xamarin 应用程序中很常见。我的 xamarin.forms 项目与 xamarin.droid 项目不同。我刚看到你的帖子，我认出来了。
如果 CompanyClasses.dll 已签名，那么单独使用 SpecificVersion = false 将无法解决问题。你需要一个bindingredirect。

【解决方案5】：

对我们来说，问题是由其他原因引起的。 DevExpress 组件的许可文件包括两行，一行用于未安装在此特定计算机上的旧版本组件。从许可证文件中删除旧版本解决了该问题。

令人讨厌的部分是错误消息没有指出是什么引用导致了问题。

【讨论】：

在我的例子中，升级到新的 DevExpress 版本后，表单的 .resx 文件包含对旧的卸载库版本的引用。我必须在代码视图中打开 .resx 并将版本更正为新版本或删除无效条目。

【解决方案6】：

尝试将缺少的内容添加到全局程序集缓存中。

【讨论】：

实际上，我没有得到反对票。当缺少参考时，有时将其添加到 GAC 实际上就是答案，假设那是参考指向的位置。我同意这个答案可以直接回答作者的问题，一个关于如何在 GAC 中获得它的链接，但我们不要因为一般性答案而受到惩罚——尤其是已经在这里的其他分支。我将 SO 视为错误类型的一系列可能答案，而不仅仅是特定场景。而且他们没有超过 50 个代表，因此他们无法对问题或帖子添加评论（恕我直言，应该更改）。

【解决方案7】：

如果您使用的是 Visual Studio，请尝试“干净的解决方案”，然后重新构建您的项目。

【讨论】：

这通常是我的解决方案。通常，删除bin 和obj 会这样做。基本上，我以前引用的东西仍然坐在那里试图满足相同的要求。例如，旧版本是我直接引用的东西，而新版本是在 NuGet 上。
从 TFS 拉取后，多个 DLL 遇到此问题。这个解决方案为我解决了这个问题。
为我工作。删除了 bin amd obj 文件夹并解决了问题。
谢谢，也为我工作，只是删除 bin 文件夹。
“清洁解决方案”对我没有任何帮助。（微软？？？？）但删除 bin 和 obj 文件夹修复了它。谢谢！

【解决方案8】：

如果您尝试使用反射进行后期绑定，如果您要绑定的程序集具有强名称或更改了其公钥标记，则会引发完全相同的错误。即使实际上没有找到任何具有指定公钥令牌的程序集，错误也是一样的。

您需要添加正确的公钥令牌（您可以在 dll 上使用 sn -T 获取它）来解决错误。希望这会有所帮助。

【讨论】：

请详细说明-什么是“sn -T”？我在哪里添加公钥令牌？
"sn.exe" 是 Visual Studio 自带的一个工具，它是一个命令行工具，可以在 Visual Studio 命令提示符下运行。只需运行 Visual Studio 命令提示符（从开始菜单），导航到包含程序集的文件夹，然后键入“sn -T ”，其中是 dll 的全名。这将获取程序集“令牌”信息。一旦你有了这个，当你使用反射进行后期绑定时，将令牌信息输入到程序集 id 字符串中（即，“Assembly=MyAssembly.dll, Public Key Token=）
感谢您的回答。在我的 App.ini 中引用配置部分时出现此错误。我最近签署了程序集，因此必须使用新的（正确的）令牌更新 PublicKeyToken=null。

【解决方案9】：

我的情况与 Nathan Bedford 的帖子非常相似，但略有不同。我的项目也以两种方式引用了更改后的 dll。 1) 直接和 2) 通过引用本身具有对已更改 dll 的引用的组件（类库）间接。现在我的组件 (2) 的 Visual Studio 项目引用了更改后的 dll 的正确版本。但是组件本身的版本号没有改变。因此，新版本项目的安装未能在客户端机器上替换该组件。

最终结果：直接引用 (1) 和间接引用 (2) 指向客户端计算机上更改的 dll 的不同版本。在我的开发机器上它运行良好。

解决方案：删除应用程序；从应用程序文件夹中删除所有 DLL；重新安装。在我的情况下很简单。

【讨论】：

【解决方案10】：

右键VS中的引用设置“特定版本”属性为True。

【讨论】：

【解决方案11】：

在我的情况下，它是 C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ 目录中的旧版本 DLL。您可以删除或替换旧版本，也可以删除并重新添加对项目中 DLL 的引用。基本上，任何一种方式都会创建一个指向临时 ASP.NET 文件的新指针。

【讨论】：

当我关闭 Visual Studio、停止 IIS 并删除所有临时 ASP.NET 文件时，这对我有用。请注意，如果在 64 位计算机上，以及在 .NET 2.0 和 4.0 文件夹中，Framework 和 Framework64 文件夹中可能有文件！
我使用 Windows 开始菜单搜索功能查找由我的解决方案创建的所有 DLL，然后将其全部删除，无论它们位于何处。我可以毫无顾忌地做到这一点，因为它们应该只在我的 Visual Studio 调试期间创建。由于 VS 将重建这些丢失的 DLL，并且我的解决方案之外的任何内容都不应引用它们，这对我来说是一个“安全”的操作。

【解决方案12】：

由于引用了与我正在构建的程序集同名的程序集，我收到了此错误消息。

这已编译，但它用当前项目程序集覆盖了引用的程序集 - 从而导致错误。

为了解决这个问题，我更改了项目的名称，并通过右键单击项目并选择“属性”来使用程序集属性。

【讨论】：

【解决方案13】：

我会让别人从我的愚蠢中受益。我对一个完全独立的应用程序有一些依赖项（我们称之为 App1）。该 App1 中的 dll 被拉入我的新应用程序 (App2)。每当我在 APP1 中进行更新时，我都必须创建新的 dll 并将它们复制到 App2 中。好吧。 . .我厌倦了在 2 个不同的 App1 版本之间复制和粘贴，所以我只是在 dll 中添加了一个“NEW_”前缀。

嗯。 . .我猜测构建过程会扫描 /bin 文件夹，当它不正确地匹配某些内容时，它会发出与上述相同的错误消息。我删除了我的“new_”版本，它只是花花公子。

【讨论】：

【解决方案14】：

我的问题是将源代码复制到新机器上，而没有提取任何引用的程序集。

我没有修复错误，所以我匆忙删除了 BIN 目录。重建了我的源代码，从那时起它就可以工作了。

【讨论】：

【解决方案15】：

我刚刚找到了另一个导致此错误的原因。我从特定库的所有版本中清理了我的 GAC，并参考与可执行文件一起部署的特定版本构建了我的项目。当我运行该项目时，我在搜索更新版本的库时遇到了这个异常。

原因是publisher policy。当我从 GAC 卸载库的版本时，我也忘记卸载发布者策略程序集，因此程序集加载器没有使用本地部署的程序集，而是在 GAC 中找到了发布者策略，告诉它搜索更新的版本。

【讨论】：

【解决方案16】：

我在尝试更新我网站的一个 DLL 文件时遇到了类似的问题。

当我通过 FTP 将此 DLL 文件复制到 bin 文件夹中时，发生此错误。

我通过以下方式解决了这个问题：

停止网站；
复制需要的DLL文件/DLL文件；
启动网站

【讨论】：

【解决方案17】：

我的 app.config 包含一个

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

对于 npgsql。不知何故，在用户的机器上，我的 app.exe.config 丢失了。我不确定它是否是一个愚蠢的用户、安装程序故障，或者是反病毒软件。替换文件解决了这个问题。

【讨论】：

【解决方案18】：

以下将任何程序集版本重定向到版本 3.1.0.0。我们有一个脚本，该脚本将始终在 App.config 中更新此引用，因此我们无需再次处理此问题。

通过反射，您可以获得程序集 publicKeyToken 并从 .dll 文件本身生成此块。

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

请注意，如果没有 XML 命名空间属性 (xmlns)，这将不起作用。

【讨论】：

这对我有用。我将“newVersion=3.3.3”更改为“newVersion=3.1.0”
如果可以避免的话，最好不要走重新绑定路线。当那个虫子来咬你时，它会咬得很紧。
我的问题是重定向指向不存在的程序集。App.Config 保存了我安装的最新 NuGet 包的程序集信息。当我后来降级这些软件包时，它并没有清理它。这是一个被 4.7.2 框架单元测试项目击中的 .NET 标准类库。单元测试项目在运行时出现的问题..
@D-Sect 是对的。如果您的源代码控制表明 web.config 发生了更改（因为您一直在使用 NuGet），那么您最好将那些 bindingRedirects 撤出。降级 NuGet 不会清除绑定重定向

【解决方案19】：

对我来说，“Local.testtesttings”文件中的代码覆盖率配置“导致”了这个问题。我忘了更新那里引用的文件。

【讨论】：

【解决方案20】：

我在运行单元测试用例时遇到了同样的问题。

错误清楚地表明问题是：当我们尝试加载程序集时，.NET 程序集加载器尝试根据其清单数据（引用的程序集名称、公钥令牌、版本）加载其引用的程序集。

检查清单数据：

打开 Visual Studio 命令提示符，
键入“ildasm”并将所需的程序集拖到 ILDASM 窗口并打开 MANIFEST 视图。有时 MANIFEST 包含一个程序集，其中包含两个版本的旧版本和新版本（如 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 窗口中，然后检查哪个依赖程序集使用旧程序集版本保存清单数据。只需重建此依赖程序集并将其引用回您的项目即可。

【讨论】：

不幸的是，我无法将程序集拖到 ildasm，因为错误阻止了程序集的构建...
这听起来很有希望，但我不明白如何解决它。我在我的解决方案中找到了一个具有两个版本 System.Web.Mvc 的项目。当我重建它时，它仍然包含两个版本。如何摆脱对旧版本的引用？

【解决方案21】：

其他答案对我不起作用。如果您不关心版本并且只想运行您的应用程序，请右键单击参考并将“特定版本”设置为 false ...这对我有用。

【讨论】：

该设置仅在编译时有效。编译后，它需要与编译时完全相同的程序集版本。见*.com/questions/24022134/…

【解决方案22】：

我想补充一点，我正在创建一个基本的 ASP.NET MVC 4 项目，并通过 NuGet 添加了 DotNetOpenAuth.AspNet。在我为 Microsoft.Web.WebPages.OAuth 引用了一个不匹配的 DLL 文件后，这导致了同样的错误。

为了修复它，我做了一个Update-Package 并清理了解决方案以进行完全重建。

这对我有用，有点懒惰，但时间就是金钱：-P

【讨论】：

对我来说类似的答案。 Update-Package -reinstall 重新安装同一版本的所有 NuGet 包。
这很棒；感谢您的发布。我尝试了所有其他很棒的建议，但这是成功的解决方案。感谢那些仍然愿意发布替代解决方案的人，即使有 80 个可用的解决方案
这为我解决了。我最近安装的公司库使用的是导致不匹配的库的较旧参考版本。安装后，这抛出了错误。 Update-Package -reinstall 将其按顺序恢复

【解决方案23】：

在 AssemblyInfo.cs 文件中的 AssemblyVersion 中，使用固定版本号而不是指定 *。 * 将更改每次编译的版本号。就我而言，这就是这个例外的问题。

【讨论】：

【解决方案24】：

我在使用内部包存储库时遇到了这个问题。我已将主包添加到内部存储库，但没有添加包的依赖项。确保将所有依赖项、依赖项的依赖项、递归等也添加到您的内部存储库中。

【讨论】：

【解决方案25】：

我添加了一个 NuGet 包，却发现我的应用程序的黑盒部分引用了旧版本的库。

我删除了包并引用了旧版本的静态 DLL 文件，但 web.config 文件从未从以下位置更新：

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

当我卸载软件包时它应该恢复到什么：

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

【讨论】：

我在哪里看到过，至少对于使用 NuGet 时的实体框架模块，如果右键单击解决方案，转到管理解决方案的 NuGet 包，然后选择已安装的包 > 全部，选择该模块，选择管理，您通常可以从项目中取消选择它。假设供应商进行了尽职调查，这应该可以清除此类事情，而无需手动进行。但是，如果您是这样删除它的，那么显然有时它们不会捕获。

【解决方案26】：

从文件夹位置手动删除旧程序集，然后添加对新程序集的引用可能会有所帮助。

【讨论】：

【解决方案27】：

我今天遇到了同样的问题，这使我在对实体框架进行更改后无法执行添加迁移。

我的解决方案中有两个项目，我们称它们为“客户端”和“数据”——一个包含我的 EF 模型和上下文的类库项目。客户引用了数据项目。

我已经签署了这两个项目，然后对 EF 模型进行了更改。删除签名后，我可以添加迁移，然后可以重新签署项目。

我希望这对某人有用，避免他们长期沮丧..

【讨论】：

【解决方案28】：

我在开始使用 InstallShield 后遇到了这个问题。尽管构建顺序显示安装项目是最后一个，但它的构建是无序的。

我通过使所有其他项目都依赖它来纠正这个问题 - 这迫使安装最后构建，从而消除了我的装配不匹配。我希望这会有所帮助。

【讨论】：

【解决方案29】：

就我而言，问题出在椅子和键盘之间:-)

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：

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

然后我意识到我忘记将新的 web.config 复制/部署到生产服务器。因此，如果您有手动部署 web.config 的方式，请检查它是否已更新。如果生产服务器的 web.config 完全不同，则必须在使用 NuGet 后同步合并这些dependentAssembly 部分。

【讨论】：

【解决方案30】：

我遇到了同样的错误... 就我而言，它得到了如下解决：

最初安装应用程序时，这里的人在应用程序中使用了 Microsoft Enterprise Library 4.1。
在前一周我的机器被格式化，然后今天当我构建该应用程序时，它给了我一个错误，即缺少企业库程序集。
然后我安装了 Microsoft Enterprise Library 5.0，这是我在 Google 上获得的第一个搜索条目。
然后当我构建应用程序时，它给了我上述错误，即定位的程序集的清单定义与程序集引用不匹配。
经过大量搜索和分析后，我发现应用程序引用的是 4.1.0.0 并且 bin 文件夹中的 DLL 版本为 5.0.0.0
然后我安装了 Microsoft Enterprise Library 4.1。
删除了以前的参考 (5.0) 并添加了 4.0 参考。
构建了应用程序，瞧……它成功了。

【讨论】：