.NET Core build warning due to different versions of EntityFramework

Question

Using VS 2019, several of my projects are generating this build warning when compiling:

5>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2081,5): warning MSB3277: Found conflicts between different versions of "Microsoft.EntityFrameworkCore" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

As the log is not really... verbose (even in detailed mode), I investigated a bit and it seems the error is provoked by Pomelo.EntityFrameworkCore.Mysql/3.1.2 (we are using MariaDB). Here is an extract of a project json, with a dependency on EF 3.1.0 while the current version is 3.1.6:

  "Pomelo.EntityFrameworkCore.MySql/3.1.2": {
    "type": "package",
    "dependencies": {
      "Microsoft.EntityFrameworkCore.Relational": "3.1.0",
      "MySqlConnector": "[0.61.0, 1.0.0)",
      "Pomelo.JsonObject": "2.2.1"
    },

Here is an example of PackageReference include sections of a test project for which the warning is happening:

  <ItemGroup>
    <PackageReference Include="FluentAssertions" Version="5.10.3" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.6.1" />
    <PackageReference Include="NSubstitute" Version="4.2.2" />
    <PackageReference Include="XmlUnit.Core" Version="2.8.0" />
    <PackageReference Include="xunit" Version="2.4.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.2">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="coverlet.collector" Version="1.3.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

What should I do:

• ignore this warning (and wait a pomelo update of the dependency)
• downgrade to EF 3.1.0
• any other idea?

BR

Macaco

add AutoGenerateBindingRedirects and GenerateBindingRedirectsOutputType to csproj, this causes usage of 3.1.6 – Nikolai

Unfortunately, doing so adds an additional warning (and does not solve existing ones): Severity Code Description Project File Line Suppression State Warning MSB3277 Found conflicts between different versions of "System.Configuration.ConfigurationManager" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed. EP2Converter.Tests C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 2081 – Macaco

post all "PackageReference Include " entries of your csprojs – Nikolai

Just added in my question – Macaco

add the Pomelo.EntityFrameworkCore.MySql and Microsoft.EntityFrameworkCore.Relational (and nuget.org/packages/System.Configuration.ConfigurationManager/… if you still get the message) directly to the test project. – Nikolai

Thanks, it did the trick ! – Macaco

ok, I posted it as answer, so that you can accept it to "close" the question. – Nikolai

accepted answer works, note this github link github.com/dotnet/msbuild/issues/2478 which indicates that the behaviour of these includes is somewhat buggy and definitely the workaround to include it again (which we should not have to do) works. – Aleppo

Answer 1

The test project misses the references to the problmematic packages. it is not enough to only have them added to a project that you reference in a 2nd project.

So add them to the testproject:

<PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="3.1.6" />
<PackageReference Include="Pomelo.EntityFrameworkCore.MySql" Version="3.1.2" />

If you still have issues related to System.Configuration.ConfigurationManager also add

<PackageReference Include="System.Configuration.ConfigurationManager" Version="4.7.0" />

to the test csproj.

Nikolai

Lesson Learned: It seems you have to include the same packages in the test application; – Antecedence

This answer works for me, but I have a follow-up question, why do I need to do this? I have other projects which work smoothly even if I don't add the references twice. Ideally I would like to avoid this, since if I upgrade the package in one project I then need to upgrade the package in the other project. – Aleppo

@Aleppo this new packagereference include is buggy. if you run into such issues add the package directly to fix it. – Nikolai

This is just nuisance. but thanks for the workaround! – Twobit