ComponentActivator will always be removed by trimming

[rseanhall]

This is the application/component hybrid scenario from dotnet/runtime#35465. When building as self-contained with trimming (either CopyUsed or Link), the custom native host is unable to call get_function_pointer for its custom entry point. Adding the following code makes it work, but is not ideal because ComponentActivator is an internal implementation detail that is subject to change in future releases of .NET.

[DynamicDependency("GetFunctionPointer(System.IntPtr,System.IntPtr,System.IntPtr,System.IntPtr,System.IntPtr,System.IntPtr)", "Internal.Runtime.InteropServices.ComponentActivator", "System.Private.CoreLib")]

Also if the application itself is trimmed, I don't know how to mark the delegate and/or the entry point method such that the linker knows not to trim it.

[vitek-karas]

I think this goes back to our discussion about the lack of proper support for this scenario. SDK doesn't know that it's building an application which will be loaded "in a special way". So it builds it as usual and trims everything it won't need.

ComponentActivator is definitely something which would need special handling - we just didn't get to it yet. I think it would probably be best to implement as a feature switch (off by default) - since again SDK won't have any knowledge of this (except for COM scenario, where SDK is aware).

For now the fix could be to use the existing trimmer annotations to pull the necessary bits together:

• Using the descriptor XML - I honestly don't know the syntax for delegate types, but it might be possible
• Using DynamicDependencyAttribute - stick this onto something which is always preserved in the app - like Main and it will force-include whatever it points to

I do agree that ComponentActivator is internal and it might get renamed/changed in future releases, but I can't think of a way around that. The correct solution would be to implement the feature-switch in the runtime for this. Recently we've added a couple (for example startup hooks which is kind of similar dotnet/runtime#44050).

[rseanhall]

Adding a feature-switch sounds like the right thing to do. I think the feature switch should be specific to GetFunctionPointer. As you can see in #14385, this will require adding an MSBuild property to enable in the SDK.

In #12043, I was told this would "create a third bucket" and was not desirable. I hope that it's becoming obvious that there is a need for this third bucket. Naturally, I would like this new MSBuild property to "implement" #12043 such that these projects would use this new property and have OutputType=<nothing>. This new MSBuild property would imply EnableDynamicLoading just like EnableComHosting does.

[vitek-karas]

I agree that on the SDK side this could be implemented by something similar to EnableComHosting - maybe EnableNativeHosting? (I suck at naming). I'm still not sold on the idea of supporting this on applications (the fact that you build it as an app is basically a workaround to the hosting API problems - ideally it would be self-contained component) - but that's just me.

I think the important part is that this is "external knowledge" - SDK has no way to tell from the project itself that it's going to be used like this since it doesn't see the native side of things - so in that sense it can't really be tied to the GetFunctionPointer since SDK won't see that being used anywhere.

[rseanhall]

dotnet/runtime#46880

[rseanhall]

The new property _EnableConsumingManagedCodeFromNativeHosting seems to have been implemented in #17657. Can it imply EnableDynamicLoading just like EnableComHosting does?

[vitek-karas]

It could, but I hope people using this property will know exactly what they're doing. The new property starts with _ on purpose - it's used by the SDK to denote properties which are considered "private" and can change any time without us worrying about breaking people with such a change. Trimming apps which are using native hosting is not supported (since trimming will break the app in almost all cases), and we currently don't have plans to make this into a supported scenario.

Another consideration is that trimming is currently only supported for apps (not libraries) and apps already effectively imply EnableDynamicLoading (that is .runtimeconfig.json is generated for them, which is the main difference).