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.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=188.8.131.52, 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>
%appdata%\Nuget and in the root folder of the
I also deleted the
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"
I managed to reproduce the problem.
I created two new
.net standard 2.0 projects class libraries.
On the first i added
On the second i added
Both same versions as you mention.
For the EF core I created a new class that just inherits from
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...
I went to all three projects and added this line to the
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.
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
PackageReferencefor 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.configconvert the contents to packages references in the project file. The syntax is like this:
<PackageReference Include="package-id" Version="package-version" />
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
There is also a discussion section that provides more information -> GitHub discussion
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.