I recently posted about the process to upgrade from ASP.NET Core 3.1 to ASP.NET Core 5.0 (preview 1) and mentioned that I had an issue with running my unit tests from Visual Studio 16.6 (preview 1).
In this short post, I want to explain what caused my issue and how to resolve it.
Symptoms of the Problem
After upgrading my solution, which included a test project, I was unable to run my unit tests from Visual Studio. However, they ran successfully when using the .NET CLI, dotnet test command. This seemed odd, and at the time, I didn’t spend any longer digging into it.
When attempting to run the tests inside Visual Studio, the tests all reported as “Not Run” and had exclamation marks against them. Not good!
I checked the output from the tests and noted the following failure message.
========== Test discovery aborted: 0 Tests found in 71.6 ms ==========
---------- Starting test run ----------
Testhost process exited with error: It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0-preview.1.20124.5' was not found.
- The following frameworks were found:
3.1.2 at [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
The specified framework can be found at:
- https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=5.0.0-preview.1.20124.5&arch=x86&rid=win10-x86
. Please check the diagnostic logs for more information.
Testhost process exited with error: It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0-preview.1.20124.5' was not found.
- The following frameworks were found:
3.1.2 at [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
The specified framework can be found at:
- https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=5.0.0-preview.1.20124.5&arch=x86&rid=win10-x86
. Please check the diagnostic logs for more information.
========== Test run aborted: 0 Tests run in 265.7 ms (0 Passed, 0 Failed, 0 Skipped) ==========
After posting my upgrade blog post, Glenn Condron from the ASP.NET team noticed my report of this issue and referred it to Kendra Havens, a PM on the Visual Studio team. As a result I was asked to submit feedback of this as a potential Visual Studio 16.6 bug.
Understanding the Problem
I received a response from the Visual Studio team very quickly. The explanation proved to be quite straightforward.
The preview installs of .NET 5 SDKs do not install both x86/x64 runtimes. I had explicitly downloaded and installed the x64 version of the SDK. Based on the output from the test failure, it was clear that the test SDK was attempting to load the runtime framework from the ‘Program Files (x86)’ folder, where of course, the framework did not exist.
Since I had only installed the x64 runtime, I would need to ensure that the selected architecture used to run the tests, was also x64. It’s important to point out here that I ran into this issue because of the way the preview installers are set up. Once the .NET SDK is bundled with a final version of Visual Studio 16.6, I expect that both runtimes will be installed.
You can configure the processor architecture from the Test Explorer settings. Opening the settings and hovering over “Processor Architecture for AnyCPU Projects” on my PC presented me this. My setting was explitly chosing the x86 architecture.
Fixing the Problem
The fix in my case was very simple; I chose the Auto option. I could also have selected x64 here.
This time they all executed and passed. My problem was solved!
Summary
When running previews of .NET and Visual Studio, it’s worth remembering that things may not work exactly as in final releases. In this case, I hadn’t paid enough attention to the clue from the test output, which hinted at the tests looking for the x86 runtime. Even if I had, I’m honestly not sure I’d have thought to check the Test Explorer settings, without the hint from the team.
I think this is a good example of learning through failure. I had hit a error which I hadn’t seem before, in this case because I was using preview products. Now that I’m aware of the setting, this will hopefully not trip me up again. All experience is valuable!
Have you enjoyed this post and found it useful? If so, please consider supporting me:
