From: Duncan on
I'm working out options for extending some MS classes provided with
MSBuild so as to add some new tools. I've no specific problem I'm trying
to overcome yet. But it looks like there's useful functionality from
various levels in a class hierarchy that wouldn't always directly
accessible from classes further up because of layers of overrides.

I'm pretty new to C#, so I initially assumed I could use a similar trick
to C++ to indicate which class's method I wanted and just call it. But
the language has different ideas :)

-Duncan
From: Peter Duniho on
Duncan wrote:
> I'm having trouble finding a working example of what I need.
>
> Assuming I'm in the overridden m() for class C, how can I call A.m()
> from there using reflection?

This ought to be enough to get you started:

C c = new C();
MethodInfo mi = typeof(A).GetMethod("m");

mi.Invoke(c, null);
From: Peter Duniho on
Duncan wrote:
> I'm working out options for extending some MS classes provided with
> MSBuild so as to add some new tools. I've no specific problem I'm trying
> to overcome yet. But it looks like there's useful functionality from
> various levels in a class hierarchy that wouldn't always directly
> accessible from classes further up because of layers of overrides.

The overrides in the intermediate classes should provide the same
functionality, but taking advantage of whatever's specific about that
intermediate class.

Alternatively, if you find that intermediate functionality is unwanted,
then you should not be inheriting the class at all.

> I'm pretty new to C#, so I initially assumed I could use a similar trick
> to C++ to indicate which class's method I wanted and just call it. But
> the language has different ideas :)

Yes, that's true. C++ is a lot better about letting the programmer make
bad decisions.

Pete
From: Duncan on
I thought that would work too after a bit of Googling. But it
disappointedly still calls C's method.

-Duncan
From: Peter Duniho on
Duncan wrote:
> I thought that would work too after a bit of Googling. But it
> disappointedly still calls C's method.

I'm not disappointed to find that out. And it is documented (from doc
page for MethodBase.Invoke
http://msdn.microsoft.com/en-us/library/4k9x6bc0.aspx):

Reflection uses dynamic method lookup when invoking virtual
methods. For example, suppose that class B inherits from
class A and both implement a virtual method named M. Now
suppose that you have a MethodInfo object that represents M
on class A. If you use the Invoke method to invoke M on an
object of type B, then reflection will use the implementation
given by class B. Even if the object of type B is cast to A,
the implementation given by class B is used

Nice to know that as dangerous as reflection can be, even in that case
there are limits to what kind of poor decision-making the API will let
someone get away with. :)

Pete