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

@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.

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

Re-opening for us to consider this again in 2.2.

With the latest 2.1.301 SDK, in addition to the mentioned changes in https://github.com/aspnet/Mvc/issues/7710:

• Using <Project Sdk="Microsoft.NET.Sdk.Web">
• Adding <PackageReference Include="Microsoft.AspNetCore.App" />

I also had to add <RuntimeFrameworkVersion>2.1.1</RuntimeFrameworkVersion> or otherwise I get a package downgrade warning for “Microsoft.NETCore.App” (being downgraded to 2.1.0).

Looking a bit further, it seems that the ASP.NET Core dependencies are not pulled in at all transitively from the web project. If you skip the step where I add a reference to IdentityServer4.AccessTokenValidation, then there will be no sign of ASP.NET Core within the test project. Even a simple unit test like this will not compile because Microsoft.AspNetCore.Hosting is missing:

[Fact]
public void Test()
{
    var webHost = new WebHostBuilder().UseStartup<Startup>().Build();
}

It seems that adding the reference to IdentityServer4.AccessTokenValidation which itself depends on a few ASP.NET Core assemblies will make some assemblies appear in the test project; while those will cause the mentioned conflict.

I looked at the last community standup again where MVC testing was the topic, and what they did there was change the test project to be a Web SDK project and reference Microsoft.AspNetCore.App explicitly again. So they are did not get the dependencies transitively either, and unfortunately didn’t really consider why they had to do what they did.

Just ran into this with ASP.NET Core 2.2. Adding <PackageReference Include="Microsoft.AspNetCore.App" /> to the test project fixed the issue, but this is really a horrible user experience, because the error gives the user no idea what’s wrong. Even looking at the detailed build log file is useless:

2> There was a conflict between “Microsoft.AspNetCore.Hosting.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” and “Microsoft.AspNetCore.Hosting.Abstractions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60”. 2> “Microsoft.AspNetCore.Hosting.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was chosen because it was primary and “Microsoft.AspNetCore.Hosting.Abstractions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” was not. 2> References which depend on “Microsoft.AspNetCore.Hosting.Abstractions, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” [%USER_PROFILE%.nuget\packages\microsoft.aspnetcore.hosting.abstractions\2.1.0\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Abstractions.dll]. 2> %USER_PROFILE%.nuget\packages\microsoft.aspnetcore.hosting.abstractions\2.1.0\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Abstractions.dll 2> Project file item includes which caused reference “%USER_PROFILE%.nuget\packages\microsoft.aspnetcore.hosting.abstractions\2.1.0\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Abstractions.dll”. 2> %USER_PROFILE%.nuget\packages\microsoft.aspnetcore.hosting.abstractions\2.1.0\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Abstractions.dll 2> References which depend on “Microsoft.AspNetCore.Hosting.Abstractions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” []. 2> %SOLUTION_DIR%\My.IdentityServer\bin\Debug\netcoreapp2.2\My.IdentityServer.dll 2> Project file item includes which caused reference “%SOLUTION_DIR%\My.IdentityServer\bin\Debug\netcoreapp2.2\My.IdentityServer.dll”. 2> %SOLUTION_DIR%\My.IdentityServer\bin\Debug\netcoreapp2.2\My.IdentityServer.dll

This is such a waste of time and it has to be a pretty common problem - please fix this!

I can confirm the problem still happens with sdk 2.2.102. The workaround to change the sdk to Microsoft.NET.Sdk.Web and reference Microsoft.AspNetCore.App works. The problem is that all projects become executable and web projects. The icon changes in Visual Studio too, which is a terrible.

For anyone interested, your .csproj has to start with:

<Project Sdk="Microsoft.NET.Sdk.Web" />

And add the Package Reference:

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

It all works. Unless you have a library, then you also have to add to your property group:

<OutputType>Library</OutputType>

If you don’t you get a compiler error that you don’t have a main method, with CS5001.

There is a thread on Stack Overflow about it.

I hope this gets fixed soon.

@natemcmaster Sorry about not answering you earlier, if you still need a repro let me know.

This issuse seems to have another side-effect, related to test projects on the latest SKD (.net core 2.1.5, SDK version 2.1.403):

We’re using Team Foundation Server (Version Version 16.131.27701.1, on-premise) and Visual Studio tells us, that the source code bindings for test projects is invalid. The weird part is, that everything seems to work fine, except the squiggles within VS’s dialog…

Turn’s out, that fixing the issue mentioned above within the .csproj (i.e. changing the SDK to the web-version, adding a direct reference to Microsoft.AspNetCore.App and setting the outputtype to exe) also fixes the problem with the TFS bindings - but only if launchsettings.json (which is auto-created during the changes) is included in the following check-in.

I have no clue whatsoever is causing this behaviour and why it is related with the original problem. Neither do I understand what originally caused the source code binding problem - but: It is reproducable for us… Just add a new test project to an existing solution and the squiggles appear. Apply the fix and they’re gone.

TLDR; A .csproj for the test project similar to this seems to fix both issues:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup Label="Globals">
    <Configurations>Debug;Release</Configurations>
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
  </PropertyGroup>

  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RuntimeFrameworkVersion>2.1.5</RuntimeFrameworkVersion>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
    <IsPackable>false</IsPackable>
    <OutputType>Exe</OutputType>    
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
    <PackageReference Include="MSTest.TestAdapter" Version="1.3.2" />
    <PackageReference Include="MSTest.TestFramework" Version="1.3.2" />
  </ItemGroup>
</Project>

Is the workaround mentioned all over this thread only for integration test project or unit test project too?

It is for all tests, or even all non-web projects that have a reference to a web project. It is not really a workaround in that the web reference did not flow transitively in .NET Core 2.x. You need to add it, and you should add it without the version so that the SDK can pick the correct version to avoid conflicts.

Better news: starting with .NET Core 3.0, the web reference will flow transitively and you can reference a web project from a test project without any other steps. So I am closing this. The design of 2.x cannot be changed, but we specifically designed things in 3.0 to have transitive FrameworkReferences, and this was a motivating scenario for that.

I was also hit by this today and adding the <PackageReference Include="Microsoft.AspNetCore.App" /> to my xunit project fixed this for me. The error was related to Microsoft.Aspnetcore.html.abstractions. If needed I can share the project internally.

I just ran into this issue. Super confusing and hard to diagnose. I added the PackageReference to my test project and the warnings resolved. Specific fix:

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

The build throws warnings with above workaround when platform is set to x64.

Example webapp csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>

    <Platforms>x64</Platforms>

  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
  </ItemGroup>

</Project>

example test csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>

    <Platforms>x64</Platforms>

    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.0.1" />
    <PackageReference Include="xunit" Version="2.4.0" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\WebApplication1\WebApplication1.csproj" />
  </ItemGroup>

</Project>

But works fine when I set <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch> in test project

With the latest 2.1.301 SDK, in addition to the mentioned changes in aspnet/Mvc#7710:

• Using <Project Sdk="Microsoft.NET.Sdk.Web">
• Adding <PackageReference Include="Microsoft.AspNetCore.App" />

I also had to add <RuntimeFrameworkVersion>2.1.1</RuntimeFrameworkVersion> or otherwise I get a package downgrade warning for “Microsoft.NETCore.App” (being downgraded to 2.1.0).

With the latest 2.1.301 SDK, in addition to the mentioned changes in aspnet/Mvc#7710:

• Using <Project Sdk="Microsoft.NET.Sdk.Web">
• Adding <PackageReference Include="Microsoft.AspNetCore.App" />

I also had to add <RuntimeFrameworkVersion>2.1.1</RuntimeFrameworkVersion> or otherwise I get a package downgrade warning for “Microsoft.NETCore.App” (being downgraded to 2.1.0).

Worked for me by only using:

• Using <Project Sdk="Microsoft.NET.Sdk">
• Adding <PackageReference Include="Microsoft.AspNetCore.App">

thanks for your guidance.

I am also getting the package downgrade warning when using 2.1.301, but only when publishing with -r. Also fixes if I use <RuntimeFrameworkVersion>2.1.1</RuntimeFrameworkVersion>.

When using a 2.2 or newer sdk (even to target 2.1), you should not need to change the sdk. The versionless package reference should be enough.

And when targeting 3.0, you don’t need the pacge reference either. Everything should flow across the project reference.

If you have a case where either of above is not working, please open a new issue with the detailed repro steps.

If this is decided to be “by design” we should at least have a better warning message which indicates the resolution. It took me a pretty long time to find this issue. The current conflict warning I had just showed that for some reason the test project is dependent on version 1.0.0.0 of the conflicting dlls, which was confusing since the test project did not reference those dlls and no project in my solution referenced version 1.

Thank you to the above contributors who posted the resolution!

I can confirm that adding <PackageReference Include="Microsoft.AspNetCore.App" /> to the test project was all that was needed to resolve it in dotnet v2.2.204 .

@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.

Damn, it doesn’t work in SDKv2.2.107 for me

Thanks. The RuntimeIdentifier was a crucial part to reproducing the issue. I’ve opened https://github.com/dotnet/sdk/issues/2364. This is indeed separate from the AspNetCore.App issue as it reproduces in a simple console application project. I mentioned a few workarounds in the issue description of https://github.com/dotnet/sdk/issues/2364