New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Core Tool Support #601

Open
StrangeWill opened this Issue Jun 12, 2016 · 68 comments

Comments

@StrangeWill

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

@sawilde

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Jun 12, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@haythem

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

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

This comment has been minimized.

Show comment
Hide comment
@StrangeWill

StrangeWill Jun 14, 2016

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

StrangeWill commented Jun 14, 2016

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

@tmds

This comment has been minimized.

Show comment
Hide comment
@tmds

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

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

This comment has been minimized.

Show comment
Hide comment
@snookerfly

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

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?

@sawilde

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Jul 5, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@snookerfly

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

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

This comment has been minimized.

Show comment
Hide comment
@StrangeWill

StrangeWill Jul 5, 2016

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

StrangeWill commented Jul 5, 2016

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

@snookerfly

This comment has been minimized.

Show comment
Hide comment
@snookerfly

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

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.

@sawilde

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Jul 5, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@snookerfly

snookerfly Jul 6, 2016

and it also happens on W10.

snookerfly commented Jul 6, 2016

and it also happens on W10.

@sawilde

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Jul 6, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@tmds

tmds 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).

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

This comment has been minimized.

Show comment
Hide comment
@StrangeWill

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

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.

@sawilde

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Jul 16, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@tverboon

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

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

This comment has been minimized.

Show comment
Hide comment
@jp7677

jp7677 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

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

This comment has been minimized.

Show comment
Hide comment
@jp7677

jp7677 Jul 18, 2016

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

jp7677 commented Jul 18, 2016

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

@sawilde

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Jul 18, 2016

Member

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.

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.

@jp7677 jp7677 referenced this issue Jul 19, 2016

Closed

Support portable pdb files #610

8 of 24 tasks complete
@haythem

This comment has been minimized.

Show comment
Hide comment
@haythem

haythem Aug 22, 2016

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

haythem commented Aug 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@tmds

tmds 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)

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

This comment has been minimized.

Show comment
Hide comment
@jacksontbryan

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

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

This comment has been minimized.

Show comment
Hide comment
@carusology

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

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

This comment has been minimized.

Show comment
Hide comment
@repspark-trh

repspark-trh Sep 16, 2016

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"

repspark-trh commented Sep 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@carusology

carusology Sep 16, 2016

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.

carusology commented Sep 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Sep 17, 2016

Member

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.

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.

@jskeet

This comment has been minimized.

Show comment
Hide comment
@jskeet

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

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

This comment has been minimized.

Show comment
Hide comment
@HarelM

HarelM 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

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

This comment has been minimized.

Show comment
Hide comment
@jskeet

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

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

This comment has been minimized.

Show comment
Hide comment
@HarelM

HarelM Jul 19, 2017

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

HarelM commented Jul 19, 2017

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

@carusology

This comment has been minimized.

Show comment
Hide comment
@carusology

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

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

This comment has been minimized.

Show comment
Hide comment
@jskeet

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

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

@sawilde

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Jul 20, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@twgraham

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

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

This comment has been minimized.

Show comment
Hide comment
@carusology

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

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.

@akamud

This comment has been minimized.

Show comment
Hide comment
@akamud

akamud Nov 8, 2017

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

akamud commented Nov 8, 2017

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

@NishaKuruvilla

This comment has been minimized.

Show comment
Hide comment
@NishaKuruvilla

NishaKuruvilla 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

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

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

  <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

This comment has been minimized.

Show comment
Hide comment
@rpokrovskij

rpokrovskij commented Dec 31, 2017

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

@smukherjee-rythmos

This comment has been minimized.

Show comment
Hide comment
@smukherjee-rythmos

smukherjee-rythmos 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

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

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Mar 21, 2018

Member

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

Member

sawilde commented Mar 21, 2018

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

@smukherjee-rythmos

This comment has been minimized.

Show comment
Hide comment
@smukherjee-rythmos

smukherjee-rythmos Mar 21, 2018

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

smukherjee-rythmos commented Mar 21, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@sawilde

sawilde Mar 21, 2018

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@jp7677

jp7677 Apr 6, 2018

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

jp7677 commented Apr 6, 2018

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

@smukherjee-rythmos

This comment has been minimized.

Show comment
Hide comment
@smukherjee-rythmos

smukherjee-rythmos Apr 12, 2018

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

smukherjee-rythmos commented Apr 12, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment