vstest: `dotnet test` fails to find .NET Core 3.0 SDK when installed from script to custom location

Description

dotnet test fails to find .NET Core SDK 3.0 when installed from https://dot.net/v1/dotnet-install.ps1 into a custom install location with -NoPath in Azure DevOps on Windows.

This does not appear to be an issue with AppVeyor, Travis CI or Azure DevOps on Linux and macOS.

This worked with various versions of the .NET Core SDK up to and including 3.0.0 RC1, but appears to have been broken in 3.0.0 with 16.3.0.

Looking at the diff between 16.3.0 and 16.3.0-preview-20190828-03, this might be a regression caused by the changes in https://github.com/microsoft/vstest/pull/2161.

Steps to reproduce

Issue can be observed in this Pull Request from commit 612e825179e4b3435613926b513a7b9a07132753: https://github.com/justeat/httpclient-interception/pull/127

Expected behavior

Tests run.

Actual behavior

dotnet test fails with:

Test run for d:\a\1\a\JustEat.HttpClientInterception.Tests.dll(.NETCoreApp,Version=v3.0)
Microsoft (R) Test Execution Command Line Tool Version 16.3.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...

A total of 1 test files matched the specified pattern.
Testhost process exited with error: It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - Check application dependencies and target a framework version installed at:
      C:\Program Files\dotnet
  - Installing .NET Core prerequisites might help resolve this problem:
      https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download
  - The following versions are installed:
      1.0.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.5 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.7 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.8 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.9 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.10 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.11 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.12 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.13 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.14 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.15 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.0.16 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.1 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.5 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.7 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.8 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.9 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.10 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.11 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.12 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      1.1.13 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.0.0 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.0.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.0.5 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.0.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.0.7 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.0.9 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.0 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.1 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.5 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.7 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.8 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.9 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.1.12 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.2.0 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.2.1 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.2.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.2.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
. Please check the diagnostic logs for more information.
Results File: D:\a\1\s\tests\HttpClientInterception.Tests\TestResults\VssAdministrator_fv-az635_2019-09-21_15_13_42.trx
Test Run Aborted.

Diagnostic logs

See here.

Environment

Azure DevOps Visual Studio 2019 image.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 7
  • Comments: 20 (10 by maintainers)

Commits related to this issue

Most upvoted comments

I fix the issue downgrading Microsoft.Net.Test.Sdk 16.3.0 to 16.2.0, if this can help!

Same issue here after installing visual studio 16.4 (that comes with .Net core 3.1). Downgrading Microsoft.Net.Test.Sdk solved the issue

I fix the issue downgrading Microsoft.Net.Test.Sdk 16.3.0 to 16.2.0, if this can help!

I am not.

Thank you for the prompt reply @unaizorrilla! For the others, please feel free to let us know if you are still having some issue.

By console do you mean cmd.exe or vstestconsole.exe?

I meant bitness of the vstest.console / dotnet test. Invoking a 64-bit test project should start a 64-bit test host even if we start it via 32-bit dotnet test. I am not 100% sure what is happening in this case, because I did not analyze it deeper. But it should be pretty easy to see once you take time to create a test project for it.

Having a 64-bit unit tests launched from a 32-bit host on a 64-bit OS is also fine. The unit tests would still be running in 64-bit mode and a 32-bit and 64-bit app can communicate with eachother over IPC or similar. Many of the Visual Studio Out of Process components work this way because VS itself is 32-bits, but compilers and other tools may need to be 64-bits.

Yup that is exactly how it works for vstest console as well. A 32-bit VS runs 64-bit TestWindowStoreHost that runs 32-bit vstest.console that then runs 32-bit or 64-bit test host and they all communicate via sockets 🙂

@vagisha-nidhi, I’ve simplified a repro to:

  1. Ensure you have a clean machine without .NET Core already installed A. the Azure DevOps ‘Microsoft-hosted’ agents available for OSS seem to fit the bill
  2. Download the 32-bit .NET Core SDK for 3.0.100 A. This could be downloaded manually from get.dot.net B. This could be downloaded using the dotnet-install.ps1 script and explicitly specifying -Architecture x86
  3. Create a unit test project targeting netcoreapp3.0 with a simple test A. This defaults to AnyCPU. I did not check if explicit x86 reproduces, as I need AnyCPU
  4. Reference the Microsoft.NET.Test.Sdk, Version=16.3.0
  5. Run dotnet test

You can optionally change the Microsoft.NET.Test.Sdk version to the last public preview (16.3.0-preview-20190828-03) and see that running dotnet test works as expected.

Looks like this issue is related to x86 vs. x64, as it seems that a 32-bit PowerShell script will install the x64 version of .NET (because it looks at the machine’s architecture), then the SDK will try and use 32-bit version of the SDK (which isn’t installed) and then fail.

At least, this is behaviour I’m seeing using TeamCity.