Support "portable" (.NET Standard 2.0) tasks

[dsplaisted]

Currently, MSBuild targets .NET Standard 1.3 and .NET Framework 4.6. If you want to build a task that runs on both .NET Core and full framework MSBuild, you can reference the .NET Core versions of the MSBuild libraries, which target .NET Standard 1.3. When running on full framework MSBuild, these references would bind to the full framework implementations (similar to the "bait and switch" technique).

As part of upgrading to .NET Core 2.0, the .NET Core versions of the MSBuild libraries will target .NET Standard 2.0. This means they won't load on .NET 4.6. They can load on .NET 4.6.1, but the proper .NET Standard facades need to be available.

[jaredpar]

Does the world get simpler here if we change the minimum required desktop version of MSBuild to be 4.6.1?

[dsplaisted]

I've resolved this with my latest changes. GenAPI creates source files which are used to create reference assemblies that go in the NuGet packages. The MSBuild APIs themselves are still compatible with .NET Standard 1.3, so I am compiling the reference assemblies for .NET Standard 1.3 in addition to .NET 4.6 and 2.0, and putting them all in the NuGet package.

[dsplaisted]

It looks like this may be a problem once again. Enabling binary serialization is causing types to be used in public APIs which aren't available in .NET Standard 1.3.

[dasMulli]

Cross-linking this with dotnet/sdk#1855 (comment)

by @ericstj

the bigger problem here is that the whole premise is busted: NETStandard libraries themselves aren't publishable/runnable since they may depend on packages with framework specific implementations and selecting at runtime between frameworks isn't something that any framework understands nor is it persisted by NuGet.

[rainersigwald]

This mostly works today: if your task has no references outside of .NET Standard 2.0 itself, it'll work fine on both flavors of MSBuild.

This part remains

NETStandard libraries themselves aren't publishable/runnable since they may depend on packages with framework specific implementations

And we should still publish better guidance (#4198).