Binaries are not automatically copied to the output directory for managed projects

[dfields-msft]

I'm using this package to supplement a native binary built for UWP so it can be used in non-UWP projects as well. This works fine if the non-UWP project is also native, but when I consume this package (directly or indirectly) from a managed project, the binaries do not get copied to the output directory; I have to add manual build steps to do this. Then everything works great! Can this package be updated to make this happen auto-magically?

[dfields-msft]

BTW, the project I was trying this from was targeting .NET Standard 2.0.

[Huios]

Hey Daniel. .NET Standard is the root of the issue, currently the fNuGet package supports automatic copying in.NET Framework 4.5+ and .NetCore 2+ projects. We'll add .NET Standard to the backlog.

[AaronRobinsonMSFT]

I am also hitting this issue in some .NET Core scenarios. All that I observe in the output directory is the following structure:

...\CSHARPWINUICONSOLE\BIN\DEBUG\NETCOREAPP3.1
│ ...
└───runtimes
├───win10-arm64
│ └───native
│ ├───debug
│ │...
│ └───release
│ │...
├───win10-x64
│ └───native
│ ├───debug
│ │...
│ └───release
│ │...
└───win10-x86
└───native
├───debug
│...
└───release
│...

/cc @Scottj1s @jkoritzinsky

[Scottj1s]

@AaronRobinsonMSFT, are you seeing this with AnyCPU solution configurations, resulting in the runtime not finding the native dlls, as they're placed under arch-specific TPM folders? If so, the fix here might be to eliminate those AnyCPU configs (we had to do this with the Package Support Framework).

FYI - separately, @manodasanW indicates that .NET core 3.1 should automatically loadlib the binaries in the appropriate TPM subfolder, but that's not working, so the vcrt forwarder nuget explicitly copies them into the TFM folder root.

[stevenbrix]

I'm running into a similar issue as well: #31

What is the correct/expected behavior? I'd imagine that the native assembly should be loaded from the proper location, which then has a dependency on the vcrtforwarders dll's being next to it.

Per @AaronRobinsonMSFT comment here:#7 (comment), the fact these dlls are in debug \ release subfolders causes problems