NUnit has stopped working in Visual Studio - visual-studio-2012

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.

Related

TFS Tests do not match framework settings

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.

How to show dotCover coverage in new VS2017-type csproj project

I have a solution that contains 3 projects.
PROJECT 1
A VS2017-style .csproj project that has multitargetting to net45 and netstandard1.1.
PROJECTS 2 and 3
Two traditional VS2015-style .csproj test projects, targetting net45, using NUnit.
The reason for projects 2 and 3 not to be new-style is because it seems that right now ReSharper does not recognize these assemblies for running tests. It does find the tests just fine on old-style projects targeting any .NET framewory (full) or netcore assemblies, though.
Using that structure, I can run all my tests all right with the unit test window from dotCover, but when trying to gather coverage results it returns all green for the old-style projects, and all empty for the new-style project.
Coverage tree shows 0% coverage for my new-style project. Gutter highlighting and code highlighting all show in grey, although the tests have run successfully. All of them.
I've tried building in Debug mode, and setting specific values for "Platform" and "Framework" on the Unit Test Sessions window of ReSharper to no avail.
Is this something I'm doing wrong, or are we waiting for an update from ReSharper to fix this?
I am using:
NUnit 2.6.4 (because my unit test projects target net45)
Moq 4.5.28
ReSharper Ultimate 2017.1.2 with dotCover 2017.1.2 (says it's up to date at the time of writing).
Visual Studio Professional 2017 15.2 (26430.12)
I have installed all target frameworks until 4.7.02053
The projects I'm talking about are in C#
I had the same issue. And setting <DebugType>Full</DebugType> solved it for me as mentions by Martin

How to change ReSharper unit test architecture to x64?

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.

Testing using an upgraded VS2012 solution, but building in VS2010

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.

Application crashes after VS2012 install

I'm not quite sure where to go with the initially...
I've got an application that has been built in VS2010, using both MFC and .NET 2.0. I then installed VS2012. Before even launching VS2012 I've tried running the application again and it now crashes just after startup with an "Application has stopped working" error.
It does however work, if I launch the application via an F5 in VS2010 (i.e. Debugger attatched right from the start).
Does anyone have any suggestions on what possible causes/fixes there may be for this? I'm currently not sure what to look for.
You probably never installed the redistributable packages for the VS2010 runtimes. Use Dependency Walker or similar tools to find out what DLL is missing, figure out where it comes from, and install that runtime package.
Ultimately it was completely unrelated to VS2012 - doh. Had an old executable that was being run, and a number of dependencies were missing.

Resources