836

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

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

在 x.Foo.FooGO()

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

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

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

我查看了我的参考资料,我只有一个参考资料Utility version 1.2.0.203(另一个是旧的)。

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

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

4

58 回答 58

489

.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

于 2008-10-18T13:39:12.460 回答
95

您可以做几件事来解决此问题。首先,使用 Windows 文件搜索在硬盘驱动器中搜索程序集 (.dll)。获得结果列表后,执行查看->选择详细信息...,然后检查“文件版本”。这将在结果列表中显示版本号,因此您可以看到旧版本可能来自何处。

另外,就像 Lars 所说,检查您的 GAC 以查看那里列出的版本。这篇 Microsoft 文章指出,在 GAC 中找到的程序集在构建期间不会在本地复制,因此您可能需要在全部重新构建之前删除旧版本。(有关创建批处理文件为您执行此操作的说明,请参阅我对此问题的回答)

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

于 2008-10-20T21:31:48.247 回答
62

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

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

无法加载文件或程序集“CompanyClasses,Version=1.4.1.0,Culture=neutral,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 之后),这个错误对我来说就消失了。

于 2009-11-17T19:15:27.677 回答
57

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

于 2012-11-02T00:34:57.527 回答
48

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

于 2010-07-13T03:27:38.163 回答
41

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

于 2013-06-28T17:21:26.330 回答
33

我现在要让每个人都大吃一惊。. .

从 .config 文件中删除所有<assemblyBinding>引用,然后从 NuGet 包管理器控制台运行此命令:

Get-Project -All | Add-BindingRedirect
于 2019-01-24T19:27:37.280 回答
27

我添加了一个 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>
于 2014-03-05T16:22:19.197 回答
27

就我而言,此错误是在运行 ASP.NET 应用程序时发生的。解决方案是:

  1. 删除项目文件夹中的obj和文件夹bin

Clean 不起作用,rebuild 不起作用,所有引用都很好,但它没有编写其中一个库。删除这些目录后,一切正常。

于 2016-10-09T18:34:13.093 回答
22

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

于 2009-09-03T00:00:33.947 回答
14

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

于 2010-09-15T17:07:15.897 回答
8

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

烦人的部分是错误消息没有表明是什么引用导致了问题。

于 2009-11-23T11:09:54.437 回答
8

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

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

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

于 2013-06-28T23:17:39.073 回答
7

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

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

于 2010-07-16T21:22:26.893 回答
5

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

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

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

于 2010-08-08T17:28:05.337 回答
5

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

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

于 2012-04-27T23:20:00.723 回答
5

在 Team Foundation Server 的构建服务上构建时出现此错误。事实证明,我的解决方案中有多个项目,使用的是通过 NuGet 添加的同一库的不同版本。我使用 NuGet 删除了所有旧版本,并添加了新版本作为所有人的参考。

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

于 2015-07-16T08:28:02.040 回答
4

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

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

于 2012-03-13T15:32:56.537 回答
4

我的 app.config 包含一个

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

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

于 2012-10-01T21:34:14.780 回答
4

在尝试了上述许多没有修复的解决方案之后,它归结为确保在 Visual Studio 的应用程序中打开“自动生成绑定重定向”。

在此处输入图像描述

可以在此处找到有关启用自动绑定重定向的更多信息:https ://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

于 2020-06-24T19:12:07.693 回答
4

是否可能您在 assemblyBinding 尝试中有错误的 nugget 版本:

  1. 移除 web.config/app.config 中的所有程序集绑定内容:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Extensions.DependencyInjection" publicKeyToken="adb9793829ddae60" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />
  </dependentAssembly>
</assemblyBinding>
  1. 在包管理器控制台中输入:Add-BindingRedirect
  2. 生成所有必要的绑定重定向
  3. 运行您的应用程序并查看它是否正常工作。如果没有,请添加软件包控制台错过的任何缺少的绑定重定向。
于 2021-02-27T12:45:29.853 回答
3

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

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

于 2012-06-01T13:07:32.967 回答
3

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

于 2013-03-04T09:04:45.777 回答
3

只需删除项目 bin 文件夹的内容并重建解决方案即可解决我的问题。

于 2017-08-10T04:15:27.300 回答
2

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

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

在此处输入图像描述

  1. 在您的解决方案中找到该 .dll 的所有副本,右键单击它们,然后检查它是哪个版本的 .dll。

在此处输入图像描述

好的,所以在这个例子中,我的 .dll 肯定是 2.0.5022.0 (所以异常版本号是错误的)。

  1. 搜索解决方案中所有.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" />

任务完成 !

于 2016-11-15T16:00:00.247 回答
2

问题已经有了答案,但是如果同一个解决方案中不同版本的NuGet包出现问题,可以试试下面的方法。

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

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

在此处输入图像描述

于 2017-05-11T23:35:06.547 回答
2

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

我建议尝试将文件夹从“bin”重命名为“oldbin”或“obj”重命名为“oldobj”

然后再次尝试构建您的解决方案。

如果您使用任何第三方 dll,则需要在成功构建后将其复制到新创建的“bin”或“obj”文件夹中。

希望这对你有用。

于 2017-12-03T18:39:23.083 回答
2

没有解决方案对我有用。我尝试了干净的项目解决方案,删除 bin,更新包,降级包等等......两个小时后,我从带有程序集的项目中加载了默认 App.config,并在那里我更改了错误的参考版本:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

到:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

在此之后,我清理了项目,再次构建它并且它工作。没有警告没有问题。

于 2019-08-22T12:39:16.617 回答
2

此类问题的一般答案是像其他答案一样使用绑定重定向。然而,这只是问题的一部分——您需要知道您正在使用的程序集文件的正确版本。Windows 属性并不总是准确的,nuget 也不总是准确的。

获得正确版本信息的唯一方法是分析文件本身。一个有用的工具是 dotPeek。根据我的经验,dotPeek 中列出的程序集名称总是准确的。

例如,此文件的正确绑定如下:

<dependentAssembly>
    <assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0"/>
</dependentAssembly>

Windows 资源管理器说该文件是 4.6.26515.06,nuget 说它是一个 5.0.0.0 文件。dotPeek 说它是 4.2.1.0,这是在我们的软件中正常工作的版本。另请注意,公钥和文化很重要,dotPeek 也会显示此信息。

dotPeek vs Windows 版本信息

于 2020-12-03T12:25:58.580 回答
2

这个问题很老了,最近我在使用 Azure DevOps Yaml 管道和 Dotnet Core 3.1 时遇到了同样的错误消息。这个问题与尝试解决的其他答案有些不同,所以我将分享我的解决方案。

我为自己的 nuget 包提供了许多项目的解决方案。我偶然在 *.csproj 文件中添加了版本标签,如下所示:

  <Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <Version>1.0.0</Version>
  </PropertyGroup>

我使用 Yaml 和 DotnetCoreCLI@2 任务为所有项目打包了 nuget 包:

 - task: DotNetCoreCLI@2
   displayName: 'pack'
   inputs:
     command: pack
     nobuild: true
     configurationToPack: 'Release'
     includesource: true
     includesymbols: true
     packagesToPack: 'MyNugetProject1.csproj;**/MyNugetProject2.csproj'
     versioningScheme: 'byEnvVar'
     versionEnvVar: 'GitVersion.SemVer'

问题是 *.csproj 文件中的版本与环境变量 GitVersion.SemVer(由 input-"versionEnvVar" 指定)中的版本不匹配。

删除 *.csproj 文件中的所有<Version>1.0.0</Version>-tags 后,dll 的程序集/文件版本由环境变量自动分配,并且 nuget 和 dll(程序集/文件版本)将具有相同的版本并且问题已解决。

于 2020-12-11T14:14:31.360 回答
1

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

于 2014-06-06T09:27:09.830 回答
1

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

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

于 2014-12-07T16:24:39.980 回答
1

我遇到了同样的错误......在我的情况下,它得到了如下解决:

  • 最初安装应用程序时,这里的人们在应用程序中使用了 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 参考。
  • 构建了应用程序,瞧……它奏效了。
于 2015-04-29T13:10:10.133 回答
1

如果您遇到类似“定位程序集的清单定义与程序集引用不匹配”之类的错误,并且您已通过VS中的 Project > Manage NuGet Packages and Update 选项卡进行了更新,那么您可以做的第一件事是尝试安装另一个版本的从NuGet Gallery 页面检查版本并从包管理器控制台运行以下命令后打包:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

尽管答案与所讨论的软件包没有直接关系,并且在很久以前就被问到了,但它是通用的,仍然相关并希望它对某人有所帮助。

于 2018-06-15T15:14:12.230 回答
1

我遇到了同样的错误,但在我的情况下,我在本地将自定义 nuget 包运行到另一个项目中。

为我解决的问题是将包版本更改为错误中请求的版本。

该软件包位于 netstandard 2.1 中,请求该软件包的项目位于 netcore 3.1 中

在此处输入图像描述

于 2021-01-15T10:12:31.050 回答
0

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

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

为了修复它,我更改了项目的名称,并通过右键单击项目并选择“属性”来获得可用的程序集属性。

于 2011-07-12T02:24:30.700 回答
0

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

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

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

  1. 停止网站;
  2. 复制所需的 DLL 文件/DLL 文件;
  3. 启动网站
于 2012-09-06T07:20:24.433 回答
0

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

该错误清楚地说明了问题是:当我们尝试加载程序集时,.NET 程序集加载器尝试根据其清单数据(引用的程序集名称、公钥令牌、版本)加载其引用的程序集。

检查清单数据:

  1. 打开 Visual Studio 命令提示符,
  2. 键入“ildasm”并将所需的程序集拖到 ILDASM 窗口并打开 MANIFEST 视图。有时 MANIFEST 包含一个程序集,其中包含两个版本的旧版本和新版本(如Utility, Version=1.2.0.200Utility, Version=1.2.0.203)。实际上,引用的程序集是Utility, Version=1.2.0.203(new version),但由于清单包含 even Utility, Version=1.2.0.200(old version),.NET 程序集加载器试图找出这个版本化的 DLL 文件,但找不到并因此引发异常。

要解决这个问题,只需将每个项目依赖程序集分别拖到 ILDASM 窗口中,然后检查哪个依赖程序集使用旧程序集版本保存清单数据。只需重建此依赖程序集并将其引用回您的项目即可。

于 2013-03-11T10:38:32.000 回答
0

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

于 2013-07-30T05:43:00.980 回答
0

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

于 2014-01-24T16:01:08.433 回答
0

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

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

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

我希望这对某人有用,以免他们长期沮丧。

于 2014-08-01T13:55:22.127 回答
0

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

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

于 2014-09-22T15:50:49.787 回答
0

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

于 2015-12-04T08:57:21.147 回答
0

好的,再来一个答案。我之前将我的应用程序创建为 64 位,并相应地更改了输出路径(项目/属性/构建/输出/输出路径)。最近我将应用程序更改为 32 位 (x86),创建了一个新的输出路径。我创建了一个快捷方式,指向我认为编译后的 .exe 的去向。无论我对源进行什么更改,它都会出现清单不匹配错误。经过大约一个小时的挫折,我碰巧检查了 .exe 文件的日期/时间,发现它很旧,显然引用了旧的 .dll 文件。我正在将应用程序编译到旧目录中,而我的快捷方式正在引用新目录。将输出路径更改为 .exe应该去的位置,运行快捷方式,错误就消失了。(拍了拍额头)

于 2017-01-18T23:45:11.163 回答
0

我的问题是在新版本中删除了旧 dll 的 dployed。为了解决这个问题,我只是选中了该框以在发布时删除目标位置的其他文件。 删除目的地的其他文件

于 2018-01-10T16:19:29.257 回答
0

在这篇文章中提到了类似的问题“关于我如何找出试图引用这个 DLL 文件的旧版本的任何建议?”

需要哪个程序集仍然引用旧的 ODATA 客户端 6.15.0 ,ildasm 帮助我缩小了范围(没有基本代码访问,只能通过在服务器上部署的 pkg)。

下面的屏幕截图用于快速总结。

DeveloperPackge 如果没有 ildasm.exe https://www.microsoft.com/net/download/visual-studio-sdks

使用 ildasm 解决程序集不匹配问题

于 2018-06-21T22:29:36.697 回答
0

我的单元测试项目中也出现了同样的错误,并导致一些测试失败。我仔细检查了我在程序集资源管理器中使用的程序集版本,并检查了运行时/依赖程序集标签的内容,并意识到我一直在使用的不同版本的程序集仍然在那里被引用。因为这是我的测试项目 app.config 中唯一的指令,所以我只是尝试删除整个 app.config 文件,重新构建解决方案,然后就成功了!对我来说没有更多的参考错误:)

于 2019-01-25T22:11:12.843 回答
0

我得到:

无法加载文件或程序集“XXX-new”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。(来自 HRESULT 的异常:0x80131040)

这是因为我将程序集的名称从 更改XXX.dllXXX-new.dll。将名称恢复为原始名称修复了该错误。

于 2019-04-18T08:45:38.637 回答
0

检查项目属性中的 licenses.licx,您会在那里找到错误的版本....它在活动报告参考中对我有用

于 2019-05-22T06:59:29.390 回答
0

发生在我身上System.ValueTuple

意外错误无法加载文件或程序集“System.ValueTuple,Version=4.0.1.0,Culture=neutral,PublicKeyToken=cc7b13ffcd2ddd51”或其依赖项之一。该系统找不到指定的文件。

.NET Framework 4.7.2 Runtime通过在发生错误的机器上安装来解决它。简单,无需添加bindingRedirect、修改 GAC 或降级 NuGet 包等。

https://dotnet.microsoft.com/download/dotnet-framework/net472

于 2019-05-29T11:35:17.760 回答
0

我有类似的问题,但没有答案对我有用。

publicKeyToken对我有用的解决方案是手动从项目文件(YourProject.csproj)中删除部分。

以前是:

<Reference Include="Utility, Version=0.0.0.0, Culture=neutral, PublicKeyToken=e71b9933bfee3534, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

更改后是:

<Reference Include="Utility, Version=1.0.1.100, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

确定SpecificVersionFalse.

于 2019-10-07T08:45:34.963 回答
0

用蛮力解决了我这样的问题。

我意识到我在整个解决方案和两个不同的版本中处理了多个 DLL 副本。

在资源管理器中进入解决方案,搜索有问题的 DLL 并将其全部删除。然后使用 DLL 的一个版本添加对 DLL 的引用。

于 2019-11-16T11:37:21.623 回答
0

我被这件事难住了一段时间。我可以在发行版中构建和运行,但由于引用与清单不匹配而无法调试。我一定检查了一百次参考,并删除了所有的 dll。我注意到在调试和发布中生成的清单是不同的。

我删除了我的项目/属性中的 app.manifest 并解决了问题。这不包括提到有问题的引用 dll - 所以我不知道为什么这会导致问题。

于 2020-05-31T16:59:46.703 回答
0

尝试从您的 webConfig/appConfig 中删除程序集引用

 <dependentAssembly>
        <assemblyIdentity name="System.IO" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.3.0.0" />
      </dependentAssembly>
于 2020-07-28T07:05:16.433 回答
0

运行迁移器以从使用 packages.config 升级到 PackageReference 为我轻松修复了此错误。如果您运行的是 Visual Studio 2017 版本 15.7 或更高版本,则可以按照以下步骤进行升级。

https://docs.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference#migration-steps

以下是步骤(从上面的链接复制):

  1. 使用 packages.config 打开包含项目的解决方案。

  2. 在解决方案资源管理器中,右键单击 References 节点或 packages.config 文件并选择 Migrate packages.config to PackageReference...。

  3. 迁移器分析项目的 NuGet 包引用并尝试将它们分类为顶级依赖项(您直接安装的 NuGet 包)和传递依赖项(作为顶级包的依赖项安装的包)。

注意:PackageReference 支持传递包恢复和动态解析依赖,这意味着传递依赖不需要显式安装。

  1. (可选)您可以通过选择包的顶级选项来选择将分类为传递依赖项的 NuGet 包视为顶级依赖项。此选项会自动设置为包含不以传递方式流动的资产(在 build、buildCrossTargeting、contentFiles 或 analyzers 文件夹中的资产)和标记为开发依赖项(developmentDependency = "true")的软件包。

  2. 查看任何软件包兼容性问题。

  3. 选择确定开始迁移。

  4. 在迁移结束时,Visual Studio 会提供一份报告,其中包含备份路径、已安装包列表(顶级依赖项)、作为传递依赖项引用的包列表以及开始时确定的兼容性问题列表的迁移。报告将保存到备份文件夹。

  5. 验证解决方案是否构建并运行。如果遇到问题,请在 GitHub 上提出问题。

于 2021-04-07T00:10:46.070 回答
-1

请在 Visual Studio 调试器中运行代码。请运行,直到你得到异常。将出现 Visual Studio 异常 UI。请阅读 Visual Studio Exception 底部的“完整详细信息”/“显示详细信息”。在 Full details/Show details 中,它告诉我我的一个项目(指的是我的主项目具有不同版本的 Microsoft.IdentityModel.Clients.ActiveDirectory)。就我而言,我的单元测试项目正在调用我的项目。我的单元测试项目和我的项目有不同版本的 Microsoft.IdentityModel.Clients.ActiveDirectory。执行单元测试时出现运行时错误。

我刚刚用相同版本的主项目更新了我的单元测试项目的版本。它对我有用。

于 2019-08-25T05:10:40.693 回答
-4

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

于 2010-07-01T13:59:07.083 回答
-4

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

于 2010-09-01T19:41:26.353 回答