【问题标题】:Projects with same nuget package referencing different version of assembly具有相同 nuget 包的项目引用不同版本的程序集
【发布时间】:2019-03-07 06:42:13
【问题描述】:

我快疯了,我希望这是我忽略的事情。

我遇到间歇性FileLoadExceptions,即使部署之间的代码更改不会更改任何程序集引用,它也会在部署后出现。

看看最近的例子,我看到了一个FileLoadException,因为System.IO.Compression,版本4.2.0.0没有被发现。

在所有情况下,我们都引用System.IO.Compression nuget 包,版本4.3.0

查看我们解决方案中的两个项目,我注意到一些非常奇怪的地方。
ProjectA 引用 ProjectB

ProjectA 在其packages.config 文件中有以下参考:

<package id="System.IO.Compression" version="4.3.0" targetFramework="net462" />

ProjectB 在其package.config 文件中有以下参考:

<package id="System.IO.Compression" version="4.3.0" targetFramework="net462" />

当我查看 *.csproj 文件时,我看到了:

ProjectA:

<Reference Include="System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
  <HintPath>..\packages\System.IO.Compression.4.3.0\lib\net46\System.IO.Compression.dll</HintPath>
</Reference>`

ProjectB:

<Reference Include="System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
  <HintPath>..\packages\System.IO.Compression.4.3.0\lib\net46\System.IO.Compression.dll</HintPath>
</Reference>`

太好了,在这两种情况下,我们都指向磁盘上的同一个程序集。

然而,当我在解决方案资源管理器中查看引用的文件时,我看到了:

ProjectA:

以上内容引用了C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.IO.Compression.dll 中的文件,更重要的是,它具有4.2.0.0 的版本,而不是nuget 包文件夹中的版本。

ProjectB:

上面正确指向了nuget packages版本的程序集,其实就是4.1.2.0

重申一下,ProjectA,它引用了ProjectB,并且两者都有一个绑定重定向,它执行以下操作:

<dependentAssembly>
    <assemblyIdentity name="System.IO.Compression" publicKeyToken="b77a5c561934e089" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0" />
</dependentAssembly>`

所以我的问题是,为什么 Visual Studio 会从我们的任何项目(直接)引用的位置拉下 System.IO.Compression 的版本?而且,我能做些什么来解决这个问题?

此外,虽然我在本地使用的是 Visual Studio 2019 的(当前)RC 版本,但我们的构建代理(Azure DevOps Pipelines)使用的是 Visual Studio 2017。

在运行时,我们发现记录了上述异常,并且我们创建 ZIP 文件的处理失败。

更新

除上述内容外,我还进行了一些额外的挖掘,发现了一个绑定重定向,它指向该程序集的4.2.0.0 版本。我已将其手动降至4.1.2.0,并再次部署到我们的测试环境,并进行了一些额外的健康检查,以了解我们的进展情况。

仍然需要了解我们是如何进入这种状态的,以及为什么与 csproj 所指的内容与解决方案资源管理器中所见的内容存在差异。

【问题讨论】:

    标签: c# visual-studio nuget assembly-binding-redirect


    【解决方案1】:

    具有相同 nuget 包的项目引用不同版本的程序集

    这是我们构建 .NET Framework 4.6.x 应用程序时的known issue

    那是因为:

    这是由于注入了对 NETStandard 2.0 的支持。我们注入新的 程序集到 NET 4.6.1 和更高版本的桌面项目中,以便添加 支持netstandard2.0。我们现在在目标中执行此操作,而不是 包,因为它不再需要引用包 建立一个网络标准库。每当我们看到一个 引用了 netstandard1.5 或更高版本的库(参见 dotnet/sdk#1386)。

    要解决此问题,我们可以将绑定重定向添加到这些引用以使用对 System.IO.Compression 的标准引用,并且不为 System.IO.Compression 引入任何 Nuget 包。如果您仍想使用 nuget 包中的引用 System.IO.Compression,可以从 MSBuild 工具中删除 System.IO.Compression

    从 Github 查看更多详细信息:

    https://github.com/dotnet/corefx/issues/25773

    希望这会有所帮助。

    【讨论】:

    • 好的 - 感谢您提供详细信息。我想如果我们将所有内容都升级到 .NET 4.7,这个问题可能会消失吗?我正在检查 Azure 应用服务和云服务是否支持该版本的 .NET。
    • @BrendanGreen,AFAIK,.NET 4.7.1 上仍然存在此问题。 .NET 4.7.2 有助于解决部分问题,但不是全部,请从此处查看信息:github.com/dotnet/standard/issues/481#issuecomment-429653699。并托管 VS2017 支持 .net 4.7.1:github.com/Microsoft/azure-pipelines-image-generation/blob/…
    • 澄清一下,这是有道理的,因为当我回顾过去时,我们开始了将解决方案的部分转换为 .NET Standard 2.0 的过程,我开始认为这是这个问题开始出现的时候.感谢您提供额外的参考资料 - 我现在有一些东西要研究......
    • @BrendanGreen,永远欢迎你 :)。如果您需要进一步的帮助,请告诉我。
    猜你喜欢
    • 2016-06-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-18
    • 2021-07-10
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多