When to use Inheritance versus Interfaces

I tend to lean towards using interfaces, as opposed to inheritance.  The reason for this is multi-fold:

1.  I can implement multiple interfaces on a single class in C#.  The only way I can implement multiple classes in C# is to have a big inheritance chain, which tends to get confusing, when going back to review code weeks or months later.
2.  With interfaces, there's no ambiguity in who implements what behavior.  There may be methods one overrides in C#, and that can get confusing when implementing a child class (ie Does the behavior this class uses match the parent class, or does it have different behavior?).  With interfaces, I must define the behavior in each implementation.
3.  In my world, and the types of applications I build, I don't see behavior being so expandable as to support a lot of inheritance; obviously, there are times when it makes complete sense to use inheritance, but for the most part, objects aren't that related.

That being said, there are times when I choose to use an interface, and find that it was an inappropriate choice for the solution I was trying to build.  The reason it becomes inappropriate is because, when I first chose to use an interface, I didn't consider some of the granularity of the classes, and I start realizing that I'm re-doing a lot of work that I wouldn't have to do if I had chosen inheritance.

There are canned solutions that make solving these problems easier, such as abstract classes; however, in this example, I'll refrain from considering the abstract class as a possible solution.

Instead, I'll try to iterate some reasons to choose an interface, as opposed to inheritance, and vice-versa:

Reasons to choose an interface
1.  Uncommon behavior, but a common "fingerprint":  If you envision a set of classes having similar public methods, but uncommon private members, constructors, and behaviors, then an interface is probably the right choice
2.  Defining multiple ways to arrive at a solution:  The data access layer is a good example of this.  An interface is a great way to have multiple options for database storage, and having that be a configurable piece of the software
3.  Multiple developers working on common tasks:  Interfaces were designed to solve problems that arise when multiple people are working independently of one another.  Defining an interface (often referred to as a public contract) is a way to keep people on the same page.

Reasons to choose inheritance
1.  Similar-looking classes:  If classes begin to look very similar, especially at the private-member level, refactoring to make those private members protected, and implementing inheritance is probably a good decision
2.  Common Behavior:  Let's face it:  interfaces exist because common behavior does occur between classes.  "Inventing" common behavior, and forcing inheritance onto multiple classes that do not have a real relationship is not a good thing, though.

A lot of the decision to choose inheritance or interfaces comes down to style and preference; however, these are a couple "fun facts" I've gleamed in the process of writing code.

By the way, check out my new project at SourceForge:  TestAutomation.  It helps to automate software testing in Windows environments.  https://sourceforge.net/projects/testautomation/