Copying Content Files from Nuget package to the consuming project's bin folder

[WingZer0o]

Hello there,

I have a Nuget Package that looks like this in Nuget Package Explorer.

This package is essentially a wrapper around a Rust library for Cryptographic algorithms. Now for the life of me, when I install this nuget package into a new project, that DLL and SO do not get transferred into the consuming project's bin.

To include this DLL and SO I am using the following in .csproj.

<Content Include="Contents/**/*.*">
	<Pack>true</Pack>
	<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
	<PackagePath>contentFiles\any\any;content</PackagePath>
	<PackageCopyToOutput>PreserveNewest</PackageCopyToOutput>
</Content>

Is there a flag I can set in .csproj to copy those files when the nuget package is installed and built from within a consuming project or does this require a MsBuild .targets file?

[baronfel]

@WingZer0o you don't usually use content files for this. Instead, packages can contain runtime specific assets, which is described here: https://learn.microsoft.com/en-us/nuget/create-packages/native-files-in-net-packages

Specifically, you need to package your native dlls in runtime specific folders that match the expected NuGet folder structure (which is linked on that page). If you do this, NuGet will tell the .NET SDK about the runtime assets during the Restore phase of the build, and the SDK will ensure that projects that reference your package have the Runtime-specific assets to their output folders when necessary.

[WingZer0o]

I've changed my .csproj to the following with no results in geting the runtime assets to copy over on build. Does {rid} and {tfm} stand for anything. Wish the documentation here wasn't so cryptic on this topic.

		<Content Include="Contents/**/*.*">
			<Pack>true</Pack>
			<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
			<PackagePath>runtimes\{rid}\lib\{tfm}/</PackagePath>
		</Content>

[baronfel]

Yes, RID and TFM have specific meaning here - they refer to specific RuntimeIdentifier and TargetFramework values. You will need to know what these are for your library to be picked up. RuntimeIdentifiers are values like limux-x64, or win-arm64, etc. TargetFrameworks are values like net8.0, net7.0, and so on. You should have an idea of what these are from your project - what is it's TFM? What platforms and architecture are your native libraries built for?

[WingZer0o]

These are Rust Native Libraries that are built with the crate type of dylib so when I build I get a .dll and .so on windows and linux respectively. Thanks for the quick response! I've been researching all night.

[WingZer0o]

I was able to get this to work for the DLL in windows. I will try more tomorrow. Thanks!!