question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Version conflicts in test project depending on a Microsoft.AspNetCore.App project

See original GitHub issue

Consider the following situation: I have a ASP.NET Core 2.1 app using Microsoft.AspNetCore.App which has a dependency on IdentityServer4.AccessTokenValidation. I also have a test project running on netcoreapp2.1 that references the web app.

When I compile the web project, everything is fine, however when I compile the test project, I do get the following warnings during build:

warning MSB3277: Found conflicts between different versions of “Microsoft.Extensions.Options” that could not be resolved. warning MSB3277: Found conflicts between different versions of “Microsoft.Extensions.Configuration.Abstractions” that could not be resolved. warning MSB3277: Found conflicts between different versions of “Microsoft.AspNetCore.Hosting.Abstractions” that could not be resolved. warning MSB3277: Found conflicts between different versions of “Microsoft.Extensions.DependencyInjection.Abstractions” that could not be resolved. warning MSB3277: Found conflicts between different versions of “Microsoft.AspNetCore.Http.Abstractions” that could not be resolved. warning MSB3277: Found conflicts between different versions of “Microsoft.AspNetCore.Http.Features” that could not be resolved.

I asked on Slack about this and @dasMulli suggested that the reason this happens is that the “dependency closure of the runtime that the project under test uses doesn’t win over the test project since the test project won’t run on the asp.net core shared framework” and “aside, the web project now chooses the package reference version using the ‘latest known’ mechanism of the web sdk”.

So if I understand this correctly, since the test project is not a Web SDK project, it does not have access to the shared framework from .App so it will fall back to normal dependency resolution which in this case will just use the latest release version. As a result, right now with the previews being there, normal 2.0 dependencies will be used.

This can be confirmed by looking at the detailed logs:

“Microsoft.AspNetCore.Hosting.Abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was chosen because it was primary and “Microsoft.AspNetCore.Hosting.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was not. “Microsoft.Extensions.Configuration.Abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was chosen because it was primary and “Microsoft.Extensions.Configuration.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was not. “Microsoft.Extensions.DependencyInjection.Abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was chosen because it was primary and “Microsoft.Extensions.DependencyInjection.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was not. “Microsoft.AspNetCore.Http.Abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was chosen because it was primary and “Microsoft.AspNetCore.Http.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was not. “Microsoft.Extensions.Options, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was chosen because it was primary and “Microsoft.Extensions.Options, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was not. “Microsoft.AspNetCore.Http.Features, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was chosen because it was primary and “Microsoft.AspNetCore.Http.Features, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was not.

This could likely be a huge problem if the tests use or test something that is 2.1 exclusive (like all the new integration test stuff).

As suggested on Slack, the problem can be solved by adding an explicit reference to Microsoft.AspNetCore.App on version 2.1.0-rc1-final to the test project. But obviously this prevents the test project from just pulling in the dependency transitively.


Complete steps to reproduce this, using 2.1.300-rc1-008673:

dotnet new razor -o Example
dotnet new xunit -o Example.Test
dotnet add .\Example\Example.csproj package IdentityServer4.AccessTokenValidation
dotnet add .\Example.Test\Example.Test.csproj reference .\Example\Example.csproj
dotnet build .\Example.Test\Example.Test.csproj

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:6
  • Comments:37 (12 by maintainers)

github_iconTop GitHub Comments

42reactions
dasMullicommented, Jan 19, 2019

@giggio actually there is a new workaround when using the 2.2 tooling (even for 2.1 apps):

Add a versionless reference to Microsoft.AspNetCore.App:

<PackageReference Include="Microsoft.AspNetCore.App" />

The change to Microsoft.NET.Sdk.Web is no longer necessary since the version selection has been moved to the base SDK.

25reactions
jnovickcommented, Dec 28, 2018

This is still happening for me on .NET Core 2.2, but installing Microsoft.AspNetCore.App fixed it.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Version conflict in AspNetCore
The reason this happens is that your locally installed Microsoft.AspNetCore.App is of version 2.1.0 and not 2.1.1.
Read more >
MSB3277: Found conflicts between different versions of ' ...
This error occurs during a build when more than one version of the same dependent assembly is referenced in a build of the...
Read more >
Troubleshoot .NET Framework targeting errors
To resolve the error, make sure that your application targets a .NET version that's compatible with the version that's targeted by the projects...
Read more >
How to resolve Error NU1107 Version conflict detected for ...
I am getting this error as follows. NU1107 Version conflict detected for Microsoft.CodeAnalysis.Common. Install/reference Microsoft.
Read more >
NETSDK1071: A PackageReference to '{0}' specified a ...
How to resolve the issue of a PackageReference to a metapackage included with the framework with a version.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found