dotnet: The fully qualified file name must be less than 260 characters, and the directory name must be less than 248
I have moved my project folder to C:\V7 a short one, I keep getting the error below when trying to publish my web app to Azure web app. Can the message below at least show whitch file has long file name?
How to solve this issue?
Thanks Gary
Microsoft .NET Development Utility CLR-x86-1.0.0-beta7-15019 Copying to output path C:\Users\gzhan_000\AppData\Local\Temp\PublishTemp\PrimeObjects.Platform.Web65
System.IO.PathTooLongException: 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.
at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
at System.IO.Path.GetDirectoryName(String path)
at Microsoft.Dnx.Tooling.Publish.PublishOperations.ExtractFiles(ZipArchive archive, String targetPath, Func2 shouldInclude) at Microsoft.Dnx.Tooling.Publish.PublishOperations.ExtractNupkg(ZipArchive archive, String targetPath) at Microsoft.Dnx.Tooling.NuGetPackageUtils.ExtractPackage(String targetPath, FileStream stream) at Microsoft.Dnx.Tooling.NuGetPackageUtils.<>c__DisplayClass0_0.<<InstallFromStream>b__0>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Dnx.Runtime.Internal.ConcurrencyUtilities.<ExecuteWithFileLocked>d__21.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Dnx.Tooling.NuGetPackageUtils.<InstallFromStream>d__0.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Dnx.Tooling.Packages.AddCommand.<Execute>d__1.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Dnx.Tooling.Publish.PublishPackage.Emit(PublishRoot root)
at Microsoft.Dnx.Tooling.Publish.PublishRoot.Emit()
at Microsoft.Dnx.Tooling.Publish.PublishManager.Publish()
at Microsoft.Dnx.Tooling.PublishConsoleCommand.<>c__DisplayClass0_0.<Register>b__1()
at Microsoft.Dnx.Runtime.Common.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.Dnx.Tooling.Program.Main(String[] args)
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
at Microsoft.Dnx.Host.Bootstrapper.RunAsync(List`1 args, IRuntimeEnvironment env, FrameworkName targetFramework)
at Microsoft.Dnx.Host.RuntimeBootstrapper.ExecuteAsync(String[] args, FrameworkName targetFramework)
at Microsoft.Dnx.Host.RuntimeBootstrapper.Execute(String[] args, FrameworkName targetFramework)
at Microsoft.DNX.Tasks.Dnu.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 21
- Comments: 48 (15 by maintainers)
Issue still exists in 2017 in VS2017
Long Path Tool can solve that problem and it is free, try it
How about, our paths can be 1000 characters long?
Try Long Path tool.
Long path tool can definitely solve this problem. I am sure.
I’ve had nothing but headaches with .NET Core…including the above issue with file names reportedly too long, VS crashing while loading NPM modules, and the build failing because my references are in the 4.x DNX and not in DNX 5. No wonder so many companies stick with “legacy” systems/software. Perhaps major software developers are so caught up in the hype of JS, Open Source and universality that we end up with unfinished (rushed to the public) systems. It is so disappointing.
Just hit this issue today:
Environment: Windows Version 20H2 (OS Build 19042.985), Visual Studio 16.10.0
Setting
Enable Win32 long pathspolicy in Group Policy editor produced a working workaround.Windowkey and typegpedit.msc, then press theEnterkey. This launches the Local Group Policy EditorLocal Computer Policy>Computer Configuration>Administrative Templates>System>FilesystemEnable NTFS long pathsEnabledOKReboot the machine and bingo, that error is gone.
I solved my problem by ensuring that all the package directories were clean of all junk and rebuilding from a clean source. My problem is now solved. It was a custom js folder. 💯
Copying file Content\js\lib\datatables\cdnjs.cloudflare.com\ajax\libs\jqueryui-touch-punch\0.2.3\jquery.ui.touch-punch.min.js to obj\Debug\Package\PackageTmp\Content\js\lib\datatables\cdnjs.cloudflare.com\ajax\libs\jqueryui-touch-punch\0.2.3\jquery.ui.touch-punch.min.js failed. 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.
@richlander not really. It’s the same error. A file path of 260 characters should be acceptable in this age, on Windows 10, in Visual Studio 2017. This is a ridiculous limitation to have still. Like some serious legacy stuff that someone avoided addressing for too long.
Or there should be a work around better than shortening the path if you can. I understand that this is probably more of a Windows issue than a .NET issue. As a developer I just don’t understand how they got away without fixing something like this for so long