[Mono-list] mcs bug and Reflection.Emit shortcoming

[Paolo Molaro]

On 06/13/02 Jeroen Frijters wrote:
> And then disassemble usedll.exe, you'll see that ToString calls
> [mscorlib]System.Object::ToString() instead of
> [testdll]testdll::ToString() (as csc does). This will cause version
> problems, if a new version of the dll overrides ToString, it will not be
> called.
> 
> The problem is that, AFAIK, Reflection.Emit doesn't have the ability to
> create a MethodInfo for an inherited method, but I hope I'm wrong.

Interesting bug. I added support in the runtime to execute code like
that (that reference methods in an inherited class instead of in the
declaring class), but I didn't understand why one would produce such code
and how until your sample test. I even asked about the issue on the
DOTNET list but no one replied. Thanks!

The Reflection API provides support for such cases in this way: if you
call FindMembers() for the ToString() method starting from the testdll
type (the base type for type test), you'll get a MethodInfo that has:

	DeclaringType: System.Object
	ReflectedType: testdll

So the info is there in the first place. My guess is that mcs sets the
DeclaredOnly binding flag and loops until it finds the method, so
ReflectedType is always equal to the DeclaringType. After mcs is fixed
I'll change our Reflection.Emit code to take into account the
ReflectedType when emitting the memberref token.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better