Comparer<T> IComparer<T> IComparable<T>

Comparer<T>.Default Property

Comparer<T>.Default doesn't use your FooComparer class. It simply returns an instance of the internal class GenericComparer<T>.
This class has the constraint that T must implement IComparable<T> so it can simply delegate the calls to it Compare method to the Compare methods of the instances it gets passed.

Something like this:

internal class GenericComparer<T> : Comparer<T> where T : IComparable<T>
{
    public override int Compare(T x, T y)
    {
        if (x != null)
        {
            if (y != null)
                return x.CompareTo(y);
            return 1;
        }
        else
        {
            if (y != null)
                return -1;
            return 0;
        }
    }

    // ...
}

IComparable<T> Vs. IComparer<T>

As the name suggests, IComparable<T> reads out I'm comparable. IComparable<T> when defined for T lets you compare the current instance with another instance of same type. IComparer<T>reads out I'm a comparer, I compare. IComparer<T> is used to compare any two instances of T, typically outside the scope of the instances of T.

As to what they are for can be confusing at first. From the definition it should be clear that hence IComparable<T> (defined in the class T itself) should be the de facto standard to provide the logic for sorting. The default Sort on List<T> etc relies on this. Implementing IComparer<T> on Tdoesn't help regular sorting. Subsequently, there is little value for implementing IComparable<T> on any other class other than T. This:

class MyClass : IComparable<T>

rarely makes sense. On the other hand

class T : IComparable<T>
{
    public int CompareTo(T other)
    {
        //....
    }
}

is how it should be done.

IComparer<T> can be useful when you require sorting based on a custom order, but not as a general rule. For instance, in a class of Person at some point you might require to Sort people based on their age. In that case you can do:

class Person
{
    public int Age;
}

class AgeComparer : IComparer<Person>
{
    public int Compare(Person x, Person y)
    {
        return x.Age - y.Age;
    }
}

Now the AgeComparer helps in sorting a list based on Age.

var people = new Person[] { new Person { age = 23 }, new Person(){ age = 22 } };
people.Sort(p, new AgeComparer()); //person with age 22 comes first now.

Similarly IComparer<T> on T doesn't make sense.

class Person : IComparer<Person>

True this works, but doesn't look good to eyes and defeats logic.

Usually what you need is IComparable<T>. Also ideally you can have only one IComparable<T> while multiple IComparer<T> is possible based on different criteria.

The IComparer<T> and IComparable<T> are exactly analogous to IEqualityComparer<T> and IEquatable<T> which are used for testing equality rather than comparing/sorting; a good threadhere where I wrote the exact same answer :)

When to use IComparable<T> or IComparer<T>

Well they are not quite the same thing as IComparer<T> is implemented on a type that is capable of comparing two different objects while IComparable<T> is implemented on types that are able to compare themselves with other instances of the same type.

I tend to use IComparable<T> for times when I need to know how another instance relates to thisinstance. IComparer<T> is useful for sorting collections as the IComparer<T> stands outside of the comparison.

Quote From:

Comparer<T>.Default Property

difference between IComparable and IComparer

When to use IComparable<T> Vs. IComparer<T>

C#/.NET Little Wonders: Comparer<T>.Default