Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I've installed NUnit Test Adapter for VS2012 + 2013. When I first installed the Adapter tests were showing up, but they stopped showing up for some reason today. After building, rebuilding, cleaning, restarting, nothing shows up in Test Explorer. Why would this be happening? I'm using VS2013 Ultimate.
If you're using a NUnit3+ version, there is a new Test Adapter available.
Go to "Tools -> Extensions and Updates -> Online" and search for "NUnit3 Test Adapter" and then install.
If your test project is set to target a 64bit platform, the tests won't show up in the NUnit Test Adapter.
My test assembly is 64-bit. From the menu bar at the top of visual studio 2012, I was able to select 'Test' -> 'Test Settings' -> 'Default Processor Architecture' -> 'X64'. After a 'Rebuild Solution' from the 'Build' menu, I was able to see all of my tests in test explorer. Hopefully this helps someone else in the future =D.
Check for NUnit versions mismatch. The currently available NUnit Test Adapter only works for NUnit version 2.6.4 and below.
To downgrade NUnit from version 3.x go to
Package Manager Console > update-package NUnit -version 2.6.4
http://jeremybytes.blogspot.co.ke/2015/11/review-of-unit-testing-makes-me-faster.html
In my situation the 'NUnit3 Test Adapter' has been disabled.
To re-enable it go to menu
Tools->Extensions and Updates...
On the left side select 'Installed'->'All'.
On the upper right corner search for 'nunit'.
If you have 'NUnit3 Test Adapter' installed, with the found item you can enable/disable it.
This answer seems pretty basic but wasn't completely obvious to me at first. If you (re)build the solution it only builds the projects that are configured to build in the Build -> Configuration Manager
This was my issue, I must have inadvertently changed a build configuration settings or something that caused my test projects not to build (when they previously were). So the Test Explorer window was looking at dlls that were out of date. It became clear to me this was the case after doing a Clean and seeing most of my tests disappear and not come back after a rebuild...further inspection of bin folder showed that these projects weren't being built at all.
I had a working setup (for NUnit2 and NUnit3 depending on the solution, and multiple versions of Visual Studio between 2012 and 2017), and it suddenly stopped working one day: no tests detected in any solution or version of VS.
In my case, it helped to delete %localappdata%\Temp\VisualStudioTestExplorerExtensions. After a restart of VS, everything worked as before.
If you are using VS 2017 and .net core ,as said here, you should add references to the test framework NUnit 3.6.1, to the test runner NUnit3TestAdapter 3.8.0-alpha1 and to the test SDK Microsoft.NET.Test.Sdk 15.0.0.
Tools
NuGet Package Manager
Manage NuGet Packages For Solution
Browse
NUnitTestAdapter.WithFramework
Ctrl+R,A to build/run tests
Using NUnitTestAdapter.WithFramework makes sure there are little/no inconsistencies across versions of NUnit and NUnit Adapter (i.e. "it just works")
Check whether you have stated
[TestFixureSetUp]
and
[Test]
in the test class
sample:
namespace ClassLibrary1
{
public class SimpleCalculator
{
public Calculator _calculator;
[TestFixtureSetUp]
public void initialize()
{
_calculator = new Calculator();
}
[Test]
public void DivideTest()
{
int a = 10;
int b = 2;
int expectedValue = a/b;
int actualValue = _calculator.Divide(a, b);
Assert.AreEqual(expectedValue, actualValue, "Functionality not working properly!");
}
}
}
I had to uninstall then re-install the xunit.runner.visualstudio nuget package. I tried this after trying all the above suggestions, so may be it was a mixture of things.
One other cause to this problem is if you open a project from a mapped drive - Visual Studio handles such projects properly, but apparently Nunit doesn't support them.
Copying the project to a physical fixed the issue.
I also found that when I uninstalled nunit v3.2.1, the nunit framework reference for v3.2.1 was still in my project in solution explorer.
Solution Explorer > ProjectName > References
If you right click it will show the version. Remove this
Then Right click on References > Add Reference.
Search for the version 2.x version and add then rebuild solution.
That worked for me!
I experienced the problem mentioned by op
My case was that I was handed an old project and the tests were actually part of the system under test. I assume they were using the external test runner.
this task chain resolved the issue for me
created a test project,
moved the test files there
added references so the test project would compile
added the Nunit and Nunit adapter NuGet packages to the test project
recompiled
i was able to successfully run the Nunit tests.
If you are using the TestCaseSource attribute, ensure the source exists and respects the documentation, otherwise your tests will not be discovered.
I had a similar issue where the tests where not being discovered. I had the correct version of NUnit, versions matched up between NUnit and adapter, and the tests where tagged correctly. I was running VS 2017 Enterprise not as an administrator. After starting VS as administrator the tests appeared.
I started a new solution with a test project in it, and compared it against my original, problem project. The original, for some reason, had an app.config in it. I excluded that file from the project and saw my tests reappear in the test explorer.
I had this problem too but the cause was different. I'm using VS2017 with F# 4.0.
Firstly, the console in Visual Studio does not give you enough details why the tests could not be found; it will just fail to the load the DLL with the tests. So use NUnit3console.exe on the command line as this gives you more details.
In my case, it was because the test adapter was looking for a newer version of the F# Core DLL (4.4.1.0) (F# 4.1) whereas I'm still using 4.4.0.0 (F# 4.0). So I just added this to the app.config of the test project:-
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="4.4.0.0" />
</dependentAssembly>
i.e. redirect to the earlier F# core.
I had the same problem, when suddenly any test didn't appeared on Test Explorer window.
I has the updated version of "NUnit3TestAdapter"
and after lots of searches and efforts,
I found that I need set the following values in project properties:
[In Solution Explorer window: right click on Project > Properties]
Under Build tab, set Platform=x64, and set Platform target=x86 or Any CPU
Build the project and all tests will be appear on Test Explorer window.
Important note:
I came to a solution after seeing the next msg in the output window:
"Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run: AutomationTests.dll is built for Framework Framework45 and Platform X64."
I had some msbuild.exe processes that were hung. I don't know if that was my problem or not, but it took me a lot of trail and error with reinstalling various NUnit adaptors before I found the hung processes.
Just to add my $.02 here, I ran into a similar issue just yesterday, where 168 of my tests were missing. I tried most everything in this post - most especially making sure my version(s) of NUnit were the same - all to no avail. I then remembered that I had my tests divided into playlists; and these do not update automatically as you add new tests. So, when I deleted the playlists, BAM!, all of my tests were back once more.
I use NUnit 3 and tried most of the other solutions I saw here. None of those worked for me.
Even though already selected, reselecting the "Playlist: All Tests" option in test explorer showed all hidden tests in my case. I need to do this after every rebuild.
Make sure your test class is public. I often make this mistake then I just look at the code for 5 minutes what is going on.
[Test]
public void YourTest()
{
...
}
Tools
NuGet Package Manager
Manage NuGet Packages For Solution
Browse
NUnit3TestAdapter (NUnit 3 in my case ..)
After installation it should be possible to use the default TestExplorer included with the installation of Visual Studio.
If your test project is not x86, the tests will not be found until you tell the test runner the correct target platform.
Prior to Visual Studio 2022, this was the "Test/Test Settings/Default Processor Architecture" option.
In VS2022 you need to create a 'runsettings' file and set the test project to use it. In that file you can specify the Target Platform, like this:
<?xml version="1.0" encoding="utf-8" ?>
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<TargetPlatform>x64</TargetPlatform>
</RunConfiguration>
</RunSettings>
You still also need to include the Nunit3TestAdapter and Microsoft.NET.Test.Sdk nugets (and make sure the project actually built, and check the various other more obscure mistakes mentioned in other answers)
Make sure your tests are properly marked with the Test attribute. If all of the tests are marked with only the Explicit attribute, the TestAdapter doesn't recognize the fixture.
Related
So my nunit 2.6 tests run in team city, the results appear in a 'tests' tab. I just select the built in nunit build step, type the name of the file with the tests in "Runs Tests from:" and the name of the category(s) in "NUnit categories include:"
However, If I upgrade my tests and select NUnit3 from the "NUnit runner" drop down things start to go wrong.
After much googling and mucking round for command lines and console runners I can't get this working with the full 'results in a tab' level of compatibility.
There is a lot of advice out there on how to make this work, but the best articles are at least a year old and I'm not at all clear that they apply to 3.5.0
Has anyone got this fully working or is it no longer supported? Can you explain how you managed it?
NUnit 3.5.0 does work with TeamCity, but it requires that you use the NUnit TeamCity Event Listener Extension. You can install it along with the NUnit Console Runner package or use the NUnit Console Runner with Extensions which includes the TeamCity extension along with other commonly used NUnit extensions.
Once you have the extension, TeamCity should automatically add the --teamcity command line option to the nunit3-console.exe.
Check here more information on the various NUnit Runner NuGet packages and what is included in each.
You add these packages to one of your test projects. That will cause them to be installed in the package directory of your solution root. From there, the built in NUnit 3 step will work, just update the executable location to point to 3.5.0. See the Getting Started With NUnit and TeamCity document. I would use the Case 4, NUnit Build Step.
If you only want to test certain categories, you will need to add your --where clause as an additional command line parameter.
On a new VS solution, I've started using NUnit 3.2. Older versions (2.6) had a external NUnit GUI, that made it possible to watch assemblies and automatically run tests on modifications. But I cannot find anything similar to this for 3.2 - neither in the docs nor through Google.
I've installed NUnit.3.2.0.msi, I've also installed the NUnit3 Test Adapter in VS + NUnit3.2 nuget package for my project.
I can easily run all my tests through VS' Test Explorer. But I miss some way to run them automatically. Anyone know how?
In older versions of Visual Studio, there used to be an option to run tests after every build, but it was removed. It was always buggy and tended to lock files and prevent you from rebuilding.
You could set a post build command on your test project to automatically run NUnit console whenever your test project recompiles. You have NUnit console installed, so you could point to that, or use the NUnit.Runners package to install it into the packages folder of your solution.
Open your test project settings and go to the Build Events tab. Click on Edit Post-Build. Enter the following;
"C:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe" "$(TargetPath)"
Now, whenever you build, your tests will be run and the results will appear in the output window.
Maybe not ideal if there is a lot of build output after your tests but it works.
FYI, the colour in the build output is a side-effect of the VSColorOutput Visual Studio extension, it is not from NUnit.
Visual Studio captures STDOUT, so I haven't been able to get it to open a CMD window and run the tests. If anyone knows how to do that, add a comment and I will update.
There is a GUI for NUnit 3 under developement on GitHub - but it's not advised for production use yet.
We set our tests up using the NUnitLite runner. This allows you to turn your test assembly into an executable - and on run, will launch the console and run all tests. [Documentation]
Here's what I am looking at
PM> Add-Migration AddedSubdivion -StartUpProjectName Data -Verbose
Using StartUp project 'Data'.
Using NuGet project 'Registry'.
Could not load assembly 'Registry'. (If you are using Code First Migrations inside
Visual Studio this can happen if the startUp project for your solution does not
reference the project that contains your migrations. You can either change the startUp
project for your solution or use the -StartUpProjectName parameter.)
I have no idea why it's trying to reference the Registry project. Registry depends on Data, not the other way around. I am very new to this, so I'd appreciate any help.
This is embarrassing, but maybe this will help out a googler in the future.
At the top of the "Package Manager Console" my default project was set to the wrong project. Changing that to my models project fixed it.
This can also be caused by a platform mismatch between .NET Core and your project. You get the error:
Could not load assembly 'DataProject'. Ensure it is referenced by the startup project 'ProgramProject'.
even though you have specified correct project and startup project names. (Either by using the drop down boxes in VS and the Package Manager Console, or by using the -project and -startupproject parameters.)
You can fix it by switching to Any CPU instead of x86, or vice-versa (or maybe to x64, etc.), but then you will have to switch back and forth every time you need to make changes to your model/DB.
As per this answer you can fix this by changing the order of your .NET Core path entries in system environment variables. If you're getting this error, then it means that either the first .NET Core path is for x64 but you're trying to make changes to your x86 project, or possibly other way around. Move the one you're targeting above the one you're not targeting, save, and then restart Visual Studio.
You can see which one is currently being used with the command dotnet --info.
(Note that this assumes you've installed both. You may also only have one of them installed, in which case you'd need to install the other one, and then check the order of the PATH entries; if the second one you installed is the one you want, then you will definitely need to change the PATH order to make it the one used by VS, since its entry should be at the bottom.)
The problem might not be so obvious if you have Package Manager Console docked with a narrow window...hiding the default project.
Its needs a wide docking.
If all fails there's always the verbose flag (-v).
A command like dotnet ef database update -v should help clarify the problem ef is facing.
In my case, the issue stemmed from EntityFramework finding it difficult to deal with the fact that my platform target was changed from AnyCPU to x86 or x64.
System.BadImageFormatException: Could not load file or assembly 'MyProject, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
Temporarily changing the platform target to AnyCPU worked just fine.
Make sure that you are focused on:
1- Startup Projects is UI (MVC, API, ... etc).
2- Default project in package manager console is place of (ApplicationDbContext).
I would like to add, if you are using .net6 preview, you will need to update the packages.
so you will need to use the preview versions EntityFrameworkCore.Tools and EntityFrameworkCore.SqlServer (6.0.0-rc-1.21452.10 version as of today)
I had this exact problem, and it turned out because I createdthe project under a blank solution and then added the class libraies and web app seperately it didnt have a start up project.
None of these worked for me. I temporarily unloaded the unrelated project from the solution, ran the command, and then loaded the project back in.
I've got this issue migrating an Asp.Net 5 to Asp.Net 6.
The problema was in the .csproj file.
This configuration
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
I've just removed this property group and the dotnet ef worked
This can also be caused by a platform mismatch between .NET Core and
Also check this in your packages
if don't have that package Dependency Injection
Its very simple you have to install dependency injection package
The package manager window has a Default Project Property.
Setting the default project in the package manager window fixed this for me.
I also had to set the startup project to the same application in the solution explorer.
You should define 2 constructor and OnConfiguring method in context.cs. And also in your UI layer you should define connection string.
Like this:
In Context.cs :
public Context()
{
}
public Context(DbContextOptions<Context> options) : base(options)
{
}
protected override void OnConfiguring(DbContextOptionsBuilder
optionsBuilder)
{
if (!optionsBuilder.IsConfigured)
{
optionsBuilder.UseSqlServer("Data Source=..");
}
}
In appsetting.json:
"ConnectionStrings": {
"SqlServer": "Data Source=....."
}
In Program.cs:
builder.Services.AddDbContext<Context>(opt =>
{
opt.UseSqlServer(builder.Configuration.GetConnectionString("SqlServer"));
});
Set the target project for the migration as the startup project and continue
I've just (today) tried SpecFlow for the first time. I'm playing about by creating a new class library in VS2010 Pro and adding a SpecFlow Feature Definition file.
Thing is, the integration doesn't appear to be working properly, with a variety of different errors. I've selected MsTest as the test runner, because I can't be bothered with invoking NUnit (I'd like to use NUnit in the long term but at the moment I just want to get some BDD code working). The generated code files however continue to reference NUnit - which is obviously wrong, since I've just told SpecFlow to run using MsTest. I've done everything I can think of to invoke the code generation again, including creating a brand new class library project with the MsTest option selected in Tools > Options > SpecFlow.
If I leave the test runner field set to 'Auto' and right-click a feature file, then select 'Run SpecFlow Scenarios' I get an error message "Could not find matching test runner".
If I instead change the test runner field to MsTest, I get a different error message on doing the same thing - "Object Reference not set to an instance of an object". I'm not surprised at this one since it's still trying to run NUnit tests even though I've explicitly asked for MsTest, though obviously it shouldn't nullref and present that to the user.
What am I doing wrong? The documentation is not helpful, and as far as I can see, there's no FAQ.
edit #1: I've established that the actual setting I'm looking for is provided using App.Config using the field <unitTestProvider name="MsTest" />. I can see what's happened - the field in the Visual Studio options menu doesn't seem to modify the project you're currently working on. Thing is, this makes it look like that field doesn't do anything at all. I've now persuaded SpecFlow to generate MsTest classes and run using the MSTest runner.
So now the question morphs into a slightly different one: What (if anything) does the Tools > Options > SpecFlow > Test Runner Tool field do?
With VS2010 the correct value is MsTest.2010 not MsTest as documented. Change your app.config (for the test assembly) and it will work fine (at least with SpecFlow 1.8)
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
</configSections>
<specFlow>
<unitTestProvider name="MsTest.2010" />
<!-- For additional details on SpecFlow configuration options see https://github.com/techtalk/SpecFlow/wiki/Configuration -->
</specFlow>
</configuration>
In answer to your latest Question. What is the setting "Tools > Options > SpecFlow > Test Runner Tool" this setting controls what will actually run the tests, not what will generate the test code. If it is set to auto i believe it will look at the App.config file where you have set the unitTestProvider to determine what the best tool is to run the tests. An alternaive Test runner made by the same guys as SpecFlow is SpecRun http://www.specrun.com/
So when you go to run the tests it will use this option. As you have discovered though the code generator uses the config file to determine what type of test it should generate (mstest/nunit..)
If you ran the specfow installer ( https://github.com/downloads/techtalk/SpecFlow/SpecFlowSetup_v1.8.1.msi ) to install all the Visual Studio Intergration components when you change the App.config file it normally promps to regenerate the features using the new provider. The manual way to do this though is to right click the Feature and select "Run Custom Tool"
In regards to documentation have you found the git hub wiki?
https://github.com/techtalk/SpecFlow/wiki/Documentation
The way I've read this is that the test runner is entirely different to that of the code generator although that doesn't always make sense when the MsTest runner doesn't know about NUnit (I think). Out of the box, the latest version (v2.3.2) even when installed with SpecFlow.MsTest nuget package (of the same version) does not configure your machine to generate MsTest based classes in the background. I am running VS2017 and have Resharper installed as my 'test runner' but the main requirement for generating MsTest based code is a change to the app.config. As per the wiki documentation you also need the following in your app.config. When you save the config you should be prompted for the files to be regenerated.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="specFlow"
type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
</configSections>
<specFlow>
<unitTestProvider name="MsTest" />
</specFlow>
</configuration>
We are using ReSharper as a runner for SpecFlow acceptance tests; it worked well right out of the box. Although ReSharper is not free, but it worth every penny...
I was never able to get SpecFlow working right from Visual Studio, I spent some time working on it but never go anywhere. Though I found these instructions on setting up NUnit in Visual Studio 2010 and I use this shortcut to run my SpecFlow tests with good effect.
Overall we use PowerShell to run a lot of tests and I was able to incorporate the NUnit command line runner and SpecFlow report generator into a single script I can run easily.
I have an ASP.NET MVC 2 application.
Web project contains a reference to SomeProject
SomeProject contains references to ExternalAssembly1 and ExternalAssembly2.
SomeProject explicitly calls into ExternalAssembly1, but NOT ExternalAssembly2.
ExternalAssembly1 calls into ExternalAssembly2
When I perform a local build everything is cool. All DLLs are included in the bin\debug folder. The problem is that when I use the Publish Web command in Visual Studio 2010, it deploys everything except ExternalAssembly2.
It appears to ignore assemblies that aren't directly used (remember, ExternalAssembly2 is only used by ExternalAssembly1).
Is there any way I can tell Visual Studio 2010 to include ExternalAssembly2?
I can write a dummy method that calls into ExternalAssembly2. This does work, but I really don't want to have dummy code for the sole purpose of causing VS2010 to publish the DLL.
None of these answers are sufficient in my mind. This does seem to be a genuine bug. I will update this response if I ever find a non-hack solution, or Microsoft fixes the bug.
Update:
Doesn't seem promising.
https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I am having this same problem (different assemblies though). If I reference the assemblies in my web project, then they will get included in the publish output, but they should be included anyway because they are indirect dependencies:
Web Project ---> Assembly A ---> Assembly B
On build, assemblies A and B are outputed to the \bin folder. On publish, only assembly A is outputed to the publish folder.
I have tried changing the publish settings to include all files in the web project, but then I have files in my publish output that shouldn't be deployed.
This seems like a bug to me.
I had the same problem with VS2010 and a WCF Service Application.
It turns out that if your (directly or indirectly) referenced DLL's are deployed to GAC, the VS publishing feature excludes them. Once I removed the assemblies from GAC, publishing feature started working as expected.
I guess VS is assuming that if your assemblies can be located in GAC on the machine you build, they will be located in GAC on the target machine as well. At least in my case this assumption is false.
My tests show that the external assemblies get published when I have a reference on them in the web project. I do not have to write any dummy code to make it work. This seems acceptable to me.
I agree with Nicholas that this seems to be a bug in visual studio. At least it escapes me what the reason for the behavior could be.
I have created this issue as a bug on Microsoft Connect. If anyone experiencing it could vote it up https://connect.microsoft.com/VisualStudio/feedback/details/637071/publish-web-feature-not-including-all-dlls then hopefully we'll get something done about it.
If you go into the ExternalAssembly2 reference property list and change the "Copy Local" to "True" i think that might solve your issue.
I don't know if you are watching this still but I found the solution (I had the exact same issue) via this MSDN article. Under "build action" for the file choose "Content" that should include it in the list of files publish brings over.
I have created a new Connect bug here https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I've also attached a solution and detailed steps to reproduce this issue. Lets hope this time they won't close it as Can't Reproduce.
Vote for this connect issue if you experience the missing dll problem.
Copy local did the trick. I had an issue that the Newtonsoft.Json assembly get included in the deploymeny package. Copy local was set to false.
I am experiencing the same type of issue with a web project. I have a web project that references assembly A which references assembly B. It worked fine for some time but today it was broken. I did a rebuild of the solution and this time it deployed everything correctly.
I had this same problem today. I published my web project and realized that not all of the reference DLL's were there. In particular, the indirect DLL references.
It turns out that the directory in which I was publishing to was out of disk space (network share). I had just enough space to publish all the files except for few indirect reference DLL's. The sad part is that VS08 didn't throw any errors. It just published the files are usual. I cleared out some HDD space and everything worked fine.
I didn't find the HDD space issue until I tried to manually move the DLL's over.
in my case it is quite tricky.
Reference to ExternalAssembly2 is not required to Build the project but vital for run-time since we use reflection to configure Unity container.
So, I delete the reference - build the project successfully, but get run-time error.
If I preserve the reference I can Build and Run the application but I cannot Publish it with ExternalAssembly2 - get run-time exception as well.
This is happen because of internal VS2010 assemblies optimization.
So, what we can do here?
1. Put some unrequired peice of code to use any ExternalAssembly2's class.
2. escape from reflection and use static assemblies linking.
Hope this helps to smbd.
I got the same problem and this is a VS2010 bug if there's a reference link like:
Web Project --> custom project --> assembly1 -->(indirectly) assembly2.
For now I find if I reference the Assembly1 in the web project, then assembly2 is included in the bin folder.
So I had to add an additional reference link like:
Web project --> assembly1 -->(indirectly) assembly2.
Then VS can recognize assembly2 and include its dll file in publish action.