Sdk: Better error message for P2P ref from "project.json / PCL" .NET Standard project to SDK-style .NET Standard project

[clairernovotny]

When I have a legacy PCL project that has P2P ref to a CPS .NET Standard class library, I get build errors:

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.Common.targets(63,5): error MSB4044: The "GetNearestTargetFramework" task was not given a value for the required parameter "ReferringTargetFramework".
2>

Repro

Clone https://github.com/onovotny/zeroconf
checkout dev
Try to build ZeroconfTest.Xam (portable) from VS.

Actual results

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.Common.targets(63,5): error MSB4044: The "GetNearestTargetFramework" task was not given a value for the required parameter "ReferringTargetFramework".
2>_GetProjectReferenceTargetFrameworkProperties:
2>  Build continuing because "ContinueOnError" on the task "MSBuild" is set to "!false".
2>C:\dev\Zeroconf\Zeroconf\Zeroconf.csproj : error MSB4057: The target "GetTargetPath" does not exist in the project.
2>
2>Build FAILED.
2>

Expected results
Compile successfully

Update 2/23/17
Use commit 51dd7238a9782bb1b4ddb7162f6f169fa6b61343 from that repo to reproduce as I'll be working around it by converting to a netstandard class lib.

[nguerrera]

@onovotny @srivatsn

OK, after some investigation, this problem is actually scoped to the following case:

1. PCL is targeting .NETStandard not a classic portable profile, AND
2. CPS project is multi-targeted.

Projects of type (1) have some unique characteristics around TFMs:

• They set TargetFrameworkMoniker to .NETPortable,Version=v5.0
• The set NuGetTargetMoniker to .NETPlatform,Version=v5.0;.NETStandard,Version=v1.0;.NETStandard,Version=v1.1;.NETStandard,Version=v1.2;.NETStandard,Version=v1.3;.NETStandard,Version=v1.4;.NETStandard,Version=v1.5;.NETStandard,Version=v1.6

Neither of these nor anything in the MSBuild evaluation indicate the specific version of .NETStandard that is targeted. It seems that the source of truth is limited to the frameworks entry in project.json. :(

Workarounds

A. Migrate to SDK-based .NETStandard. This is what we'd generally recommend to get all of the other goodness of the new project system. Is there something holding you back from moving that project?
B. Explicitly indicate the moniker you want to use to resolve project references and have it match what is in project.json (one line change to PCL csproj):

<PropertyGroup>
  <ReferringTargetFrameworkForProjectReferences>.NETStandard,Version=v1.0</ReferringTargetFrameworkForProjectReferences>
</PropertyGroup>

Fixing

There isn't an easy fix here. It can't go in the SDK because we don't get imported by PCL and putting in msbuild common targets would be complicating things at the wrong layer IMHO. I think the PCL targets need to be adjusted somehow. cc @rchande, @Pilchie

Given that there are viable workarounds vs. real risks with a late change for this, I recommend that we postpone this past RTM. I also think we should consider investing in a migration experience from PCL -> SDK.

[clairernovotny]

Thanks for the explanation! In my case, there's nothing stopping me from migrating over to a .NET Standard library; I was just filing the issue based on trying stuff that seemed like it should work.

While there's no easy fix for RTW, is there any way this specific condition can be detected so that a better error can be inserted pointing at this issue or a workaround?

[dsplaisted]

Moving to 2.0 for us to provide a better error message here.

[nguerrera]

These projects are no longer supported, so we won't fix this.