16. May 2009 02:49
by Troy

Maximum file path length - Windows and TFS - Part 2 - error CS0006: Metadata file could not be found

16. May 2009 02:49 by Troy | 0 Comments

I blogged about TFS and the maximum file path length issue a while back, and thought I had covered it pretty well.  However, the issue came back to sting me again, so I thought it deserved another post.

Our issue was, sometimes, but not all the time, we would get this error on our team build on the build server (but the local developer build would always work fine).

[Any CPU/Release] CSC(0,0): error CS0006: Metadata file '..\..\..\..\SharedAssemblies\MSApplicationBlocks\Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll' could not be found

It took some time to figure this out... the path was correct on the server and the DLL was there.  Now if you are the intuitive type, you may have already guessed from this blogs title that the problem is related to Windows path length limitation, but why was the problem intermittent?

It turns out that this assembly reference was on a VS.NET Team Test Unit Test project.  When you used the right click "Create Unit Tests" menu to create a new test, the wizard automatically adds assembly references, including a reference to this ExceptionHandling.dll.  This would break the build on our build server.  Our quick solution was to remove the reference from the unit test project, everything still compiled and it didn't seem to be needed.  The builds now worked again on the build server, UNTIL someone added a new unit test and the cycle would start over again.  This explained our intermittent problem.

It still didn't explain why the build failed when this assembly was referenced, until I happened to find this blog entry... the same blog entry I noted in Part 1 of this blog series, but I didn't connect the dots until now. Aaron's blog entry talks about the 260 character path limit, but doesn't mention the error message we were seeing.

It turns out, that for our unit test project,  this ExceptionHandling.dll reference was the longest path of all of them, and was just long enough to be too long, but ONLY on the build server.  The way the build server paths are structured is different than our dev boxes, which was shorter by about 25 characters and this explains why the build would break on our build server but not on our local boxes.

The other severely annoying thing is that the actual error message mentions NOTHING about the path length... just that the file cannot be found.

Using Aaron's tip about these variables ($(BuildDefinitionPath) and $(BuildDefinitionId)) in the properties of the Build Agent I switched to using the $(BuildDefinitionId) which shortened the path on our build server by about 23 characters.  Now the builds always work.

The moral of the story is... if you see the error message above, double-check your path lengths.

3. August 2008 01:55
by Troy

Maximum file path length - Windows and TFS

3. August 2008 01:55 by Troy | 1 Comments

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.