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.
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'
The fix I found for this in Visual Studio is way easier than I thought:
Exit all instances of VS
Open your project folder in Windows Explorer, find the .vs folder, delete it
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.
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.
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.
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
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
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
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.
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.
Related
We recently migrated an ASP.NET Core project from the old project.json format to the new .csproj one.
Everything runs fine on our development machines. But once the application is deployed on the server, IIS fails to launch the application with a 502.5 (Process Failure) exception. The Windows event log mentions a BadImageFormatException for libuv.dll.
Has anyone encountered this? What could be the source of the problem?
Apparently, when an ASP.NET Core project is migrated to the csproj format, there are certain conditions under which the resulting csproj will not receive an explicit <PlatformTarget>.
And Visual Studio doesn't seem to behave identically when doing a usual build vs. publishing.
In both bases, it will build an PE32 executable with the 32BITREQ flag (32-bits only). But when publishing, it will deploy 64-bit libraries alongside, leading to the aforementioned BadImageFormatException, while it doesn't do that in a non-publish build.
Solution: In the project property page, reselect the platform in the dropdown list. Event if it doesn't have any visual effect, an explicit <PlatformTarget> will be added to the csproj on save and this solved my problem.
I'm using Azure 2.7.
I created a C# cloud service that only contains a single worker role. After it's done, the solution contains
A ccproj
A csproj
Both are using the setting of AnyCPU.
I then added the PropertyGroup "Debug|x64" and "Release|x64" into both projects. Also changed the default to x64 for both. As a result, an x64 build.
However, whenever I select "publish" on the "ccproj", I notice that it always builds AnyCPU instead of x64. I cannot find how to force it to build x64 for packaging and deployment.
I then edited both proj file again, and removed the PropertyGroup for "Debug|AnyCPU" and "Release|AnyCPU". After I did this, and when I tried to build x64 again, I got error as:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(723,5):
error : The OutputPath property is not set for project
'AzureWorkerRoleExample.ccproj'. Please check to make sure that you
have specified a valid combination of Configuration and Platform for
this project. Configuration='Release' Platform='AnyCPU'. This error
may also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
I could not figure out how to work around this error.
Any idea on how to force VS to make a x64 build of cloud service and deploy it?
One workaround I found is that: keep AnyCPU property groups, but also put
<PlatformTarget>x64</PlatformTarget>
in the group. Thus the AnyCPU assembly are actually targetting to x64. But this sounds hacky.
Any idea?
Thanks a lot!
I am running NUnit 2.6.3 in VS2012 with NUnit Test Adapater 1.1.0.0, on 64 bit Windows 7. The project is C# winforms.
My project's unit tests have stopped running from within VS. I can launch NUnit directly and run the project OK, but running or debugging tests from within VS just greys them out with this message in the output window:
No test is available in
[Your Output Path].
Make sure that installed test discoverers & executors, platform &
framework version settings are appropriate and try again.
Any pointers of what that means? Where can I find the "platform and framework version settings" - does it refer to NUnit settings, project settings, VS settings, or one of the NUnit plugin settings?
I think that it's related to me updating to the latest version of the Test Adapter, but unfortunately I'm not sure :(
Have fixed it by:
- Updating my project target to .NET framework 4.5 from 3.5 (which my project was in - not my choice!). I cannot find any documentation stating this as a limitation, so perhaps it's a bug.
(I have also changed to using NuGet to install NUnit to the project instead of the VS plugin, but I'm not sure that had an effect).
I had a similar problem but when I tried to run my tests just showed that yellow inconclusive circle.
I ended up solving my problem by going into the bin folder for my project, deleting the NUnit framework dll files and then re-running the tests. Worked like a charm.
In VS2012, I resolved a BadImageException from running a unit test by going to: TEST-> TEST SETTINGS -> DEFAULT PROCESSOR ARCHITECTURE -> x64.
This works in the built in Visual Studio test window but I cannot find the equivalent settings for ReSharper and so I cannot run the unit tests by clicking on the little nodes to left of the test. This is obviously not critical but really annoying.
Does anyone know where these settings are?
ReSharper will run tests with the bit-ness of the test project. So if your test project is AnyCpu, it will run in an AnyCpu host process, which means 32bit on a 32bit system or 64bit on a 64bit system. If you set your project to be 32bit or 64bit specific, ReSharper will run it in a 32bit or 64bit host process.
So, if your production code is 32 bit specific, you should make your test project 32 bit specific, too. If your production code is 64 bit specific, it should work fine, as long as your test project is 64 bit or AnyCpu.
Similarly, it will use the .net runtime of the test project - .net 2 or .net 4.
These defaults work for the vast majority of cases. I've never had to set it manually, but you can override this behaviour, and force a bit-ness or .net framework version. ReSharper 8 has these settings in the Options dialog (Options -> Tools -> Unit Testing). If you set this when a solution is open, it sets it for the current solution. If there isn't a solution open, it becomes the default for all solutions. You can also set this on a per-test run basis in the unit test sessions window. This setting doesn't persist.
I tried different things that I found in Google and on StackOverflow (including other answers in this topic), but what worked for me is:
ReSharper's Unit Test Sessions window -> on the top panel set Platform dropdown to 64-bit.
My solution is too hacky, but thats the only thing which worked for me
I placed a copy of vstest.executionengine.x86.exe for backup and placed a renamed vstest.executionengine.exe (64bit version) instead of old 32 bit version.
We had a similar issue when trying to setup MSTEST for Sharepoint 2007 - it would keep running in x86 instead of x64. Instantiating SPSite kept saying "The Web application at http://server:port/ could not be found".
Option 1 - Assign Proper Active TestSettings
I started with replacing the EXEs suggested by #valentin-kuzub to confirm it would work - but then realized that we had the wrong Test Settings file active - there were (2) Local.testsettings and TraceAndTestImpact.testsettings. One of them was set to use x86 instead of targeting x64.
Option 2 - Configure RunSettings
Another option is switching from testSettings to runSettings and assigning TargetPlatform.
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<!-- [x86] | x64 - You can also change it from menu Test, Test Settings, Default Processor Architecture -->
<TargetPlatform>x64</TargetPlatform>
<!-- Framework35 | [Framework40] | Framework45 -->
<TargetFrameworkVersion>Framework40</TargetFrameworkVersion>
</RunConfiguration>
Option 3 - Use Test Settings Default Architecture
The last option (which you already tried) is in the XML comments from option #2 -> You can also change it from menu Test->Test Settings->Default Processor Architecture->x64.
When working with high memory code you may find you need to alter the R# test runner config to include
<runtime>
<gcAllowVeryLargeObjects enabled="true" />
</runtime>
You can find this file located at
%localappdata%\JetBrains\Installations\ReSharperPlatformVs12\
JetBrains.ReSharper.TaskRunner.CLR45.x64.exe.config
This path is likely dependudant upon Visual Studio version and may vary upon R# version. This specific path is Visual Studio 2013 with Resharper 9.1. Recurrent issue with Resharper 10. Location of config file is unchanged. https://youtrack.jetbrains.com/issue/RSRP-446178
I just ran into this with ReSharper and MsTests - error "unit test runner failed to run tests incompatible target platform".
Our issue was that the test project wasn't being built.
To fix:
Build
Configuration Manager
Confirm that Build is ticked.
Switch between your Solution Configurations to confirm it's being built in all configurations.
With, Visual Studio 2015, I've found that both x86 and x64 settings will cause this. The solution was to close and restart Visual Studio.
So I've downloaded VS2012 RTM and upgraded my Coded UI test projects to the VS2012 versions.
The reason I have done this is because I was having issues with VS2010 Coded UI tools due to partial support of IE9.
So I ran the tests from my developer machine both locally and remotely (making use of the new Visual Studio agent tools), and the tests worked successfully. Presumably, the reason my tests now work is that VS2012 upgraded them so that they now work with IE9, right?
So - this is my problem. I want to automate these tests, by launching them from our build machine - but our build machine still runs on VS2010, and for the time-being this is not going to change.
So I checked in my new VS2012 Coded UI test solution into TFS and queued a new build - so the build machine built my solution. And the build was successful. All good there.
So, next I created a new test case in Microsoft Test Manager and associated with the ordered test list in my new solution. Then I launched the tests (using the existing VS2010 test controller) on my remote test environment (which has the existing VS2010 test agent tools).
But the tests failed - the same issues that affected my tests with the VS2010 Coded UI tests (due to lack of full support for IE9)
Why did they fail?
Do I need the new VS 2012 agent tools for my test controller and agents? Must I build my solution in VS2012?
Ideally, I don't want to have to install VS2012 RTM on my build machine - I want to do the minimum possible to get my tests working and automating.
Is there a way around this?
Your coded ui tests reference assemblies that come with VS installation or your agent's installation (the assemblies defininf the WpfControl, Mouse, Keyboard, Playback and other classes).
So if you run it on a build/test machine with older versions of the dll's the same issues are going to stay, the tests will not start using the newer fixed assemblies thatt were shipped with VS2012.
As a temporary workaround you can check what dll's you reference and make sure that the build process puts them in the same directory with your tests assembly. That way the lookup for them will find the in the current directory without using the /path and finding them in the VS installation directory.