I suggest you ...

4,545 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    ScottLanghamScottLangham shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    114 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • johnrafjohnraf commented  ·   ·  Flag as inappropriate

        “Long Path Tool” is very helpful for this error !
        You can use to solve this problem.

      • Griffin001Griffin001 commented  ·   ·  Flag as inappropriate

        you can try Long Path Tool to solve your problem. it can shorten your file path name and find the root source. The fun part is its easy to use and its totally free.

      • Eric BrownEric Brown commented  ·   ·  Flag as inappropriate

        AWESOME news! Thank you for fixing this rather than just closing it and ignoring the outcry. It took the community quite a bit of effort to get to this point, but, I'm glad to see the effort has paid off! :)

        Thank you to everyone who has persisted in clamoring for getting this corrected and more importantly, thank you to the team that eventually fixed this! It's MUCH appreciated!

      • FredFred commented  ·   ·  Flag as inappropriate

        16 years for this bug since XP was released and not fixed?

        My guess is it is a rewrite of a good part of the NT based operating system and higher in the risk category.

        Deprecate the limited win32 calls, replace them with longer path ones, rewrite the .NET parts, move MS products using the deprecated win32 calls to the longer path ones, ...
        remove the deprecated ones in a future Windows version.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        On the .NET VLOG for Thursday, June 23, 2016, it was announced that .NET Framework 4.6.2 has the ability to use long path names and the extended syntax. .NET Core has had this functionality since last fall (2015). They also go on to say that the Windows Team is working on the issue for Windows itself.

        What does this mean? NTFS has supported long path names (up to ~32768 characters) since XP was first released, but only via the Win32API and by using extended path names. .NET was never given access to this, until now. Windows has always had access to this since XP, but never used it. I would guess that Windows will have full access to long paths before the end of 2016. Once you have .NET Framework 4.6.2 installed on a machine, PowerShell will immediately have access to long path names as well.

        ENJOY!

      • Jahanzeb SayalJahanzeb Sayal commented  ·   ·  Flag as inappropriate

        Microsoft!!! Please eat this FROG now ... you have to eat it at some time in future ... better NOW than later .... in my opinion...
        Thanks for reading.

      • EricTNEricTN commented  ·   ·  Flag as inappropriate

        I'm probably a bit confused here, and/or I'm stating something that's been stated repeatedly already in several of the 100 comments that have already been made, but: isn't this a Windows problem, not a .NET problem? When npm has its way with my workstation, inevitably it throws a couple 100 files in a DEEPLY-nested spider-web of folders inside folders inside folders inside folders inside.... ok.. you get the idea, and you already know that. I can't get **WINDOWS** to deal with that, let alone .NET. Maybe I'm missing something. I try to move this vast impenetrable web of folders from one spot to another on my hard drive, and it would appear that WINDOWS refuses to do it. So.... sorry if I'm not even talking about something relevant here.

      • Bassem MohsenBassem Mohsen commented  ·   ·  Flag as inappropriate

        Very often I hit this limitation because of the "Add Service Reference" utility in Visual Studio that generates stupid long file names (the .datasource files that nobody wants or uses).

      • Anonymous commented  ·   ·  Flag as inappropriate

        this is a problem for us with a relativley small solution with 25 projects. I would love to see this fixed. Since .net core is only web right now, this will not be a fix for us in the near future.

      • Anonymous commented  ·   ·  Flag as inappropriate

        .Net Core? How about all the... rest of... things...

        Sure, normal users won't care, but maintaining any sort of an automated Windows-based environment professionally is a nightmare in part because of this. It's a symbolic link, mapped-drive, environment variable NIGHTMARE. The excuse that "it requires major architectural changes" is RUBBISH. Microsoft can easily increase this limit to 64K without noticeable performance loss on any modern system. Oh noes, but "old apps won't work" is also RUBBISH. Old apps didn't work before on those paths...

        As a side note, it will be a great chance to finally audit all the buffer overrun security flaws in the OS.

        The biggest losers who are hit by this limitation are the developers. Projects get more and more complex and nested. We're at a point where Windows can't build most modern projects, unless they are on C:\. Come on :/

      • Richard HubertRichard Hubert commented  ·   ·  Flag as inappropriate

        Until this is fixed, node.js projects cannot be realistically developed with Visual Studio. Fix this, or remain irrelevant in the node community.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        Now that .NET Core 1.0 supports path names up to 32,768 Unicode characters in length, when can we expect products to take advantage of the new frameworks?

      ← Previous 1 3 4 5 6

      Feedback and Knowledge Base