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.
Related
I am trying to get a C# Visual Studio 2019/MSBuild job to build on a Jenkins build server. I know that my file paths are too long, so I have enabled Long File Paths in the Group Policy Editor (and verified that it has persisted in the registry editor after a server restart).
However, now I am getting the following error "ALINK: fatal error AL1065: File name ... is too long or invalid".
A quick google search led me to this page for Alchemy Software. However I have no idea what Alchemy Software is and why it is being used in the build process and why it is failing. (Although for the last point, I'm guessing that the Alchemy Software .dll is not "Long Address Aware", which I believe is necessary for an application to take advantage of Long Paths in Windows. But since I can't locate any .dll or .exe associated with this software, I can't be certain.)
Does anyone know why my build is still failing with this error, what Alchemy Software is, and how to get it to take advantage of Long Paths in Windows?
P.S. And please, no comments about how I should restructure my file paths to be shorter. I have tried doing that but it's impractical for this application. And anyway, it keeps popping up and is becoming a whack-a-mole situation, so I'd really rather fix the root cause rather than constantly putting band-aids everywhere.
I am going to set this as an answer since, after Hans Passant's very helpful comments and subsequent research, I think it's pretty definitive that this can mostly only be worked around, not resolved. (As possible exception will be discussed at the end of this answer.)
As stated in those comments, this error originates from a linker module called al.exe that is utilized by MSBuild for certain project configurations (more on that later). This linker can be found in a couple places, but for me it was being called from C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools.
MSBuild can handle long file paths as long as Windows is configured to do so (by enabling long paths in the Group Policy Editor or by modifying the registry directly). However this al.exe module cannot. And as far as I can tell, there's no way to force it to do so. So if your build tool chain requires this al.exe module to be used, you're kind of SOL.
For my particular situation, for a job in Jenkins that was failing because my paths were too long, I worked around this by changing the workspace of my job. So now instead of the default of something like D:\Jenkins\workspaces\[product]\Releases\[product_version], I changed it to D:\j\dd0_1c, which is an encoding that makes sense to me. This shortening of the folder path avoids any subsequent file paths from exceeding the limit of 260 characters. It's not a satisfying solution, but it works for my particular situation.
I did mention that there was a possible exception to all of this: if you can get MSBuild to avoid using al.exe altogether, then you can avoid this error.
I don't know all of the scenarios or workflows in which MSBuild utilizes this module, but I do know that it does get utilized when your application has localized resources, and somehow, some way, MSBuild uses al.exe when it is generating those resources. This was exactly my scenario, and I found this page and this page describing how you can reconfigure your localization projects such that MSBuild does not utilize al.exe. I did try the steps described in these pages and was able to verify that I no longer got this ALINK error from al.exe. However I never got my project to fully build since this reconfiguration caused other build errors to crop up. So in the end, for the sake of expediency (and because it was cleaner than performing a major refactor of my code), I went with the Jenkins workspace workaround.
However, it is interesting to note that you can get MSBuild to avoid using al.exe as long as your project is conducive to the solution given in those two links. So hopefully, if someone runs into this same issue, they might have more success than I in utilizing this method.
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.
When I deploy my SharePoint project I receive the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets(375,5): error : '.', hexadecimal value 0x00, is an invalid character. Line 1, position 1.
The line number relates to the following in the build XML:
<CreateSharePointProjectService Configuration="$(Configuration)"
Platform="$(Platform)"
ProjectFile="$(MSBuildProjectFile)"
ProjectReferences="#(SharePointProjectReference)"
OutDir="$(TargetDir)">
<Output PropertyName="ProjectService" TaskParameter="ProjectService" />
</CreateSharePointProjectService>
Furthermore I've managed to whittle down the problem (or at least seemingly) to the following property:
ProjectFile="$(MSBuildProjectFile)"
i.e. if I remove this property then I no longer get the same error message (but I get others as a consequence).
I'm not sure what's going on here as I know nothing about MSBuild. Obviously this always used to work before so I don't know what's changed to cause it to no longer work. Any suggestions will be greatly appreciated as I've wasted a lot of time on this already. BTW, this problem occurs in both Visual Studio 2010 and 2012.
Thanks
OK, problem sorted. It turns out that the error message actually referred to an XML file referenced by the solution (containing some deployment files). This XML had somehow become corrupted which does fit the message '.', hexadecimal value 0x00. After removing this feature (which didn't need deploying anyway) the problem disappeared so the world can go on being a happy place again (or at least my manager is!)
I just ran into this after downloading an msbuild file from the internet. Opening the newly downloaded file in a hex editor showed me what the problem was pretty quickly. The file was downloaded with 2 byte characters, and every other byte was a 0. I think Notepad++ said the encoding was UCS-2. In any case, the fix was pretty simple. Notepad++ has an Encoding menu option that I used to rewrite the file as UTF-8. Changing the file back to UTF-8 immediately fixed the problem.
Hope this helps people in the future.
--Addendum - I might have tried to muck with the file using PowerShell before its encoding changed.
We recently started getting the following error message in TFS 2010 automatedd builds:
C:\Builds\1\MyProject\MyProject Release\Sources\MyProject\MainLineMyProject.SharePoint.EnterpriseUI.SiteDefinition\Features\MasterPagesMyProject\MasterPagesMyProject.feature: 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.
Initially I thought this is due to Sharepoint, but some further research points me in the TFS direction. Any way other than truncating the path around this problem?
This is indeed a TFS limitation inherited from Windows.
See here for possible workaround:
http://geekswithblogs.net/MikeParks/archive/2009/06/20/team-build-260-character-path-limit-workaround.aspx
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.