You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The .NET SDK has produced portable apps since .NET Core 1.0. That may or may not have made sense, but it no longer does now. Portable apps are bigger, slower to startup, and less reliable in some scenarios. In addition, portable apps are not fully coherent since they have a RID-specific executable but portable assets. That means that you can use the executable for one RID environment and cannot for any other. It's an odd design choice. A perfect example is containers. RID-specific apps are always better for containers. Another example is client apps. Client apps require an executable, such that they should always be RID-specific.
Motivation for break:
Portable apps are good for a small subset of scenarios.
RID-specific apps are the only good option for a variety of popular scenarios.
dotnet build/publish does not produce an exe/apphost for portable apps by default
Portable apps are intended to run in multiple environments. By definition, an executable is RID-specific and therefore only compatible with one of the environments in which a portable app can run. It's possible that developers are happy with this asymmetry, but should opt into that experience.
Motivation for break:
The apphost makes portable apps incoherent.
It is easier to explain how to use portable apps in absence of an executable apphost.
The text was updated successfully, but these errors were encountered:
The following list defines breaking changes that are proposed for .NET 8.
Proposed:
Carryovers from .NET 7:
dotnet build/publish produces RID-specific apps by default
Proposal: dotnet/sdk#23540
The .NET SDK has produced portable apps since .NET Core 1.0. That may or may not have made sense, but it no longer does now. Portable apps are bigger, slower to startup, and less reliable in some scenarios. In addition, portable apps are not fully coherent since they have a RID-specific executable but portable assets. That means that you can use the executable for one RID environment and cannot for any other. It's an odd design choice. A perfect example is containers. RID-specific apps are always better for containers. Another example is client apps. Client apps require an executable, such that they should always be RID-specific.
Motivation for break:
dotnet build/publish does not produce an exe/apphost for portable apps by default
Proposal: dotnet/sdk#23545
Portable apps are intended to run in multiple environments. By definition, an executable is RID-specific and therefore only compatible with one of the environments in which a portable app can run. It's possible that developers are happy with this asymmetry, but should opt into that experience.
Motivation for break:
The text was updated successfully, but these errors were encountered: