I created a fresh solution with .Net Core exe project. I added an MSTest v2 project too.
I ran Analyze Code coverage for All tests, but I have ony received coverage data fot the test project, and not for the main .Net Core project.
Then I have added a .Net Core dll, still no sucess.
Then I have added .Net Framework exe and .Net Framework dll. I rebuilt a solution and ran Code coverage, but still only MSTest V2 project appears in the results.
Then I have added an Nunit project. This time the result shows MSTest v2 and Nunit project, but none of the projects to be tested.
I also tried to add [ExcludeFromCodeCoverage]. I tried to enable Autodetect runsettings file. Nothing helped.
I also tried adding this code to main project:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<DebugType>Full</DebugType>
</PropertyGroup>
No effect.
I read that if I add a custom runsettings file, things might start to work. However, I think this is just a workaround, as when I asked to run Code Coverage on my collegue's Visual Studio, all projects appear in the result.
Looking for solutions.
Ok, the solution is simple and stupid, but still may solve a tonne of time to an unexperienced unit tester.
The problem is that it is not enough just to add a test project and to add a reference from it to the main project. And even having a test class which does not test anything in the main project does not work.
The real solution is just to add a class which tests at least one method in the main project.
This way the code coverage will get activated and show results, showing you have one method covered. Thus, it seems not possible to have a main project in the coverage results stating 0% of the project is covered. You will always need to have at least minimal coverage.
Related
I have a simple .sln with 2 projects:
-- .NET standard Library
-- NUnit Test Project
The issue presents itself when I add the NUnit Test Project to the .sln because VisualStudio adds another reference to the test inside the .NET standard Library project (see picture).
Screenshot from VS Explorer:
This folder is not physically present on my laptop but still is causing several build errors for duplicate references.
To add more information:
Deleting the NUnit Test from the Library project will make the Test unavailable.
enter image description here
I've found the culprit even though I'm not sure why it behaves like that.
My solution structure was
-- sln
-- Folder
-- .Net Library
-- NUnit Test
Eliminating the folder will eliminate this strange behavior and adding the NUnit test will not create a duplicate inside the .Net Library.
I created a fresh Xamarin Forms solution, upgraded all the NuGets, made sure that the UWP version was targeting build 16299, and made sure the .NET Standard project is targeting 2.0. I ran the project and was able to debug the .NET Standard 2.0 DLL fine. You can download this here but I don't think it will be of any use: https://www.dropbox.com/s/jw13heu98yq2n6x/CleanXF.7z?dl=0.
I then pulled these projects in to another solution, added some references to other projects, and copied and pasted some Xamarin Forms pages etc. in to the new clean projects. I could then compile and run the project, but debugging the .NET Standard 2.0 Xamarin Forms project does not work at all. Debugging the UWP code does work, and the lower level .NET Standard 2.0 projects do debug. It's only one project that won't debug. I have already tried Git cleaning the folders again and again to ensure that rebuilds are happening. I have also tried creating the project from scratch and adding all the files back in. Again, it compiles and runs, but doesn't debug.
What things can I try to get debugging working?
It turns out that there are still issues with debugging .NET Standard 2.0 assemblies in UWP. Apparently there is a new type of PDB that is generated in .NET Standard 2.0 projects. This is related to this bug which has a workaround:
https://github.com/dotnet/sdk/issues/955
It's just a matter of editing the .NET Standard 2.0 project like so:
<PropertyGroup>
<DebugType>pdbonly</DebugType>
</PropertyGroup>
This switches to old school PDBs and will slow down debugging, but until MSBuild etc. catches up, it's the only way to solve the problem from what I can see.
Edit: Microsoft claim that the original bug is now fixed in the latest version of Visual Studio, but I have not confirmed this:
https://github.com/Microsoft/UWPCommunityToolkit/issues/1951
Some people are still experiencing this issue - even people at Microsoft, so I don't know the status of this at the moment.
alternative solution to accepted solution, you use also below lines. it tells that use full debugging, symbols included only for debug mode. I am not sure if Melbourne developers answer is affecting release mode, just to ensure.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>
In my VS2017 solution I have several unit test projects.
In on of them my xUnit tests do not get discovered by mstest and therefore are not run.
I do get the warning:
Warning: [xUnit.net 00:00:00.7641189] Skipping: Testing.UnitTests (could not find dependent assembly 'Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0')
But Microsoft.VisualStudio.QualityTools.UnitTestFramework is referenced in the project in exactly that version.
I have multiple unit testing projects. Many of them contain xUnit tests as well, but they get found and executed without any problems.
All projects containing xUnit tests have the same xUnit nuget packages assigned, especially xunit.runner.visualstudio
I am also using NCrunch and NCrunch has no problem discovering and execution the xUnit tests in question.
What could possibly be the reason to my problems?
Further Findings:
After upgrading Microsoft.VisualStudio.QualityTools.UnitTestingFramework to version 10.1.0.0, the xUnit tests were found but then I suddenly had 438 from 2447 failing. Those failing tests -mostly not xUnit - were previously working fine.
After shutting down an restarting visual studio the UnitTeestingFramework was automatically reset to version 10.0.0
opening the Reference Manager (Add References) all the project references are shown by selected checkboxes except of Microsoft.VisualStudio.QualityTools.UnitTestingFramework which only shows up if I previously add e.g. "Quality" to the search box, but then I see Microsoft.VisualStudio.QualityTools.UnitTestingFramework three times. One checked (version 10.0.0.0) an other one with same version, but different path and one with version 10.1.0.0
All together looks quite odd to me...
I had this issue but am not sure if this is exactly the same as yours. I saw an error in the output/tests window which stated it couldn't restore package xunit.runner.utility 2.2.0
After manually adding this in in package manager console like so:
install-package xunit.runner.utility -v 2.2.0
It started working again
Let's say my solution has 2 projects:
The first called "MainProject" (A .NETStandard 2.0 project).
The second called "MainProjectTests" (A NUnit test project) with some unit tests for each class into "MainProject".
The first project (MainProject) has a NuGet dependency called "dependencyX". Obviously, the project "MainProjectTests" has a reference to "MainProject".
So when the test runner runs a test of "MainProjectTests" that calls methods from "MainProject" using "dependencyX" I'm getting a System.IO.FileNotFoundException exception:
System.IO.FileNotFoundException : Could not load file or assembly
'dependencyX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one
of its dependencies.
Why am I getting this exception? When I add "dependencyX" to "MainProjectTests" all works fine, but it seems to me not a good practice... How to solve it?
I'm using Visual Studio for Mac Community 7.2 preview (7.2 build 583)
Thanks for the help.
EDIT:
Tried putting the options:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
in the NUnit project, but getting the same result.
This seems to be a known bug regarding .NET Standard libraries (and maybe especially in conjunction with NUnit). I already filed a bug report here which seems to confirm that this is not the intended behaviour. Altough there has been no progress for over half a year.
Maybe one should file a bug in the NUnit repo after confirming this only happens when using NUnit.
For the time beeing you'll need to reference all libraries used in a .NET Standard project also in all projects referencing the .net standard one as you are doing right now.
It is a bug reported to Microsoft few times and it seems they did not do much on this, look at this Visual Studio does not copy referenced assemblies through the reference hierarchy
On the other hand at least with Nuget Packages you have a simple way (to add the same package to multiple projects in the same solution) using the package manager for the solution, as you can see here Nuget Package Manager.
I am really loving the new .csproj format. It is so much better than that dreaded (limited) project.json.
However, there is one thing that I am trying to work out. I have merged my (multiple) test projects into a single multi-targeted project.
<TargetFrameworks>netcoreapp1.0;net40;net35</TargetFrameworks>
But, there doesn't seem to be any tooling in Test Explorer in Visual Studio to select the target framework - it always just runs the first one. I found a workaround - to add a <TargetFramework> element with a specific framework...
<TargetFramework>net35</TargetFramework>
But, is there any way to select the target framework without resorting to hand-editing the MSBuild (.csproj) file? I am looking for some option in the GUI to do this - specifically so I don't have to remember to edit the .csproj file in order to switch frameworks before debugging a test or to remember to have to remove this line before the release.
I know that the question is about VS, but I find useful that when targeting multiple frameworks dotnet tests command will run tests for all frameworks in <TargetFrameworks> node:
> dotnet test
...
Test run for [projectPath]\bin\Debug\netcoreapp1.1\XUnitTestProject.dll(.NETCoreApp,Version=v1.1)
...
Test run for [projectPath]\bin\Debug\net461\XUnitTestProject.dll(.NETFramework,Version=v4.6.1)
...
NCrunch can also recognize multiple targets and run tests for every target automatically:
Best option currently is to change the order of your target frameworks in the csproj.
<PropertyGroup>
<TargetFrameworks>netcoreapp2.1;net45;net46;net461;net462;net47</TargetFrameworks>
</PropertyGroup>
If wanting to debug unit tests for net45 framework, you'll need to change it to:
<PropertyGroup>
<TargetFrameworks>net45;net46;net461;net462;net47;netcoreapp2.1</TargetFrameworks>
</PropertyGroup>
The UI for doing this in Visual Studio would be relatively simple to implement but they have not done so as of this answer.
It turns out that Microsoft has finally fixed this in Visual Studio 2019 (not sure exactly when).
If you specify multiple target frameworks:
<TargetFrameworks>netcoreapp2.1;net451</TargetFrameworks>
The GUI now displays:
and lets you run tests on all target platforms at once.
Use TargetFrameWorkVersion in a runsettings file using the 'or' operator.