Xamarin-macios: Dependencies on Mono class libraries not present in dotnet/runtime

[filipnavara]

When running on .NET 5 runtime with the new class libraries the following dependencies are currently not available:

• Mono.SystemDependencyProvider.Initialize
• System.Threading._ThreadPoolWaitCallback.SetDispatcher

Additionally, the version returned by Mono.Runtime.GetDisplayName() may no longer be relevant.

Related to #7528.

[chamons]

Mostly FYI @rolfbjarne of possible implementation details noted by our community

[lambdageek]

Some of the previous SetDispatcher discussion is here: https://github.com/mono/mono/pull/17387#issuecomment-545540303

I don't think there's an issue open in dotnet/runtime about bringing (some form of) SetDispatcher back.

[filipnavara]

I don't think there's an issue open in dotnet/runtime about bringing (some form of) SetDispatcher back.

No issue for that yet. I'll bring it up.

[marek-safar]

The work to clean up the binding to build against pure netcore API has not been done so the bindings still depend on some APIs not available on netcore

[lambdageek]

SystemDependencyProvider looks like some indirection that @baulig added to help corlib and System reference each other to get at the system cert store (I think).

So I think there are two possibilities (maybe Martin can correct me if I'm wrong):

1. This isn't needed in .NET 5 because there's some other mechanism to integrate the system cert store into the runtime
2. There's no such support in .NET 5 at all and work would need to be done on the .NET 5 libraries side.

[filipnavara]

The ThreadPool issue is filed.

SystemDependencyProvider is no longer necessary with the new BCL. The certificate APIs work just fine.

One thing I forgot about is that the HttpClient handlers may behave differently. I only checked it on macOS where the managed code was used by default and worked properly. It may be an issue on iOS though.

[filipnavara]

The work to clean up the binding to build against pure netcore API has not been done so the bindings still depend on some APIs not available on netcore

I am aware of that. I've been building Xamarin myself with the problematic code patched out. I thought it may be useful to open an issue to give a perspective on the scope of the work necessary.

[baulig]

SystemDependencyProvider looks like some indirection that @baulig added to help corlib and System reference each other to get at the system cert store (I think).

The sole purpose of this class is to inject APIs that reside in System.dll into corlib.dll, to allow code in corlib to access some of the crypto and certificate code that resides in System.dll.

I believe that we can simply short-circuit this for .NET 5 - remove that entire class (and it's implementations) completely and use the relevant APIs correctly.

[filipnavara]

This has been largely addressed by #8070. Remaining pieces are marked as NET_TODO in the source code and/or tracked in individual issues.