Any important enterprise software development project should utilize some sort of source control system. If you are doing enterprise software development on the Microsoft .Net platform the suggested tool for ALM (application lifecycle management), and therefore source control, is TFS (Team Foundation Server).
I use the TFS client that comes with Visual Studio 2010 Ultimate and it runs on a Windows 7, 64-bit edition operating system. With all the latest and greatest tools I was shocked when I realized that TFS has a limitation where it can't "get" files that have a path length of greater than 259 characters.1 This results in the following error:
TF10128: The path <path> contains more than the allowed 259 characters. Type or select a shorter path.
For ease of use, I use the default paths that Visual Studio installs with. So the default "C:\Users\username\Documents\Visual Studio 2010\Projects" uses up 55 characters before I even specify a file name. When branching occurs into multiple folders and hierarchies the full qualified path can get big really quick.
Online searches are mostly limited to Team Build workarounds modifying build scripts and moving files around to shorter paths. I disagree with this approach as I feel there is a much easier approach to solving the problem by using a substitute drive letter to point to your folder by simply adding a registry entry. This approach is similar to using the SUBST command line keyword, but it makes the fix persist through reboots. As an example, lets say my path to my Visual Studio 2010 projects folder is at "C:\Users\username\Documents\Visual Studio 2010\Projects" and I want to map the drive letter "V:" to that folder. I can just add the following to an empty text file, save it with a .reg extension and double click it. After a reboot I will have a new V: drive where I can map my TFS project folders to.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices]
"V:"="\\DosDevices\\C:\\Users\\username\\Documents\\Visual Studio 2010\\Projects"
1 The apparent root cause isn't actually Windows or TFS, but rather a .Net limitation due to the way it wraps the Windows API for the file system so that it could maintain backward compatibility with older versions of Windows (see the documentation on maxpath).
