Update requirements on docs

[MarcoRossignoli]

Contributes #466

cc: @tonerdo @AArnott @vagisha-nidhi

[AArnott]

The docs look fine, but I don't think this should close #466 because a doc on this README is neither discoverable nor alleviates the fault-looking error when the test run fails.

IMO we need to update docs where users look. Personally, the docs I was basing my work on were here: https://aka.ms/vstest-collect. They don't even mention coverlet, but apparently coverlet is an implementation detail of how code coverage is collected. Can/should we get those docs updated to indicate the restriction?

Also, can we produce a better error than the one mentioned in #466 to educate the user as to what they should do?

This limitation required that I break up my otherwise monolithic dotnet test command into individual dotnet test -f TFM1 commands (6 of them, I think) just so I could avoid adding the code coverage switch to the netcoreapp1.x targeted test target frameworks. I'd rather keep just the one command in my Azure Pipeline and have the non-supporting targets emit a warning to the effect of "coverage won't be collected on .NET Core 1.x" but otherwise let the tests run their course.

[MarcoRossignoli]

The docs look fine, but I don't think this should close #466 because a doc on this README is neither discoverable nor alleviates the fault-looking error when the test run fails.

I understood that issue was to only update our side with the info.

IMO we need to update docs where users look. Personally, the docs I was basing my work on were here: https://aka.ms/vstest-collect. They don't even mention coverlet, but apparently coverlet is an implementation detail of how code coverage is collected. Can/should we get those docs updated to indicate the restriction?

Should be keep updated by coverlet dev members? cc: @vagisha-nidhi @cltshivash @PBoraMSFT

Also, can we produce a better error than the one mentioned in #466 to educate the user as to what they should do?
This limitation required that I break up my otherwise monolithic dotnet test command into individual dotnet test -f TFM1 commands (6 of them, I think) just so I could avoid adding the code coverage switch to the netcoreapp1.x targeted test target frameworks. I'd rather keep just the one command in my Azure Pipeline and have the non-supporting targets emit a warning to the effect of "coverage won't be collected on .NET Core 1.x" but otherwise let the tests run their course.

I agree