Cocoa-to-.NET bridge?

David also asked, “if a developer of a Cocoa application wanted to use a CoreCLR engine, but a Cocoa UI, would they just ‘load the CoreCLR.framework’ or is there more to it than that.”

There is no technical limitation of CoreCLR that would not allow calls from it into Cocoa (ObjC[++]) or vice versa, in the same way that Cocoa can call into C/C++ normally. The CoreCLR, like the desktop runtime, supports a hosting interface that allows .NET to be hosted in an application environment. Unlike the desktop runtime, CoreCLR is currently only ever hosted (e.g., in the browser control called Silverlight). You can ask the hosting interface to create a function delegate, which will take a managed function and turn it into a C-style function pointer, which, were you to call it, would marshal all the arguments into the managed world and run managed code. Beyond that, you could theorize creating something like the ObjC-Perl bridge, where managed objects were made visible directly to the ObjC runtime¹.

That said, there are a couple of things that would stymie the average developer if they wanted to do this:

• At the moment, only internal (i.e., Microsoft) clients of CoreCLR have access to the hosting interface.


• The security model of CoreCLR, at least in the Silverlight timeframe, is changing so that only Microsoft trusted libraries have access to sensitive OS operations, and normal developers’ code would be sandboxed (much like it would be if it were running in Silverlight).

I don’t have too much insight as to whether these things might change in the future. However, there are a bunch of details that would have to be resolved first, e.g., how to ensure 3^rd party CoreCLR users keep their CoreCLR serviced with the appropriate security fixes. If you’re interested, let your request be known in the feedback forums up on http://silverlight.net.
--
¹Although, at this point, you’d end up with double garbage collection. If an ObjC object held a reference to a managed object, and then lost its last reference, then eventually the pool would get collected, which would then release the (possibly) last reference to the managed object, which would then get collected when the CLR GC occurs.