Repository navigation
Add analyzer and documentation to migrate customers from MonoPInvokeCallbackAttribute to UnmanagedCallersOnlyAttribute #47177
Description
We are recommending use of UnmanagedCallersOnlyAttribute moving forward, but its usage isn't quite the same. We should have an analyzer to detect use of MonoPInvokeCallbackAttribute and documentation on how to migrate over where appropriate.
cc: @marek-safar
Activity
lambdageek commentedon Jan 19, 2021
There are no plans at this time to drop support for
MonoPInvokeCallbackAttributefrom MonoVM. That is, if you declare your ownMonoPInvokeCallbackAttributeor useObjCRuntime.MonoPInvokeCallbackAttributeit will continue to work. ButUnmanagedCallersOnlyAttributeis preferred.It's not quite the same however since it doesn't use a delegate for the method signature, and it also makes the method uncallable from managed.
/cc @rolfbjarne @AaronRobinsonMSFT
AaronRobinsonMSFT commentedon Jan 19, 2021
Yep. There is a lot to consider if one goes with
UnmanagedCallersOnly- basically all types must be blittable. I don't see this as a being particularly good idea unless the consumers want to go down the path of manually marshalling all non-blittable types - that seems like a complicated message to suggest. It would become:"Consider
UnmanagedCallersOnlysince all arguments of blittable"or
"Converting all arguments to blittable will permit usage of
UnmanagedCallersOnly"or the most scary
"Read up on blittability and convert to blittables types to use
UnmanagedCallersOnly"What sort of guidance is being considered here?
marek-safar commentedon Jan 20, 2021
What are the benefits of using UnmanagedCallersOnlyAttribute instead of MonoPInvokeCallbackAttribute ?
rolfbjarne commentedon Jan 20, 2021
One reason I can think of is that you get a nice compiler error if you use UnmanagedCallersOnlyAttribute wrong.
On the other hand, if the signature of the delegate passed to MonoPInvokeCallbackAttribute doesn't match the signature of the method, the AOT compiler will abort with a very unhelpful error.
I also believe that the error message you get if you add MonoPInvokeCallbackAttribute to an instance method is less than ideal.
CoffeeFlux commentedon Jan 20, 2021
You also have the ability to set the
EntryPoint, which I believe is something @jonpryor had asked for withMonoPInvokeAttribute.lambdageek commentedon Jan 20, 2021
For library authors [UnmanagedCallersOnly] is nice because you can use it on all .NET5 runtimes.
The different marshalling behavior does mean that it might be a big ask to migrate all users over. So maybe this is too ambitious until we have a source generator that can make marshalling wrappers on reverse pinvokes.
marek-safar commentedon Jan 20, 2021
I think this is nice to have for 6 but we should replace the usage of this attribute in SDKs to not encourage further usage of the attribute.
CoffeeFlux commentedon Jan 20, 2021
It looks like rolf opened an issue for iOS, and I opened #47176 for our samples in dotnet/runtime, so I guess that just leaves Android.
dotnet-policy-service commentedon Jul 22, 2025
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.
This process is part of our issue cleanup automation.
dotnet-policy-service commentedon Aug 6, 2025
This issue will now be closed since it had been marked
no-recent-activitybut received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.