[Mono-bugs] [Bug 77191][Nor] Changed - [PATCH] Mono remoting runtime can not resolve overload method during remote request method call processing.

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by alex.gap at mail.ru.

http://bugzilla.ximian.com/show_bug.cgi?id=77191

--- shadow/77191	2006-01-16 13:18:54.000000000 -0500
+++ shadow/77191.tmp.13987	2006-01-16 16:19:06.000000000 -0500
@@ -244,6 +244,34 @@
 ------- Additional Comments From lluis at ximian.com  2006-01-16 13:18 -------
 I don't think this patch is correct. If the message doesn't provide a
 signature, it means that the method is not overloaded (so
 type.GetMethod (methodName, methodBindings) should be enough), not
 that it has no parameters. Maybe the client is failing to provide the
 signature in an overloading case?
+
+------- Additional Comments From alex.gap at mail.ru  2006-01-16 16:19 -------
+However this patch solves visible problem.
+I am agreed with Lluis about overload signature. But I also missed the
+real application of such mechanism in my first report: it used in
+Dispose()/Dispose(bool) pattern in my server application. I should
+note that Dispose() is public, and Dispose(bool) is protected. And as
+far as I know it's not possible to invoke non public methods through
+remoting *by design*, so type.GetMethod (methodName, methodBindings)
+should not be the source of ambigity but it does! As a consequence I
+can presume that methodBindings has invalid value in this call cause
+it *must* contain System.Reflection.BindingFlags.Public flag only
+without System.Reflection.BindingFlags.NonPublic.
+
+Case described in the first report is different. It can fail due to
+wrong or absent overload signature provided by client.
+I'll try to make test to find out possibility of wrong overload
+signature provided by Mono client to MS .NET server.
+
+And one more question. It doesn't possible to repeat same problems
+with ContextBoundObject. I always thought that they use same
+invokation dispatch mechanism (for example,            
+RemotingServices.ExecuteMessage(...)). But in real tests such
+assumption is not confirmed (for Mono test from my first report works
+succesfuly in case of ContextBoundObject). Am I missed something, or
+does Mono use separate dispatching mechanisms for ContextBoundObject
+and channel based invokations?
+