Based on a previous question I posed (see here) and the following msdn threads, why does debugging fail when the full path of the vshost.exe is >= 127 characters?
To reproduce the issue create a project with a full path (directory + assembly name + vshost.exe) that is >= 127 characters. Then press F5 to start debugging and the program will exit immediately.
- http://social.msdn.microsoft.com/forums/en-US/vsdebug/thread/e3619f20-f97d-4128-b274-94b1e3cdd211/
- http://social.msdn.microsoft.com/forums/en-US/csharpide/thread/c9ead6da-5e30-4c1d-9187-74361ae5b37a/
Note, my environment is Visual Studio 2008, C#, Windows XP, .NET 3.5 SP1.
This is well known issue. The recommendation from MS for awhile has been to not use the default directories for project locations on XP / Vista. Specifically to create a “Projects” directory off of the root.
Incidentally, this is one of the primary reasons MS did away with the “Documents and Settings” folder in favor of “Users”. They haven’t been able to fix this for various reasons.
UPDATE
BTW, here is a little reading from our favorite host. Also, you might want to check out this MS article.
And, for kicks: https://connect.microsoft.com/VisualStudio/feedback/details/338223/envdte80-solution2-addfromtemplate-reports-path-too-long-incorrectly
The real point is that if your project folder + project name + 80 characters exceeds MAX_PATH then it won’t work. They started really enforcing this to prevent buffer overflows in API parts that are not unicode compliant and therefore can’t take advantage of 32,000 character paths.
Also, the enterprise library team ran into the same issues.
In the case of your vshost, consider the full pathing includes the 80 + 126 (which is 206) that leaves you with less than 54 characters for the other stuff that vshost requires on the line. Of course, you have to take the slashes and other things into account.
The simple answer is to just move your project or otherwise figure out how to reduce the paths.