dotCover never works in Rider?

Hello Dave,

Please enable Traces for dotCover in Help | Diagnostic Tools | Trace Scenarios, reproduce the issue and collect the logs via Help | Collect logs. Resulting log bundle attach with a new issue on our bug tracker. It will help us to take a closer look at your issue and system Thank you in advance!

I found that after converting my project from .NET Core 3.1 to .NET 4.0 that dotCover now works for that project. It still does not work for other .NET Core 3.1 projects though.

Is there anything in particular in the log that is more important, like the idea.log file or something? I can see various IndexOutOfRangeExceptions and some others in idea.log. It looks like if I share the entire log bundle that I will be giving you my entire project structure.

After trying to get another completely new and empty .NET Core 3.1 project working with MSTest, I think I've come to the conclusion that MSTest does not actually support .NET Core 3.1. The Rider log seemed to show that it was reverting to .NET Framework 4 in some cases (even though I was targetting only .NET Core 3.1), and then got an exception when trying to retreive System.Runtime 4.2.2.0. From what I can see, Microsoft.NET.Test.Sdk supports .NET Core 2.1, not 3.1, and indeed, changing my very simple test setup to .NET Core 2.1 instead, things work right away.

It would be nice if I had some confirmation of that though. It doesn't seem very well documented.

It should be easy to test: 1 new .NET Core 3.1 Class Library and 1 new  .NET Core 3.1 MSTest project with package references like I originally posted. Reference the library from the test project, and write some code and a test method and try to run the test. Should end up with inconclusive, the test was not run, and a rider log that shows the System.Runtime load exception.

On the other hand, my original issue was with dotCover, and I seemed to be able to run the tests just not cover them, so maybe it _should_ work, but then I don't know what the problem is now.

My question now is: does MSTest support .NETCore 3.1? I can't tell one way or the other.

Dave Cousineau, I'm mostly interested in Unit Test session and backend logs, but it would be better to have the whole bundle. On tracker you can set up visibility of request to only JB representative, we can also sign up NDA if required. I have also tested MSTest project with netcoreapp 3.1 as target framework on the latest Rider and have not faced any issues with running or coverage, so I need more information from your set up to be able to take a closer look.

K I've determined that under unit test settings, if "Default .NET Framework version:" is set to anything other than "Automatic", that tests for .NET Core will just not run, since it defaults to whatever version of .NET Framework you have selected, even though it's a .NET Core test project.

For example, if I select .NET Framework 4.7, I see lines like this in the rider unit test output log:

Provider: MSTest
Target Framework: .NETCoreApp,Version=v3.1
Strategy: MsTestTestRunnerRunStrategy
Runtime Environment: TestRunnerRuntimeEnvironment
Project: _____
TargetPlatform: X86
TargetFrameworkId: .NETFramework,Version=v4.7
IsUnmanaged: False

...

TestRunner: Discoverer [MSTest][Discovery][C:\___\bin\x86\Debug\netcoreapp3.1\___.dll] Unable to load types from the test source 'C:\___\bin\x86\Debug\netcoreapp3.1\___.dll'. Some or all of the tests in this source may not be discovered.
Error: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

This is not really related to my original dotCover issue but is a separate unit test issue I've encountered on a different workstation and codebase.

Could you please specify Rider version you are using? I tried to perform the same using the following sample on the latest available Rider 20.3 and have not faced such issues. 

Still dealing with this almost 4 years later. Cover tests, tests all pass, statements all “uncovered by tests” despite just having executed. I've stopped using this feature altogether which really sucks.

Hello Dave,

We are sorry to hear that you encountered such a problem. Would you mind sharing additional information so that we can take a deeper look?

• Collect log for the issue using the suitable instruction from the article;
• That would help us a lot if you could share a recording that demonstrates the issue (or several screenshots that demonstrate the problem)

Please upload it to the Upload Service and let me know the Upload ID.

Have a nice day!

I can't share information about my company's whole solution. I've tried coverage in a new empty test solution and I had maybe 90% success. In my main solution I am currently having 0% success; it at least used to work 50% of the time or so, but is not working at all right now.

I have learned that there is a command-line version `dotnet dotcover` and trying that out I am actually getting correct results so I guess I will just move to the command line instead.

Hello Dave,

I am sorry to know tests coverage doesn't work in Rider for you. Unfortunately, without having a deeper look, we can't investigate the issue.

Note: the files uploaded to JetBrains Uploads server are only accessible by JetBrains employees.

Should you wish, we could sign an NDA, so that you can share the information freely. Please let me know if you are interested.

Have a nice day!

Ok I built a whole test codebase from scratch that mirrors my real ones and managed to get the failing to happen in a non-proprietary solution. I tried doing the logs as indicated but my logs were still filled with proprietary information even with a non-proprietary solution, so I used a completely new Windows profile as well to make it as clean as I possibly could and moved the test solution away from my other files. I then found that it started working, and I realized the main thing that had changed was my settings. I imported my settings and sure enough it started failing (to cover) right away.

I now had a single settings file and if I deleted all the settings, it worked, and if I put them back it failed, with 100% repeatability. I slowly removed settings all the way down to a single setting. This single setting, if present, causes dotCover to fail in certain cases (in this specific case, dotCover will say that the test itself is covered, but code from a different library that was executed was not covered).

The setting looks like this in the settings file (this is inside a root ‘wpf:ResourceDictionary’ tag):

    <s:String x:Key="/Default/Environment/Hierarchy/Build/SolBuilderDuo/UseMsbuildSolutionBuilder/@EntryValue">No</s:String>

I don't know what actual setting this relates to; perhaps it is a legacy setting that does not exist anymore, not sure. I tried playing around with it, and the value of the setting seems to not matter. If I change it to Yes, or gibberish, or blank, or self-close the tag, no matter what the value is, dotCover fails to cover library code. If I remove that one line, then dotCover works. If I change the key value at all, then dotCover also works, so it is specifically the key /Default/Environment/Hierarchy/Build/SolBuilderDuo/UseMsbuildSolutionBuilder/@EntryValue that causes failure, for whatever reason.

Hopefully this is enough information for you. Maybe I could send you my test solution if it isn't. (I tried to get it to happen with this setting in a bare-bones solution and I could not get it to fail, so it may be one of the various things I am doing in my solution in addition to this setting that causes it.)

Hello Dave,

Thank you for the investigation done. I am checking with Team what is this setting. Meantime, that would be great if you could share a repro project with me.

Have a nice day!

Checking my other settings files I can see that in one case the value of this setting is set to NewVersion. Testing that value in my separate solution I find that having a value of NewVersion does work.

I will next try to get my real solution working by trying to find and update this setting in the various settings layers.

Ok after updating the value in four different settings files from No to NewVersion it looks like it is working now in my real solution finally. (I set one of the four to Newest instead accidentally at first and just having that one setting wrong was enough to make it fail; was worried it hadn't worked at first but then I noticed the wrong value. The value must be NewVersion or removing the setting altogether also works I think; presumably the default value is already NewVersion perhaps.)

Hello Dave,

Thank you for the details shared. Unfortunately, I was not able to reproduce the issue, and we can't imagine how this setting might impact the TestCoverage feature. Would you mind sharing a repro project with me, so that I can have another look?

Have a nice day!

K I've uploaded my test solution with ID 2024_09_25_GU6wpNiQsTi3FdwJPBubSE

there are some .bat files in the build process that I've also included; these might need to be on the PATH for things to work correctly.

the problem should be as follows: 

• drop any existing test coverage results (garbage can icon)
• cover all tests in solution
• coverage results should show that tests in the Tests folder are 100% covered, but that tests in the Libraries folder are 0% covered.
• repeating these steps without the above setting (or with it set to NewVersion) and Libraries will show as 100% instead of 0%.

Hi Dave,

Thank you for the solution, much appreciate your efforts!

In my environment, it still does not reproduce:

Please share the following:

1. Logs collected from the solution where the issue appears. If it reproduces on your side with the small one you sent, please use it. Share the logs via Uploads in the same way.

2. Screenshot of the File | Settings | Build, Execution, Deployment | Toolset and Build page when the affected solution opened in Rider.

Thank you!