You can simulate multiple inheritance using interfaces. If multiple inheritance with classes were allowed, it would lead to the Diamond problem.
For reasons multiple inheritance is not supported, I suggest you read Why doesn't C# support multiple inheritance?
Different languages actually have
different expectations for how MI
works. For example, how conflicts are
resolved and whether duplicate bases
are merged or redundant. Before we can
implement MI in the CLR, we have to do
a survey of all the languages, figure
out the common concepts, and decide
how to express them in a
language-neutral manner. We would also
have to decide whether MI belongs in
the CLS and what this would mean for
languages that don't want this concept
(presumably VB.NET, for example). Of
course, that's the business we are in
as a common language runtime, but we
haven't got around to doing it for MI
yet.
The number of places where MI is truly
appropriate is actually quite small.
In many cases, multiple interface
inheritance can get the job done
instead. In other cases, you may be
able to use encapsulation and
delegation. If we were to add a
slightly different construct, like
mixins, would that actually be more
powerful?
Multiple implementation inheritance
injects a lot of complexity into the
implementation. This complexity
impacts casting, layout, dispatch,
field access, serialization, identity
comparisons, verifiability,
reflection, generics, and probably
lots of other places.
