Native assets are not copied to bin for net472 app if any referenced package uses netstandard2.0

Full description is here: https://github.com/dotnet/symreader-converter/issues/151

I suspect this is an SDK bug in C:\Program Files\dotnet\sdk\2.1.504\Sdks\Microsoft.NET.Sdk\tools\net46\Microsoft.NET.Build.Tasks.dll; see https://github.com/dotnet/symreader-converter/issues/151#issuecomment-475344092.

My workaround for now is to add this to the csproj, but it’s obviously brittle:

  <ItemGroup>
    <ReferenceCopyLocalPaths Include="C:\Users\jmusser\.nuget\packages\microsoft.diasymreader.native\1.7.0\runtimes\win-x64\native\Microsoft.DiaSymReader.Native.amd64.dll" />
  </ItemGroup>

[peterhuene]

Perhaps NuGet could warn that native assets were found in a package but the RID graph was not resolved?

[peterhuene]

@jnm2 it’s not a problem with the ShellProgressBar package and instead the result of how netstandard libraries were being packaged for 1.x vs. 2.0.

To restore native assets, NuGet needs a RID graph. This is what tells NuGet that RID win7-x64 is a child of win-x64, which is a child of win when resolving assets, for example. The RID graph comes from the Microsoft.NETCore.Platforms package; its sole asset is the runtime.json file that defines the graph.

When you target a .NETCoreApp TFM, you get the RID graph as a transitive reference via the (implicitly referenced) Microsoft.NETCore.App package. When you target a .NETFramework TFM, you don’t get a RID graph because there’s no reference (transitive or direct) to Microsoft.NETCore.Platforms.

However, when you referenced a netstandard1x package, it had a transitive reference to Microsoft.NETCore.Platforms so a RID graph was found and the native assets were resolved. This transitive reference no longer exists for netstandard2.0 packages. As a result, you’ll need an explicit reference on Microsoft.NETCore.Platforms if you desire to resolve native assets from your packages when targeting .NETFramework.

Does that make sense? Adding an explicit reference should solve the problem and is a necessary step when building an application with a .NETFramework TFM that desires to resolve native assets from its packages.

I’m going to close this issue by design for now. Thank you for your assistance in helping us to identify the issue.