search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

Support including native dependencies for Linux and macOS platforms by default #13670

Open baronfel opened 3 months ago

baronfel commented 3 months ago

NuGet Product(s) Involved

NuGet.exe, MSBuild.exe, dotnet.exe

The Elevator Pitch

When creating packages NuGet has a list of approved extensions for that package's contents. That list today is .dll; .exe; .winmd; .json; .pri; .xml; .mdb; .pdb. This list works great for managed libraries!

However, when packaging native dependencies in a package by default NuGet only allows native dependencies for the windows platforms. .so and .dylib assets for these other platforms are filtered out by the configuration above.

I propose that NuGet add these two extensions to the allow list so that packaging native assets is easier and less confusing for users.

Additional Context and Details

I ran across this when helping @JanProvaznik package his MSBuildWasm project as a NuGet package containing MSBuild logic. Since his MSBuild logic needed both managed dependencies and native dependencies for all platforms, but we didn't want to package to lib/ to prevent consumers from getting any of these libraries as runtime assets, we had to direct NuGet to package these dependencies to the task/ subfolder. However, after adding Native dependencies to the BuildOutputInPackage ItemGroup, I found the non-dll native assets scrubbed out.

nkolev92 commented 2 months ago

Team Triage: MSBuild tasks tend to have requirements that don't always apply to more general packages. Normally, we'd expect native content to be part of the runtimes, not the lib folder. https://learn.microsoft.com/en-us/nuget/create-packages/native-files-in-net-packages is a great write on creating packages with native content. We'd need to dig deeper to understand the full range of consequences from changing that default.

Another consideration is whether the BuildOutputInPackage item is right item for including this content during the pack customization.

baronfel commented 2 months ago

I guess the question I'm trying to ask here is: Why is NuGet blocking me when I explicitly ask for specific files to be included? I'm not making a package for any project to consume, for all intents and purposes, so why is me saying "Include this .so file" not respected?

nkolev92 commented 2 months ago

Fair, maybe ignoring extension checks when BuildOutputPath is non-default is good enough.