TFS Tests do not match framework settings

Question

I am attempting to move a solution from TFS 2012 to TFS 2018 SP2RC2 but I can't get the unit tests to run correctly. All projects have been re-targeted to 4.7.1 and are built as x86 platform. We have a testsettings file that supplies nothing but deployment items. I am using the new VSTest Platform Installer task (as directed by MS) and the VS Test Task. At the start of the test run I get the following message:

Test run will use DLL(s) built for framework .NETFramework,Version=v4.5 and platform X86. Following DLL(s) do not match framework/platform settings.

So all of the test are skipped as they target 4.7.1. Where is this 4.5 setting coming from? I cannot find it specified anywhere and can't figure out how to change it.

Lineman

What's the list of assemblies that are skipped? I ask because it may just be dependency assemblies that target .NET 4.5 (say, NuGet packages), and you actually have a completely different problem. – Studnia

Also, TFS 2018 Update 2 RTM shipped today, probably a good idea to update. – Studnia

@DanielMann It skips ALL of our assemblies. The task only looks at assemblies with "Test" in the name, but they are all skipped. We don't use 3rd party stuff really as we are in a heavily regulated (medical) arena. – Lineman

It seems this is only an issue when using the testsettings file. Without that, the tests start to run. Of course, then some items don't get deployed. I know the testsettings file is legacy at this point, but does that just force it to 4.5? – Lineman

testsettings forces it to use mstest.exe instead of vstest.console.exe. Use runsettings instead. – Yapok

Answer 1

There is a /Framework: parameter that you can specify to VSTest.

In your case, you should specify /Framework:.NETFramework,Version=v4.7.1

See more at https://msdn.microsoft.com/en-us/library/jj155796.aspx?f=255&mspperror=-2147217396

To add this parameter in a Azure DepOps yaml pipeline, use the otherConsoleOptions argument

- task: VSTest@2
    otherConsoleOptions: '/Framework:.NETFramework,Version=v4.7.1'

Helban

Thanks! In my AZDO pipeline I was getting the error below. Adding this command to my vstest task fixed it - /Framework:.NETCoreApp,Version=v2.0 Test run will use DLL(s) built for framework .NETFramework,Version=v4.0 and platform X86. Following DLL(s) do not match framework/platform settings. MyProject.UnitTest.dll is built for Framework 2.0 and Platform AnyCPU. – Mayemayeda

@Lara - were you able to fix this in VS2019? – Rayshell

@Cosmin, I am afraid not. – Astraphobia

It looks that in the latest preview they have fixed it - developercommunity.visualstudio.com/content/problem/579073/…. Didn't confirm it myself yet. – Rayshell

Thanks @Rayshell - I had this issue running tests in VS2019 16.1.6 and using VS2019 Preview 16.3.0 Preview 1.0 fixed it. – Sholes

The latest 16.2.1 release has this fix, so no need for a preview version if you don't want it. – Tuppeny

I had such an issue in Azure Pipelines (Azure DevOps), and adding the following line to the VSTest task fixed it: otherConsoleOptions: '/Framework:.NETStandard,Version=v2.0' – Moskva

Answer 2

The fix I found for this in Visual Studio is way easier than I thought:

1. Exit all instances of VS
2. Open your project folder in Windows Explorer, find the .vs folder, delete it
3. Restart VS, the folder rebuilds itself, tests work again.

Apparently there are some settings that the NUnit plugin stashes in this folder and they are in binary so you can't edit them. This happened to me after I updated to NUnit3TestAdapter version 3.17.

Oakes

This worked great for me although it's the .vscode folder; not .vs. In my situation, I was going back to an earlier version that uses .NET v2.1. The later version was using .NET v6.0 and following Dennis' steps cleared out the newer version of .NET and my project ran successfully. – Unsuspecting

Deleting the ".vs" folder did fix it for me, but that folder was in a different location in my solution. It was also marked as hidden. So make sure to turn on "Show hidden files and folders" from the View menu in windows explorer. – Microscopic

Answer 3

For me skipping tests in local VS2022 run was related to testsettings file. I deleted .vs folder of my project then selected Test ->Configure Run Settings -> Select Autodetect run settings file After that I can debug unit tests

Carlyle

Answer 4

I had trouble running a test project developed on another machine where no tests where able to be run using the MSTest test runner. In addition to message in your question I also got the messages:

Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.

Discover test finished: 0 found

In my case I resolved it by unloading and updating the .csproj file adding the following import directly under the root Project tag.

<Import Project="..\packages\MSTest.TestAdapter.1.3.2\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.3.2\build\net45\MSTest.TestAdapter.props')" />

Hope this answer will help save you some time.

Thinnish

Answer 5

I got this error using Visual Studio 2019 with NUnit 3.12.0:

Test run will use DLL(s) built for framework .NETFramework,Version=v4.5 and platform X86. Following DLL(s) do not match framework/platform settings. Project.UnitTests.dll is built for Framework 4.5.2 and Platform AnyCPU.

Installed NUnit3TestAdapter 3.13.0 and then everything started working. Did not need to modify Framework version or CPU settings.

Turf

This worked for me too. Tests using MSTest, running with the Visual Studio Test task in Devops with the MSTest.Adapter fails. Installing the NUnit3TestAdapter and all tests run fine. Any idea why NUnit3TestAdapter fixes this? – Dressel

@JoelLister Nope, I was just glad it worked and did not investigate further. – Turf

Answer 6

TLDR: If you use *.runsettings file for your test projects, try removing TargetFrameworkVersion node

I had similar problem but with .Net Core

Test run will use DLL(s) built for framework .NETFramework,Version=v4.0 and platform X64. Following DLL(s) do not match framework/platform settings. MyProject.Tests.dll is built for Framework .NETCoreApp,Version=v3.1 and Platform AnyCPU.

Turns out there was another problem. For my other .NET Framework test projects I had defined *.runsettings file

And in this file I had

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
    <!-- Parameters used by tests at runtime -->
    <TestRunParameters>
        <Parameter name="ConnectionString" value="Data Source=localhost;Initial Catalog=MyDatabase;Integrated Security=True" />
    </TestRunParameters>
    <RunConfiguration>
        <!-- Framework35 | [Framework40] | Framework45 | FrameworkCore10-->
        <TargetFrameworkVersion>Framework40</TargetFrameworkVersion>
    </RunConfiguration>
</RunSettings>

Supported values for TargerFrameworkVersions based on https://learn.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019 are:

FrameworkCore10 for .NET Core sources, FrameworkUap10 for UWP-based sources, Framework45 for .NET Framework 4.5 and higher, Framework40 for .NET Framework 4.0, and Framework35 for .NET Framework 3.5.

But for Core 3.1, FrameworkCore10 doesnt work!

So I removed node TargetFrameworkVersion completely

Ftc

Answer 7

Had the exact same issue as Bill, working on legacy code in VS2019, nothing else had worked. I simply changed the Run Settings to use the Auto Detect.

In the menu go to Test -> Configure Run Settings -> Auto Detect runsettings File

Schreck

In VS2017, there is no auto detect, so you have to set this to x86 or x64 manually. This link shows this as well: github.com/Microsoft/vstest/issues/907 – Absorber

Answer 8

I had the same problem in VS 2019 on a legacy project.

Restarting Visual Studio did not help, nor did build as Release then rebuild as Debug, nor did deleting the .vs folder. I did those things and still was unable to run tests, getting a message like the OP's during test detection each time. I mention these here for completeness.

I deleted the LocalTestRun.testrunconfig file and the *.vsmdi file from Solution Explorer, cleaned and rebuilt the solution, and the unit tests worked again.

Revivalism

Answer 9

I was running into the same issue with the Visual Studio Test Task version 2 in an Azure Devops 2019 pipeline after a .csproj test project was upgraded from .NetFramework 4.6.1 to .NetCore 3.1.

The fix for us was to be more specific when specifying the test files. The default of **\*test*.dll was finding several other assemblies with "test" in their names that didn't exist before the upgrade. Using an explicit **\<MyTestAssemblyName>.dll fixed the issue.

Bursiform