I was recently browsing the code source of Managed Extensibility Framework and realized that this future part of .NET 4, full of tricky and advanced ideas, was naively relying on strings to describe files and directories paths. It seems that the version 4 of .NET will miss the need for a decent path API. There is the class System.IO.Path but it is feature limited, full of flaws and pitfalls (to not say bugs) and it fosters users to encode their paths into raw strings. It seems to me that using strings to encode paths is as primitive as using String.IndexOf("<tag>") to parse some XML.

As many other applications, the tool NDepend needs to perform many complex paths operations. This includes:

• Relative / absolute path conversion + Path rebasing.

• Path normalization API

• Path validity check API

• Path comparison API

• List of path operations (TryGetCommonRootDirectory, GetListOfUniqueDirsAndUniqueFileNames, list equality…)

In mid 2007, during the development of NDepend we came to the point where relying on the naïve and flawed System.IO.Path was just not acceptable anymore. We then invested a few weeks in building our own strong-typed path library NDepend.Helpers.FileDirectoryPath, that we released Open-Source on CodePlex. The library is bug-free (at least there is no known bug) 100% covered by tests but still, it didn’t attract the mass (only 477 downloads in 14 months). Moreover I don’t know any other equivalent library (do you know any?).

The conclusion is that in 2009 and beyond, doing something as mainstream as handling paths operations in .NET, will still be a pain!

This reminds me the C# non-nullable types debate where half of the bugs in .NET code still comes from the pesky NullReferenceException. IMHO concerning this issue, the future .NET 4 contracts API will help a bit, but certainly not as much as a proper non-nullable strong typing integration at language and platform level. Sadly, Anders Hejlsberg recognized that the absence of non-nullable types is their biggest mistake in designing C# and .NET and cut any hope for seeing them one day.

    A.H: You sort of end up going, well ok, if we ever get another chance in umpteen years to build a new platform, we’ll definitely get this one (i.e non-nullable types) right.

The problem is that both Microsoft and its partners have now capitalized for almost a decade in .NET and won’t likely shift to another platform before a very long time. Maybe I am narrow-minded but I really can’t think of the post .NET era.

• The last years shown that investment in research and innovation from the Java world cannot compare to what MS is doing. Since LINQ in 2007 and even .NET generics in 2005, Java doesn't lead the way anymore in technical innovation and they won’t likely be able to change this trend.

• Microsoft invests massively into .NET for all its own products and it looks like it is just the beginning. I can’t think of Microsoft replacing .NET with something else soon!

• And except the Java community or Microsoft, who else is able today to produce a mainstream platform?

Debug.Assert(… != null); or if you prefer CodeContract.Requires( … != null) will continue to be our friends for a very, very long time.