Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

What is Microsoft waiting for providing a decent path API?

Posted by Patrick Smacchia on December 28, 2008

 

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.

 

 

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Stephen

    I’m not sure why they cannot add nullability into the CLR, given they now have the ability to run CLR’s side by side .. surely all they need to get right is the syntax – and have a whole new remastered BCL.. hell – .NET 4 introduces co/contra variance which has led them to fix up BCL classes..

    They’ll come a point where librarys just won’t cut it for keeping the platform attractive.. it’ll have so many librarys for what we start to consider fundamentals that it’ll become a nightmare..

    Whats so scary about launching the next next version of .NET (.NET 5 say), as a whole new infrastructure will a level of backwards compat and a high order of interop?

    People will move onto the new platform as its needed and can still keep their old legacy code.. its not like its any different from today.. want to do WPF? you need at least version 3..

    Theres tons and tons of things that could be added to the core of the CLR to make it more capable.. and I’d be really surprised if they weren’t planning what and how to implement it.

  • http://www.NDepend.com Patrick Smacchia

    Stig, some issues with System.IO.Path are:

    It prevents from having a strong typed way of handling paths

    Even simple rebasing/relative/absolute path conversion can become nightmare to perform because paths are not normalized “C:\dir\file.txt” “c:/dIR\\FILE.TXT” “C:\dir1\..\dir\file.txt”

    Some methods uses internally some win32 path methods that require file/dir path existence to work, which is not always what you want.

    Some methods require some CAS permissions that might raise security exception (see GetFullPath(…) impl)

    Some implementations are very naive, look at Path.Combine(…) imp with Reflector, basically:
    return (path1 + DirectorySeparatorChar + path2);
    what about /.. and /. sub dir?

    It doesn’t support list of paths operation, like extract common sub-paths…

  • Stig

    Please enlighten me. Where are the pitfalls in System.IO.Path?

  • http://www.nyminutedating.com Speed Dating

    I think it works great without a decent path API but you are right – how could they make such a naive mistake? Thanks for this info, I hadn’t taken a look at the code before.

  • TDL

    LOL.. I thought you were wanting a “decent path API” and had mis-typed it. Had no idea that it was really called “descent path”.
    Crawling back under my rock now…

  • http://www.NDepend.com Patrick Smacchia

    TDL, obviously you never had to do things like path comparison, path absolute/relative conversion and other operations on paths with the class System.IO.Path.

    A descent path API is strongly typed and let you do logical path operations, no matter the input string path looks like:
    “C:\dir\file.txt”
    or
    “c:/dIR\\FILE.TXT ”
    or
    “C:\dir1\..\dir\file.txt”

  • TDL

    What is a “descent path API”? Do you use it when writing software to land aircraft?

  • http://siliconbea.ch Bruce Boughton

    Absolutely agree w.r.t Path API. The same is true of URIs. Uri and UriBuilder are totally inadequate. Read the remarks on UriBuilder.Query (http://tr.im/2ozh) for example!

  • Dan

    Agree about NullReferenceException, the first thing I teach to a new team member is how we use Null Object Pattern to avoid the loss of time and dummy code to solve the exception.

    There is an open source CLR language ( Cobra ) that has compile-time nil tracking, it’s so difficult to implement for Microsoft ?