260 Characters. This seems like alot, and it is, however...
I ran into this issue a while back with an existing project I worked on and it was a royal pain. When attempting to follow the naming conventions adopted for the folders and projects within a Visual Studio solution, the newly added filename + path exceeded this hardcoded limit within windows (many core Windows APIs still have this hardcoded limit, and many of the more recent APIs, including the .NET framework still depend upon many of these core APIs). This issue became apparent when trying to check the file into Visual SourceSafe, when an error was thrown.
Now having moved on to a new project, and new technology (Team Foundation Server), I somehow thought that the issue would magically disappear. Not so.
While 260 characters seems like alot, it is quite possible to hit this limit when you:
- use nice descriptive names for folders within projects instead of more cryptic abbreviations
- root your TFS workspace in a subfolder, that will ultimately add unnecessary characters to the total path (D:\work vs. D:\CompanyName\ProjectName\Source)
- use a VS.NET database project, which has its own built in folder structure (Schema Objects\Tables\Keys\) and file naming conventions, which if you have descriptive table names, means the file name of a foreign key constraint SQL file could be really long, just over 100 characters alone for the filename itself without the path in a recent database that I reverse engineered
There is no real fix for this that I have found, except using a shorter path. Being aware of this limitation when setting up the naming conventions on a new project can save alot of hassle later on, and could avoid having to rename the existing files/paths or changing your naming conventions part way through a project to accommodate this limitation.
Edit: I've posted Part 2 on this topic here.