.NET Core Tool Support

[StrangeWill]

Any plans to support the new "dotnet" command? Considering dnx command support is dropped and the new tooling should allow for better self-configuration over the old DNX method found here: https://github.com/OpenCover/opencover/wiki/DNX-Support

[sawilde]

Currently not yet - the runtime does not fully support the Profiling API and to also fully support the platform would require us to build the profiler virtually from scratch to run on linux platform, something I do not have the bandwidth for. If you build your libraries as PCL I believe you can also run them on .NET 4.5 etc on windows and get coverage from OpenCover assuming your tooling allows that.

I only develop/enhance OpenCover for my needs and I currently do not have the need; It doesn't mean someone else can't do the work but it probably won't be me in the near future.

[haythem]

Hi @StrangeWill,

I've managed to get it running using the following command :
opencover.console.exe -register:user -target:"C:/Program Files/dotnet/dotnet.exe" -targetargs:"test test/MyProject.Test" -output:"coverage.xml"

Make sure you have xunit-runner on your test project. Please let me know if you encounter any problems.

[StrangeWill]

@haythem Awesome! Thanks I'll try that out later this week.

[tmds]

I tried

c:\Users\tmds\AppData\Local\Apps\OpenCover\OpenCover.Console.exe "-target:C:\Program Files\dotnet\dotnet.exe"  -targetargs:test -register:user -filter:"+[*]* -[xunit*]*" -output:coverage.xml

This generates a report, but the report shows zero coverage for all the code.
What could be wrong?

[snookerfly]

I had this running with dotnet RC2 too, but when upgrading to final it stopped working on my CI machine (Windows 2012 R2), but still works on developer machines (Windows 7).

Any ideas anyone?

[sawilde]

What does it say in the XML file for the reason why an assembly of interest was skipped?

[snookerfly]

Nothing. The assembly was not skipped, you just get an entry with line / branch coverage 0.

Interestingly enough it works when using the oldStyle switch. I also installed VS 2015 Update 3 on our CI server but still the same issue exists.

[StrangeWill]

dotCover is also having the same issue since 1.0.0 came out, wonder if the change that broke them both is related...

[snookerfly]

might be. only strange thing is that it's only occuring on W2k12R2 (at least that's where it's happening for me). I'll check W10 tonight.

[sawilde]

Interestingly enough it works when using the oldStyle switch.

Ah that explains it - OpenCover needs to hook into a class in mscorlib to work around a security issue with pinvoke - the class in question in .NET core is no longer mscorlib so OpenCover can't hook it anymore - The -oldstyle switch does not use that class but you may encounter security issues especially around 'AssemblyAllowsPartialTrust...'

see #595

[snookerfly]

and it also happens on W10.

[sawilde]

and it also happens on W10.

it's not an OS issue it's what they've done to the structure - since there is a workaround I have not made it high on my agenda.

[tmds]

There are two aspects to this issue:

• make it work on .NET Core
• integrate with .NET Core

From what I read here, if you pass -oldstyle it should work.
The second aspect is supporting OpenCover as a dotnet tool. This means you can add it in the project.json tools section, pull it as a dependency and invoke it using the dotnet cli (like Microsoft.EntityFrameworkCore.Tools).

[StrangeWill]

Yeah @tmds I was originally asking about the second aspect, though I'm not sure how "OK" it is to build tools that only work on specific platforms.

[sawilde]

make it work on .NET Core

currently you can use the -oldstyle flag until we implment #595

integrate with .NET Core

OpenCover currently only works with the Full .NET FW on windows due to its dependency on the Profiler API. The profiler is written in native c++ as you cannot write the profiler in .NET (unlike Java profilers I believe)

I understand there is some progress in migrating this API to the .NET Core but I am not sure how ready it is see #549. The migration on windows will be relatively easy as the profiler will still use the windows API. The same profiler capability on linux based platforms may take some time.

The second aspect is supporting OpenCover as a dotnet tool.

I am not sure where to start here - we do have nuget support and just added chocolatey support for the next release #603, we can accomodate other packaging formats but I want to be able to automate that as part of the pipeline - e.g. no manual actions after the initial 'kick-off'. But, the tool would still be limited to windows OSs for the time being.

[tverboon]

For anyone who wants to use OpenCover on Windows with MSBuild and wants the results in Visual Studio Team Services, we use it like this:

https://gist.github.com/tverboon/1c187b082b9597abef89dcec3df2422c

The conversion to Cobertura is to get it in Visual Studio Team Services.

[jp7677]

In addition to the info already provided in this thread: Please note that you can't use
"debugType": "portable" in your project.json build options, otherwise OpenCover fails with pdb's missing.

[jp7677]

So another thingie for OpenCover would be the support for the new pdb format.

[sawilde]

So another thingie for OpenCover would be the support for the new pdb format.

We get that support from the Mono.Cecil project - @jp7677 could you raise that as a separate issue please that way when we start to resolve it you will be kept informed. preferably with a sample showing how to repeat the issue etc if possible.

[haythem]

@tmds @StrangeWill

I'm sorry for the late response. In fact, I had the same problem after upgrading to AspNetCore 1.0 RTM.

This how I managed to solve it and don't ask me how 😄

c:\Users\tmds\AppData\Local\Apps\OpenCover\OpenCover.Console.exe "-target:C:\Program Files\dotnet\dotnet.exe" -targetargs:test -register:user -filter:"+[*]* -[xunit*]*" -output:coverage.xml -oldStyle

Please let me know if you encounter any other problems.

[tmds]

There are a number of items covered in this issue.

• One can be worked around using the 'oldstyle' switch and will be fixed by .net core support #595
• One is related to the profiler api not being available on Linux, see https://github.com/dotnet/coreclr/issues/445
• One is a feature request to be able to use OpenCover as a cli tool (project.json tools section)

[jacksontbryan]

It's not clear from the coreclr#445 ticket when profiler api is expected for linux. It looks like there work being done then it went quiet. Was there any discussion on it being 1.0.1 or 1.1.0?

[carusology]

In case it's helpful, you can see a working example of OpenCover running on a .NET Core project here, but I had to use one of the .NET Platform Standard framework designations (i.e. netstandard1.*) for my source project to get it all to work. That enabled running my .NET Core project on Windows (read: Appveyor) with the traditional .NET Framework so I could run OpenCover. While this is unnecessarily restrictive, it isn't crippling since the .NET Platform Standard frameworks enable the broadest portability.

I wrote up the gotchas on this StackOverflow answer here.

[repspark-trh]

I got this working with my .NET core 1.0.0 project. OpenCover version 4.6.519.

I had to change the debug type in my project.json from portable to full:
debugType: "full"

Run the following from the console where OpenCover.Console.exe lives:

OpenCover.Console.exe
"-target:C:\Program Files\dotnet\dotnet.exe"
-targetargs:" test ""path\to\project.json"" "
-register:user
-filter:"+[service_]_ -[service]*Test"
-output:coverage.xml
-oldStyle

The above will generate a coverage.xml file. I then downloaded ReportGenerator and ran the following command to generate an html file based off the coverage.xml file:

ReportGenerator.exe -reports:"path\to\coverage.xml" -targetdir:"path\to\output\directory"

[carusology]

Any there any downsides to using -oldStyle if you do not care about Silverlight? The usage notes are pretty clear it's a last resort kind of thing, but they don't explain the tradeoff.

[sawilde]

Any there any downsides to using -oldStyle if you do not care about Silverlight?

It's not just Silverlight - there are some security issues as well that may cause the instrumentation to fail - try it and see - your mileage may vary.

[jskeet]

@HarelM: That's using debugType=full though, which is a problem in my case - I was hoping for the portable pdb support mentioned earlier.

[HarelM]

You can completely ignore my comment then... :-)

[carusology]

@jskeet We have got around this limitation by having our CI pipeline copy the project file, transforming the debugType to full from portable, and running code coverage on the copied / transformed variant. Is that tenable for your case? If not, I'm actually quite curious what you have run into that prevents that from being a solution.

[jskeet]

@carusology: That would be feasible, but it sounds like a lot of work to automate (which would have to be done in a "meta" way given that we have a lot of projects...) and it'll slow things down as well, building another copy of everything. I'd rather not do that work if the proper fix is reasonably imminent...

[sawilde]

as I have said in the past I am waiting for the new mono.cecil release which is perpetual beta at the mo - I could release with the beta but I am bit wary.

[twgraham]

@sawilde not to be the straw that broke the camels back - I really appreciate your massive contribution to the community through this tool - but would you consider releasing an alpha/beta with the mono.cecil beta?

[carusology]

Well, if it helps, our multi-project solutions are organized like so:

/
  /src
    /Foo.Bar
    /Foo.Biz
    /Foo.Baz
  /test
    /Foo.Bar.Tests
    /Foo.Biz.Tests
    /Foo.Baz.Tests

Then we use this script to find all of our *.csproj files and convert their DebugType from portable to full programmatically.

[akamud]

This has been evolving in the coreclr repo: https://github.com/dotnet/coreclr/issues/445#issuecomment-338014386

[NishaKuruvilla]

Coverage is showing as 0.00 %

I have used beow command

"%LOCALAPPDATA%\Apps\OpenCover\OpenCover.Console.exe" -output:"%CD%\opencover.xml" -oldstyle -target:%NUNITCONSOLE%\NUnit.Console-3.7.0\nunit3-console.exe -targetargs:"E:\ProjectFiles\CODE\GRM.Search"\Web API"\SearchService\SearchService.Test\bin\Debug\SearchService.Test.dll" -register:user

In the output xml file showing Missing PDB

  <Module skippedDueTo="MissingPdb" hash="73-2C-23-38-69-24-C6-47-B0-15-58-8D-B3-63-F3-64-AC-79-40-D5">
  <ModulePath>E:\SONAR\NUnit.Console-3.7.0\nunit3-console.exe</ModulePath>
  <ModuleTime>2017-11-14T07:09:46.6084668Z</ModuleTime>
  <ModuleName>nunit3-console</ModuleName>

[rpokrovskij]

Any users of https://github.com/rpokrovskij/opencover4vs.ps1 ? Need feedback.

[smukherjee-rythmos]

Using XUnit2.2.0 in .Net Core 2.0. Using -oldStyle as suggested but it still complains about missing PDBs (not able to recogniz the PDB). Below is the command running ... any suggestion

 C:\Users\UN\.nuget\packages\opencover\4.6.519\tools> .\OpenCover.Console.exe -target:"C:\Program Files\dotnet\dotnet.exe" -targetargs:"test D:\Code_Trials\unit-testing-using-dotnet-
test\PrimeService.Tests\PrimeService.Tests.csproj --no-build /p:DebugType=full" -filter:"+[*]* -[*.Tests*]*" -register:user -output:"_CodeCoverageResult.xml" -oldStyle

[sawilde]

@smukherjee-rythmos support for .net core is limited in the current version of OpenCover

[smukherjee-rythmos]

@sawilde I am keeping an eye on issue #595. Looks like the current version not able to recognize the PDB's since .Net Core generates portable PDB. Any workaround for this? I believe one was to use oldStyle switch but no luck with that. Not sure how come other mentioned that it worked for them? When we will have full .Net Core support with OpenCover, any timeline?

[sawilde]

When we will have full .Net Core support with OpenCover, any timeline?

Nothing specific - too much else going on and too many versions of dotnet core to keep up with - now that mono.cecil has come out of beta I may update it and see if that helps everyone.

[jp7677]

FYI, an alternative for coverage reporting on NetCore (also for Linux) would be https://github.com/tonerdo/coverlet

[smukherjee-rythmos]

@jp7677 That did worked nice. Thank You. @sawilde am sorry, using -oldStyle switch works but that needs debugtype to set to full in *.csproj file for all project under test. Which certainly will not work for me but thank you for your response.

[sawilde]

on windows .net core is supported both full, embedded and portable formats - only .net (core) old frameworks and 2.2, 3.1 and 5.0 supported

4.7.1137-rc onwards