My friend and fellow Team System MVP, Neno Loje, has been on a blogging frenzy this year. Recently he has published a handy Visual Studio template if you do a lot of playing with Team Foundation Server API calls (as I do), or if you are trying to play with an TFS API example that you have found on the net but are having trouble finding the assemblies required to use it.
Go check out Neno’s post now if you are serious about TFS API development, and while you are at it be sure to subscribe to his blog.
The MAX_PATH limitation is not a limitation of NTFS. Rather it is a limitation of the .NET Framework I/O wrappers. Many APIs however adopt this limitation. The Windows Shell API is a good example. But it is not a limitation in NTFS or of the native File Management API which can support over 32 thousand Unicode characters in local file paths.
Kenny,
Very true, I guess I should not say that it is a file system limitation at all. I kinda knew this which is why I talk about local paths rather than talking about the \\?\C:\ way of working.
It was my understanding that the native Windows shell support 3 types of path:
Taking the Win32 GetFullPathName function for example, it has two versions - the ANSI one (GetFullPathNameA) and the Unicode one (GetFullPathNameW).
Are we saying that the fault in .NET is that it is calling the ANSI versions of the Win32 classes rather than the Unicode variants? If you use a local path (C:\) with the unicode variants are you still limited to MAX_PATH (260 characters) and would need to use the Long UNC style to use up to 32k?
Anyway - it is clear that this is not an underlying file system issue but rather an API one. It is also clear that .NET makes the underlying Win32 issues even worse rather than the same or better?
I know that it is probably too late for .NET 4.0 but I would love to file a bug in Connect around this issue and be as precise about the issue as possible to stand a chance of getting the issue fixed in the BCL of a later version of .NET.
Thanks for the correction - I will re-word the introduction to this post.
This is a simple work around to a very annoying problem.
Congratulations Martin!
Nice work Martin! Well deserved!
Thanks for the great write-up, Martin. I think you posted this mere seconds before I redirected that page to a new blog post here: http://blogs.msdn.com/mswanson/archive/2009/03/26/mix09-keynote-and-session-videos.aspx. Didn't want your readers to miss out on the session renamer batch file.
Teamprise continues to do great stuff - thanks Martin!
Nice work. Next step is invoking builds on a Linux box!