Nuget needs to support dependencies specific to target runtime
ericstj opened this issue · 11 comments
Currently there is no way to represent dependencies that are specific to a library under runtimes/{rid}/lib/{tfm}. This made since when RID was only used for architecture, now that RID also represents OS platform it does not. There are entire packages/technologies that will only exist on a certain OS and folks will need to build fat-packages that depend on these.
I met with @davidfowl, @yishaigalatzer, @anurse, @Eilon, and @lodejard on 10/6 and we came up with the following:
Sounds like a good feature. Doesn’t replace runtime.json, solves a different problem.
A couple different options for representation:
- targetRuntime on a dependency group
- Separate runtime dependency section that supports both targetFramework and targetRuntime.
- Has the benefit of also supporting another scenario which is “private dependencies”.
We’d need to make sure that it has the right interaction with runtime.json if that is also in play.
WCF has a need for this as I need to add a dependency to WinHttpHandler for Windows only.
@mconnew are you sure https://docs.nuget.org/create/uwp-create doesn't give you enough tools already?
I'm already packaging up Matt's stuff with runtime specific packages, but its an example of a set of libraries that don't belong in the ".NET Standard" but need to have platform specific implementations. I think WCF benefit from this feature rather than putting the platform-specific implementation information in the framework's lineup (runtime.json).
Ping. Where is this at on the priority list? Would you like to get together and work on a spec?
Lets talk today. Right now I don't see it happening in Dec, but we can talk further
Sent from my Windows Phone
From: Eric StJohnmailto:notifications@github.com
Sent: 12/10/2015 8:44 AM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Nuget needs to support dependencies specific to target runtime (#1660)
Ping. Where is this at on the priority list? Would you like to get together and work on a spec?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1660#issuecomment-163683085.
Yes. Though it's more of a feature. Right now NuGet provides no way for a package to expose different API nor dependencies based on runtime. It's not blocking us but it is a gap that has come up quite a few times.
+1
It would help our use case quite a lot too: Xenko.Graphics uses OpenTK on Linux, SharpDX on Windows, etc...
Considering this is possibly a breaking change, any chance this makes it to NuGet 5.0/VS2019?
Hi,
@xen2 I think you can have a shot at having what you want with several runtime nugets and a meta-package on top.
You have then to use a runtime.json trick that was meant for .Net core / framework itself and not apparently meant to be widely used.
So use at your own risks 😁
There is a very well explained example project.
At the Nuget team, this has been around for a while now, how do you think it should be implemented (so people might be able to help), and why not just document the runtime.json and let people generate meta-packages ?
Thanks and kind regards.
PackageReference condition only support TargetFramework variable.
src: https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#adding-a-packagereference-condition
While it doesn't scale at all if you want to start to support multiples RID at least the limitation is now documented 😞
@DevTeam think of the combinatory explosion <os> x <platform>.
e.g [linux, win, osx] x [x64, arm64] => 6 PackageReferences...