Native hosting proposal

[vitek-karas]

Design describing current level of support for hosting managed code from native applications and proposal for improvements in this area.

[pakrym]

cc @jkotalik

[swaroop-sridhar]

Can AppHost be implemented as one customization of nethost (for code/scenario reuse)? For now, there's only framework-dependent apps with nethost, bit this is not a fundamental technical limitation, right?

[vitek-karas]

Re framework dependent: Self-contained nethost while possible introduces interesting problems - for one it would only allow loading one component. Trying to load a second component into that process would become really tricky, since we could not rely on framework resolution to validate/match framework dependencies. Instead this resolution would have to happen on assembly level which is obviously much more complicated. So while possible, I would like to see a real world scenario for this first.

Re apphost == nethost: All the hosts are essentially the same: apphost, comhost, ijwhost and now nethost all do basically the same thing - locate the hostfxr and call into it. They differ in two things:

• What do they call in hostfxr
• How do they expose the functionality

In that regard if we were to unify anything, then comhost and nethost are actually very similar. Also ijwhost is similar to them to a degree. They all allow loading "components" - isolated islands of managed code (they will use fully isolated ALC to load the code into). They generate TPA which only contain frameworks - and they only support framework dependent apps.

apphost is the outlier here.

• It's an exe unlike all the others which are dlls. I know that on Windows it's possible for an exe to be loaded as a dll and ask for exports, so in that sense it's possible to have both. I don't know about Linux/macOS - if it's even possible to have such a binary.
• It runs the app - which effectively means it "owns" the process. For example returning from Main will terminate the process. Unlike all the other hosts which don't have that power.
• It loads the managed code into the default ALC, meaning it produces TPA which contains everything, frameworks and app.

Then on Windows there's the added complexity of allowing customization of apphost (native resources, name and so on).

From a testing point of view it's kind of unfortunate since we need to test that many binaries, but from a shipping point of view it kind of doesn't matter. Each needs its own support in SDK, so there's no real gain from sharing the binary. Not counting that nethost is special in this sense as it won't be integrated into SDK - it will be its own NuGet package (or something like that).

[pakrym]

Not counting that nethost is special in this sense as it won't be integrated into SDK - it will be its own NuGet package (or something like that).

We need nethost in every app that we are trying to run using AspNetCoreModule, having export on apphost would be much more preferable as it would allow us to avoid having two copies of the same functionality in every customers app.

[vitek-karas]

I actually don't think you need nethost in every app - you need nethost in your code - to find hostfxr… has very little to do with the app. nethost has to be 100% backward compatible anyway, so it should work on old apps as well.

If we add an export to apphost it would only work for new apps, it won't fix your problem with existing apps.

And more importantly nethost to find hostfxr doesn't need to know much about the app, what it must know are the various rules how to find the install location of .NET Core on the machine.

[pakrym]

If we add an export to apphost it would only work for new apps, it won't fix your problem with existing apps.

We would have to keep the existing code for backcompat anyway, we do a lot more than the apphost does (traverse the PATH)

I actually don't think you need nethost in every app - you need nethost in your code - to find hostfxr… has very little to do with the app. nethost has to be 100% backward compatible anyway, so it should work on old apps as well.

Not sure how I feel about redistributing nethost with AspNetCoreModule and if it brings any benefit.

[vitek-karas]

Not sure how I feel about redistributing nethost with AspNetCoreModule and if it brings any benefit.
I think I'm confused. I though the general desire was to not have the "how to find hostfxr" logic in the ASP.NET code, but instead for that to come from some other component. I agree that in case of apps with apphost it can come from there, but apps which don't have apphost will still have that problem.

This API is also for cases where there's no app at all to begin with (for example the MSBuild/VS case of finding all available SDKs).

[jkotalik]

When loading the apphost.exe or dotnet.exe it may be nice to add versioning for API capabilities. Today, we would check versioning by calling GetProcAddress on these functions to check for existence. In the future, if we decide to add another set of APIs, the logic would get even more complex.

[vitek-karas]

@jkotalik What do you mean by version API?
I especially don't understand adding versino API to dotnet or apphost.
I could see us adding a hostfxr_get_version to hostfxr so that the native host can have code which lights up if there is newer version of hostfxr available on the machine it's running on. But that really is only for hosts which work directly with hostfxr.

Hosts which will use nethost or comhost carry the nethost/comhost with them and thus can fully rely on it being the version they built with. Light up in this case would be either built into the APIs exposed by nethost or handled by the nethost transparently.

[jkotalik]

@jkotalik What do you mean by version API?
I especially don't understand adding versino API to dotnet or apphost.

I mis-read above. I now see that the apis will be exposed on nethost/comhost, not the exes.

[vitek-karas]

I've split the "Loading components" part of this proposal into a separate document see #5486. It seems that the "loading components" part of the discussion has more or less reached approval, so having it separate will make it possible to merge and start the implementation work.

That feature is independent of the other proposal around runtime properties and location of hostfxr which will still be discussed as part of this PR.

[vitek-karas]

Please give this another read. Based on the feedback we've now designed an API which allows for runtime property resolution/modification as well as possibly caching (to avoid double resolve in the ASP.NET scenario). The new proposal adds quite a few new APIs to hostfxr and improves it's functionality and extensibility. It's also quite different from the previous proposal.

Note: For now I'm leaving out an easy-to-use API on nethost for loading managed components. The discussion around such APIs is part of #5486 and so far hasn't been resolved. The new proposal will make it possible to load managed components using the "hard way" via hostfxr which will provide lot of flexibility for the native host.

[jeffschwMSFT]

Thanks for writing this up @vitek-karas, I really like the initialize then activate structure. I am also happy to see that we are proposing a way to modify the default startup flags by the host. I have asked some questions and provided some feedback.

[vitek-karas]

Added detailed description of multi-threading and versioning behavior.
@sdmaclea, @elinor-fung, @AaronRobinsonMSFT could you please take a look if it matches what we've discussed offline?

[jeffschwMSFT]

Thanks for iterating on this design. I am a little fuzzy on the usage of the delegate, I like the design but think we need a sample to help show people on how to use it. (which can be a separate document)