Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
I'm creating a set of C# bindings for an iOS library we develop and I ran into a issue with a DelegateProxy we had implemented in Obj-C. The problem was that under certain conditions methodSignatureForSelector: returns different values for native and managed objects;
With a native object, methodSignatureForSelector will return a non-nil value if the object responds to the selector, or the method is declared on a protocol the object adopts. It will return nil if the selector is not declared on any of the protocols the object adopts.
With a managed object that inherits an abstract base class with virtual methods bound to each method defined on the protocol, methodSignatureForSelector will return a non-nil value if the object overrides the related method, but will return nil otherwise.
The problem we are seeing here is that the managed object is returning nil for a method that exists in it's base class, but is not overridden on that object. We would expect it to return a non-nil value, just like when a native object chooses not to implement an optional method from a protocol.
We've had to put extra guards onto our DelegateProxy in the native library to work around this issue.
Some time ago we implemented much better support for protocols, which means that methodSignatureForSelector: should now return a non-nil value for selectors that are implemented in protocols the managed object implements.
methodSignatureForSelector: will still return nil for selectors that are only in non-overridden virtual methods (and not in any protocols the managed object implements). This is by design; the virtual method is there to ease implementing an override (i.e. you just type 'override ' in the IDE and get the list of potential candidates; you'll also get the correct method signature), it is not considered an actual implementation.