Support for Mono's DllImport(@"__Internal") ?

[tido64]

Can we add support for loading symbols within the hosting application as documented here?

As a Mono extension, if the library being loaded is __Internal, then the main program is searched for method symbols. This is equivalent to calling dlopen(3) with a filename of NULL. This allows you to P/Invoke methods that are within an application that is embedding Mono.

This will make it easier for existing applications to expose method symbols to managed code without having to 1) separating desired methods to a separate dynamic library or 2) passing tables of function pointers to managed code on initialization.

[jkotas]

cc @yizhang82

[gkhanna79]

@yizhang82 Please fix the milestone as applicable.

[jkoritzinsky]

@jkotas @AaronRobinsonMSFT I'm looking into working on this next. It fits in well with our goal of improving our hosting story for .NET Core 3.0 as well as improving compatibility with Mono. What do you think?

[jkotas]

The managed NativeLibrary APIs that we are adding for 3.0 allow people to resolve __Internal to whatever module they wish. It means we have a basic story for this in 3.0 already. You have to write a bit of code for it, but I think that's acceptable - you are not blocked.

A great hosting story is not a theme for 3.0. I would wait for doing anything more here until a great end-to-end hosting story is a theme.

[AaronRobinsonMSFT]

@jkotas I would argue the managed COM hosting theme I am working on is probably just that scenario. Being able to load a managed COM server and then have that COM server communicate with the native host seems very natural to me and something I have done. I think this is actually a valuable task for the following reasons:

1. There is some demand (i.e. this issue).
2. A scenario does exist, perhaps simple/contrived, but it does exist and the fact there is an issue demonstrates a non-COM scenario is in the mind of the community.
3. Has no blocking issues which means it could be accomplished at this time and can be written in an abstract way meaning the implementation can change, but the community can be unblocked immediately.
4. Prior art/aligning with Mono scenarios.
5. It can easily be tested/validated.

I don't see a real strong reason not to start on this, unless there is something more pressing at the moment.

[jkotas]

I do not think __Internal is relevant for COM hosting. __Internal would be relevant for custom hosting/embedding in native apps. We are not investing much in this area for .NET Core 3.0. Internal user story https://devdiv.visualstudio.com/DevDiv/_queries/edit/650238/. It does not mean that this is unimportant, nor that we are doing absolute zero. It just means that it did not fit.

In any case, this would need more detailed design proposal first.

[jkoritzinsky]

Do we have any docs or guidance written down anywhere on writing up design proposals? I know we have some docs for the corefx API review process. Is it a similar process or something different?

I just want to make sure that when I eventually write up a design doc for something that I am doing it correctly.

[jkotas]

There is no prescribed format. Smaller proposals just get written as a few paragraphs in the tracking issue. Larger proposals get written as standalone docs, e.g. look under https://github.com/dotnet/coreclr/tree/master/Documentation/design-docs

I think this one would be likely on the smaller proposal side.

[AaronRobinsonMSFT]

I do not think __Internal is relevant for COM hosting. __Internal would be relevant for custom hosting/embedding in native apps.

@jkotas Sure it is. I have a native application that is using a managed COM server. My managed COM server relies on some native function in my native application. The managed COM server is merely a subset of the native hosting scenario. Am I missing something?