How to invoke (non virtually) the original implementation of a virtual method?

Question

I have the following situation:

In a 3rd party library (can not be modified):

class A { public virtual void M() {} }

class B : A { public override void M() {} }

In my own code:

class C : B { public override void M() {} }

From C's implementation of method M I want to call A's (but not B's!!). Can I?

Any tricks accepted, reflection included. I tried reflection already, but using the MethodInfo that I get from typeof(A) still generates a virtual call (calling C's implementation with subsequent stack overflow).

Deriving C from A is out of the question due to the complexity of reimplementing B.

Answer 1

you can generate dynamic method to make proxy that use Call (not CallVirt) instruction

        var x = new C();
        var m = typeof (A).GetMethod("M");
        var dm = new DynamicMethod("proxy",  typeof (void), new [] {typeof(C)}, typeof (C));
        var il = dm.GetILGenerator();
        il.Emit(OpCodes.Ldarg_0);
        il.Emit(OpCodes.Call, m);
        il.Emit(OpCodes.Ret);
        var action = (Action<C>)dm.CreateDelegate(typeof (Action<C>));
        action(x);

Answer 2

In my previous answer I missed the fact that A and B are in an external library and cannot be modified. In that case, I would suggest a different approach. Basically, if the design flaw is in B, you can’t use B. Subclass from A instead.

The unfortunate consequence of this, of course, is that you may need to reimplement some or all of the functionality in B. You may be able to copy the code from Reflector if necessary. I realise that this sounds undesirable, but I still think it is preferable to using unmodifiable code that has a known issue that causes you problems.

Answer 3

Quite old question but I had a similar problem recently. desco's answer gave the crucial hint. But the generated proxy delegate should be encapsulated in class C, can be static and initialized via static constructor so time consuming reflection will be required only once.

// -- in foreign assembly
class A { public virtual void M() { Console.WriteLine("A.M"); }}
class B : A {public override void M() { Console.WriteLine("B.M"); }}
//
// -- in own assembly
class C : B
{
    private static Action<C> call_A_M;

    public override void M() {
        call_A_M(this);
        Console.WriteLine("C.M");
    }

    static C()
    {
        var m = typeof(A).GetMethod("M");
        var dm = new DynamicMethod("", typeof(void), new[] { typeof(C) }, typeof(C));
        var il = dm.GetILGenerator();
        il.Emit(OpCodes.Ldarg_0);
        il.Emit(OpCodes.Call, m);
        il.Emit(OpCodes.Ret);
        call_A_M = (Action<C>)dm.CreateDelegate(typeof(Action<C>));
    }
}

But as Dan Bryant already mentioned: never ever use such dirty tricks in production code.

Answer 4

I’m afraid this is not possible directly the way you describe — the purpose of virtual methods is for the overriding to be transparent. So the only way to do this at all is via a workaround.

Let me try to whip one up, but please be aware that this is a hacky suggestion. If you really need this construct in your code, it may be an indication that your code has a fundamental design flaw somewhere else, so restructuring something might be more desirable than filling it with yet another design flaw. But anyway, here goes...

class A {
    public virtual void M() { m_protected(); }
    protected void m_protected() { /* code goes here */ }
}

class B {
    public override void M() { /* code here, possibly invoking base.M() */ }
}

class C {
    public override void M() { m_protected(); }
}

Answer 5

You cannot do that. You should probably design your class hierarchy differently, because it looks strange that C inherits from B, while behaving like A.

Anyway, it could make sense in your case. Then you should make another method in A which you will not override:

class A {
    protected virtual void basicM() {}
    public virtual void M() { basicM(); }
}
class C {
    public override void M() { basicM(); }
}

BTW, if you name the method as I did in the example, then you should probably rethink the whole thing. If this hierarchy is justified, than basicM probably performs something that deserves to be a separate method with a different name, perhaps even a public method.