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.

[teo-tsirpanis]

I agree with @TFTomSun, Microsoft.Build.Framework and Microsoft.Build.Utilities.Core should still target .NET Standard 2.0.

[I]f your task has any dependencies, you'll need the ones for the right runtime, so people are basically forced to multitarget task assemblies.

Not if all the task's dependencies target .NET Standard 2.0; I maintain a task package that falls under this category.

[rainersigwald]

We had decided offline that we will no longer target .NET Standard 2.0, but we will continue to produce a reference assembly for NS2.0 that would keep things working. And we should have noted that here.

[TFTomSun]

@rainersigwald Can you tell a bit more about how this NS2.0 reference assembly can be consumed then? It's not clear to me what "not target netstandard, but produce reference assembly for netstandard" means.

[AraHaan]

It means, that for your tasks it will reference those reference assemblies to be able to compile, but at runtime msbuild would load the versons shipped with itself when the task is loaded.