I suggest you ...

2,766 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 →

    67 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...
      • Anonymous commented  ·   ·  Flag as inappropriate

        I'm now forced to run some NodeJS projects inside a Docker VM on windows because of this ridiculous file limit.

      • LS DevLS Dev commented  ·   ·  Flag as inappropriate

        MIcrosoft, has this issue been addressed/fixed in Windows 10???

        Or are we going to be stuck with this 260-character for the next decade as well? Surely there was something to be learned from the infamous assumption that "we'll never need more than 640K RAM".

      • SamCPPSamCPP commented  ·   ·  Flag as inappropriate

        Yes 3 votes for this issue too. 2600+ votes must be pretty high up on the tree. Disappointing to see the slow adoption for fundamental issues such as path length, 64-bit tooling, running dot net processes as 64-bit (we had to fight tooth and nail to stop the default being x86 which is pretty incredible), 64-bit EnC. Those things are really foundation blocks for the dev platform but Microsoft tends to toss them straight into the "too hard basket".

      • craigcraig commented  ·   ·  Flag as inappropriate

        man this is pretty crazy in the year 2015... this is a dark ages limit...

      • juroshjurosh commented  ·   ·  Flag as inappropriate

        Yes, this problem is mostly thing why developers are converting to MAC. It's nothing else I hear in office that "npm is not working, ******* windows"... and sadly it's not npm issue directly because of this max path problem. So please fix this is next release if you want also us developers use windows.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        @digiface: All versions of Windows since Windows 2000 (both workstation and server) are Windows NT, and there is no difference in code between workstations and servers.

      • TT commented  ·   ·  Flag as inappropriate

        Solution: create an opt-in option (set true by default) in Visual Studio that allow for infinite file names. For those old-timers that need this constraint, they can disable this option.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        For those visiting here for their first time, this issue has plagued us for over 12 years, and while some people have come up with work-arounds that work for them, no current work-around works for everyone. The fact that the .NET Framework Core is now open source does not mean that just anyone can contribute, as Microsoft is still the gatekeeper for all code check-ins. However; it is probably a HUGE factor as to why they have kept my Connect ticket alive:

        https://connect.microsoft.com/VisualStudio/feedbackdetail/view/932051/long-filepaths-260-characters-are-not-supported

        If you want to truly get this fixed, please vote at the link above.

      • AlexandraAlexandra commented  ·   ·  Flag as inappropriate

        I am too running into this problem. Very annoying!

        @Stelvio How to you tell TFS to use your link instead of the full path?

      • StelvioStelvio commented  ·   ·  Flag as inappropriate

        Well, I found a workaround that ALLOW work with path with more than 260 chars.

        Disclaimer: I've tried this trick only on Windows 8 x64 and Visual Studio 2013

        So, to make it work I've just create a junction to the folder with the mklink command:

        Assume this is the original path: d:\very\very\long\path\to\solution\folder, you can obtain a short link as d:\short_path_to_solution_folder just jaunching this command from a dos shell as administrator:
        mklink /J d:\short_path_to_solution_folder d:\very\very\long\path\to\solution\folder

        change source and destination path to you needs

        Best Regards!
        Stelvio

      • cmoyacmoya commented  ·   ·  Flag as inappropriate

        This is a ridiculous issue that pops up at the most annoying times and is hard to work around. You and your team come up with a great project structure. You go Publish BOOM "path error" because WCF creates ridiculously long paths in the proxy files and although Visual Studio was able to create them (and use them!) you can't copy them?!?! Fine. You move your project to the root (lots of issues around that, but I digress).... a few months down the rood BOOM "path error", this time because App_Themes creates a fairly deep tree structure. I hear Node.js is unusable because of this too.

      ← Previous 1 3 4

      Feedback and Knowledge Base