Proposal for allowing "get delegate" functionality on application host context by vitek-karas · Pull Request #36990 · dotnet/runtime (original) (raw)

In my mind hostfxr_initialize_for_runtime_config is targeted at components (so things like plugins). It's usefulness for apps is questionable due to the fact that it doesn't populate TPA (the default ALC) with application code, only frameworks.

On top of that "self-contained component" is not a thing in .NET Core (yet). There's no SDK support for it. We only allow one runtime in process as well, which complicates this as well.

If we were to allow SCD in hostfxr_initialize_for_runtime_config it would have to be either a very limited experience (cumbersome build, only one such component in process, hard to explain, ...) or we would have to deliver lot of new functionality (SDK support, probably at least some basic VS support, open the question of multiple runtimes in process which ignoring some technical difficulties in the runtime would cause lot of problems for diagnostics, ...).

Combined with the fact that the scenario you describe (along with several other users asking for something similar) is somewhere in between app and component (as you correctly pointed out and I didn't realize at the beginning, your scenario is much closure to an app in a way).

I've also seen a few asks on allowing the "get delegate" functionality on pure apps (no component involved), even ones started directly as .NET Core apps (no native host at the beginning).

In theory it's possible to use hostfxr_initialize_for_dotnet_command_line on "components", but I view that as "bending the system" - quite a bit in fact. And still, if I would want SCD, then it has to be an app, there's no other supported way to actually build it.