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

问题描述：

我试图运行在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)

我看在我的参考文献中，我只有对Utility version 1.2.0.203（另一个是旧的）的参考。

关于如何弄清楚什么是试图引用这个旧版本的DLL文件的任何建议？

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

答

.NET Assembly loader无法找到1.2.0.203，但确实找到了1.2.0.200。这个程序集不符合要求，因此你会得到这个错误。简而言之，它找不到所引用的程序集。确保它可以通过将其放入GAC或应用程序路径中找到合适的组件。另见http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx。

+13

但是当我看项目的引用，它指向1.2.0.203 ..。没有任何东西似乎指向1.2.0.200 – leora 2008-10-18 13:40:18

+99

确切地说 - 它是*寻找* 1.2.0.203，但它*发现* 1.2.0.200。找出该文件的位置，并将其替换为正确的版本。 – 2008-10-18 13:44:49

+13

我在这里问过类似的问题，并得到了有效的解决方案：http://*.com/questions/4187907/net-picking-wrong-referenced-assembly-version – 2010-11-15 20:12:29

答

你可以做几件事来解决这个问题。首先，使用Windows文件搜索来搜索您的硬盘驱动器（.dll）。获得结果列表后，执行查看 - >选择详细信息...，然后选中“文件版本”。这将在结果列表中显示版本号，以便您可以查看旧版本可能来自何处。

另外，就像Lars说的那样，请检查您的GAC，看看列出了哪些版本。 This Microsoft article指出在构建过程中在GAC中找到的程序集未在本地复制，因此在重建所有程序之前可能需要删除旧版本。（请参阅我的回答this question关于创建批处理文件以便为您执行此操作的注意事项）

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

+14

不要忘记文件版本不是程序集标识的一部分。组件版本是，但不一定与文件版本相同！ – 2011-12-06 08:10:45

如果使用fuslogvw进行服务，请阅读http://blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx – Nick 2015-09-28 15:23:40

搜索文件名解决了我的问题。我在我的Temporary ASP.Net文件夹中有一个旧版本的dll，InstallShield使用它而不是最新版本！干净的解决方案，重建，重新启动PC什么也没做。本地工作良好，每次部署时都会爆炸。 – JumpingJezza 2015-12-02 03:24:39

答

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

答

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

我有两个我的主项目引用的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

麻烦的是，我没有在我的系统上的任何文件CompanyClasses.dll用的1.4.1版本号。没有在GAC中，没有在应用程序文件夹中...没有任何地方。我搜查了我的整个硬盘。我所有的CompanyClasses.dll文件都是1.4.2。

我发现真正的问题是CompanyControls.dll引用了CompanyClasses.dll的1.4.1版本。我刚刚重新编译了CompanyControls.dll（在引用CompanyClasses.dll 1.4.2之后），并且此错误对我而言已消失。

+1当我有一个DLL引用旧版本的Caliburn Micro时，发生了类似的事情。 – 2013-02-01 23:48:54

我也是，你的经验引发了我需要看的地方，并且我的问题得到解决。 – Esen 2013-02-06 16:56:26

另一种办法是打开`CompanyControls`项目，右键单击`CompanyClasses.dll`参考 - >属性 - >`SpecificVersion = FALSE` – 2013-10-04 22:43:34

答

对我们来说，这个问题是由别的东西造成的。 DevExpress组件的许可证文件包含两行，一行用于未安装在此特定计算机上的旧版组件。从许可证文件中删除旧版本解决了问题。

烦人的部分是错误信息没有提供什么参考导致问题的迹象。

答

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

答

如果您使用Visual Studio，请尝试“清理解决方案”，然后重建您的项目。

答

如果您尝试使用反射延迟绑定，并且绑定到的程序集获取了强名称或其公钥标记已更改，则会引发完全相同的错误。即使实际上没有使用指定的公钥标记找到任何程序集，该错误也是一样的。

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

答

矿山与内森贝德福德的职位非常相似，但情况稍有不同。我的项目也以两种方式引用了更改后的dll。 1）直接和2）间接通过引用一个组件（类库），它本身有一个引用更改后的DLL。现在我的组件（2）的Visual Studio项目引用了正确版本的更改后的dll。然而，compnent本身的版本号没有改变。因此，新版本项目的安装无法替换客户机上的该组件。

最终结果：直接引用（1）和间接引用（2）指向客户端计算机上已更改dll的不同版本。在我的开发机器上它工作得很好。

解决方法：删除应用程序;从应用程序文件夹中删除所有的DLLS;重新安装，就像我的情况一样。

答

右键单击VS中的引用，将“Specific Version”属性设置为True。

答

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

答

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

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

要修复它，我通过右键单击项目并选择“属性”，更改了项目的名称以及可用的装配属性。

答

我会让别人从我的剪切愚蠢中受益。我有一些完全独立的应用程序的依赖关系（我们称之为App1）。来自该App1的dll被拉进我的新应用程序（App2）。任何时候我在APP1中进行更新，我都必须创建新的DLL并将它们复制到App2中。好。。。我厌倦了在2个不同的App1版本之间进行复制和粘贴，所以我只是给dll添加了一个'NEW_'前缀。

嘛。。。我猜测构建过程会扫描/ bin文件夹，以及何时会错误地匹配某些内容，它会使用与上面提到的相同的错误消息来提示。我删除了我的“new_”版本，它只是建立了花花公子。

答

我的问题是将源代码复制到一台新机器，而没有拉过任何引用的程序集。

没有，我做了修正错误，所以在匆忙中，我完全删除了BIN目录。重新构建我的源代码，并从此开始工作。

答

我刚刚发现另一个原因，为什么要得到这个错误。我从所有版本的特定库中清理了我的GAC，并参考与可执行文件一起部署的特定版本构建了我的项目。当我运行这个项目时，我得到了这个异常搜索库的更新版本。

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

答

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

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

我解决了这个问题：

停止的网站;
复制需要的DLL文件/ DLL文件;
启动web站点

答

我的app.config包含

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

Npgsql的对。不知何故，在用户的机器上，我的app.exe.config失踪了。我不确定这是一个愚蠢的用户，安装程序故障还是反病毒。替换文件解决了问题。

答

以下内容将任何程序集版本重定向到版本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），这将不起作用。

答

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

答

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

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

要检查清单数据：

打开Visual Studio命令提示，
类型“ILDASM”和所需组件拖动到ILDASM窗口并打开清单视图。有时候，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窗口中，并检查哪个相关程序集包含旧程序集版本的清单数据。只需重建此相关程序集并将其引回您的项目。

答

如果你不关心版本，而只是想让你的应用程序运行，那么右键单击引用并将“特定版本”设置为false。其他解决方案不适合我。 enter image description here

答

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

要修复它，我做了Update-Package并清理完整重建的解决方案。

这工作对我来说，是一种懒惰的方式，但时间就是金钱:-P

答

在AssemblyInfo.cs文件您的AssemblyVersion，而不是使用指定*固定的版本号。 *会更改每个编译的版本号。对我而言，这是个例外。

答

我在使用内部软件包存储库时遇到了这个问题。我已经将主包添加到内部存储库，但不包括该包的依赖关系。确保将所有依赖关系，依赖关系的依赖关系，递归等添加到您的内部存储库中。

答

我添加了一个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>

答

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

答

我今天有同样的问题，阻止我在实体框架中进行更改后执行添加迁移。

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

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

我希望这能为一个人是有用的，免去其长期的挫折..

答

我开始使用InstallShield后有这个问题。即使构建顺序显示安装项目是最后一次，它的构建也是无序的。

我纠正了这个问题，让每个其他项目都依赖它 - 这迫使安装最后建立，从而消除了我的程序集不匹配。我希望这有帮助。

答

在我的情况下，问题是椅子和键盘之间:-)

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库，这将不会是一个问题。此外，我的本地计算机上的web.config文件是自动更新的NuGet：

<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部分。

答

我得到了同样的错误... 对我来说，它得到了解决如下：

在应用程序安装时首先那么这里的人们曾使用微软企业库4.1的应用程序。
在上周我的机器被格式化后&今天，当我建立该应用程序，然后它给了我一个错误，企业库程序集丢失。
然后，我安装了Microsoft Enterprise Library 5.0，这是我在Google上搜索的第一个搜索条目。
然后，当我构建应用程序时，它给了我上述错误，即位于程序集的清单定义不匹配程序集引用。
经过大量的搜索工作&分析，我发现应用程序是指4.1.0.0 &在bin文件夹中的DLL是版本5.0.0.0
我所做的是后来我安装了微软企业库4.1 。
删除了之前的参考文献（5.0）&添加了4.0参考文献。
构建应用程序&瞧...它的工作。

答

我在构建Team Foundation Server的构建服务时遇到了此错误。事实证明，我的解决方案中有多个项目，使用与NuGet一起添加的相同库的不同版本。我使用NuGet删除了所有旧版本，并添加了新版本作为参考。

Team Foundation Server将所有DLL文件放在一个目录中，当然，一次只能有一个特定名称的DLL文件。

答

如果您将AssemblyInfo.cs与AssemblyVersion标签一起使用，并且.csproj文件具有不同的值，也会发生这种情况。通过匹配AssemblyInfo或删除所有部分，问题就消失了。

答

在我的情况下，运行ASP.NET应用程序时发生此错误。解决的办法是：

删除obj和bin文件夹，在项目文件夹

清洁没有工作，重建没有工作，所有引用都很好，但它不是写一个图书馆。删除这些目录后，一切都完美无缺。

答

这是我解决这个问题的方法。

从异常消息中，获取“问题”库的名称和“预期”版本号。

查找解决方案中的所有副本即.dll文件，对他们单击鼠标右键，并检查该.dll它是哪个版本。

好了，所以在这个例子中，我的.dll文件绝对是2.0.5022.0（所以异常版本号是错的）。

搜索解决方案中所有.csproj文件中异常消息中显示的版本号。将此版本号替换为dll中的实际编号。

所以，在这个例子中，我将取代这个...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

...这... ...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

作业已完成！

开始=>

答

好的，还有一个答案。我以前创建我的应用程序为64位，并相应地更改输出路径（项目/属性/生成/输出/输出路径）。最近我将应用程序更改为32位（x86），创建了一个新的输出路径。我创建了一个快捷方式，我想认为已编译的.exe正在进行。不管我对源代码做了什么修改，它都得到了不匹配错误的清单。经过大约一个小时的沮丧之后，我偶然检查了.exe文件的日期/时间，看到它显然是旧的，显然引用了旧的.dll的。 我正在将应用程序编译到旧目录中，并且我的快捷方式引用了较新的目录。将输出路径更改为.exe 应去去，运行快捷方式和错误消失。 （拍打前额）

答

的问题已经回答，但是如果问题已经NuGet包在不同版本的同一个解决方案发生，你可以尝试以下。

打开NuGet包管理器，因为您看到我的服务项目版本与其他项目不同。

然后更新包含旧版本软件包的项目。

答

只需删除您项目的bin文件夹的内容，并重新生成解决方案解决了我的问题。

答

清理并重建解决方案可能不会替换输出目录中的所有dll。

什么，我会建议是尝试从“BIN”重命名文件夹“oldbin”或“目标文件”到“oldobj”

，然后尝试重新建立你silution。

柜面如果你使用任何第三方DLL的那些你需要复制到新创建的“bin”或成功构建后“目标文件”文件夹中。

希望这会对你有用。

答

与我的问题是，有旧的DLL的dployed和已经在新的版本中删除。要解决这个问题，我只是在发布时选中了复选框以删除目标文件中的其他文件。 Remove additional files at destination

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

相关推荐