# .NET Core Tool Support #601

Open
opened this Issue Jun 12, 2016 · 68 comments

Projects

### StrangeWill commented Jun 12, 2016

 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

Member

### sawilde commented Jun 12, 2016

 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 commented Jun 14, 2016

 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 commented Jun 14, 2016

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

### tmds commented Jul 1, 2016

 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 commented Jul 4, 2016

 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?
Member

### sawilde commented Jul 5, 2016

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

### snookerfly commented Jul 5, 2016

 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 commented Jul 5, 2016 • edited

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

### snookerfly commented Jul 5, 2016

 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.
Member

### sawilde commented Jul 5, 2016

 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 commented Jul 6, 2016

 and it also happens on W10.
Member

### sawilde commented Jul 6, 2016

 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 commented Jul 7, 2016

 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 commented Jul 7, 2016

 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.
Member

### sawilde commented Jul 16, 2016

 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 commented Jul 18, 2016

 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 commented Jul 18, 2016

 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 commented Jul 18, 2016

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

### sawilde commented Jul 18, 2016

 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.

Closed

Closed

### haythem commented Aug 22, 2016 • edited

 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 commented Aug 22, 2016

 There are a number of items covered in this issue. One can be worked around using the 'oldstyle' switch and will be fixed by #595 One is related to the profiler api not being available on Linux, see dotnet/coreclr#445 One is a feature request to be able to use OpenCover as a cli tool (project.json tools section)

### jacksontbryan commented Sep 2, 2016

 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 commented Sep 7, 2016

 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 commented Sep 16, 2016 • edited

 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 commented Sep 16, 2016 • edited

 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.
Member

### sawilde commented Sep 17, 2016

 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.

Open

Closed

Closed

Closed

Closed

Open

Open

Closed

### jskeet commented Jul 19, 2017

 Any updates on an expected timeline for this? Nothing I'd try to hold anyone to, but it would be nice to have a rough idea, partly in terms of whether I should start looking for alternative coverage solutions.

### HarelM commented Jul 19, 2017

 I have a dot net core project which is running CI with coverage using open cover. Results can be seen here: https://coveralls.io/github/IsraelHikingMap/Site CI build can be seen here (last few build have an issue with NuGet which is an appvoyor problem not with the code): https://ci.appveyor.com/project/HarelM/site Project sources can be found here: https://github.com/IsraelHikingMap/Site

### jskeet commented Jul 19, 2017

 @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 commented Jul 19, 2017

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

### carusology commented Jul 19, 2017

 @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 commented Jul 19, 2017

 @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...
Member

### sawilde commented Jul 20, 2017

 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 commented Jul 20, 2017

 @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 commented Aug 10, 2017

 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.

Closed

### akamud commented Nov 8, 2017

 This has been evolving in the coreclr repo: dotnet/coreclr#445 (comment)

Merged

### NishaKuruvilla commented Nov 21, 2017

 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  E:\SONAR\NUnit.Console-3.7.0\nunit3-console.exe 2017-11-14T07:09:46.6084668Z nunit3-console 

### rpokrovskij commented Dec 31, 2017

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

### smukherjee-rythmos commented Mar 20, 2018

 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 
Member

### sawilde commented Mar 21, 2018

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

### smukherjee-rythmos commented Mar 21, 2018 • edited

 @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?
Member

### sawilde commented Mar 21, 2018

 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 commented Apr 6, 2018 • edited

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

### smukherjee-rythmos commented Apr 12, 2018 • edited

 @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.

Closed