-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
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
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
added
⌚ Not Triaged
Not triaged
binary incompatible
Existing binaries may encounter a breaking change in behavior.
labels
May 18, 2023
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
gewarren
added
🏁 Release: .NET 8
Work items for the .NET 8 release
and removed
⌚ Not Triaged
Not triaged
labels
May 18, 2023
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
added
the
in-pr
This issue will be closed (fixed) by an active pull request.
label
Jun 8, 2023
github-project-automation
bot
moved this from 👀 In review
to ✅ Done
in dotnet/docs June 2023 sprint
Jun 8, 2023
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.
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:
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
Windows
macOS
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
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
totrue
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
The text was updated successfully, but these errors were encountered: