Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

Full description is here:

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

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

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

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:29 (18 by maintainers)

github_iconTop GitHub Comments

peterhuenecommented, Mar 22, 2019

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

peterhuenecommented, Mar 22, 2019

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

Read more comments on GitHub >

github_iconTop Results From Across the Web

Nuget package not copying native DLLs on build
The nuget package has the managed DLL in the lib/netstandard2.0 directory and even has the unmanaged DLL in root/runtimes/RID/native directory.
Read more >
Select Assemblies Referenced By Projects - NuGet
Make a subset of assemblies in the package available to the compiler, while all assemblies are available at runtime.
Read more >
Troubleshooting NuGet Package Restore in Visual Studio
This error occurs when you attempt to build a project that contains references to one or more NuGet packages, but those packages are...
Read more >
Using .NET Standard with Full Framework .NET - Rick Strahl
This adds a non-trivial amount of assemblies to your application's bin folder that have to be distributed with your application and a bunch...
Read more >
Dependencies of project reference not copied to output ...
Dependencies of project reference not copied to output breaking ... NET Standard library; Use some classes from above nuget package in .
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found