A Lesson Learnt - Test Explorer Processor Architecture Settings Header

A Lesson Learnt: Test Explorer Processor Architecture Settings

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:

Buy me a coffeeBuy me a coffee Donate with PayPal

.

Steve Gordon

Steve Gordon is a Microsoft MVP, Pluralsight author, senior developer and community lead based in Brighton. He works for Madgex developing and supporting their data products built using .NET Core technologies. Steve is passionate about community and all things .NET related, having worked with ASP.NET for over 15 years. Steve is currently developing cloud-native services, using .NET Core, ASP.NET Core and Docker. He enjoys sharing his knowledge through his blog, in videos and by presenting at user groups and conferences. Steve is excited to be a part of the .NET community and founded .NET South East, a .NET Meetup group based in Brighton. He enjoys contributing to and maintaining OSS projects, most actively helping save lives with open source software and the Humanitarian Toolbox (www.htbox.org). You can find Steve online at his blog www.stevejgordon.co.uk and on Twitter as @stevejgordon