Consider this:

PLAIN TEXT
C#:
  1. public interface IDeap {
  2.     long Id { get; }
  3. }
  4. public interface IHierarchy : IDeap {
  5.     string Name { get; }
  6. }

Now please take a pen and paper and write down whatever you think is the integer stored in "answer".
Here:

PLAIN TEXT
C#:
  1. PropertyInfo[] properties = typeof(IHierarchy).GetProperties(
  2.     BindingFlags.Instance | BindingFlags.Public
  3.   );
  4. int answer = properties.Length;

And here:

PLAIN TEXT
C#:
  1. PropertyInfo[] properties = typeof(IHierarchy).GetProperties(
  2.     BindingFlags.Instance | BindingFlags.Public | BindingFlags.FlattenHierarchy
  3.   );
  4. int answer = properties.Length;

If you wrote down "1" and "2" you would think like I do. Unfortunatelly it is "1" and "1". This is something that really messed up my last half hour. And I can't understand it completely. I did some digging and apperently this passage of the ECMA CLI specification is responsible for this behaviour:

8.10 Member inheritance

Only object types can inherit implementations, hence only object types can inherit members (see §8.9.8). While interface types can be derived from other interface types, they only “inherit” the requirement to implement method contracts, never fields or method implementations.

Oh, come on.

Anyway, there is a "workaround": use typeof(IHierarchy).GetInterfaces() and descend into the interface "hierarchy". But beware there might be dragons, like duplicated properties and blablabla...

Why, oh why, does FlattenHierarchy not behave like IntelliSense? Just a thought. FlattenHierarchy should walk the hierarchy of the CONTRACT. That's all I expect from a reflection over an interface, since I see them as a guarantee, like a contract. Why else would we have interfaces?