Benedikt Reinartz

I'll take the liberty of closing this issue. Feel free to open it again if the issue persists, but I at least won't be able to help out as I...

#538 has been merged and released, closing this.

@lostmsu I lined out how we could do it anyhow, via a runtime/startup feature flag mechanism. No magic required.

I think we can close this because the "compiler" doesn't exist anymore.

That's very unfortunate... @lostmsu I don't really see a way to fix this apart from using `IntPtr` for the delegates again and doing the "conversion" to `New/BorrowedReference` in a wrapper.

Apparently we don't test constructor overloading :/ My guess would be that we only need to detect during binding whether the "method" is actually a constructor and prepend a `null`...

I don't know of a workaround right now, this is a bug that has to be fixed. Overload resolution has gotten a lot better, that's probably why no one(?) seems...

Related issues and PRs: https://github.com/dotnet/runtime/issues/35465 https://github.com/dotnet/runtime/issues/39167 https://github.com/dotnet/runtime/pull/36990

Thank you for the report, I'll look into it. It's probably enough to force finishing up the initialization in `set_runtime` instead of keeping it in limbo until `load` is called.

I am aware of the issue of loading a separate domain and have not been able to fix it, yet. There is an open PR: #42 Help in debugging and...