I think this may well be the only case when prefixes are useful.
Classes and interfaces really do have different semantics, and because both are types, are easy to mix up.
When I see a class declaration, I can instantly tell what it derives from and what it implements:
public sealed class ActivityCollection : List<Activity>,
IList<Activity>, ICollection<Activity>, IEnumerable<Activity>,
IList, ICollection, IEnumerable
It would be harder to understand if the definition looked like
public sealed class ActivityCollection : ListClass<Activity>,
List<Activity>, Collection<Activity>, Enumerable<Activity>,
List, Collection, Enumerable
And how would you call ListClass? Clearly it's not just ListBase because it's usable on its own.
So, we either have to solve a problem we just invented, or adapt a prefix that separates classes from interfaces, which is what .NET Framework designers did.
Also, personally I find it useful when I can tell from the method signature that it works with interfaces.
public void PrintLines (IEnumerable<string> source)
It's like a signal to my head: hey, I can implement this! I can feed the method whatever matches the contract.
Of course one can argue it's not that important but this is one of those little things that make the prefix worth it for me. It's especially useful when writing a lot of code with IoC containers when you constantly work with interfaces and need to easily differentiate between the two.
By the way, not only the interfaces have prefixes in .NET type system. Don't forget about the generic type parameters:
public delegate TResult Func<in T, out TResult>(
T arg
)
This is another situation when it's extremely useful to be able to differentiate between classes and another kind of types.
Best Answer
I'm not entirely sure what you're referring too, but two of the things that Microsoft pushed really hard for that never did happen was amongst other things
a) .Net as a cross-platform development environment One of the big selling points when .Net was introduced was the runtime/IL code architecture that would allow developers to develop for .Net and have that code work on any platform (ie Linux and Mac). Microsoft more or less promised, or at least strongly implied that runtime for other platforms where forthcoming. Unfortunately they never did come around to doing that, fortunately Mono did. It would have been nice to be able to deploy .Net apps on any platform similarily to Java but I see the strategic disadvantage that Microsoft possibly saw: If apps are "mobile" between platforms that what says people won't leave windows. "Don't f*ck with windows" as the quote famously goes
b) Smart Clients as replacements for "Web applications" Microsoft long tried to battle the web by pushing smart clients, or click once as they also where called. The concept is quite brilliant actually and I think it might catch up one day still. The idea is that you can enter an url to an application and it will be downloaded (and possibly installed) and run on the fly from within a sandbox in Windows. That way you can code an actual GUI application that have the ease of deployment of a webpage but power of a "real application". The problem was that the security model was way too complicated for it being practical together with the fact that the need really wasn't there yet. It was cloud apps before cloud apps even was becoming popular. Now with the cloud making a strong appearance and multi-core development becoming more and more crucial I can see a comeback for that concept, they have to make it way more easier to develop and deploy though.