Is there equivalent to MonoPInvokeCallback in dotnet?

[you74674]

I have been looking for solution to the callbackOnCollectedDelegate problem.
So far MonoPInvokeCallback is the best solution I found, it's much better than having to save the state of each callback delegate,
but it looks like it only exists in iOS(and Unity, inside AOT namespace).
I wonder if there's a similar feature, or a plan to implement it in dotnet?

Edit:
I think I have some misunderstanding about the topic.
Originally what I found is that methods with MonoPInvokeCallback seems to solve the callbackOnCollectedDelegate in Unity,
but after some more test, it looks like the key is static method, so maybe not related to MonoPInvokeCallback.
Any static method as callback doesn't get callbackOnCollectedDelegate problem in Unity,
but it does in dotnet.
So now the question is, how does Unity resolve this problem?
It's kind of unrelated now, but there's no way to delete the discussion, sorry.

[PathogenDavid]

Instead of using delegates marshaled as function pointers you should just use C# 9's function pointers instead. (In which case the equivalent attribute would be UnamangedCallersOnly.)

If you're on an older pre-.NET 5 runtime and need to use delegates, you need to ensure the delegate does not get garbage collected when not in use. If the delegate is long-lived or will be reused many times the easiest way is to save it in a static field somewhere. If it's short lived (such as a callback that will only be used for the duration of a native function call) use GC.KeepAlive to ensure it survives until after the function call is completed. (IE: MyCallback cb = MyFunction; SomeNativeFunction(cb); GC.KeepAlive(cb);)

So now the question is, how does Unity resolve this problem?

My basic understanding of the old delegate-marshaled-as-function-pointer method is that the runtime would dynamically create a stub which handles marshaling from the native calling convention to the managed calling convention. When these delegates get garbage collected these stubs get destroyed.

When you're on an AOT-compiled platform that dynamic stub creation isn't possible, it has to be done ahead of time. MonoPInvokeCallback tells Mono's AOT compiler to generate this stub statically. Since this stub was generated statically it doesn't get garbage collected. Since it isn't garbage collected it doesn't matter if the associated delegate is garbage collected.

[you74674]

Thank you for the detailed answer.

MonoPInvokeCallback tells Mono's AOT compiler to generate this stub statically

I have tested using non-static/static function as callback from Unity and from dotnet,
and I'm confused because static function without MonoPInvokeCallback seems to work and doesn't cause collected callback problem in Unity.
As an experiment, I tried to garbage collect the delegate object created from static function in Unity, but so far I cannot achieve it. (it's easy in dotnet)
Does that mean the stub is generated statically anyway even if MonoPInvokeCallback is not used? If so then what's the meaning of MonoPInvokeCallback?
If it doesn't generate the stub statically, why doesn't it fail?

In which case the equivalent attribute would be UnamangedCallersOnly

What I planned is to make an alias to UnamangedCallersOnly as MonoPInvokeCallback in dotnet, but the syntax is quite different.
Essentially I'm trying to port some Unity code to dotnet without modifying it, but I guess I'm asking too much.

edit:
I found this document that might explain why the Unity test works.
http://docs.go-mono.com/?link=T%3aMonoTouch.MonoPInvokeCallbackAttribute
If Unity script belongs to "regular ECMA CIL programs", then it means MonoPInvokeCallback is the default behavior?
Now I just wonder if there's way to implement "compiler feature" by user in dotnet...