具有相同nuget包的项目引用了不同版本的程序集 [英] Projects with same nuget package referencing different version of assembly

问题描述

我在这里生气，我希望这是我根本忽略的事情.

I am going mad here, and I am hoping that it's something that I've simply overlooked.

我遇到了间歇性的FileLoadExceptions，即使部署之间的代码更改不更改任何程序集引用，部署之后仍会显示FileLoadExceptions.

I am experiencing intermittent FileLoadExceptions, which are showing up after deployments even if the code change between deployments doesn't change any assembly references.

看一下最近的例子，由于System.IO.Compression，找不到4.2.0.0版本，我看到了FileLoadException.

Looking at the most recent example of this, I am seeing a FileLoadException due to System.IO.Compression, version 4.2.0.0 not being found.

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

In all cases, we are referencing the System.IO.Compression nuget package, version 4.3.0.

看着我们解决方案中的两个项目，我注意到了一些非常奇怪的东西.
ProjectA引用ProjectB.

Looking at two projects in our solution, I noticed something very strange.
ProjectA references ProjectB.

ProjectA在其packages.config文件中具有以下引用:

ProjectA has in its packages.config file the following reference:

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

ProjectB在其package.config文件中具有以下引用:

ProjectB has in its package.config file the following reference:

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

当我查看*.csproj文件时，会看到以下内容:

When I have a look into the *.csproj files, I see this:

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

太好了，在两种情况下，我们都指向磁盘上的同一程序集.

Great, we are pointing to the same assembly on disk in both cases.

但是，当我在解决方案资源管理器中查看引用的文件时，会看到以下内容:

Yet, when I look at the referenced file in the Solution Explorer, I see this:

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包文件夹中的版本.

The above is referencing a file that's in C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.IO.Compression.dll, and more importantly has a version of 4.2.0.0, rather than the version that's in the nuget packages folder.

ProjectB:

以上内容正确指向了程序集的nuget软件包版本，实际上是4.1.2.0.

The above correctly points to the nuget packages version of the assembly, which is in fact 4.1.2.0.

要重申，引用ProjectB的ProjectA都具有绑定重定向，该重定向将执行以下操作:

To reiterate, ProjectA, which references ProjectB, and both have a a binding redirect that's doing the following:

<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版本?而且，我该怎么做才能解决此问题?

So my question is why is Visual Studio pulling down a version of System.IO.Compression from a location that is not referenced (directly) by any of our projects? And, what can I do to fix this?

此外，当我在本地使用Visual Studio 2019的(当前)RC版本时，我们的构建代理(Azure DevOps Pipelines)正在使用Visual Studio2017.

Further, while locally I am using the (current) RC version of Visual Studio 2019, our build agents (Azure DevOps Pipelines) are using Visual Studio 2017.

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

At runtime, we find the aforementioned exception logged, and our processing that creates a ZIP file fails.

更新

此外，我还做了一些其他的挖掘工作，发现绑定重定向指向该程序集的4.2.0.0版本.我将其手动降到4.1.2.0，然后通过一些其他运行状况检查将其再次部署到我们的测试环境中，以了解我们的工作情况.

Further to the above, I've done some additional digging, and found a binding redirect that points to the 4.2.0.0 version of this assembly. I've dropped that manually down to 4.1.2.0, and am deploying again to our test environment with some additional health checks to see how we go.

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

Still remaining to understand how we would have gotten into this state, and why the discrepancies with what the csproj is pointing to vs. what is seen in the Solution Explorer.

推荐答案

具有相同nuget包的项目反映了不同版本的程序集

Projects with same nuget package refrencing different version of assembly

这是我们构建.NET Framework 4.6.x时的已知问题.应用程序.

This is a known issue when we build a .NET Framework 4.6.x app.

那是因为:

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

This is due to the injected support for NETStandard 2.0. We inject new assemblies into NET 4.6.1 and later desktop projects in order to add support for netstandard2.0. We do this in targets now instead of packages because its no longer a requirement to reference a package to build a netstandard library. This injection happens whenever we see a netstandard1.5 or greater library referenced (see dotnet/sdk#1386).

要解决此问题，我们可以将绑定重定向添加到那些引用，以使用对System.IO.Compression的标准引用，而不为System.IO.Compression引入任何Nuget程序包.如果仍要从nuget包中使用引用System.IO.Compression，则可以从MSBuild工具中删除System.IO.Compression.

To resolve this issue, we could add binding redirect to those reference to use standard references to System.IO.Compression and not bring in any Nuget package for System.IO.Compression. If you still want to use the reference System.IO.Compression from nuget package, you can delete System.IO.Compression from the MSBuild tooling.

从Github中查看更多详细信息:

Check more detail info from the Github:

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

希望这会有所帮助.

这篇关于具有相同nuget包的项目引用了不同版本的程序集的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！