search

xamarin / xamarin-macios

.NET for iOS, Mac Catalyst, macOS, and tvOS provide open-source bindings of the Apple SDKs for use with .NET managed languages such as C#
Other
2.47k stars 514 forks source link

[Mac] Offer a mechanism to have a registrar definition per assembly and its deps #12067

Open Therzok opened 3 years ago

Therzok commented 3 years ago

Steps to Reproduce

  1. Given a extensible application, see the context in https://github.com/xamarin/xamarin-macios/issues/12066

Expected Behavior

You should be able to associate the registrar with an assembly. When an assembly is loaded, it's registrar is also loaded and associated with the objc runtime. That way, the registrar would work even in the presence of custom AssemblyResolve.

I don't know how you would end up in a situation where native code could need a type that's not loaded yet in managed code, but I also am not fully aware of all the moving parts in the interop machinery.

Actual Behavior

If you override AssemblyResolve to load a different dll than the ones in the registrar, you'll end up with runtime crashes.

rolfbjarne commented 3 years ago

If I understand this correctly, fixing #12066 will make sure these crashes stop:

If you override AssemblyResolve to load a different dll than the ones in the registrar, you'll end up with runtime crashes.

but then you'll fall back to the dynamic registrar, which is slow. So this proposal would be to somehow attach the generated registrar code (in a compiled version) to an assembly, and then use that instead of what's built into the .app. Is that correct?

Therzok commented 3 years ago

12066 would fix the crashes, yes.

There are behavioral differences we've seen between the static and dynamic registrars so this enhancement would help us by shifting left on catching them and allowing extensions to plug into the IDE in an optimized fashion.

this proposal would be to somehow attach the generated registrar code (in a compiled version) to an assembly, and then use that instead of what's built into the .app. Is that correct?

Yup, a crude example I'd see is having the registrar live in a MyAssembly.registrar.dylib that the runtime use to override built-in registrar data - provided there would be no ABI incompatibilities.

I opened the issues separately as they have different impact.