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

[Breaking change]: Runtime host looks for RID-specific assets via a known list instead of RID graph by default #35398

Closed
2 of 3 tasks
elinor-fung opened this issue May 18, 2023 · 1 comment · Fixed by #35710
Assignees
Labels
binary incompatible Existing binaries may encounter a breaking change in behavior. breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 8 Work items for the .NET 8 release doc-idea Indicates issues that are suggestions for new topics [org][type][category] Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.

Comments

@elinor-fung
Copy link
Member

elinor-fung commented May 18, 2023

Description

When running an application with RID-specific assets, the host determines which assets are relevant for the platform on which it is running. This applies to both the application itself and the resolution logic used by AssemblyDependencyResolver.

Previously, it tried to compute the RID at runtime and then read the RID graph to determine which RID-specific assets match or are compatible with the computed RID. Now, the default behaviour no longer uses the RID graph and a computed RID, relying instead on a known list of RIDs based on how the runtime itself was built.

PR: dotnet/runtime#84100
Related issue: dotnet/runtime#83246
Related design: dotnet/designs#260

Version

.NET 8 Preview 5

Previous behavior

The process for selecting RID-specific assets was:

  1. Read the RID graph from the .deps.json of the root framework (Microsoft.NetCore.App)
  2. Compute the current RID at run-time and try to find an entry for it in the RID graph
    • If it doesn't exist, check for a fallback RID (built into the host at compile-time)
  3. Starting from the entry found in the RID graph, look for assets matching that RID.
  4. Continue down the list of RIDs in the RID graph entry until an asset match is found or the list ends.

This had the effect where if the RID graph didn't have the computed RID or the fallback RID, RID assets would not be properly resolved.

New behavior

By default, the process no longer relies on the RID graph and now checks for a known set of portable RIDs based on how the host was built. For example:

Linux

  • linux-x64
  • linux
  • unix-x64
  • unix
  • any

Windows

  • win-x64
  • win
  • any

macOS

  • osx-x64
  • osx
  • unix-x64
  • unix

For non-portable builds of the host/runtime, the build may also set a non-portable RID that will be checked first.

Type of breaking change

  • Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
  • Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code may require source changes to compile successfully.
  • Behavioral change: Existing binaries may behave differently at run time.

Reason for change

The RID graph has consistently been costly to maintain and understand, requiring .NET itself to be distro-aware in a fragile manner. The .NET team and the community spend a non-trivial amount of time updating the graph and backporting such updates to previous releases. The long-term goal is to stop updating the RID graph, stop reading it, and eventually remove it. This breaking change is a step towards that goal.

Recommended action

Using portable RIDs (for example, linux, linux-musl, osx, win) is recommended path forwards. For specialized use cases, APIs like NativeLibrary.SetDllImportResolver or AssemblyLoadContext.ResolvingUnmanagedDll can be used for custom loading logic.

A backwards compat switch is also provided to revert to the previous behaviour. Setting the runtime config property System.Runtime.Loader.UseRidGraph to true in a runtimeconfig.json or MSBuild property will use the previous method of reading the RID graph.

Feature area

Deployment

Affected APIs

AssemblyDependencyResolver


Associated WorkItem - 97016

@elinor-fung elinor-fung added doc-idea Indicates issues that are suggestions for new topics [org][type][category] breaking-change Indicates a .NET Core breaking change Pri1 High priority, do before Pri2 and Pri3 labels May 18, 2023
@dotnet-bot dotnet-bot added ⌚ Not Triaged Not triaged binary incompatible Existing binaries may encounter a breaking change in behavior. labels May 18, 2023
@elinor-fung elinor-fung changed the title [Breaking change]: Runtime host looks for RID-specific assets via a known list by default [Breaking change]: Runtime host looks for RID-specific assets via a known list instead of RID graph by default May 18, 2023
@elinor-fung
Copy link
Member Author

cc @agocke @richlander @vitek-karas

@gewarren gewarren added 🏁 Release: .NET 8 Work items for the .NET 8 release and removed ⌚ Not Triaged Not triaged labels May 18, 2023
@gewarren gewarren added the 🗺️ reQUEST Triggers an issue to be imported into Quest. label Jun 2, 2023
@github-actions github-actions bot added 📌 seQUESTered Identifies that an issue has been imported into Quest. and removed 🗺️ reQUEST Triggers an issue to be imported into Quest. labels Jun 3, 2023
@ghost ghost added the in-pr This issue will be closed (fixed) by an active pull request. label Jun 8, 2023
@gewarren gewarren moved this from 🔖 Ready to 👀 In review in dotnet/docs June 2023 sprint Jun 8, 2023
@github-project-automation github-project-automation bot moved this from 🆕 New to ✅ Done in .NET 8.0 work items Jun 8, 2023
@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in dotnet/docs June 2023 sprint Jun 8, 2023
@ghost ghost removed the in-pr This issue will be closed (fixed) by an active pull request. label Jun 8, 2023
kythant pushed a commit to microsoft/WindowsAppSDK that referenced this issue Nov 28, 2023
…ionCopyFilesToStagingDir.ps1

.NET8 introduced a [conditional breaking change](dotnet/docs#35398) that influences how the runtime host looks for RID-specific assets. In NET8, support for non-portable RIDs (runtime identifiers specific to versions and distributions, such as win10-x86) is discontinued. The folder structure of the Microsoft.WindowsAppSDK NuGet is structured with assets marked using these non-portable RIDs:
![image (4).png](https://dev.azure.com/microsoft/55e8140e-57ac-4e5f-8f9c-c7c15b51929d/_apis/git/repositories/2467406e-dc4e-49eb-b903-238f0da5a43e/pullRequests/9926818/attachments/image%20%284%29.png)
The changes made to the `CopyFilesToStagingDir.ps1` script along with the project template changes should help support the .NET8 scenario. The selection of the project template's RIDs is conditional and based on the TFM chosen by the user. If NET8 is chosen, the RIDs become portable, enabling the runtime host to locate the RID-specific assets that were previously unattainable.
kythant pushed a commit to microsoft/WindowsAppSDK that referenced this issue Nov 28, 2023
…ionCopyFilesToStagingDir.ps1

.NET8 introduced a [conditional breaking change](dotnet/docs#35398) that influences how the runtime host looks for RID-specific assets. In NET8, support for non-portable RIDs (runtime identifiers specific to versions and distributions, such as win10-x86) is discontinued. The folder structure of the Microsoft.WindowsAppSDK NuGet is structured with assets marked using these non-portable RIDs:
![image (4).png](https://dev.azure.com/microsoft/55e8140e-57ac-4e5f-8f9c-c7c15b51929d/_apis/git/repositories/2467406e-dc4e-49eb-b903-238f0da5a43e/pullRequests/9926818/attachments/image%20%284%29.png)
The changes made to the `CopyFilesToStagingDir.ps1` script along with the project template changes should help support the .NET8 scenario. The selection of the project template's RIDs is conditional and based on the TFM chosen by the user. If NET8 is chosen, the RIDs become portable, enabling the runtime host to locate the RID-specific assets that were previously unattainable.
kythant added a commit to microsoft/WindowsAppSDK that referenced this issue Nov 29, 2023
…ionCopyFilesToStagingDir.ps1 (#3997)

.NET8 introduced a [conditional breaking change](dotnet/docs#35398) that influences how the runtime host looks for RID-specific assets. In NET8, support for non-portable RIDs (runtime identifiers specific to versions and distributions, such as win10-x86) is discontinued. The folder structure of the Microsoft.WindowsAppSDK NuGet is structured with assets marked using these non-portable RIDs:
![image (4).png](https://dev.azure.com/microsoft/55e8140e-57ac-4e5f-8f9c-c7c15b51929d/_apis/git/repositories/2467406e-dc4e-49eb-b903-238f0da5a43e/pullRequests/9926818/attachments/image%20%284%29.png)
The changes made to the `CopyFilesToStagingDir.ps1` script along with the project template changes should help support the .NET8 scenario. The selection of the project template's RIDs is conditional and based on the TFM chosen by the user. If NET8 is chosen, the RIDs become portable, enabling the runtime host to locate the RID-specific assets that were previously unattainable.

Co-authored-by: Shashank Nayak <shasnayak@microsoft.com>
bpulliam pushed a commit to microsoft/WindowsAppSDK that referenced this issue Dec 6, 2023
…ionCopyFilesToStagingDir.ps1

.NET8 introduced a [conditional breaking change](dotnet/docs#35398) that influences how the runtime host looks for RID-specific assets. In NET8, support for non-portable RIDs (runtime identifiers specific to versions and distributions, such as win10-x86) is discontinued. The folder structure of the Microsoft.WindowsAppSDK NuGet is structured with assets marked using these non-portable RIDs:
![image (4).png](https://dev.azure.com/microsoft/55e8140e-57ac-4e5f-8f9c-c7c15b51929d/_apis/git/repositories/2467406e-dc4e-49eb-b903-238f0da5a43e/pullRequests/9926818/attachments/image%20%284%29.png)
The changes made to the `CopyFilesToStagingDir.ps1` script along with the project template changes should help support the .NET8 scenario. The selection of the project template's RIDs is conditional and based on the TFM chosen by the user. If NET8 is chosen, the RIDs become portable, enabling the runtime host to locate the RID-specific assets that were previously unattainable.
Scottj1s pushed a commit to microsoft/WindowsAppSDK that referenced this issue Dec 11, 2023
)

* Merged PR 9926818: .NET 8 Breaking Changes and WindowsAppSDK IntegrationCopyFilesToStagingDir.ps1

.NET8 introduced a [conditional breaking change](dotnet/docs#35398) that influences how the runtime host looks for RID-specific assets. In NET8, support for non-portable RIDs (runtime identifiers specific to versions and distributions, such as win10-x86) is discontinued. The folder structure of the Microsoft.WindowsAppSDK NuGet is structured with assets marked using these non-portable RIDs:
![image (4).png](https://dev.azure.com/microsoft/55e8140e-57ac-4e5f-8f9c-c7c15b51929d/_apis/git/repositories/2467406e-dc4e-49eb-b903-238f0da5a43e/pullRequests/9926818/attachments/image%20%284%29.png)
The changes made to the `CopyFilesToStagingDir.ps1` script along with the project template changes should help support the .NET8 scenario. The selection of the project template's RIDs is conditional and based on the TFM chosen by the user. If NET8 is chosen, the RIDs become portable, enabling the runtime host to locate the RID-specific assets that were previously unattainable.

* Fix: Correct Binary Deployment for .NET8 Breaking Change Support #3998

* initial commit

---------

Co-authored-by: Shashank Nayak <shasnayak@microsoft.com>
Co-authored-by: Shashank <shashanknayak33@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
binary incompatible Existing binaries may encounter a breaking change in behavior. breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 8 Work items for the .NET 8 release doc-idea Indicates issues that are suggestions for new topics [org][type][category] Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.
Projects
No open projects
Status: Done
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants