Who needs code coverage?

Not cross-plat dotnet developers, I guess.

I love continuous integration. I love continuous deployment. These two processes are my bread-and-butter for making day-to-day development easy. I just recently completed a migration for moving a set of dotnet core projects from 1.0 to 2.0. With that came the new 2.0 tooling, which I've been pretty excited about - gaining access to msbuild should provide a lot more power, right?

As a part of enabling some new CI/CD functionality, I went to go and turn on some basic test metrics like code coverage, so we can make better decisions about what and when to deploy. There are a lot of free and open source options, and this is a pretty basic functionality. You'd think it would have been part of a major release, right? 

Well. Not exactly.

Apparently code coverage can't be harness indirectly, and to use it directly requires an install of vstest.console.exe. Running dotnet test --collect:"Code Coverage" results in some pretty buggy output that definitely is not code coverage. Welp. I'm not super excited about being forced to not only have my build agents be Windows boxes, but to also require them to have an install of VS2017 Enterprise on them. 

I'll update again if I can string together a workaround!