Question

Was looking at some code in our codebase and I’m unable to understand how/why this is even working (and not causing a stackoverflow due to infinite recursion). I have pasted some equivalent code below:
We have a virtual method Foo(B) defined in class P1 and overridden in class P2. P2 also defines a private non-virtual method Foo(A). B derives from A. P2::Foo(B) has a call in the end: Foo(b). I expect this to end up in a stack overflow.
However, the output is:
P2::Foo Virtual
P2::Foo Private Non-Virtual

Looks like the second call to Foo in the overridden method is picking up the non-virtual method Foo in this case. On doing similar operations in P1 (uncomment code), we end up calling Foo infinite number of times through recursion.

Questions: (finally!)
1. Why is the behavior different in the original virtual method and the overridden method? Why is one calling itself and the other calling a different method?
2. Is there an order of preference specified somewhere? Note that if we change the private modifier to public, in both cases, we end up calling the non-virtual method (Even if we instantiate P2 this way: P1 p2 = new P2(); , instead of P2 p2 = new P2();) It looks like the non-virtual version is preferred, except when it is inside a virtual method definition. Is this true?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
public class P1
{
    static void Main(string[] args)
    {
        B b = new B();
        P2 p2 = new P2();
        p2.Foo(b);
        // Uncomment code to cause infinite recursion
        //P1 p1 = new P1();
        //p1.Foo(b);
    }

    private void Foo(A a)
    {
        Console.WriteLine("P1::Foo Private Non-Virtual");
    }

    public virtual void Foo(B b)
    {
        Console.WriteLine("Inside P1::Foo");
        // Uncomment code to cause infinite recursion
        // Foo(b);
    }
}

public class P2 : P1
{
    private void Foo(A a)
    {
        Console.WriteLine("P2::Foo Private Non-Virtual");
    }

    public override void Foo(B b)
    {
        Console.WriteLine("P2::Foo Virtual");
        Foo(b);
    }
}

public class A
{
    public int a = 10;
}

public class B : A
{
    public int b = 20;
}

}

Answer 1

This is because overload resolution only looks at inherited members if it cannot select an overload defined on the derived type. From the spec (version 4):

For example, the set of candidates for a method invocation does not include methods marked override (§7.4), and methods in a base class are not candidates if any method in a derived class is applicable (§7.6.5.1).

To address your questions specifically:

Why is the behavior different in the original virtual method and the overridden method?

Because the overridden method is defined in a derived class, and an applicable overload exists in that class, the virtual method is not considered. The overriding method is not considered, because overrides are never considered.

Why is one calling itself and the other calling a different method?

The behavior in the derived class is explained above. In the base class, the best candidate for overload resolution is the virtual method itself, because it is more specific (B is derived from A).

Is there an order of preference specified somewhere?

Yes, in the C# Language Specification (link to the MSDN page for the Visual Studio 2012 version of the specification).

Note that if we change the private modifier to public, in both cases, we end up calling the non-virtual method (Even if we instantiate P2 this way: P1 p2 = new P2(); , instead of P2 p2 = new P2();)

Accessibility is not a significant issue in this case. The type of the variable p2 is not relevant either, because the overload resolution you’re asking about concerns a call site in the P2 override of the virtual method. Virtual dispatch ensures that the call in Main() invokes the override, regardless of the static type of the variable. At the call site in P2‘s override void Foo(B b), the receiver is implicitly this, which always has a static type of P2.

It looks like the non-virtual version is preferred, except when it is inside a virtual method definition. Is this true?

Not quite; as explained above, the preference is not for non-virtual methods, but for methods defined in the type of the receiver (i.e., the static type of the object reference on which the method is being called).