Unable to consolidate NuGet package transitive dependency versions in two NET Standard projects

血红的双手。 提交于 2020-12-03 07:49:42

问题


Adding EF Core to a NET Standard project introduces transitive dependency versions incompatible with NuGet packages in other projects

I have a solution with multiple .NET Standard 2.0 projects.

One Project A uses the Google.Protobuf (3.11.2) NuGet package, that depends on

System.Memory (4.5.3)
    System.Buffers (4.4.0)
    System.Numerics.Vectors (4.4.0)
    System.Runtime.CompilerServices.Unsafe (4.5.2)

A few other projects also depend on System.Memory and all use the same dependency versions.

Another Project B uses Microsoft.EntityFrameworkCore (3.1.0) NuGet package that depends on

System.Memory (4.5.3)
    System.Buffers (4.5.0)
    System.Numerics.Vectors (4.5.0)
    System.Runtime.CompilerServices.Unsafe (4.7.0)

Even though the System.Memory version is (4.5.3) in both cases, it depends on System.Buffers, System.Numerics.Vectors and System.Runtime.CompilerServices.Unsafe and their versions differ.

When I run the application that uses these projects (a Microsoft Prism WPF .NET Framework 4.8 app that uses Unity IoC) UnityContainer throws the following exception:

System.IO.FileLoadException: 'Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

After searching for a solution I added this to my NuGet.Config:

  <config>
    <add key="DependencyVersion" value="Highest" />
  </config>

In both, %appdata%\Nuget and in the root folder of the .sln file.

I also deleted the %userprofile%\.nuget\packages folder.

Then I removed the NuGet packages from the projects and added them back again, but their dependecies come with the same versions as before.

If I navigate to "Manage NuGet Packages for Solution..." in Visual Studio and choose "Consolidate" it just says "No packages found"


回答1:


I managed to reproduce the problem. I created two new .net standard 2.0 projects class libraries.

On the first i added EF Core. On the second i added Google protobuf.

Both same versions as you mention.

For the EF core I created a new class that just inherits from DbContext. For the protobuff i just created an empty class. I am not familiar on how to use it. I was still able to replicate the problem though.

The i created a console app .net framework 4.7.2 referencing the above two projects.

I instantiated the two classes in the Console App and got the error System.IO.FileLoadException: 'Could not load file or assembly...

How i resolved it.

I went to all three projects and added this line to the csproj.

<RestoreProjectStyle>PackageReference</RestoreProjectStyle>

to the Property Group.

<PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
  </PropertyGroup>

After that i ran again and no error appears.

Please let me know your results. Even if my solution does not work for you. I believe it is good practice to have it.

To quote Oren.
"Using .NET Standard requires you to use PackageReference to eliminate the pain of “lots of packages” as well as properly handle transitive dependencies. While you may be able to use .NET Standard without PackageReference, I wouldn’t recommend it."

Also Hanselman mentions: "The "full" Framework projects are using the older .csproj format and by default, they use package.config to manage dependencies. The newer projects can reference Packages as first-class references. So we need to tell ALL projects in this solution to manage and restore their packages as "PackageReferences.""

Here are my sources.

https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx

https://oren.codes/2017/04/23/using-xamarin-forms-with-net-standard-vs-2017-edition/

Updated according to Sommen's extra info from the github issues Kudos to Sommen for providing this extra info. Also Kudos to Immo Landwerth for providing this Info at GitHub. I will provide as is the Workarounds that already exist in the Github page just for complecity as advised by the OP jinjinov.

Taken from GitHub Issues

Workarounds

Regular .Net Framework projects

  1. Enable automatic binding redirects in the root .Net framework application
  2. Make sure your root application project doesn't use packages.config but uses PackageReference for NuGet Packages If you currently don't have packages.config, simply add if you currently don't have packages.config, simply add <RestoreProjectStyle>PackageReference</RestoreProjectStyle> If you currently do have a packages.config convert the contents to packages references in the project file. The syntax is like this: <PackageReference Include="package-id" Version="package-version" />

ASP.NET web applications and web sites

  1. Web applications and web sites don't support automatic binding redirect generation. In order to resolve binding conflicts, you need to double click the warning in the error list and Visual Studio will add them to your web.config file
  2. In web application projects, you should enable PackageReference like mentioned above. In web sites, you cannot use PackageReference as there is no project file. In that case, you need to install all NuGet packages into your web site that any of the direct or indirect project references depend on.

Unit tests projects

By default, binding redirects aren't added to class library projects. This is problematic for unit testing projects as they are essentially like apps. So in addition to what's outlined in automatic binding redirects you also need to specify GenerateBindingRedirectsOutputType:

<PropertyGroup> <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType> </PropertyGroup>

There is also a discussion section that provides more information -> GitHub discussion




回答2:


Yeah, welcome to the struggle.

Like PanosKarajohn pointed out using packagereference instead of packages.config helps with this. Unfortunately, that is Vs2017 and up and for some of us that is not yet in sight.

The problem is actually explained pretty much here: https://github.com/dotnet/announcements/issues/31

You need to use binding redirects to redirect all the version numbers to the highest on you got and then pray that everything plays nice with each other.

I use the Microsoft.aspnetcore.signalR package in a .net 4.6.1 project and you have the same issues.



来源:https://stackoverflow.com/questions/59644282/unable-to-consolidate-nuget-package-transitive-dependency-versions-in-two-net-st

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!