question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

A default value for the CoverletOutput MSBuild property

See original GitHub issue

I assume that a default value for the CoverletOutput property should not be the $(MSBuildProjectDirectory) but the $(OutputPath). Here are a few reasons why this is a more appropriate value:

  1. A code coverage report is a kind of program output, as well as binaries and XML documentation files.
  2. A code coverage report will be automatically redirected to another location when the project stores output somewhere outside the project (or the solution).
  3. Code coverage reports for different configurations can be different (e.g., due to #if directives). And thus, the value of $(OutputPath) can automatically store reports in different folders without overwriting since it evaluates to the $(BaseOutputPath)\$(Configuration)\ by default.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:8 (2 by maintainers)

github_iconTop GitHub Comments

2reactions
eerhardtcommented, Jan 14, 2019

@alexanderkozlenko - why did you close this issue? I fully agree with your reasoning above - the default value shouldn’t be in the source directory for a project. All the outputs should be directed to output folders.

1reaction
eerhardtcommented, Jan 15, 2019

@tonerdo - you could follow that same reasoning for any output file. The build .dll and .pdb. The documentation .xml file. The test results file .trx.etc. They would be easier to find in VS if they weren’t in the “output” directory. However, most users know to look in the output directory for the outputs. So putting output files in a different directory actually makes it confusing.

Writing to the “source” directory of a project during the build is generally frowned upon. One reason is that people need to add a specific .gitignore entry for those files (I assume code coverage results files shouldn’t be checked in). Another reason is that a human can easily tell what can be cleaned up - just delete the bin and obj folders.

I would imagine most projects would need/want to change this default, which doesn’t make it a very good default in my opinion.

Read more comments on GitHub >

github_iconTop Results From Across the Web

A default value for the CoverletOutput MSBuild property #152
I assume that a default value for the CoverletOutput property should not be the $(MSBuildProjectDirectory) but the $(OutputPath).
Read more >
coverlet/Documentation/MSBuildIntegration.md at master
Coverlet allows you to specify a coverage threshold below which it fails the build. This allows you to enforce a minimum coverage percent...
Read more >
MSBuild script default property best practices explanation
When using the recommend approach however, if MyProperty is not specified elsewhere, it will have 'Default Value' as value. Invoke both cases ...
Read more >
Use code coverage for unit testing - .NET
Unit tests help to ensure functionality and provide a means of verification for refactoring efforts. Code coverage is a measurement of the ...
Read more >
Common MSBuild Project Properties
The default value is true , which means that projects will be built in parallel if the system has multiple cores or processors....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found