Over the years we have had several cases where TFS builds or our CI process fails to create a workspace. After digging into the logs we find the following error:

Exception Message: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. (type PathTooLongException)

Exception Stack Trace: at Microsoft.TeamFoundation.VersionControl.Common.VersionControlUtil.CheckLocalItem(String item, String parameterName, Boolean allowNull, Boolean allowWildcards, Boolean allow8Dot3Paths, Boolean checkReservedCharacters)

The back story here is Windows has always had a max file/directory length. For years, Microsoft said this couldn’t be fixed and we would have to live with it. That was until Jeremy Kuhne (an engineer at Microsoft) decided this had to be fixed. Read more about the new solution at

https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Jeremy also discussed this topic on .NET Rocks!

This solution applies to Windows 10, Server 2016 and .NET 4.6.2 or later. So long term this will be fixed but we have to live with it until updating to the latest OSes and frameworks.

A potential quick fix

This exception typically dumbfounds developers and they are unsure how to get around this. A solution we have used in the past was to shorten the names of folders or projects to cut back on the max length of directories. This works but can be a pain to implement.

After a few instances of this exception occurring over time and analyzing the longest paths in our solution we often found SOAP service reference files were the common culprit. These files are automatically generated when adding service reference in Visual Studio.

The .datasource files specifically are typically the longest. This StackOverflow post says they are provided to bind the service to UI controls of client apps. We never use these so we deleted them (the project still works correctly) and it solved our PathTooLongException on more than one occasion. I suspect this will be an easy solution for other too.

If you need to quickly find the longest paths in your solution folder you can use the following LinqPad script:

Happy Coding!