Home: ResolveNuGetPackageAssets msbuild target needs RID fallback support for .NET Core

[eerhardt]

As it exists today, the MSBuild Target ResolveNuGetPackageAssets doesn't do any RID interpretation. However, this is a problem because when building in VS, I get errors like the following:

Your project.json doesn't list 'win-x64' as a targeted runtime. You should add '"win-x64": { }' inside your "runtimes" section in your project.json, and then re-run NuGet restore.

'win-x64' isn't really a supported RID in .NET Core. Today, the "base" 10 RIDs that are supported for .NET Core are:

  "runtimes": {
    "win7-x64": {},
    "win7-x86": {},
    "osx.10.11-x64": {},
    "ubuntu.14.04-x64": {},
    "ubuntu.16.04-x64": {},
    "centos.7-x64": {},
    "rhel.7.2-x64": {},
    "debian.8-x64": {},
    "fedora.23-x64": {},
    "opensuse.13.2-x64": {}
  }

The ResolveNuGetPackageAssets target expects someone to set the $(BaseNuGetRuntimeIdentifier) property before it is executed. However, this property can't be hard-coded in the user's .csproj because they can take the exact same .csproj and build on Windows, OSX, or Linux. Thus this property must come from somewhere.

NuGet and the Microsoft.NuGet.targets file needs to work together in order to find the most appropriate RID in the user's project.lock.json file to use, if one hasn't been specified by the user expicitly (like through the command-line). My suggestion would be to use the RID of the current machine, and then do the appropriate RID fallback until one is found in the project.lock.json file.

@jasonmalinowski @yishaigalatzer @emgarten @rrelyea @harikmenon

[eerhardt]

Another issue in this vein - in .NET Core today, the default app type is a "portable" app, which doesn't have a "runtimes" section at all. However, when building from VS, I still get:

Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win-x64": { } }' to your project.json and then re-run NuGet restore.

Which is incorrect, because portable apps don't have a "runtimes" section.

[eerhardt]

With the implementation of the new ResolveLockFileReferences target in https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.DotNet.Core.Build.Tasks/Microsoft.PackageDependencyResolution.targets, this issue can now be closed. We will not be using the ResolveNuGetPackageAssets target in .NET Core. ResolveLockFileReferences handles RIDs correctly.

[yishaigalatzer]

How do this ship to customers?

[eerhardt]

How do this ship to customers?

The .NET Core SDK ships in a NuGet package that contains the MSBuild tasks and targets necessary to build .NET Core projects. You can see the package here: https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.DotNet.Core.Sdk

[yishaigalatzer]

My question was around how this ships for the non core scenario

[eerhardt]

My question was around how this ships for the non core scenario

I can't help you there. Maybe @davkean and @natidea have an idea and can answer.

[nietras]

I have these exact issues in VS 15.5.5. Building from command line using dotnet build works, but not from VS. So it doesn't seem resolved to me.