[WIP] Embed .NET (Core) in your D app

[evilrat]

On Tuesday, 11 February 2020 at 08:47:48 UTC, Jonathan Marler 
wrote:
>
> The code generation side adds complexity.  However, all the 
> generated code ends up calling into a small simple library 
> called ClrBridge.dll.
>
> https://github.com/marler8997/clrbridge/blob/master/dotnetlib/ClrBridge.cs

Yes, but it is moved from user to library maintainer. That way 
users are happy, they just don't care about these details. And it 
only adds single DLL with few dependencies to redistribute. In 
total 12 files less than 1 MB in size, including 4 files for 
Mono.Cecil which is a leftover from my compiler experiments that 
I forgot to exclude.

>
> It defines a handful static functions to load assemblies, get 
> types, methods, call methods, marshal values, box values and 
> create arrays.  The bare minimum you need to have access to the 
> entire Clr if you're only able to call static methods through 
> the coreclr library.
>

Most of this is accessible without extra helpers.
That's why I did delegate handling first. It creates static 
delegate at runtime that can be called as normal function 
pointer, and rewrites incompatible types to pass handles instead, 
then before calling former method it obtains actual objects using 
that handles.

System.Activator - is 'new' operator.
System.Array - all things for arrays.
System.Type - basically all reflection
System.Delegate - call methods, etc..

 From that list I only need static helpers for Type.GetType(), 
Type.GetMethod(), Delegate.CreateDelegate() and 
Marshal.GetFunctionPointerForDelegate(), this provides access to 
specific types and methods and after creating delegate and then 
obtaining callable function pointer with these helpers the rest 
should be accessible.


> You can have access to the full CLR with this library without 
> any code generation as well.  Here's an example that doesn't 
> use any code generation:
>
> https://github.com/marler8997/clrbridge/blob/master/dlang/noCodegenExample.d
>

ok, will take a second look.


>
> Interesting.  I haven't found a case yet where I've needed to 
> generate IL code to marshal types.  I don't anticipate needing 
> to either as I already have a design that should work for 
> marshaling any type.  What types are you needing to generate IL 
> to marshal for?

There is not much going on.
My conclusion is that they just not yet implemented full handling 
for delegates so far.
So all I did was just take reference types in method 
params/return instead to be rewritten as IntPtr and handled using 
GCHandle, simply it just calls 
GCHandle.Alloc(ret)/GCHandle.FromIntPtr(param).Target on return 
value and parameters.
(hamburger analogy where meat is the real method and bread is 
that extra handling)

Though this can change later as it is still at the very early 
stage right now. This does not account for structs with reference 
types, etc...
Also CLR does marshal arrays just fine, while my current solution 
currently takes the route of using object handle for that(which 
might be slower or even incorrect in some cases?).