TargetFrameworkVersion gets lost on PCL targets #492

onovotny opened this Issue Dec 14, 2016 · 2 comments


None yet

4 participants

onovotny commented Dec 14, 2016 edited

Splitting from #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'">

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" />

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


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-*


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.

@nguerrera nguerrera was assigned by srivatsn Dec 21, 2016
@srivatsn srivatsn added this to the 1.0 RTM milestone Dec 21, 2016
@srivatsn srivatsn added the Bug label Dec 21, 2016
@onovotny onovotny referenced this issue in dotnet/cli Jan 17, 2017

Meta: Blocking RTM issues #5365

2 of 9 tasks complete
@srivatsn srivatsn modified the milestone: 1.1, 1.0 RTM Jan 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment