NuGet and long file name support
AndreyAkinshin opened this issue · 116 comments
I often have the following exception during restore on Windows:
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.
In the NuGet 2.x API, there is a nice interface IFileSystem. So, I could implement own file system which supports long paths. In the NuGet 3.x API, IFileSystem is legacy; the core logic works with the file system directly via System.IO (see an example).
Is there a workaround which adds the long paths support in NuGet 3.x?
We do not yet support long paths in NuGet.
https://channel9.msdn.com/Shows/On-NET/Jeremy-Kuhne-long-path-support has some details on new .net framework support for it. We'd like to support this in the future.
@rrelyea, why did you drop the IFileSystem approach? We worked with NuGet 2.x + long paths for a long time. But we can't do it anymore because there is no IFileSystem in NuGet 3.x.
@rrelyea since Jenkins Branch Pipeline creates horribly long sln root folder names (and they aren't willing/capable to change that, so I can't shorten the path anymore. Is there a another workaround? Will this be addressed in 3.* or in 4?
We don't know the exact timeline when we'd be able to do this work. We know if won't fit into NuGet 4.0.0
Bug 389573:[Feedback] Nuget restore fails because path too long
Any update on this?
I am running into this with a path that is long because of the system package names. \runtime.opensuse.42.1-x64.runtime.native.system.security.cryptography.openssl\4.3.0\runtime.opensuse.42.1-x64.runtime.native.system.security.cryptography.openssl.4.3.0.nupkg.sha512
Any updates? It's a critical issue for us because we still have to use NuGet 2.x for some features; it's impossible to migrate to NuGet 4.x because of the lack of the long file name support.
We tried applying the long file paths GPO to work around this but it was a fail. https://www.saotn.org/wp-content/uploads/2016/10/GPO_Enable_Win32_long_paths_2.png
I am suggesting "Long Path Tool" program that solves path too long issues with simplicity.
Any updates?
It is the very painful issue if you restore packages into AppData folder and you have a long username. Some package couldn't be restored. :(
I'm using core DLLs from nuget for processing packages, and I cannot move to v4 APIs because of this problem.
You can shorten with subst program.
Pretty ugly solution but works.
Here is a related issue: #1727 "Packages with deep content get partially unpacked and an incorrect error result of "Package Not Found"" (Nov 13, 2015)
And another one: #3981 "nuget restore exceeding MAXPATH" (Nov 21, 2016)
And an issue on msdocs.uservoice.com: https://msdocs.uservoice.com/forums/364242-site-feedback/suggestions/18432571-add-a-how-to-enable-long-path-support-with-nuget "Add a "how to enable long path support with nuget and .NET 4.6.2" section" (February 23, 2017)
What’s keeping this from being fixed? Do you need technical assistance, a pull request, any other kind of help?
The link above makes it seem trivial to enable support in the most recent versions of .NET.
I’m trying to support the MS ecosystem and have to sit by and watch yarn and npm move along, I haven’t heard of this issue with those tools.
@rrelyea Any updates? I mean looks like some people here will kindly implement this for you and this issue still has no traction
Well, at least it got the Priority-1 tag just days ago. But we all wonder how this can stay unfixed for so long.
NuGet developers: wouldn't simply upgrading the NuGet supportedRuntime to .NET 4.6.2 solve it? Or at least setting the Switch.System.IO.UseLegacyPathHandling=false the AppContext switch?
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
@AndreyAkinshin looking for a short term workaround, I'm curious how you solved it with NuGet 2.x. I used the nuget 2.12 binary from mono/nuget-binary and enabled long path support both via the registry and via group policy, but still did not help :/
Could you elaborate on your approach with NuGet 2.x a bit?
>NuGet developers: wouldn't simply upgrading the NuGet supportedRuntime to .NET 4.6.2 solve it?
As far as I could tell it does not, did try this along with changing the registry setting.
Does anyone know how far back the 260 char path limit goes? I think it may actually have been in the code when Paul Allen himself mostly rewrote MS-DOS, to bring out version 2.0, thirty-five years ago.
Last couple weeks It was announced of all Azure usage about half the servers run Linux. Who knows, maybe a tiny part of that trend is wanting to move past 1983. :-)
@whitneyland I've been meaning to try this, I'm really curious as to what errors you saw after making the changes, would you share what you found?
It has also been pointed before that restore is just the first step. If nuget.exe successfully writes out long paths these tools also need to support long paths in order to successfully use the packages:
- csc.exe
- MSBuild
- Visual Studio
@emgarten thanks for your reply. The error message and repro steps in my case are here in #6034.
I assumed the runtime version configuration for nuget as used in VS2017 was controlled by the VS setup process, and that it was enough to have the latest framework/nuget/VS installed.
However, if changing it manually could make a difference I'm glad to try that, if you wouldn't mind pointing to the location of the config file it uses when running in VS.
It seems that Nuget 4.1.0 is the latest version that works (at least in my case). Is this correct?
I just gave it a try with nuget 4.1.0 and 4.4.1 on a Windows Server 2016 with the long path support enabled (updated in the GPO).
Both are failing with the same error:
[Build Back] Restoring NuGet package wsf-refapp-feature-storelocator.2.0.0-release00000026.
[Build Back] Adding package 'wsf-refapp-feature-storelocator.2.0.0-release00000026' to folder 'C:\jenkins-slave\workspace\masters\master-mybrand\develop\packages'
[Build Back] WARNING: 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.
I tried to shorten the path of jenkins pipelines' workspace by using wks(path) command but that's not enough. We have long paths in our nuget packages due to data serialized by Unicorn, and this issue is a real blocker for us.
@rrelyea: any idea when this severe issue could be fixed?
Same issue during nuget pack on another project
C:\jenkins-slave\workspace\masters\wsf-master-brand2\feature_new-jenkins-pipeline>nuget pack brand2.nuspec -Version 0.0.0-unstable00000004
Attempting to build package from 'brand2.nuspec'.
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.
I made it work for now by shortening the path of jenkins workspace, but that's just a hack to reduce the probability of the issue
Pipeline function used to set the workspace
def getWorkspace() {
def hashLength = 8
def hash = MessageDigest.getInstance("MD5").digest(script.env.JOB_NAME.bytes).encodeHex().toString().take(hashLength)
return "C:\\wks\\${hash}".replace("%2F", "_")
}
...
void execute() {
script.pipeline {
script.node ('WIN-Build-Slave') {
script.ws(getWorkspace()) {
...
gives this result at runtime
[Pipeline] node
Running on windows-slave-01 in C:\jenkins-slave\workspace\eature_new-jenkins-pipeline-OHEXMC4ZBUQJVWJ2R3S3QN7F5H64UFOGNIIVVRWPHJS4PKQKJWEQ
[Pipeline] {
[Pipeline] ws
Running in C:\wks\385792ee
Checked as well with new nuget.exe v4.5.0, the issue is still there.
Any update on this?
We have a project which adds the nuget package 'NPM'. This package has a 'longest filename including the /package folder' of 207 characters. This is extremely restrictive in our environment since the /package folder is not at the root of the 'trunk'. And people usually like to have their branches inside a subfolder (ex: project name).
All of this quite easily breaks the 260 character limit. Can we have an update on this please?
I solved npm issue with my own NuGet which had flatten-packages package run before packaging.
This removes the nesting and somehow workarounds the NuGet issue.
Can you build the nuget under .net462?
If so we will use the DOS Device Paths to solve this issue.
Are you fucking kidding me? Still not fixed?
I agree .. this is ridiculous. I shouldn't have to be thinking about this kind of thing.
Here’s a summary and a few reasons I believe it’s not being handled correctly. Hope it can help as a quick catch up for anyone interested. @emgarten @karann-msft
Had a conversation with @AndreyAkinshin during MVP summit and as discussed, we have started a cross team discussion around how to solve this issue. It seems this might not be just a NuGet issue but may have its tentacles spread across other tooling. Will update the thread on the progress made soon.
@anangaur, I still think (as I suggested two years ago) that the best possible workaround is the IFileSystem interface (which is existed in NuGet 2.x). We can create "smart" implementation of such interface that solves the "260 characters" limitation with the help of the \\?\ prefix. We use this approach in R#/Rider for years, everything works fine. Also, this approach is already implemented in some open sourced libraries like ZetaLongPaths or Pri.LongPath.
If we have any reasons to keep the legacy behavior by default (security? backward compatibility? something else?), such mode can be enabled via managed API or via a command line argument. Thus, people who actually need this feature will be able to turn it on. Once again: my suggestion doesn't change defaults: it just provides additional API which allows enabling the support of long file names.
I still didn't receive any feedback from the NuGet team for my original message about the IFileSystem approach. Why was this interface removed in NuGet 3.x? Is it OK to introduce it again? If it's OK for you, I will be more than happy to create a pull request. It's not a huge change (we should introduce a few additional classes and replace all usages of System.IO).
If it's not OK, please let me know why. I can try to come up with another workaround, but I should know why the suggested solution doesn't work for you.
Now let's talk about tooling.
- It's a pretty common situation when NuGet is used for content delivery. In such case, the restored files are not used by other Microsoft products, they can be consumed by user tools which also support long file names. For example, we do such things in some of our products. I also know people from other companies who also use NuGet as a content delivery tool and process restored packages with custom tools. Thus, the support of long file names in other Microsoft products is not always a problem.
- To be honest, I don't know the exact state of the long file name support in all Microsoft products, but I know that other teams do something with this problem. For example, MSBuild uses
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />(PR: https://github.com/Microsoft/msbuild/pull/2430/files; see explanation in links below)
Related links:
https://blogs.msdn.microsoft.com/bclteam/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton/
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/
@anangaur appeciate the response, but it’s just not apparent how this requires a complicated solution, cross microsoft product code changes, or detenticlization.
Here’s a challenge for you: Let @AndreyAkinshin and I come on campus for a week. If he’s game, I bet with just two people combining ideas we have a solution implemented within a week.
I’m not talking about some proof of concept hack, l bet with some careful planning and feedback iteration it would be able to pass an internal code review within the week allotted. Only caveats would be once it passes code review, checking in the code is not included because that’s just process time, and we’d need standard contractor access (for GAL access to efficiently navigate/communicate cross team).
So right now we’re at two years, I say it should be done in a week. Want to accept the challenge and see who’s right?
Alternatively, please let us know your best guess. No hard commitment needed, just what is your estimate of a rough timeline of when this will be resolved?
It will amuse you to know I solved my problem by creating a user account with two characters and installing my repo in c:. Old school fix!
I just lost 5 hours trying to rework a chocolatey package to deal with this. If this limit is going to exist, it's unconscionable to have folder names like Microsoft.VisualStudio.TestTools.CUIT.Framework.Resources%2Cversion%3D15.6.27323.2%2Clanguage%3Den-US\ in microsoft delivered choco packages / nuget packages. Don't torture me for no reason
https://blogs.msdn.microsoft.com/bclteam/2007/03/26/long-paths-in-net-part-2-of-3-long-path-workarounds-kim-hamilton/ Here is some guidance from Microsoft from 11 years ago about how to work around this when you find it. Nuget/chocolatey team, why can't you use the unicode prefix on file names?
Our ultimate shared goal is that the scenario works well end-to-end, and for that to happen, various VS components as well as other components integral to our ecosystem, will need to be adjusted to support long-paths. The situation is complicated by the fact that we need this to work in a reasonable way on Windows 7 as well. This topic is important all-up for VS, and we will track its status via this UserVoice item that has existed for a while. We have reopened this item, and scoped it to cover an end-to-end scenario – we don’t believe we can solve all the problems and components in one go, but we can move the user experiences forward with a longer term goal of a complete solution.
I am scheduling some time to dig back into the IFileSystem proposal, to determine if that, or something like that, could be an improvement in this space. We are dealing with a number of critical deliverables for NuGet 4.7/VS 15.7 and follow ups to our NuGet 4.6/VS 15.6 work – so unfortunately, my guess is that I’ll be able to come back in about 4 weeks with more knowledge in this space so I can articulate the design goals and constraints with that any proposed solution would need to meet. At that time, I’d love to talk through what I learnt on GitHub, and/or Skype.
If we find a mutually agreeable solution approach, we can discuss community contributions to help rectify this shortcoming in NuGet.
Thanks again for being vocal about issues that impact your experience with NuGet.
Thanks, Rob Relyea
Engineering Manager, NuGet Client Team
@zhili1208 - please start investigating options.
Thanks @rrelyea for following up and working to make it right.
Maybe one thing that was a factor here was Engineering Manager tug-of-war. Depending on where people work not everyone sees the phenomenon. What I mean by tug-of-war: Sometimes when a dev team is a shared resource at a large company, and that team's internal customers are large and politically powerful business units that are not always 100% in sync in their demands, then it's sometimes no picnic mediating and balancing all these demands at once. No idea if you're ever in that situation, just pure speculation on my part.
Nevertheless I'm optimistic there are still short term options. For example if there is basic agreement between stakeholders at the design level, maybe it wouldn't require any coordination to allow a nuget fix to proceed by hiding the functionality behind an experimental flag, or other non-breaking change approach.
Can you guys just please just fix this? It's been years with multiple NuGet releases since this issue was identified. Get with the program already.
Investigation is going well. Details will likely be published in mid-May.
To fix the long path issue, we have a couple of options as mentioned earlier in this post:
- Build an abstraction that avoids System.IO support in .NET Framework or .Net Core
- Rely on .NET Framework or .NET Core support built on top of OS support
In NuGet v2, an abstraction existed, called IFileSystem that allowed a host to work around problems like this. NuGet v3 (shipped in VS 2015) was written as a major rewrite of NuGet and thus doesn't have this abstraction.
We believe that we should pursue a fix that is provided by .NET and the OSes that we run on, instead of working around this problem at the NuGet level. The reason being that without work from the lower levels these workarounds tend to be very fragile as they often have unintended side effects (such as disabling path normalization).
We have been looking into this issue for last couple of weeks. We have separated the issue per NuGet scenario (creating separate issues to track, as required) and would be pursuing them independently. Here is the summary of our investigation and path forward for each of the NuGet scenarios:
- NuGet.exe restore (downloaded from https://nuget.org/downloads)
Current state (for long file path support):
Broken in NuGet.exe 4.7.0 and earlier versions:
Plan: #6937 (fix NuGet.exe to support longfilenames on Windows 10)
We intend to fix the issue in NuGet.exe 4.8.0.
- dotnet.exe restore
Current state (for long file path support):
Works today in dotnet SDK 2.0.x/2.1.200 on all OSes
- Custom Exe which uses NuGet.*.dll
Current state (for long file path support):
Broken today with NuGet components of version 4.7.0 and earlier versions.
Plan:
Doing the same steps detailed under NuGet.exe scenario, see #6937, will also enable this scenario. We’ve confirmed that this works with our currently shipped packages.
- Visual Studio
Enabling this within Visual Studio, will likely take fixes to MsBuild, NuGet, and project system – and a coordinated effort. As I mentioned in my March 19th reply:
This topic is important all-up for VS, and we will track its status via this UserVoice item that has existed for a while. We have reopened this item, and scoped it to cover an end-to-end scenario – we don’t believe we can solve all the problems and components in one go, but we can move the user experiences forward with a longer term goal of a complete solution.
Of course, anyway that you can reduce the base path length will be helpful. One such way is by using PackageReference instead of Packages.Config.
We’d love to hear feedback on additional scenarios that are important to you with long file paths that we may have missed.
Edit by rrelyea: This is not just a picture...this is a link to a video...that I think has something to do with "long file names"
I'm interpreting this as a positive reaction. -rrelyea
NuGet.exe restore (downloaded from https://nuget.org/downloads)
Current state (for long file path support):
Broken in NuGet.exe 4.7.0 and earlier versions:Plan: #6937 (fix NuGet.exe to support longfilenames on Windows 10)
We intend to fix the issue in NuGet.exe 4.8.0.
And fix for Windows 2012?
@Ramon-Balaguer Why wouldn't the fix for Windows 2012 be to upgrade to Windows 2016?
@PeterMurdoch In the company that I work we have some problems with the Windows 2016 licenses
The reason being that without work from the lower levels these workarounds tend to be very fragile as they often have unintended side effects (such as disabling path normalization).
Why do you think that these workarounds are very fragile? We use it for years without any problems.
It's great that you are going to support long paths for new versions of Windows, but what about users with old versions of Windows (e.g. Windows 7) and old versions of VS?
@Ramon-Balaguer -- Yes, the fix would be to move to Windows 10 or Windows 2016.
@AndreyAkinshin - Appreciate your questions. With the context of the backlog we have, replumbing IFileSystem through the NuGet client code base is not an investment we want to make, or support. I'm sorry if the team working on NuGet 3.0 in 2014/2015 didn't solicit better feedback about IFileSystem from the community at the time.
We aren't interested in duplicating investments that the OS/.NET Teams have made. So that means Windows 7 users wouldn't have the ability to support long file names with NuGet.exe 4.8.0 and later, like Windows 10 users will have.
Old versions of VS are irrelevant. We are only fixing NuGet.exe for now.
The fix for NuGet.exe #6937 has been merged, and should ship in 4.8 Preview3. Will try to remember to post here when that is available.
@rrelyea , you mention NuGet.exe 4.8.0 will fix this for Windows 10, but what about Windows Server 2012 R2? We are experiencing this issue on some of our Team City build agents running NuGet.exe (3.4.4) pack on a node project. Strangely, it is working on one of the build agents, even though the same paths, nuget version and Windows version is used.
I guess what I don't understand is why is Microsoft, understanding these limitations, are creating package names like Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated.15.0.26228 as a folder and Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated.15.0.26228.dll as the dll. This could also be mitigated by some training.
@rrelyea Is there an expectation around when we might see 4.8 Preview 3 given that 4.7 is still the latest available and the nightly build is 4.7.0 preview 1? July? Before end of 2018? I am trying to plan for whether I can incorporate this change in the first iteration of my CI/CD system or if I am going to have to add tech debt for the eventual refactor when the NuGet CLI can handle this.
For anyone watching this, 4.8 Preview 3 is now available for download: https://dist.nuget.org/win-x86-commandline/v4.8.0-preview3/nuget.exe
Have not yet validated if it solves the long path issue, but happened to notice the new version while working on something else.
Hey, @SQLEmil you stole my thunder. I was waiting to announce that until we had the docs written and published too. :-)
Yes, install 4.8 preview 3 of nuget.exe.
See requirements and config change needed here: https://docs.microsoft.com/en-us/nuget/tools/cli-ref-long-path
Please let us know how it works.
@ptutt1 - Sorry, we aren't supporting this on Windows Server 2012. It requires a minimum OS of Windows 10 or Windows Server 2016. Not sure why it was working someplaces.
@bleaker19 - good question. That package names seems pretty crazy. Please give feedback to the package author if it is impacting you.
We have two checks in pack right now.
- we error if the ID is more than 100 chars.
- we warn if the total path of any content in a package + the package name is more than 200 chars.
the 2nd one is new.
We'd love feedback, if you have ideas on how to improve that error/warning.
Hi @rrelyea, I'm wanting to try this fix with one of my TFS build configs. I usually use the Nuget Tool Installer to install the latest 4.x tool. However, on changing this step to look for 4.8.0-preview3, it can't find it. It only picks up versions marked as Released or ReleasedAndBlessed, not EarlyAccessPreview. Any chance you could let me know if this could be marked as Released, to allow me to test please? I can pick up other pre-release versions, such as 4.6.0-preview3, because they are marked as Released. Or any alternative way to test through TFS? Thanks!
Hi @rrelyea! Sorry to steal your thunder, I was just so excited when I saw it. Finally had a chance to come back around to test it, and it works great! Turned up an issue with the Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.2.4.0 package, but it's nothing to do with the CLI. (It installs an unexpected folder structure that does not contain its own nupkg file, but it just threw a warning and didn't break the build. As for my app's function, we'll see. ;))
RESOLVED - This is the error you'll get if Win32 Long Paths isn't enabled on the machine running nuget.exe.
@rrelyea - I spoke too soon. Just ran into another problem that seems almost certainly long-path related. The issue I found with the TelemetryChannel package mentioned in my last comment is actually related to this, as well.
Using:
NuGet Version: 4.8.0.5278
Windows Server 2016 Standard Version 1607
When using nuget restore against a solution file in a Jenkins workspace path, one of the packages to be downloaded is Microsoft.CodeDom.Providers.DotNetCompilerPlatform 2.0.0. I receive an error from this, saying it "Could not find a part of the path 'C:\longpathtoworkspace\longworkspacename\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Extentions.props'." The length of this path is >260 characters. That build\net45 folder contains another file whose path with full file name in the Jenkins workspace is exactly 255 characters. That file is installed without issue.
This led me to look at my issue with Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.2.4.0, and I found that the path for that package file also exceeds 260 characters.
How can I resolve this issue? I am, by corporate policy, restricted to Windows 8.1. My project needs to have Microsoft.ApplicationInsights.AzureWebSites installed, but it keeps throwing:
Install-Package : 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 line:1 char:1
+ Install-Package Microsoft.ApplicationInsights.AzureWebSites -Version ...
+ #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-Package], Exception
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
I have the solution in a short folder .. C:\Source .. however, I am unable to proceed and need guidance. #6892
OK, so when does this "fix" make it into the rest of the world?
I have:
- Windows 10 Pro, 1809 installed on 10/03/2018, OS build 17763.55
- Visual Studio 2017 Enterprise 15.8.9
- NuGet 4.8.1 (downloaded 11/06/2018)
- NuGet,Server v3.2.1.0 (local)
- Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled = 1
and I'm STILL getting the error: "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." when attempting to install a just-compiled and pushed (the push goes just fine) project into a local NuGet server (3.2.1.0) package via "Manage NuGet packages" for a project in Visual Studio.
Am I missing something here? If so, what?
@chiefengineer you're not alone, man. Same setup, same error when building a solution with NuGet packages hosted in Azure DevOps package storage.
The problem is that there is no way to override the built-in version of Nuget in Visual Studio. That is currently at 4.6.0 as of version 15.8.9. The Nuget release notes here are incorrect in saying that 4.8 is part of VS 15.8.
Another issue (for me at least) is that there are different behaviours between nuget.exe and Nuget in VS. Using nuget.exe I can restore my projects but I can't update packages, as nuget.exe does not modify project files, and modifying them manually kind of defeats the purpose.
Hopefully VS 15.9 will contain at least version 4.8 of Nuget. If anyone is running the preview, could you confirm?
EDIT:
I looked at the files in ..\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet and they are indeed version 4.8.1, however Help > About shows Nuget at 4.6.0. Maybe there's another bug happening here?
Does anyone know when this will be resolved? This is unbelievable.
@chiefengineer you're not alone, man. Same setup, same error when building a solution with NuGet packages hosted in Azure DevOps package storage.
Any update on this ??
Did this get reintroduced in 5.0.0?
Is this still an open issue? I ask, because I used nuget to install microsoft reporting services and I can't 'publish' the website.
is there a succinct work-around for this? tia. jill
Problem still appears on Visual Studio 16.1.1.
I found a workaround:
In my case, I was first trying to install a package using Manage Nuget Packages for Solutions and was getting this error. Then I tried installing same package using Package Manager Console and it worked fine. I again uninstalled that package and tried installing using Manage Nuget Packages for Solutions and this time it worked fine as well.
i cant believe there is no solution. i cant install npm in my solution (130 chars for project and svn stuff). this is incredible that 1. path can be max 260c long, 2. npm needs more than 130 chars to intstal itself...
the workaround above does not work in VS2015 and vs2017
@brennt I solved this with own NuGet package where I run [url=https://www.npmjs.com/package/flatten-packages]flatten-packages[/url] before packaging.
I agree it is not a solution but possible workaround.
@brennt I solved this with own NuGet package where I run [url=https://www.npmjs.com/package/flatten-packages]flatten-packages[/url] before packaging.
I agree it is not a solution but possible workaround.
Hey, I dont see how can this help? I am trying to install NPM from nuget packet manager console and I get error. I don't want to manually edit packages so unless I can download it flattened its not really a solution ;(
If VS does not allow paths longer than 260chars then it should not allow adding packets with longer structure than eg. 150 chars... and include this info in package description.
You can create your own NuGet package containing npm.
Or install npm using other method not involving NuGet which supports long path.
Reminder...see this comment from last year with the latest status from the NuGet team about our different scenarios:
Nothing yet?
I installed nuget.exe to a custom location then added it to my PATH (env. variable). I then restored
my packages outside of VS. I launched, in admin mode, a cmd/powershell window > cd to the root of the application and run nuget.exe restore there. This is the only thing that worked for me!
Experiencing the same issue while trying to simply upgrade a package with some dependencies in Visual Studio Pro (Nuget v5.2.0.6090). The only temporary workaround (which breaks source control bindings) is to make a directory junction and then launch the project from the temporary path whenever it needs to be used. The downside to directory junctions is that it breaks the source control binding which then requires us to move the project somewhere else (which is what I think everyone else is trying to avoid here.)
The other downside to doing this is that if you do try to re-launch the project from the original path after upgrading packages, there are still output errors when trying to load and enumerate the project. Example:
C:\Users\username\Documents\Visual Studio Workspace\Projects\SampleProject\Master\localhost_12227\Project-Latest-Branch\SampleProject.csproj : error : Cannot expand metadata in expression "roslyn\%(RecursiveDir)%(Filename)%(Extension)". The item metadata "%(Filename)" cannot be applied to the path "C:\Users\username\Documents\Visual Studio Workspace\Projects\SampleProject\Master\localhost_12227\Project-Latest-Branch\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\..\..\tools\roslynlatest\System.Runtime.InteropServices.RuntimeInformation.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. C:\Users\username\Documents\Visual Studio Workspace\Projects\SampleProject\Master\localhost_12227\Project-Latest-Branch\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props
How to make a directory junction if you're interested:
mklink /J C:\NewShortFolderPath C:\LongOldFolderPath
We do not yet support long paths in NuGet.
https://channel9.msdn.com/Shows/On-NET/Jeremy-Kuhne-long-path-support has some details on new .net framework support for it. We'd like to support this in the future.
Still fails, 2019 with VS 2019. There are multiple solutions to this that don't involve local system settings. There is no other package manager system or caching system I've used that has the same problem. (And when I've worked on such, I've been mindful of path limits..)
Please address the core issue of how NuGet (INCORRECTLY) uses the File System when such super-long-path-support is not universal; it's no more valid for a "universal" program to do this than it is for code to rely on a 'only guaranteed in 95% of cases threading construct'. Doesn't work all the time? Fix it or remove all claims of support for said environment.
Very disappointing that such a "core" tool issue still plagues many people and requires local work-abouts. Even more so that it's been a known issue for a few years - plenty of time to correct.
(I have a very-short Package Path setup in the project; the issue is the NuGet Cache Path in the App Data, which is arguably even more of an issue..)
Anyway, (at least since NuGet 3.6), one can can locally "fix" the Cache Issue by setting NUGET_HTTP_CACHE_PATH to a path like "F:\NuGet!@#$Cache" (I use a system environment variable); this is separate from the package install issue (which can be controlled via sane project path locations and a VS setting); prior to 3.6 was the same as the package-path which could be locally controlled in VS.
Very little information exists on how to resolve the problem and the "Shorten the folder names and try again" message on MSDN is pretty much worthless as there is no way to do so from the UI.
Many packages combined with Tfs buildsfolder/build/collection/branch/solution/project easily exceed the limit. This breaks TFS builds where there's little flexibility for these workaround. When you tell a XAML build definition to get a deeper path from source control, to try and shorten the resulting path, it still generates all the parent directories.
For example, consider the path from this package with Microsoft's ridiculously long DLL name, combined with typical parent elements you easily exceed the limit: packages\TypeScript.MSBuildTask.1.7.3\tools\MSBuild\Microsoft\VisualStudio\v14.0\JavaScript\cs\Microsoft.VisualStudio.JavaScript.Project.BuildTask.resources.dll
Any update on this?
I'm still using NuGet 3.6 and cannot install missing packages into my VS project.
PM> install-package C:\Users\MMast\Downloads\microsoft.identitymodel.clients.activedirectory.3.13.9.nupkg
install-package : Some NuGet packages are missing from the solution. The packages need to be restored in order to build the dependency graph. Restore the packages before performing any
operations.
At line:1 char:1
- install-package C:\Users\MMast\Downloads\microsoft.identitymo ...
-
+ CategoryInfo : InvalidOperation: (:) [Install-Package], InvalidOperationException + FullyQualifiedErrorId : NuGetMissingPackages,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
When I attempt to Restore, I get the 260 character path length error. Seems like I'm stuck here...
This is causing us a lot of problems with share feed. The behavior is the packages are ignored and it is slowing Nuget adoption in our org. The workaround is they have to copy the feed locally and it is clunky.
Hmm. Does "removed from the Backlog" mean "won't fix [the poorly designed structure impacting many people]" or does it mean it's being picked up as active work?
Even detecting the issue and providing useful suggestions and work-abouts in error messages would be a vast improvement. There are at least two (and maybe more) related path-length issues that are often conflated - the cache and the packages directory.
Ridiculous
quick workaround using subst:
> subst z: C:\Workspace\really\long\path\to\some\project\folder\WithAVeryLongProjectNameDotNetStyle
> nuget restore .\packages.config -SolutionDirectory z:
I have experienced a similar issue with the same mentioned package (https://www.nuget.org/packages/runtime.opensuse.13.2-x64.runtime.native.System.Security.Cryptography.OpenSsl/). I have the following dev/NuGet configuration:
- VS 2019 Pro (with the latest updates installed)
- Project: An empty “Console App”, TargetFramework is the “.NETFramework 4.5.2” (i.e., any “Full”, but not a .NET Core based),
- Two registered active NuGet feeds:
- The "nuget" - the public NuGet.org by the V3 protocol https://api.nuget.org/v3/index.json
- The "corp" - a corporate one by the V2 protocol https://nuget.CORP_DOMAIN/HASH/api
- The Visual Studio -> NuGet Package Manager -> The "Package source" selector is either set to "All" or "nuget".
When trying to install the problematic long-name package (standalone or as a part of some big package), I can see the following picture of 3 steps (the real 1 and 2 steps order may be different due to the asynchronous calls nature) for resolving the package's info within a file system (note that all active feeds are consumed independent of the "Package source" selected mode):
filePath=
"C:\Users\20_CHARS_USERNAME\AppData\Local\NuGet\v3-cache\HASH$ps_api.nuget.org_v3_index.json\list_runtime.opensuse.13.2-x64.runtime.native.system.security.cryptography.openssl_index.dat"
The real "filePath" length is 224. Almost reaches the allowed 248 characters length, but does not fail yet.
NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.FilePathToLockName(string filePath) NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.FileLockPath NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync NuGet.Protocol.dll!NuGet.Protocol.RegistrationUtility.LoadRanges NuGet.Protocol.dll!NuGet.Protocol.ResolverMetadataClient.GetDependencies NuGet.Protocol.dll!NuGet.Protocol.ResolverMetadataClient.GetRegistrationInfo NuGet.Protocol.dll!NuGet.Protocol.DependencyInfoResourceV3.ResolvePackage
filePath=
C:\Users\20_CHARS_USERNAME\AppData\Local\NuGet\v3-cache\SOME_HASH_CORP_NUGET_FEED_api\list_Packages(Id='runtime.opensuse.13.2-x64.runtime.native.System.Security.Cryptography.OpenSsl',Version='4.3.3')_page1.dat
The real "filePath" length is 257. Fails.
NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.FilePathToLockName(string filePath) NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.FileLockPath NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync NuGet.Protocol.dll!NuGet.Protocol.HttpSource.GetAsync NuGet.Protocol.dll!NuGet.Protocol.V2FeedParser.LoadXmlAsync NuGet.Protocol.dll!NuGet.Protocol.V2FeedParser.QueryV2FeedAsync NuGet.Protocol.dll!NuGet.Protocol.PackageMetadataResourceV2Feed.GetMetadataAsync
filePath=
C:\Users\20_CHARS_USERNAME\AppData\Local\NuGet\v3-cache\SOME_HASH_CORP_NUGET_FEED_api\list_FindPackagesById()_id='runtime.opensuse.13.2-x64.runtime.native.System.Security.Cryptography.OpenSsl'&semVerLevel=2.0.0_page1.dat
The real "filePath" length is 268. Fails.
NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.FilePathToLockName(string filePath) NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.FileLockPath NuGet.Common.dll!NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync NuGet.Protocol.dll!NuGet.Protocol.HttpSource.GetAsync NuGet.Protocol.dll!NuGet.Protocol.V2FeedParser.LoadXmlAsync NuGet.Protocol.dll!NuGet.Protocol.V2FeedParser.QueryV2FeedAsync NuGet.Protocol.dll!NuGet.Protocol.V2FeedParser.FindPackagesByIdAsync NuGet.Protocol.dll!NuGet.Protocol.V2FeedParser.GetPackage
Result:
As a result, when trying to install this package under the described configuration, I get the following error in the Visual Studio -> NuGet Package Manager:
Failed to fetch results from V2 feed at 'https://nuget.CORP_DOMAIN/HASH/api/FindPackagesById()?id='runtime.opensuse.13.2-x64.runtime.native.System.Security.Cryptography.OpenSsl'&semVerLevel=2.0.0' with following message : 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.
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, regardless the project sources folder (p1) or user profile folder (p2) paths, the long feed url-based computed path may exceed the available path length. As a result, the suggested workarounds for reducing the p1 and p2 paths, do not help.
What is strange, is that when trying to reproduce this issue with a similar app ("The Console App"), but for the ".NET Core" target, there is no such an issue. The order of requested paths is different. The only path, which is related to the "corp" feed url I can see, is the following:
C:\Users\20_CHARS_USERNAME\AppData\Local\NuGet\v3-cache\SOME_ANOTHER_HASH_CORP_NUGET_FEED_api\list_runtime.opensuse.13.2-x64.runtime.native.system.security.cryptography.openssl_page1.dat
The real "filePath" length is 226. OK.
However, it does not exceed the allowed length.
Please, let me know if there is any solution/workaround for this related issue (may be related to the custom/corp feed url processing).
@mpreyskurantov, the only available workaround for now is to set the NUGET_HTTP_CACHE_PATH environment variable to a short path (e.g., C:\Temp). In this case, NuGet will use it as temporary storage for cache files instead of C:\Users\<UserName>\AppData\Local\NuGet\v3-cache\. This environment variable should be set individually on each machine, there is no global way to solve this problem on the level of your solution.
@mpreyskurantov Of course, it can be also easily solved on the NuGet side, but it "is not an investment the NuGet team want to make, or support."
Still having this issue, any update when this will be resolved ?
After my last twitter complaint about this issue, we arranged a call on August 26 (two months ago) with the NuGet team. I explained all the problems related to the long path limitations and suggested several ways to workaround them. If I remember correctly, we agreed that I will get a follow-up email with a further plan, but I didn't get anything.
@JonDouglas do you have any updates? I see that this issue was included in Sprint 175 (closed on September 16) and Sprint 176 (closed on October 19). Any progress so far?
The challenge today with providing long path support to NuGet via a IFileSystem interface or leveraging a custom implementation from another provider would be that we aren’t confident this would fix the issue outside of the NuGet layer and you may still fail at the MSBuild/another tooling level instead. Although MSBuild has done work to support this in 16.0, there is no guarantee your whole stack will build with long path support.
i.e.
dotnet/msbuild#53 (comment)
dotnet/msbuild#53 (comment)
In short, .NET Framework requires that you enable long paths in Windows using a group policy or setting a registry key. .NET Core/dotnet CLI however supports long paths by default. So our challenge is that what if NuGet works, but your build ultimately doesn’t? NuGet doesn’t necessarily control the opt-in for .NET Framework’s long path support since it uses System.IO APIs.
We are more than willing to take on a file system abstraction & would love to look over an outline of a design (before any large API changes) through a PR if anyone is up to the challenge.
This would help us take a step forward to support long path support for .NET Framework workloads. For those using .NET Core today, the dotnet CLI supports long paths by default.
https://github.com/NuGet/Home/wiki/Submitting-Bugs-and-Suggestions#pull-requests
https://github.com/NuGet/NuGet.Client/blob/dev/CONTRIBUTING.md#contributing-step-by-step
If there are other solutions that we should pursue outside of a file system abstraction, please let us know in the comments.
Reference: https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-long-path
Thanks all!
I've resorted to manually editing the packages.config and copying the relevant folder from another location into the packages folder (for .NET framework projects, I haven't had an issue with .NET Standard yet.)
So our challenge is that what if NuGet works, but your build ultimately doesn’t?
There are two primary cases when build is irrelevant:
- Most of the long path problems arise when NuGet tries to fetch package metadata from a remote server and cache the responses. For example, the
runtime.opensuse.42.1-x64.runtime.native.system.security.cryptography.opensslpackage is a very popular source of problems. The problem is inside internal NuGet logic: it's about how NuGet stores HTTP responses. Meanwhile, you could have an acceptable length of the package files in the final destination (which should be processed by MSBuild), but you don't have a chance to check it because NuGet throws an exception on the metadata fetching stage.
The problem was mentioned several times in this issue, there are a lot of complaints about it on GitHub and StackOverflow, and we discussed this problem in our meeting. - Many companies use NuGet as a content delivery technology because of its versioning features. In these cases, they use NuGet to download some files that will be processed by other tools (which may support long paths despite Windows registry keys).
Just to second @JonDouglas, my primary case is that using an internal repo like Artifactory makes absorbing a package like runtime.opensuse.42.1-x64.runtime.native.system.security.cryptography.openssl impossible due to this limitation.
Guessing I can directly edit my local nuget cache to include the relevant installation folders for things like runtime.opensuse.42.1-x64.runtime.native.system.security.cryptography.openssl but that seems error prone and somewhat defeats the purpose of Nuget as a whole.
Don't get me wrong Nuget has made my life as a developer very easy, but this issue HAS TO BE FIXED as it's a breaking issue. Nuget is nothing if it's only as good as it's biggest flaw. Cmon Nuget / Microsoft, you've built up a lot of well deserved equity, just get this done and Nuget Restore our Faith (sorry had to do it).