Remove the GetCLRRuntimeHost export from coreclr binary

[AaronRobinsonMSFT]

The GetCLRRuntimeHost export on the coreclr binary is a way to get at the COM interface hosting API that is no longer supported in .NET 5+. We should get rid of this API and simplify the internal initialization logic by removing the COM API style. Since it is no longer supported and we have no test coverage assets it is sitting there waiting to get broken.

runtime/src/coreclr/vm/corhost.cpp

Lines 861 to 868 in acb4c46

	extern "C"
	DLLEXPORT
	HRESULT GetCLRRuntimeHost(REFIID riid, IUnknown **ppUnk)
	{
	WRAPPER_NO_CONTRACT;
	return CorHost2::CreateObject(riid, (void**)ppUnk);
	}

The new API is officially documented with guidance and a sample can be found here.

/cc @vitek-karas @elinor-fung

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The GetCLRRuntimeHost export on the coreclr binary is a way to get at the COM interface hosting API that is no longer supported in .NET 5+. We should get rid of this API and simplify the internal initialization logic by removing the COM API style. Since it is no longer supported and we have no test coverage assets it is sitting there waiting to get broken.

runtime/src/coreclr/vm/corhost.cpp

Lines 861 to 868 in acb4c46

	extern "C"
	DLLEXPORT
	HRESULT GetCLRRuntimeHost(REFIID riid, IUnknown **ppUnk)
	{
	WRAPPER_NO_CONTRACT;
	return CorHost2::CreateObject(riid, (void**)ppUnk);
	}

The new API is officially documented with guidance and a sample can be found here.

/cc @vitek-karas @elinor-fung

Author:	AaronRobinsonMSFT
Assignees:	-
Labels:	area-Host
Milestone:	-

[elinor-fung]

If and when this happens, we should make sure it gets announced / tagged as a breaking change.

The startup flags should be achievable through runtime config properties via our recommended hosting APIs. I think the only AppDomain flags used in CreateAppDomainWithManager now are:

• APPDOMAIN_IGNORE_UNHANDLED_EXCEPTIONS
  • Should move towards Allow ignoring unhandled exceptions in UnhandledException event handler #42275
• APPDOMAIN_FORCE_TRIVIAL_WAIT_OPERATIONS
  • ?

We should also have a better story for things like loading in the default ALC to replace ExecuteInDefaultAppDomain scenarios that actually need/expect the default ALC.

[batzen]

If it gets removed, what would be the suggested way to do things like ExecuteInDefaultAppDomain does?
Currently tools like Snoop use the export to get a handle to the runtime host and execute ExecuteInDefaultAppDomain afterwards.
Is there any alternative to call .NET code from C++ without using managed C++?

[AaronRobinsonMSFT]

If it gets removed, what would be the suggested way to do things like ExecuteInDefaultAppDomain does?

@elinor-fung has been working on a solution to this problem. I believe it is a .NET 8 plan, but that will need to exist before we can remove this API.

Is there any alternative to call .NET code from C++ without using managed C++?

There are two approaches. The first is to NativeAOT your library and the second is to use the approach that is taken by DNNE.

[vitek-karas]

There are two approaches. The first is to NativeAOT your library and the second is to use the approach that is taken by DNNE.

I don't think that applies in this case. If I understand it correctly Snoop wants to effectively call into already running managed code - I think it's something like a UI inspector tool which you "attach" to a process. So NativeAOT approach is not applicable because that would not attach to the existing runtime. And DNNE will run into the same limitation as mentioned above because it also relies on nethost/hostfxr.

[batzen]

Excatly. Snoop injects itself into a running WPF application to allow users to inspect/modify the UI etc., similar to the live visual tree in Visual Studio.
Because of that it has to execute it's code in the runtime started by the target process.

[AaronRobinsonMSFT]

There are two approaches. The first is to NativeAOT your library and the second is to use the approach that is taken by DNNE.

I don't think that applies in this case.

I was narrowly answering the question of "Is there any alternative to call .NET code from C++ without using managed C++?". NativeAOT and DNNE are the specific answers to that. For the combination of calling from C++ and attaching to an existing runtime instance, I agree that is more complicated. @elinor-fung's proposal, if I recall, is around getting access to the Default ALC and injecting into that so that would be the API.

I was also under the impression that an already loaded hostfxr will know the current coreclr and can then "attach". If the desired runtime versions match, the DNNE approach would just need to call a different API for injection. I agree the NativeAOT approach is a non-starter for attaching and loading to an existing runtime instance.

[elinor-fung]

getting access to the Default ALC and injecting into that

We currently have a way to get a function pointer to something already loaded into the default ALC, but no way to load an assembly in the default ALC. #77696 is the rough idea for adding a similar API that allows loading an assembly into the default ALC.

I was also under the impression that an already loaded hostfxr will know the current coreclr and can then "attach".

nethost looks for an already loaded hostfxr. Assuming the runtime was originally started using hostfxr (so 'normal' app run or a native host loading the runtime using hostfxr - as opposed to a native host directly loading coreclr itself), it will 'attach'.