Vstest: .NET 5.0 RC1 - "dotnet build" succeeds to build but "dotnet test" fails to build the same exact SLN

[wli3]

---

Issue moved from dotnet/sdk#13584

• Please respond to @pedramrezaei.

---

_From @pedramrezaei on Monday, September 14, 2020 8:23:06 PM_

Repro:

1- Clone this repo: https://github.com/cloudtoid/interprocess
2- Run dotnet build src/Interprocess.sln and it succeeds.
3- Run dotnet test src/Interprocess.sln and it fails to build.

[nohwnd]

@pedramrezaei could you show us the error please? 🙂

[pedramrezaei]

@nohwnd, here is an example:

src\Sample\Publisher\Program.cs(2,17): error CS0234: The type or namespace name 'Interprocess' does not exist in the namespace 'Cloudtoid' (are you missing an assembly reference?) [...\interprocess\src\Sample\Publisher\Publisher.csproj]

[wdolek]

@nohwnd I'm facing the same issue with w4k-aspnetcore-correlator, however when I specify -f netcoreapp3.1 (as my test project targets that) it works as expected. (However I'm still struggling to make this to work in GitHub Actions)

@pedramrezaei what if you try adding <TargetFramework>/<TargetFrameworks> to your test project? Will it help?

[nohwnd]

@wdolek looking at the error in your pipeline you have net5.0 installed but you don't have the runtime for netcoreapp3.1 which is the target framework of your test projects. This means that you can build the project just fine, because SDK can be used to build any TFM (target framework). BUT then when you try to run it, the test host will try to start using the appropriate runtime (netcoreapp3.1) and will fail to resolve it. You can either:

• install the appropriate aspnetcore runtime on the station (or install the 3.1 SDK)
• allow it to roll forward across major version and run your tests as net5.0 (use ROLL_FORWARD=Major environment variable https://docs.microsoft.com/cs-cz/dotnet/core/tools/dotnet#environment-variables or DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX=2)
• change your test TFM to net5.0

[nohwnd]

@pedramrezaei what if you do dotnet build to build the solution, and then follow it by dotnet test --no-build? make sure to specify the same --configuration in both places though. Would that work? (seems to work for the solution linked above by @wdolek)

[nohwnd]

@wdolek Can repro on your master. I collected some binary logs. It looks like it takes different paths if we provide the TargetFramework and when we don't provide it. When we provided it uses the new core build target. And the old one is missing a reference when calling compiler (csc).

@rainersigwald Would you mind having a quick look on this one, please. Looks like when the build itself has to figure out it is a dotnet core it misses some references and does not succeed, do you see why that would be and if we can change something in the vstest task to fix this?

See the different paths to the build in the bottom. The left one is triggered when we just call dotnet test, which internally triggers VSTest MSBuild task. The other one happens when we normally build or when we call dotnet test -f netcoreapp3.1 which will define TargetFramework global property to netcoreapp3.1 (is that what makes it work though? I don't know, there are more properties defined, but this one seemed like it would be generic enough to force some SDK task to know that this is core build right away).

Took the command line to csc from working and failing build, replaced whitespace (\s+) with newline (\n), and compared the two in vscode. One reference is missing there, which seems to corelate with what we see in the console, a missing reference.

binlogs for the failing and working build, and normal dotnet build attached. Plus the CSC.

binlogs_and_csc.zip

[wli3]

I'll look into this later

[wli3]

actually is it possible to have a minimal repro? The missing reference seems very specific to this project. And there is a fair amount of custom build.

[ap0llo]

I think I ran into the same problem and was already setting up a repro for it before I found this issue.
You can find the repro code here: https://github.com/ap0llo/repro-net5-dotnet-test-error

Some observations I made that might be helpful:

• dotnet test --no-build works fine
• The issue seems to only occur when project referenced from the test project uses mutli-targeting
• The issue seems to only occur when running dotnet test for the solution file, calling dotnet test for the test csproj works fine in my case

[dsplaisted]

This will be fixed in the GA release of .NET SDK 5.0.1xx. So we can close this issue.

[nohwnd]

Thanks! Especially @rainersigwald 👏👏👏

[AraHaan]

I managed to make this not work with the .NET 6 Preview 3 SDK in Github Actions with dotnet test --no-build.