This post was most recently updated on September 30th, 2022.
3 min read.This post describes a few different ways of fixing the “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.” error. One can encounter this issue when trying to package/publish a SharePoint solution, web site, or an Azure Webjob.
Symptoms
Visual Studio throws the following error when packaging a SharePoint solution to a .wsp file when deploying or publishing your web project (for example Azure Webjob). In the former case, the error shows in the console as a build error, and the build fails. In the latter case, depending on your tooling, the error is either shown in the console when the publishing fails, or it’s shown in a pop-up in your Visual Studio after you’ve selected to publish your project to an Azure App Service.
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.
So, what to do to fix this?
Solution
Depending on the type of your project, the right solution might be just a bit different – although the error seems to be thrown by msbuild during the build/publish action in any case. And just like the error says, it’s because a step in the process is failing because it’s trying to use a folder that’s located in a path that’s too long.
How to fix SharePoint Solutions in Visual Studio?
We’ll need to get the feature’s deployment path to be shorter. This applies to AT LEAST the following typical, Classic SharePoint solutions:
- Full-trust solutions
- sandboxed solutions and
- add-in projects.
If it’s actually about just a few characters (and it often is), you can try the following solution:
Time needed: 10 minutes
How to change a SharePoint feature’s deployment path in Visual Studio?
- Open the feature’s extended settings
This can be done by double-clicking it’s name in the Solution Explorer in Visual Studio.
- Select “Deployment path”
You should see something like “$SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$“
- Modify it
Remove the first token, or replace it with a short name describing your project or solution.
- Save and build/package/deploy.
The problem should be gone now!
This should fix the issue for your typical SharePoint projects. But what about other types of projects or solutions in Visual Studio?
How to resolve the issue for other project types?
In case you’re publishing a webjob or other web project, or the difference is not by just a few characters, you could also try the following steps.
How to change the path for the build process’s temporary files?
- Unload your web/webjob project
- Select “Edit [yourprojectfilename].csproj“
- Add the following entry under the first <PropertyGroup> that exists in the xml file:
- <IntermediateOutputPath>..\Temp</IntermediateOutputPath>
- Reload the project
- Clean the project
- Try the deployment/publish again – it should work now.
So, what does this do? It quite simply shortens the temporary build/publish output path for Visual Studio, so that it doesn’t exceed the 260-character limit. For me, the publish to Azure went fine after this.
In case you STILL encounter this problem, you may have to actually use some slightly blackish magic to map your code to somewhere on your file system where your paths become shorter. Symbolic links might help you – but I never had to go that deep. If this doesn’t fix your issue, let me know in the comments section below!
References
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- “Performing cleanup” – Excel is stuck with an old, conflicted file and will never recover. - November 12, 2024
- How to add multiple app URIs for your Entra app registration? - November 5, 2024
- How to access Environment Secrets with GitHub Actions? - October 29, 2024
