We just had this error occur, causing a checkin to PlasticSCM to fail on a Windows client. There are many, many questions and answers regarding this error message in SO, but I'm posting this specifically for the issue we encountered during PlasticSCM checkin. Providing the answer below, as we were able to solve it.
The solution for us was that one of the files in the checkin had a Windows path and file name in excess of 260 characters -- 264 to be exact -- which is more than the 260 character Windows limit. We shortened one of the directory names in that file's path, and that fixed it. It's not always an easy option to go renaming project directory tree paths, but if it's an option, that may solve this PlasticSCM error message. You'd think it would report the specific Windows error message about path length being limited to 260 characters, but it provided this rather misleading message instead.
As suggested by https://www.visualstudio.com/en-us/docs/tfvc/share-your-code-in-tfvc-xcode I am putting my existing code to TFVC using git-tf. But my paths are deep. During check-in I am getting,
git-tf: TF205022: The following path contains more than the allowed 259 characters:
/Users/VeryLongPath
Even though the path length limitation is really annoying, the most effective and easy way still is spending some time tweaking your file/folder structure to make this work.
For example: instead of \xx\Build\Drop\ProjectName, just use \xx\Build\Drop (or \xx\Builds) since the project name is also in the build name.
For the long path issue in TFS, there had been a related uservoice and now completed. However, it's still a problem in some areas.
Fix 260 character file name length limitation
We’ve removed the limitation from the BCL for the basic file
manipulation functionality (CRUD). You can find more details here:
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
Immo Landwerth Program Manager .NET
Also suggest you to take a look at this great blog-TFS Path Too Long problems for how to deal with the issue.
In short currently its the TFVC limitation, from https://www.visualstudio.com/en-us/docs/reference/naming-restrictions#version-control-paths
Must not contain more than 259 Unicode characters for a single folder or file name.
I work with Visual Studio 2010. I wanted to create a Project (Windows Forms Application) with the Name:
MyCompany.MyApplication.CommunicationConfiguration.Test
If I want run this project I get the error message:
Error while trying to run project: Unable to start program '...\bin\Debug\MyCompany.MyApplication.CommunicationConfiguration.Test.exe'. Access is denied.
After trying with different names and option I found out that visual studio has problem if the project name contains '.Com'.
So names like '.Com.Test' , 'HelloWorld.Communication' etc. throws exceptions. But if '.com' is the end of the name there is no problem.
My question now is, if someone knows if there is a rule which says that '.com' is not allowed in project names unless at the end of the name. I didn't found any rule in the internet and also visual studio doesn't warn by creating a project with '.com' inside the name.
Thanks in advance for your help!
Regards
rhe1980
I'm not getting a repro for this at all, Windows 7 x64. This is almost surely environmental, most likely related to your anti-malware software. Looks like it might fumble the parsing of the filename, giving up the ghost when it contains multiple dots. The .com part of the problem is somewhat significant, it is the filename extension for 16-bit non-relocatable programs back in the MS-DOS days.
Try this on another machine. You could try killing processes with Taskmgr.exe one by one to find the trouble-maker.
I have a pretty simple Could Project (named Uploader.Cloud) with one Web Role (UploaderWebRole) and I'm trying to build them using visual studio. I've modified the project files of both of these projects to change their output path to a different place than the default spot. What I'm finding is that I'm getting a MSB3021 build error when I build Uploader.Cloud:
Unable to copy file "D:\Enlistments\FB1\Dev\Izer\Build\Release\Cloud\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\_PublishedWebsites\UploaderWebRole\bin\Microsoft.WindowsAzure.Diagnostics.dll"
to "D:\Enlistments\FB1\Dev\Izer\Logging\Uploader.Cloud\obj\Release\LogUploaderWebRole\bin\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\_PublishedWebsites\UploaderWebRole\bin\Microsoft.WindowsAzure.Diagnostics.dll".
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.
Upon further inspection, I find it odd that the bin folder of my web role (LogUploaderWebRole\approot\bin) has a cloud package in it (Uploader.Cloud.csx). I don't think that should be the case and am curious if this is a bug in my configuration or if there's a bug in how Visual Studio's Azure tools are building my project.
Any help would be appreciated!
I found the issue. I modified the OutputPaths of the Uploader.Cloud and LogUploaderWebRole projects to build to a different spot. On top of that, Uploader.Cloud was using a web role named LogUploaderWebRole, but the project was named UploaderWebRole. Replacing all instances of LogUploaderWebRole with UploaderWebRole in both projects fixed the issue. For some reason, having the different names caused the build process to nest Uploader.Cloud.csx in multiple levels of the build directory hierarchy.
Does anyone have a method to overcome the 260 character limit of the MSBuild tool for building Visual Studio projects and solutions from the command line? I'm trying to get the build automated using CruiseControl (CruiseControl.NET isn't an option, so I'm trying to tie it into normal ant scripts) and I keep on running into problems with the length of the paths. To clarify, the problem is in the length of paths of projects referenced in the solution file, as the tool doesn't collapse paths down properly :(
I've also tried using DevEnv which sometimes works and sometimes throws an exception, which isn't good for an automated build on a separate machine. So please don't suggest using this as a replacement.
And to top it all, the project builds fine when using Visual Studio through the normal IDE.
It seems that it is limitation of the MSBuild. We had the same problem, and in the end, we had to get paths shortened, because did not find any other solution that worked properly.
The SUBST command stills seems to exist so remapping the root of your build folder to a drive letter may save some characters if Judah Himango's solution is no good.
I solved similar issue by adjusting CSPROJ-file:
<BaseIntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(MSBuildProjectDirectory)\..\..\..\Intermediate\$(AssemblyName)_$(ProjectGuid)\'))</BaseIntermediateOutputPath>
As the result during compilation CSC.EXE receives full path instead of relative one.
Thanks to harrydev for clue on how CSC.EXE operates with the paths.
There are two kinds of long path problems relevant to build. One is paths that aren't really too long, but have lots of "..\" in them. Typically, these are references' HintPath values. MSBuild should normalize these paths down to below the max limit, so that they work.
The other kind of path is just plain too long. Sorry, but these just won't work. After looking at it a fair bit, the problem is that there just isn't sufficient API support for long paths. The BCL team (see their blog) had similar problems. Only some of the Win32 API's support the \?\ format. Arbitrary build tools, and probably 98% of apps out there, don't; and worse would probably behave badly (think of all the buffers sized for MAX_PATH).
We came to the conclusion that until there's a big ecosystem effort to make long paths work, or Windows comes up with some ingenious way to make them work anyway (like the short paths mangling?) long paths just aren't possible for MSBuild to support. Workarounds include subst, as you found; but if your tree just is simply too deep, your only options are to build it in fragments, or to shorten the folder names. Sorry.
Dan/MSBuild
I found the problem to be that when the C# compiler (csc.exe) is called it uses the projects directory path PROJECTDIRECTORY together with the output path OUTPUTPATH by simply appending them as:
PROJECTDIRECTORY+OUTPUTPATH
However, if the OUTPUTPATH is relative i.e. "..\..\Build\ProjectName\AnyCPU_Debug_Bin\" and the project directory is pretty long then the total length is longer than 259 characters since the path will be:
PROJECTPATH+"..\..\Build\ProjectName\AnyCPU_Debug_Bin\"
instead of an absolute path.
If csc.exe would make an absolute path before calling Win32 functions this would work. Since in our case the absolute path length is less than 160 characters.
For some reason the call to csc.exe from visual studio is then different from MSBuild than it is from visual studio. Do not know why.
In any case, the problem can be resolved by changing either or both PROJECTDIRECTORY and/or OUTPUTPATH paths.
Have you tried DOS paths? Or the \\?\ prefix? The .NET BCL team blog has more info.
If the path length is 260, then there is warning resolving reference, for 259 or 261 of this error does not occur. I think there is msbuild bug.
I know there is already an accepted answer, but I had a different problem while using msbuild that gave me the same error output, and led me on a circular wild-goose chase. So, for future googlers, here goes:
We have a batch file that calls msbuild, but as the build machine can build for multiple versions of Visual Studio, each batch file calls vcvarsall.bat before it runs msbuild. This has the nasty side effect of stuffing the path completely full of the same thing over and over again. When it fills up, you get the error shown in the question above: The input line is too long. A simple Google search could make you think your paths are suddenly too long for msbuild.
In my case, it was as simple as killing the session of cmd.exe and restarting, as this reverted the environment variables to their native state.