我正在尝试在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:line 123中的x.Foo.Foo2(String groupName_)位于FooTests.cs:line 98中的x.Foo.UnitTests.FooTests.TestFoo()**System.IO.FileLoadException:未能加载文件或程序集“Utility,Version=1.2.0.203,Culture=neutral,PublicKeyToken=764d581291d764f7”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。(HRESULT的异常:0x80131040)

我查阅了我的参考资料,我只参考了实用程序版本1.2.0.203(另一个是旧版本)。

关于我如何找出试图引用此DLL文件的旧版本的内容,有什么建议吗?

此外,我想我的硬盘上甚至没有这个旧组件。是否有任何工具可以搜索此旧版本的程序集?


当前回答

这个问题由来已久,我最近在Azure DevOps Yaml管道和Dotnet Core 3.1中收到了同样的错误消息。这个问题与其他答案试图解决的问题有些不同,因此我将分享我的解决方案。

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

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

我用一个DotnetCoreCLI@2任务:

 - 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(由输入“versionEnvVar”指定)中的版本不匹配。

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

其他回答

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

https://learn.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference#migration-步骤

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

使用packages.config打开包含项目的解决方案。在解决方案资源管理器中,右键单击“引用”节点或packages.config文件,然后选择将packages.cnfig迁移到程序包参考。。。。迁移器分析项目的NuGet包引用和尝试将它们分类为顶级依赖项(NuGet直接安装的软件包)和Transitive依赖项(作为顶级包的依赖项安装的包)。注意:PackageReference支持可传递的包还原和解析依赖关系是动态的,这意味着传递依赖关系需要不能显式安装。(可选)您可以选择将NuGet包分类为通过选择程序包的顶层选项。此选项自动设置为包含不流动的资产的包(build、buildCrossTargeting、contentFiles或分析器文件夹)和标记为开发依赖项(developmentDependency=“真”)。检查所有程序包兼容性问题。选择“确定”开始迁移。在迁移结束时,Visual Studio提供了一个带有备份路径、已安装软件包的列表(顶级依赖项),引用为可传递的包列表依赖关系,以及在开始迁移。报告将保存到备份文件夹中。验证解决方案是否构建并运行。如果您遇到问题,在GitHub上提交问题。

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

我也犯了同样的错误。。。在我的案例中,问题解决如下:

最初安装应用程序时,这里的人在应用程序中使用了Microsoft Enterprise Library 4.1。在前一周,我的机器被格式化了,在那之后,今天当我构建应用程序时,它给了我一个错误,即缺少企业库程序集。然后我安装了Microsoft Enterprise Library 5.0,这是我在谷歌上作为第一个搜索条目获得的。然后当我构建应用程序时,它给了我上面的错误,即找到的程序集的清单定义与程序集引用不匹配。经过大量的搜索和分析,我发现应用程序引用的是4.1.0.0,bin文件夹中的DLL版本是5.0.0.0然后我安装了Microsoft Enterprise Library 4.1。删除先前的引用(5.0)并添加4.0引用。构建应用程序(&V)。。。它奏效了。

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

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

虽然答案和所讨论的包并没有直接关系,而且早在很久以前就有人问过它,但它是一种通用的,仍然相关,希望它能帮助一些人。

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

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

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

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

希望这对你有用。