Archive for .NET

The limit of 260 characters path length and mysterious error message

If you work on small and relatively simple projects (in terms of number of components) you may not encounter this limitation. But in any non trivial ‘line of business’ application it is very likely that sooner or later you will come across this troublesome problem: Visual Studio refuses to open a project when the length of its (or any of its references) file system path is longer than 260 characters. The issue is more serious as it seems to be because of its manifestation in somewhat cryptic error message (I suppose different error messages caused by this problem may be spotted in the wild as well).


The error message gives absolutely no clue what the real problem is. After some research I was aware of the existence of this limitation, but I could not believe the path issue can end up with such error message. Eventually, I decided to conduct in-depth investigation with some advanced debugging tools to confirm the root cause of the problem. I followed the great advice from Case of the Unexplained series by Mark Russinovich: when in doubt, run Process Monitor. The picture below shows file system activity of devenv.exe process when it is opening solution containing suspicious projects.


  • We can see the querying directory event and part of its results.
  • The results comprise file names in alphabetical order. These files should be opened by Visual Studio and thus the appropriate project references should be loaded. All of these files are expected to take part in consecutive file system events.
  • File names in green frames are both in the result list of querying directory and are then opened by the devenv.exe process. As expected.
  • File names in red frames are in the result list of querying directory, but are missing from file system activity events further (second window in the background). And this causes the problem.
  • All files that are missing have path length longer than 260 characters.
  • All files that are correctly opened by devenv.exe and loaded into the project and whose file system events are visible in Process Monitor have path length shorter than 260 characters. Obviously, the example shows only some of them, but I analyzed them all to draw the conclusion:

This proves that project references that point to dependencies with path length longer than 260 characters were not loaded and thus prevented the whole project from being loaded properly. After moving the solution to the root directory of the drive (the single letter, e.g. C, is indeed the shortest directory name possible) the problem was solved.

To wrap up:

  1. Be aware that 260 characters limit for path does exist in Windows operating system.
  2. The observable symptoms of hitting this limitation probably will not help you solve the problem.
  3. The solution in most cases could be to rename one or more directories or to make a symbolic link in the root directory of the drive.
  4. The problem described above occured under Windows 7 SP1 64-bit and Visual Studio 2012 Professional.
  5. Do not hesitate to use Process Monitor. It is incredibly powerful tool when it comes to solving wide range of operating system problems.

Quick-tip: Using newest Entity Framework assembly in ASP.NET MVC 4

For me it has been kind of unexpected behavior. When I update NuGet package, I get newest Entity Framework binaries. Today it is version 5.0. However, default MVC template targets .NET version 4.0. Newest version of Entity Framework for .NET 4.0 is 4.4. The NuGet package contains both assemblies, but the project will use 4.4 because the project targets .NET 4.0 by default. Furthermore, simply changing target runtime version in project properties is not enough. What finally has worked for me was manually editing .csproj file. I located assembly reference in XML and changed path in HintPath tag from \lib\net40\EntityFramework.dll to \lib\net45\EntityFramework.dll. The conclusion is to pay close attention to what particular version of assembly is actually being referenced and not relying only on NuGet versioning.