UAP target doesn't have package references properly generated/used

[clairernovotny]

When trying to cross compile with a project that includes a uap10.0 target, the csc task doesn't have the package references resolved correctly and put on the CSC task.

To repro, look at the vs2017 branch of https://github.com/onovotny/Zeroconf/tree/vs2017

In there you'll see it cross-compiling to netstandard1.3 and uap10.0. The problem is that it's using the wrong mscorlib reference for uap10.0 and when you look at the msbuild log and csc task invocation, it's not passing the correct /reference's that include all of the package dependencies that come from both the NETStandard.Library and the Microsoft.NETCore.UniversalWindowsPlatform reference. The RAR task seems to not generate anything.

Not sure if this is in the SDK tasks or the NuGet tasks?

[clairernovotny]

/cc @piotrpMSFT @yishaigalatzer

[clairernovotny]

Happens on latest RC with preview4 sdk.

[clairernovotny]

Here is the diagnostic build log showing a netstandard and a uap cross compiled build. You can see that there are no resolved package dependencies for the uap build.

build.txt

project.assets.json.txt

[davkean]

tag @nguerrera @ericstj

[davkean]

and @dsplaisted

[dsplaisted]

I think you can work around this by setting the following when the TargetFramework property is uap10.0:

<NugetTargetMoniker>UAP,Version=v10.0</NugetTargetMoniker>

The problem is that without this, the NuGetTargetMoniker is being set to "UAP,Version=v10.0.10240", which isn't matching the target in the lock file. Microsoft.PackageDependencyResolution.targets is explicitly using the first three segments of the TargetPlatformMinVersion when the TargetFrameworkMoniker is ".NETCore,Version=v5.0". So there may be a reason that the target moniker is supposed to include the Windows SDK version, and we may need a different solution than to simply use the simpler version of NugetTargetMoniker as in the workaround.

[natidea]

Those lines were inherited from Microsoft.NuGet.targets and presumably their application is the same in this context. The full condition suggests that explicitly setting UseTargetPlatformAsNuGetTargetMoniker to false will result in NuGetTargetMoniker == TargetFrameworkMoniker.

[clairernovotny]

While setting <NugetTargetMoniker>UAP,Version=v10.0</NugetTargetMoniker> let the references go through correctly, it created another issue -- all of the references are now copied to the output directory.

This should only happen for an AppX, Xap or Exe. The UWP library project shouldn't have all of the NuGet references copied to its output directory (slow/size, etc).

[clairernovotny]

Similar issues with other TFM's. It's not calculating the version correctly in the lock file. In the lock file it was Version=v0.0

For portable-win81+wpa81:

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

win8 also needed the following:

  <PropertyGroup Condition="'$(TargetFramework)' == 'win8'">
    <NugetTargetMoniker>Windows,Version=v8.0</NugetTargetMoniker>
    <TargetFrameworkIdentifier>.NETCore</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
    <DefaultLanguage>en-US</DefaultLanguage>
    <PackageTargetFallback>$(PackageTargetFallback);netstandard1.1</PackageTargetFallback>
    <LanguageTargets>$(MSBuildExtensionsPath)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets</LanguageTargets>
  </PropertyGroup>

The ones for the "inbox" frameworks, windows, wp, wpa, sl, profile pcl's and xamarin should have these property groups in there by default in the SDK

[nguerrera]

... it created another issue -- all of the references are now copied to the output directory.

@onovotny I believe this is because the SDK currently only defaults $(CopyLocalLockFileAssemblies) to false for .NET Core or .NET Standard. Can you try setting this to false yourself? Or did swapping the LanguageTargets already resolve that?

[clairernovotny]

@nguerrera adding that line to disable the local lock file copy did the trick. The LanguageTargets did not.

[clairernovotny]

When working on this bug, keep in mind that calculating the NuGet Moniker based on TargetPlatformMinVersion may not work if UAP is bumped up to uap10.1 as it exists here: dotnet/corefx@7f22710. The version of Windows itself, and thus the PlatformMinVersion is unlikely to change (or will change for marketing reasons independent of what the TFM means).

[dsplaisted]

@onovotny This would be fixed by your PR #889, right?

[clairernovotny]

maybe?

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.