[Feature Request] Prefer to use the dotnet local tool installed in the solution for coverlet, if available.

[nike4613]

Installed product versions

• Visual Studio: 2019 Preview Community (16.9.0 Preview 3.0)
• This extension: 1.1.116

Description

If the solution being worked in has a locally installed dotnet tool for coverlet, use it in place of the set version the extension defaults to using.

Current behavior

Currently, the extension always uses an old version of coverlet, which, in my case, does not have a certain patch I need.

Expected behavior

I would expect that a locally installed dotnet tool would override whatever the extension used by default.

Side Notes

This can be easily seen by just creating a new solution, installing a new version of coverlet.console locally, then trying out the extension. In my specific case, I need a feature in the coverlet preview builds that automatically ignores source files referenced by PDBs that end in .g.cs, because I make heavy use of source generation. Currently, without going out of my way to manually install the tool to the folder that the extension expects it to live in, I simply cannot use the extension with my code generation.

A different solution would be to switch to using --collector:"XPlat Code Coverage" during the normal VSTest runs, if that is possible, then just reading the results, though this would have the drawback of slowing down normal test runs.

[FortuneN]

We are planning on moving away from the console and use the collector soon (--collector:"XPlat Code Coverage").
The console has a big flaw that we cannot ignore anymore : https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/KnownIssues.md#1-vstest-stops-process-execution-earlydotnet-test

None-the-less i understand the need to run "your own version" as opposed the default.
The only concern is that you may wish to run a version that we haven't tested (possibly incompatible).
Though, i suppose, we could allow that with a "Here be dragons" warning.

With regards to ignoring files, please have a look at the following:
https://github.com/FortuneN/FineCodeCoverage#global-shared-options
https://github.com/FortuneN/FineCodeCoverage#local-test-project-options-override-globals-in-your-csprojvbproj--optional
https://github.com/FortuneN/FineCodeCoverage#options

@tonyhallett What do you think?

[nike4613]

Unfortunately ignoring files like that does not actually solve the issue (see coverlet-coverage/coverlet#1084), and I have, for now, just provided a Powershell script that updates the executable used by the extension to use the version of coverlet that works. I would appreciate even a "here be dragons" option, as long as its present.

[tonyhallett]

@nike4613
The latest vsix will use coverlet data collector version 3.0.3 if you opt in - see here. This version has the fix for the issue that you are experiencing.

@FortuneN
Should we upgrade the global console tool to the latest version now https://www.nuget.org/packages/coverlet.console/ ?

[tonyhallett]

@FortuneN
Even if we update to the latest version there will still be a need for this feature request. Before I tackle it let's get to an agreement of how to proceed.

If we are allowing specifying a different coverlet console we have to allow for the 3 different ways that the tool could be installed. Global, global tool path and local.
We can check global installs with dotnet tool list --global and allow the user to specify globally and on a test project basis - e.g UseCoverletGlobal boolean.
Global tool path would have to be specified as a full path - again this can go in vs options or in a test project.
For local installs we could search up directories for .config/dotnet-tools.json and read the json or use dotnet tool list - so UseCoverletLocal boolean would suffice.

In a similar manner we should allow for the user to specify the --test-adapter-path when using coverlet data collector. This is slightly different in that we should be able to determine this ourselves if the user has installed the nuget package.
With my nuget setup the data collector files get installed here C:\Users\tonyh.nuget\packages\coverlet.collector

This was mentioned here
Although doable ( we would need to consider PackageReference vs Packages.config ) it would be so much simpler for the user to specify the path.
I propose then that we have a global and project option CoverletCollectorPath.

Your thoughts.

[FortuneN]

CoverletCollectorPath is fine

[tonyhallett]

@FortuneN You ok with the UseCoverletGlobal etc ?

[FortuneN]

Go for it

…

On Sat, 27 Feb 2021 at 01:35, Tony Hallett ***@***.***> wrote: @FortuneN <https://github.com/FortuneN> You ok with the UseCoverletGlobal etc ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#96 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLAAT3BDREZZGVZRVA2XWDTBAV5VANCNFSM4XYFDIXQ> .

[tonyhallett]

Will do. Please can you publish to marketplace

[FortuneN]

Done!

…

On Sat, 27 Feb 2021 at 01:37, Tony Hallett ***@***.***> wrote: Will do. Please can you publish to marketplace — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#96 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLAAT57M4D4NA5M4NRTVHDTBAWFBANCNFSM4XYFDIXQ> .