我正在尝试在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文件的旧版本的内容,有什么建议吗?

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


当前回答

与“文件资源管理器”>“属性”>“详细信息”选项卡中的版本相比,.DLL在代码中使用反射的“版本”属性报告不同的版本并不罕见。

多年来,我发现使用这种powershell可以更好地找到应该将绑定重定向设置到哪个版本。

[Reflection.AssemblyName]::GetAssemblyName('C:\Source\Project\Web\bin\System.Memory.dll').Version

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      1      2

通过以上步骤,我可以在app.config文件中插入(或替换)绑定重定向:

<dependentAssembly>
    <assemblyIdentity name="System.Memory" culture="neutral" publicKeyToken="cc7b13ffcd2ddd51"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.1.2" newVersion="4.0.1.2"/>
</dependentAssembly>

在该特定示例中,System.Memory.dll的“详细信息”选项卡报告的文件版本为4.6.31308.01。

其他回答

这个问题由来已久,我最近在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版本)将具有相同的版本,问题得到解决。

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

用蛮力解决了我的问题。

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

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

我也有类似的问题,但没有一个答案对我有效。

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

以前是:

<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>

确保SpecificVersion为False。

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

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

要检查清单数据,请执行以下操作:

打开Visual Studio命令提示符,键入“ildasm”并将所需的程序集拖到ildasm窗口并打开MANIFEST视图。有时MANIFEST包含一个具有两个版本的程序集,即旧版本和新版本(如Utility,版本=1.2.0.200和Utility,版本=1.2.0203)。实际上,引用的程序集是Utility,版本为1.2.0.203(新版本),但由于清单甚至包含Utility,版本=1.2.0.200(旧版本),.NET程序集加载器尝试查找此版本的DLL文件,找不到,因此引发异常。

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