Sdk: TargetFrameworkVersion gets lost on PCL targets

[clairernovotny]

Splitting from https://github.com/dotnet/sdk/issues/477

There are a few issues around using profile-based PCL's in the SDK build system that all seem be traced back to the TargetFrameworkVersion segment of the NuGetTargetMoniker getting "lost."

@emgarten @yishaigalatzer @rrelyea The .NETPortable v0.0 thing is more pervasive than just the above as it appears to affect at least the lock file generation and package generation.

In order to support portable-win81+wpa81 for example, you need the following. Note the explicit NuGetTargetMoniker is required with v0.0 in it because that's how the lock file was generated.

  <PropertyGroup Condition="'$(TargetFramework)' == 'portable-win81+wpa81'">
    <TargetFrameworkIdentifier>.NETPortable</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v4.6</TargetFrameworkVersion>
    <TargetFrameworkProfile>Profile32</TargetFrameworkProfile>
    <DefaultLanguage>en-US</DefaultLanguage>
    <NugetTargetMoniker>.NETPortable,Version=v0.0,Profile=Profile32</NugetTargetMoniker>
    <LanguageTargets>$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets</LanguageTargets>
  </PropertyGroup>

Later, when calling the pack target, the generated nuspec has the following

      <group targetFramework=".NETPortable0.0-Profile32">
        <dependency id="System.Reactive" version="3.1.1" exclude="Build,Analyzers" />
        <dependency id="NETStandard.Library" version="1.6.1" exclude="Build,Analyzers" />
      </group>

The pack target is generating it wrong too (I believe it should be .NETPortable4.6-Profile32)

[emgarten]

This sounds painful.

NuGet ignores the different versions of portable, so when used within a nupkg or nuspec it is fine to have .NETPortable0.0.

For the build task consuming the assets file I would expect this behavior:

1. If a target graph with an exact match on the TFM exists use it
2. Fallback to using .NETPortable,Version=*,Profile=Profile32

It would be really unexpected if 2 had more than one match, failing with an error would be reasonable there.

NuGet has never used the portable version number in the past, so requiring it now could break users passing in TFMs as portable-*

[clairernovotny]

Fair enough, using 2 is ok long as the "best match" is evaluated correctly for p2p refs. Key thing here is just ensuring that the NugetTargetMoniker hack isn't required.

[livarcocc]

Seems like the Fallback is the right escape hatch here. Closing this issue.