Update (27-Mar-2008): This post applies to Team Build 2005. If you are working with TeamBuild 2008, the team has done a great job in helping to get around this issue. For more info, please see Aaron Hallberg’s post.
I’ve been busy with my blogs today between reading system documentation. I came across a post by Tom Hollander describing how his work with the Enterprise Library has been dogged by paths that have gotten out of hand. His experiences are very similar to my own with regard to bumping up against the limit of a path.
Once upon a time, in the kingdom of DOS, the people all used 8.3 filenames for their programs, documents and source files. The subjects got used to files like LETTER.DOC, MSCDEX.EXE and VBRUN200.DLL. Nobody ever knew whether there was any limit to the number of 8.3 names that could be strung together to make deep paths, since there were no good GUI tools or even tab-completion, so the paths needed to a manageable length to enable typing by hand. And besides, there were only so many files you can fit on a 20Mb hard disk.
During the reign of Windows 95, the wise ruler decided that the people deserved more, and they were granted long filenames. Now any filename could have as many as 256 characters. And the people rejoiced…
When working with Team Build, you will inevitably run across this issue. Be warned!
UPDATE (17-APR-2007): I just came across a blog post from the Base Class Library team regarding the reasons this “bug” hasn’t been fixed. It’s interesting reading.
Harry Potter-esque graphic used without Tom’s permission or even his knowledge, I just thought it was cool!