.NET 8: [breaking] dotnet build/publish does not produce an exe/apphost for portable apps by default

[richlander]

[breaking] dotnet build/publish does not produce an exe/apphost for portable apps by default

Proposal: Construct portable apps as fully coherently portable, with the same activation pattern in all environments, which means not including a RID-specific executable by default.

That means:

• Portable apps will not have an executable by default.
• Developer can opt for an executable as an option.

Context

The purpose of portable apps is that they can correctly and uniformly execute in multiple environments, differing by both operating system and architecture. As long as a compatible runtime is deployed, the app can run. That's great. By default, an executable apphost (that matches the SDK RID) is provided for portable apps. We should think of this apphost as a developer apphost. It isn't possible to configure the RID of the apphost, which means that it is primarily only provided to aid the developer and not for production (unless production coincidentally matches production). That means that the utility of the apphost is limited.

However, portable apps provide little benefit for developers since developers almost always build from source. As a result, RID-specific apps are just as good, if not better, for development. During development, you are working on a single machine, like a Windows x64 or Linux Arm64 machine. RID-specific apps are tailored for a specific machine type. Portable apps are better targeted as a publish configuration since they enable production flexibility.

Again, portable apps shine by providing by supporting running in multiple environments. It makes sense to start from the idea of executing those apps with the same pattern in all environments. By definition, that means/requires not using an apphost executable (which can only work in one environment). As a result, to simplify portable apps, it makes sense not to offer an apphost by default, but to make it opt-in.

Zooming out a little further, we should recommend portable apps as a publish/production scenario as opposed to a dev scenario, in much the same way we think of self-contained apps.

This proposal is dependent (not technically, but scenario-wise) on the implementation of #23540.

[AraHaan]

As long as WindowsDesktop apps remain unchanged where they will get the exe/apphost when they are portable (because many people using WindowsDesktop depends on it being as such).

However, I would love it if it was possible for one to specify more than a single Application Icon file without needing to create an .res file for it (like ApplicationIcons where they are separated by ;.

[tmds]

@richlander @baronfel this is also beneficial for the container tooling. On a source-built SDK, the source-built apphost may be incompatible with the base image. Not having an apphost and starting the app through dotnet <assembly.dll> mitigates the issue.