Repository navigation
Need a way to specify RID-specific dependencies #4552
Description
Folks often need to cross compile and use an OS-specific package. Today the only way they can do this is to fork their project.json.
I think we need a "dependencies" section under the RID entry in runtimes.
This is related to NuGet/Home#1660.
Activity
ericstj commentedon Dec 10, 2015
Dependencies under RID might not be the right design since RID has no impact on the compile graph today, but the basic problem is I need to produce an implementation on Windows that uses windows specific packages (which cannot be used for Unix and will fail to resolve any assets) and vice-versa.
/cc @davidfowl @anurse
ericstj commentedon Jan 9, 2016
Here's a suggestion for how we can represent this: permit a runtime to be nested under framework. When that exists it indicates that we should cross compile for that runtime. In that case we'll use the TFM:RID target (runtime graph) for both the compile items and the runtime items. The runtime listed under framework can have its own dependency section to represent packages dependencies specific for that runtime. Here's a sample of how that might be used:
EG:
@davidfowl @anurse: thoughts?
andyleejordan commentedon Jan 26, 2016
We are definitely going to need this for an internal project, sooner rather than later.
davidfowl commentedon Jan 26, 2016
I'll write something up with how this might work. We have a design in mind
vors commentedon Jan 26, 2016
I (as a user) think it's a good design.
Also connected scenario: I want to be able to build my dependencies from sources, but at the same time, I want to be able to consume dependencies as packages from nuget. I would love to have it to provide an easier setup for people, who care only about a particular package in the project.
Looks like this feature will allow me to do it as well.
davidfowl commentedon Jan 26, 2016
Project file changes
Foo/project.json
{ "version": "1.0.0-*", "frameworks": { "netstandard1.3": { "dependencies": { "System.Console": "4.1.0-rc2-3455" } }, "netstandard1.3(win7)": { "dependencies": { "System.Security.Cryptography.Cng": "4.1.0-rc2-3455", "System.Net.Http.WinHttpHandler": "4.1.0-rc2-3455" } }, "netstandard1.3(unix)": { "dependencies": { "System.Security.Cryptography.OpenSsl": "4.1.0-rc2-3455", "System.Net.Http.CurlHandler": "4.1.0-rc2-3455" } } } }We would infer defines for the RID.
Lock file changes
{ ... "targets": { "DNXCore,Version=v5.0": { }, "DNXCore,Version=v5.0(win7)": { }, "DNXCore,Version=v5.0(unix)": { }, "DNXCore,Version=v5.0/win7-x86": { }, "DNXCore,Version=v5.0/win7-x64": { } } ... }Notice the {tfm}({rid}) sections. These are new "compile time graphs".
dotnet/nuget pack changes
Foo.1.0.0.nupkg
Foo.nuspec
The sections DO NOT MERGE. During the runtime graph walk, one of the sections are chosen, just like the TFM graph walk today.
Potential additions
This would be a shortcut for supporting multiple runtimes (if dependencies were shared).
ericstj commentedon Jan 26, 2016
What happens if a dependency like this only shows up in the runtime graph?
Since runtime.jsons are only honored if the appear in the compile graph wouldn't the RID specific dependencies be ignored?
Foo is a library that has a Unix and Win build. Unix build depends on Bar. Bar gets listed in Foo's runtime.json.
Bar is a library that has a Linux and OSX build. Linux build depends on Baz. Baz gets listed in Bar's runtime.json.
Foo is consumed by App that is not RID specific. The app's compile graph contains Foo so it gets Bar. The app's compile graph does not contain Bar, so it never gets Bar's runtime.json, and thus never gets Baz when deployed on Linux.
davidfowl commentedon Jan 27, 2016
@ericstj We decided to put something in the nuspec. Updated the spec to respect this.
ericstj commentedon Jan 27, 2016
LGTM. I'm guessing minClientVersion for this should be 3.4.0 or something.
So when consuming this package
<group targetFramework=".NETStandard1.3">section<group targetFramework=".NETStandard1.3" targetRuntime="win7">section<group targetFramework=".NETStandard1.3">section<group targetFramework=".NETStandard1.3" targetRuntime="unix">sectiondavidfowl commentedon Jan 27, 2016
@ericstj
We need to roll back the change to System.Security.Principal.Windows (WindowsPrincipal) and potentially the System.Windows.Registry until we have this feature because right now we (ASP.NET) are broken. https://github.com/dotnet/corefx/issues/5694
davidfowl commentedon Jan 27, 2016
@ericstj That's correct.
andyleejordan commentedon Jan 27, 2016
I thought @anurse already had a spec for this.
Specifically this section.
davidfowl commentedon Jan 27, 2016
You can assume this supersedes that 😀
analogrelay commentedon Jan 27, 2016
@andschwa That is not technically related, that is for configuration of
corehost. It is derived from this data, but it a different spec.Temporarily permit install of OpenSSL on windows
andyleejordan commentedon Jun 20, 2016
@piotrpMSFT why won't this make it into RTM? It's still blocking us pretty badly. We have to use a
LINUXconfiguration and preprocessor definitions to work-around this. It's ugly.Merge pull request #465 from smadala/to-utf-8
baronfel commentedon Nov 28, 2023
NuGet packages support RID-specific assets now. Closing this as a result.
PathogenDavid commentedon Dec 10, 2023
@baronfel This isn't about RID-specific assets, it's about RID-specific dependencies.
Unless I missed something in .NET 8, I don't think the latter is supported.
(That being said, maybe NuGet/Home#1660 or NuGet/Home#10571 is a better place to track this anyway?)
baronfel commentedon Dec 10, 2023
Ah, good call on both counts. NuGet will need to understand/define something structure for describing these, then probably the SDK's ResolvePackageAssets task will need updating to follow that structure.