Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
TargetFrameworkVersion gets lost on PCL targets #492
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
In order to support
<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
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:
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-*