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.

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

Mechanism for supplying runtime.json outside of a package #7351

Closed
nguerrera opened this issue Oct 1, 2018 · 8 comments · Fixed by NuGet/NuGet.Client#2882
Closed

Mechanism for supplying runtime.json outside of a package #7351

nguerrera opened this issue Oct 1, 2018 · 8 comments · Fixed by NuGet/NuGet.Client#2882

Comments

@nguerrera
Copy link

nguerrera commented Oct 1, 2018

In Core 3.0, the platform will not be represented as a traditional nuget package. As such, there's no obvious place for the RID graph to be supplied to NuGet.

  1. The SDK will need access to the RID graph to pick the appropriate "runtime pack"
  2. Restore will also need access to it to pick the correct RID-specific package assets for packages outside the platform.

For (2), the feature request here would be to have msbuild items that specify runtime.json files on disk to use during restore.

Something like

<ItemGroup>
  <RuntimeGraph Include="path/to/runtime.json" />
</ItemGroup>

It's a separate question as to how the SDK will locate runtime.json for (1), but once we do that, we can then just pass it in to restore if we had this feature.

Update by @nkolev92
Spec

@dsplaisted
Copy link

Downsides of current workaround (referencing platform package implicitly if there are any other package references):

  • Platforms package shows up in dependency tree
  • .NET Framework may still have issues if we don't also add code to automatically reference it

@dsplaisted
Copy link

Probably we would use an MSBuild property instead of an item for this, as that wouldn't require nomination API changes.

@rrelyea rrelyea modified the milestones: 5.1, 5.2 Apr 30, 2019
@nkolev92 nkolev92 self-assigned this Jun 4, 2019
@nkolev92
Copy link
Member

nkolev92 commented Jun 4, 2019

The idea is to use a property to avoid nomination changes. It can be a semicolon delimited property similar to TargetFrameworks for example.

I will create a short spec on this.

@nkolev92
Copy link
Member

nkolev92 commented Jun 6, 2019

Update the issue body with link to the spec.

@nkolev92
Copy link
Member

Project system bug: dotnet/project-system#4951
Project system PR: dotnet/project-system#4952

@rrelyea rrelyea added the Type:DCR Design Change Request label Jul 11, 2019
@xen2
Copy link

xen2 commented Oct 14, 2019

Noticed a bunch of regression and need some help:

  1. Our game engine (Xenko), add extra runtimes (https://github.com/xenko3d/xenko/blob/master/sources/engine/Xenko/runtime.json)
  2. Since updating to VS 2019 16.3.0 (with .NET Core 3), we had to add <RuntimeIdentifierGraphPath></RuntimeIdentifierGraphPath> to one of our target file for this to keep working.
    It doesn't seem to work anymore in latest VS2019 (however it work if I move <RuntimeIdentifierGraphPath></RuntimeIdentifierGraphPath> from our package target to user project but still half broken depending on PackageReference order).

I would be fine to change things around, so maybe you have some recommendation/other way to achieve this and keep the old way (which is still supposed to be supported for .NET Core 2 from what I understood)?

@nkolev92
Copy link
Member

nkolev92 commented Oct 15, 2019

Not sure if this is enabled in 2.x, @nguerrera, @dsplaisted will know.

Can you clarify what you are seeing when it fails?

The assets file will have all the info about what nuget "thinks" exists, and it should be on a per framework basis.

@xen2
Copy link

xen2 commented Oct 15, 2019

Never mind, I think it might have been due to something else.
We had a circular runtime identifier references between our runtime identifier (on purpose so that win includes win-d3d11 by default).
I suppose this PR changed the default (undefined) order of runtime inclusion, which we shouldn't have relied on in the first place.
We will do things differently.

xen2 added a commit to stride3d/stride that referenced this issue Oct 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants