-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve handling of native packages (Support RID specific dependencies) #10571
Comments
It'd be nice if NuGet defaulted to the RID of the host system without the user having to specify RuntimeIdentifier manually, so that it could download the correct packages for the host system in development environments, and then only fail when attempting to publish. |
It would be nice to allow package dependencies conditioned on the host RID. For instance, ILCompiler supports targeting win-arm64 RID on a win-x64 host using the |
dotnet/ClangSharp#229 is another example of where native package handling could be improved. When a RID specific package contains |
Another issue I've discovered recently is that GeneratePathProperty for a package which uses a runtime.json isn't correctly updated to point to the path of the package specified in the runtime.json - this makes using artefacts from packages like https://www.nuget.org/packages/Microsoft.NETCore.DotNetAppHost when hosting .NET Core a lot harder. |
Hey @tannergooding It seems like we didn't dedup it originally, but there seems to be a lot of overlap. |
Issue
Native dependencies tend to be OS/architecture specific and larger than managed assemblies. Due to this, it isn't uncommon to end up with a NuGet package that is "unreasonably" large due to needing to support at least the 4 most common architectures (x86 Windows, x64 Windows, x64 Linux, x64 MacOS). This only increases once you also factor in Linux Distro specific variants that are often required (Ubuntu vs RHEL) or up and coming architectures (ARM32/64).
Native dependencies such as
libClang
are currently ~22MB per RID (compressed) and so they are using theruntime.json
functionality to have a small central dependency (libclang, 16.75kb) which refers to the larger RID specific dependencies of which there are currently 11. For example: ((libclang.runtime.win-x64, 22.33mb). A similar situation exists for libLLVM.runtime.json
works very well at limiting the usage to only what the user actually needs. However, the experience is less than stellar when not specifying a RID as the downstream native dependencies aren't copied to the output folder and are therefore not discoverable at runtime. And, at least as I understand,runtime.json
is not "officially" supported for general usagelibclang.runtime.win-x64
vs referencinglibclang
) works in that the relevant binaries do get copied.Workaround
The current workaround for this has been to explicitly specify a RID at build time, such as:
However, this means that users need to go through an additional step beyond simply adding their dependency and need to understand what the consequences of specifying a RID are. Additionally,
NETCoreSdkRuntimeIdentifier
may belinux-x64
in which case it won't resolve to the actual RID specific binary that is desired (such asubuntu.20.04-x64
).Requested Fix
It would be ideal if there was an official way to have RID specific native dependencies that could be easily and correctly handled from .NET libraries.
Users should be able to reference a central "meta" package that lists the RID specific dependencies so they download the minimum binaries required, particularly when in a development environment.
The correct native dependencies should be resolvable under F5 by
DllImport
andNativeLibrary.Load
without the user needing to specify additional project configuration settings.There should be some mechanism for resolving native dependencies when things don't line up. That is, you should be able to use
ubuntu18.04
fromubuntu20.04
if not20.04
specific dependency does exist. It would (IMO) be fine if this was via explicit opt-in at the individual package level or if it was enabled by default with a warning.The text was updated successfully, but these errors were encountered: