[Breaking change]: Default Dotnet Tool to Run on Latest Runtime - Build time change RollForward to Major

[JL03-Yue]

Description

#31957

We changed the default RollForward behavior from LatestPatch to Major for dotnet tools.

Version

.NET 8 Preview 5

Previous behavior

Previously, .NET applications use a runtimeConfig to determine their runtime. The default RollForward policy is LatestPatch, which allows an application to run on any runtime of the same major/minor version that is at least as high a version as the application was built against. However, dotnet tools should be able to run on any .NET runtime equal or greater than the application's original runtime, Previously, tool authors must either explicitly set a more flexible roll-forward policy or set multitargeting. The latter has various side effects.

New behavior

We could address the mismatch in build time. The new change changes the RollForward of all tools from LatestPatch to Major. This would cause the desired behavior for all newly-built apps.

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

#30336

Dotnet tools should be able to run on any .NET runtime equal or greater than the application's original runtime. The previous RollForward policy is LatestPatch, which allows an application to run on any runtime of the same major/minor version that is at least as high a version as the application. We changed the default RollForward policy to Major to address this mismatch.

Recommended action

N/A

Feature area

SDK

Affected APIs

No response

---

Associated WorkItem - 97026

[JL03-Yue]

According to #34132, we decided to revert the changes as it might imply a change to our compat bar. Currently discussing alternative solutions. Is it possible to revert this breaking change documentation?

[gewarren]

@JL03-Yue So it will only be present in Preview 5 and Preview 6? If so we should probably keep the documentation until GA and then remove it, but we can add a note saying it was reverted in Preview 7.

[JL03-Yue]

@gewarren It'll be present in preview 7 too and reverted in rc1 according to @marcpopMSFT

[gewarren]

Move this to the October/November sprint when those are available.