Retarget netcoreapp1.0 -> netcoreapp2.1, remove System.Xml.XPath.XmlDocument

[nguerrera]

Description

We need to eliminate pre-built binaries for source build and System.Xml.XPath.XmlDocument isn't built anymore. It is present in the package inserted into CLI only because the bits target netcoreapp1.0 AFAICT. You should be able to retarget to netcoreapp2.1 now as the CLIs you insert new bits into have that as a baseline. When you do this, you can remove the package reference to s.x.xp.xmldocument as the API it provided will be available directly from the framework.

Steps to reproduce

Build and looks for System.Xml.XPath.XmlDocument.dll

Expected behavior

No

Actual behavior

System.Xml.XPath.XmlDocument.dll is present in the bits inserted into dotnet CLI.

cc @singhsarab

[nguerrera]

Moderately related: #1886, but this is more blocking. Even if the dependencies were handled better, we would still want this dependency to be eliminated entirely.

[singhsarab]

@mayankbansal018 @cltshivash We need to consider picking this up soon. I am under the impression that moving to netstandard2.0 should resolve such issues.

The only problem I see would be related to supporting older UWP projects (built in VS2017 or prior), I think we can take a call on that.

[nguerrera]

Do the vstest bits in C:\Program Files\dotnet\sdk[version\ impact UWP projects? How so? (I hope not.)

If you can't move everything to netstandard2.0 (or netcoreapp2.1), the only requirement from us that you don't build the bits being inserted into CLI against netcoreapp1.0. Actually, even that you can get away without doing for this, if you can otherwise remove System.Xml.XPath.XmlDocument, but retargeting would be the easiest way to achieve that.

[ViktorHofer]

Targeting netstandard everywhere would also help us in corefx to not clash with framework assemblies that are currently restored via the graph.

[singhsarab]

This is done. #2067