Fix CoverletSourceRootsMapping path

[martincostello]

Fix the path for the CoverletSourceRootsMapping file not being set correctly if the $(OutputPath) property does not end with a trailing directory separator.

I was trying to enable deterministic builds using version 2.9.0 of the MSBuild package, but the code coverage wasn't being reported. I then noticed that the file was being created with the name artifactsCoverletSourceRootsMapping in my solution root, rather than as CoverletSourceRootsMapping in the artifacts directory.

[MarcoRossignoli]

Thank's Martin!
Seems ok to me, @clairernovotny can you double check if there is a better way or if it's ok as is(you're more expert than me on msbuild)?

[MarcoRossignoli]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[clairernovotny]

You probably want EnsureTrailingSlash https://docs.microsoft.com/en-us/visualstudio/msbuild/property-functions?view=vs-2019#msbuild-ensuretrailingslash

[martincostello]

Ah yes, I’d forgotten about that one. Will update the PR a bit later. Thanks!

[MarcoRossignoli]

Thank's to all

[MarcoRossignoli]

@martincostello you can try nigthly https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/ConsumeNightlyBuild.md tomorrow(published ~00.00)

Let me know!

Thank's again to all!

[martincostello]

@MarcoRossignoli I've pulled the nightly into this PR here and it's working as expected without my workaround for the incorrect path: martincostello/xunit-logging#139

However, I still need to use the CoverletGetPathMap MSBuild target for it to work. I was under the impression that the workaround wasn't needed with coverlet.msbuild 2.9.0+ and .NET SDK 3.1.300+?

Without: https://github.com/martincostello/xunit-logging/pull/139/checks?check_run_id=741352608#step:4:151

With: https://github.com/martincostello/xunit-logging/pull/139/checks?check_run_id=741370987#step:4:154

[MarcoRossignoli]

Interesting, I don't know what changes were done on that side, but we can keep the "fix"...btw in future version of sdk we can avoid target workaround dotnet/roslyn#43706 (comment)

[martincostello]

I guess the fix that will make the extra target redundant will come in a future version of 3.1.3xx as it seems to have missed 3.1.300

[MarcoRossignoli]

@tmat maybe can answer, but I think that will come since next release as servicing dotnet/roslyn#43476 (comment)
We'll need also some update to coverlet.

[clairernovotny]

The target update missed the 3.1.300 and Coverlet needs an update to call the updated target as well.

There are two options for Coverlet: always call the target and fail not do the path mapping if it hasn't been updated (basically require the SDK that has the fix as a minimum), or conditionally call that target and also support the workaround target for lower SDK's.