Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Nuget needs to support dependencies specific to target runtime #1660

Open
ericstj opened this issue Oct 29, 2015 · 11 comments
Open

Nuget needs to support dependencies specific to target runtime #1660

ericstj opened this issue Oct 29, 2015 · 11 comments
Labels
Area:PackageDefinition Functionality:Restore Partner:VS-Other Priority:2 Issues for the current backlog. Style:PackageReference Type:Feature
Milestone
Backlog

Comments

@ericstj
Copy link

ericstj commented Oct 29, 2015

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.
@ericstj ericstj mentioned this issue Oct 29, 2015
Closed
@yishaigalatzer yishaigalatzer added this to the 3.4 milestone Oct 31, 2015
@mconnew
Copy link

mconnew commented Nov 19, 2015

WCF has a need for this as I need to add a dependency to WinHttpHandler for Windows only.

@yishaigalatzer
Copy link

@mconnew are you sure https://docs.nuget.org/create/uwp-create doesn't give you enough tools already?

@ericstj
Copy link
Author

ericstj commented Nov 20, 2015

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).

@ericstj ericstj closed this as completed Nov 20, 2015
@ericstj ericstj reopened this Nov 20, 2015
@ericstj
Copy link
Author

ericstj commented Dec 10, 2015

Ping. Where is this at on the priority list? Would you like to get together and work on a spec?

@yishaigalatzer
Copy link

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.

@ericstj ericstj mentioned this issue Jan 21, 2016
Merged
@ericstj ericstj mentioned this issue Feb 2, 2016
Merged
@yishaigalatzer yishaigalatzer removed this from the 3.4 milestone Feb 22, 2016
@ericstj ericstj mentioned this issue Feb 25, 2016
Closed
dotnet-bot pushed a commit to dotnet-bot/wcf that referenced this issue Mar 3, 2016
@ericstj
**Suppress implementation dependencies from compile.**
db1f53d 
Packages with ref and lib list all their dependencies
in a single section for that target framework.

This creates a couple problems:
1. Folks end up taking a dependency on the fact that a package
happens to use another package in its implementation.
2. For packages that have multiple implementations for the
same TFM and different RID all dependencies appear in the
same section even though some may be RID specific.
Those RID speicific dependencies will compatibility
errors during restore since the packages won't be supported
on all RIDs.
In lieu of the NuGet feature to represent RID-specific
dependencies NuGet/Home#1660
we can at least suppress the compatibility error by
excluding these implementation specific depdencies from
compile.

Further details are here:
dotnet/buildtools@d40435b#diff-abe065d40d7c72dbdc1ad1957148d23fR14

[tfs-changeset: 1581170]
dotnet-bot pushed a commit to dotnet-bot/corefx that referenced this issue Mar 3, 2016
@ericstj
**Suppress implementation dependencies from compile.**
5a26b24 
Packages with ref and lib list all their dependencies
in a single section for that target framework.

This creates a couple problems:
1. Folks end up taking a dependency on the fact that a package
happens to use another package in its implementation.
2. For packages that have multiple implementations for the
same TFM and different RID all dependencies appear in the
same section even though some may be RID specific.
Those RID speicific dependencies will compatibility
errors during restore since the packages won't be supported
on all RIDs.
In lieu of the NuGet feature to represent RID-specific
dependencies NuGet/Home#1660
we can at least suppress the compatibility error by
excluding these implementation specific depdencies from
compile.

Further details are here:
dotnet/buildtools@d40435b#diff-abe065d40d7c72dbdc1ad1957148d23fR14

[tfs-changeset: 1581170]
@ericstj ericstj mentioned this issue Mar 4, 2016
Merged
@andyleejordan andyleejordan mentioned this issue Mar 16, 2016
Closed
@ericstj ericstj mentioned this issue Sep 7, 2016
Closed
@rrelyea
Copy link
Contributor

rrelyea commented Dec 8, 2016

@ericstj - going through old issues. Still an issue?

@ericstj
Copy link
Author

ericstj commented Dec 9, 2016

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.

@NightOwl888 NightOwl888 mentioned this issue Apr 16, 2017
Closed
@emgarten emgarten added this to the Backlog milestone Nov 10, 2017
@emgarten emgarten added the Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. label Nov 10, 2017
@xen2
Copy link

xen2 commented Oct 28, 2018 •
edited
Loading

+1
It would help our use case quite a lot too: Xenko.Graphics uses OpenTK on Linux, SharpDX on Windows, etc...

@xen2
Copy link

xen2 commented Jan 28, 2019

Considering this is possibly a breaking change, any chance this makes it to NuGet 5.0/VS2019?

@chaami
Copy link

chaami commented Jul 24, 2019

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.

This was referenced Jan 31, 2020
Closed
Closed
@nkolev92 nkolev92 added Priority:2 Issues for the current backlog. Functionality:Restore Style:PackageReference Area:PackageDefinition and removed Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Platform:Xplat labels Apr 9, 2020
@Mizux
Copy link

Mizux commented Sep 21, 2021

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...

@tannergooding tannergooding mentioned this issue Oct 20, 2021
Open
picenka21 pushed a commit to picenka21/runtime that referenced this issue Feb 18, 2022
@ericstj
**Suppress implementation dependencies from compile.**
6be4ead 
Packages with ref and lib list all their dependencies
in a single section for that target framework.

This creates a couple problems:
1. Folks end up taking a dependency on the fact that a package
happens to use another package in its implementation.
2. For packages that have multiple implementations for the
same TFM and different RID all dependencies appear in the
same section even though some may be RID specific.
Those RID speicific dependencies will compatibility
errors during restore since the packages won't be supported
on all RIDs.
In lieu of the NuGet feature to represent RID-specific
dependencies NuGet/Home#1660
we can at least suppress the compatibility error by
excluding these implementation specific depdencies from
compile.

Further details are here:
https://github.com/dotnet/buildtools/commit/dotnet/corefx@d40435b1c460416768cc53a27091e57d948be171#diff-abe065d40d7c72dbdc1ad1957148d23fR14

[tfs-changeset: 1581170]


Commit migrated from dotnet/corefx@5a26b24
@ericstj ericstj mentioned this issue May 4, 2022
Open
@nkolev92 nkolev92 mentioned this issue Jul 29, 2022
Open
@asimmon asimmon mentioned this issue Jul 31, 2022
Open
@eerhardt eerhardt mentioned this issue Jun 28, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area:PackageDefinition Functionality:Restore Partner:VS-Other Priority:2 Issues for the current backlog. Style:PackageReference Type:Feature
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests