Sdk: dotnet publish of net461 does not copy native assets but netcoreapp2.1 will

[robmen]

I have a managed .nupkg (WixToolset.Core.Native) that depends on a .nupkg with native assets (runtime.win.WixToolset.Core.Native). The native assets are in runtimes\win\native.

I have two other projects that consume the WixToolset.Core.Native.nupkg. One project is netcoreapp2.1 and one is net461. When publishing the netcoreapp2.1 project all of the assets from runtimes\win\native are copied. When publishing the net461 project none of the native assets are copied.

The following will demonstrate the above behavior:

1. Clone https://github.com/wixtoolset/Core.git
2. Run "appveyor.cmd"
3. Note present build\Release\publish\netcoreapp2.1\wixnative.*.exe

4. Note missing build\Release\publish\net461\wixnative.*.exe

   @nick_guerrera (Twitter) suggested opening this issue after discussing in this thread: https://twitter.com/nick_guerrera/status/1017903818367881216

[nguerrera]

This is not what I initially thought on Twitter because you are specifying a RID.

[nguerrera]

Meaning this may well be a bug. I will have to dig in.

[nguerrera]

Thanks for the repro.

[robmen]

More information. It appears that when I change the "runtime.win.WixToolset.Core.Native" to use runtimes\win-x86\native that both netcoreapp2.1 and net461 work.

Perhaps the issue is only a problem for net461 finding native assets in runtimes\win\native?

Also, note, since I've made this change, I've also "broken" the repo steps above as things appear to be working with this new organization. Let me know if you need help getting a proper repro recreated.

[dasMulli]

Quick hypothesis from my mobile: does it change when you also reference Microsoft.NETCore.Platforms?
If there is no package pulling that in transitively, there’s no RID graph specifying the win-x*>win relationship

[nguerrera]

Good call, @dasMulli. I think that's likely the explanation.

Also, I cloned yesterday so I should have a repro. I didn't try it yet though. I just visually established that it wasn't my first guess.

[nguerrera]

If so, though, it means we have tests that are just lucky to use exact rid match. But I can't see how it can work without that package in the graph, so that must be the case. :( I think we should have a diagnostic for this. I'll work with the Nuget team on that if we've diagnosed this right.

[dasMulli]

Yeah I remembered this from https://github.com/dotnet/standard/issues/497

@dasMulli right now, those libraries would want to reference the platforms package specifically if they require the RID graph. My comment above was referring to existing packages which depended on it transitively via previous versions of NETStandard.Library. I gather you are suggesting that it would be nice if packages didn't have to do this. I tend to agree, though that would mean we'd need some sort of implicit PackageReference on all targeting-pack-based frameworks: desktop, xamarin.*, etc.

Would require some work, but a fallback graph that's carried by the SDK would be nice for these scenarios. (even harder since it probably should work for non-sdks projects using PackageReference as well)

[dasMulli]

So I get the repro when fixing the reference to WixToolset.Core.Native back to 4.0.12 (before the RID change in the package) in WixToolset.Core.csproj. When I then added a reference to Microsoft.NETCore.Platforms/2.1.0 the rid-specific assets appeared in the publish output.

[nguerrera]

Fixed by #3406, we now supply a built-in RID graph to NuGet.