I\'m trying to figure out which of these interfaces I need to implement. They both essentially do the same thing. When would I use one over the other?
It all depends on whether your type is mutable or not. You should only implement IComparable on non-mutable types. Note that if you implement IComparable, you must override Equals, along with the ==, !=, < and > operators (see Code Analysis warning CA1036).
Quoting Dave G from this blog post:
But the correct answer is to implement IComparer instead of IComparable if your objects are mutable, and pass an instance of the IComparer to sorting functions when necessary.
Since the IComparer is just a disposable object used for sorting at that point in time, your object can have any mutable semantics you desire. Furthermore, it doesn't require or even suggest using Equals, GetHashCode, or == - you're free to define it in any way you please.
Finally, you can define multiple IComparer's for your type for sorting on different fields or with different rules. This is much more flexible than being stuck with one definition.
In short: Use IComparable for value types and IComparer for reference types.