Update Projects Targeting `netstandard2.0`

[benvillalobos]

From Rainer in this thread:

I don't think there's a good reason to not retarget that. But it doesn't have to be in this PR. Reasons to do it: use new APIs etc in tasks, which is a good thing.

"That", being any project that targets netstandard2.0 still.

[rainersigwald]

Any given version of MSBuild runs in the standard shipping configuration on one runtime: the one of the SDK in which its distributed. So I think all of our assemblies should directly target net5.0 (or 6.0, and on into the future) for MSBuild on .NET (Core).

I think there are two reasons to think about preferring netstandard:

1. Task authoring
2. API consumers

Neither really supports netstandard: if your task has any dependencies, you'll need the ones for the right runtime, so people are basically forced to multitarget task assemblies. And if you're using the API you'll need Locator, which must multitarget because of the radically different discovery mechanisms between Core and Framework, so no advantage there either.

[TFTomSun]

@rainersigwald we have some build task libraries which are built against .NET Standard 2.0. They have also dependencies (.NET Standard 2.0) Does that mean that they need to be retargeted to .NET48 and NET5 in the future? I'm a bit afraid that this would doubly the package sizes of packages that are often large, because build packages with tasks need to bring all their dependencies with them.

[KalleOlaviNiemitalo]

The "in this thread" link seems to be invalid somehow. In Safari, it points to back to this issue #6032; in the GitHub mobile app, it points to http://localhost/.

[KalleOlaviNiemitalo]

I wanted to use the Microsoft.Build.Construction API on netstandard2.0 for loading a project file, editing it, and saving it; not for defining tasks or calling targets. Because Microsoft.Build/16.0.461 and later versions no longer support netstandard2.0, and older versions may be completely unable to load projects that contain elements defined in newer versions (like MSBuild 4.0 does not tolerate the Sdk element), I ended up loading the project file in XML DOM and analysing it ad hoc, which was rather cumbersome with the case insensitivity and the optional XML namespace. However:

• This ship already sailed in Remove netcoreap20 #3528.
• I'm not sure whether MSBuild loaded from the NuGet package would even have been able to locate the SDKs that it would have needed for evaluating the values of properties, whereas the ad hoc code can skip most of that and still be compatible with the project files that it needs to edit.