I suggest you ...

Fix 260 character file name length limitation

The 260 character limit on file paths really gets in the way of having a deeply-nested project hierarchy. It's only there as backwards compatibility with the old school APIs, and has no place in any sort of modern development environment.

We should be able to work with file paths of whatever size we want.

2,999 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…)
    Steve LeighSteve Leigh shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    declined  ·  Visual Studio UV Site AdminAdminVisual Studio UV Site Admin (Admin, Microsoft) responded  · 

    Hello everyone and thank you for the feedback and for voting on this issue. We understand that this can be a frustrating issue, however, fixing it requires a large and complicated architectural change across different products and features including Visual Studio, TFS, MSBuild and the .NET Framework. Dedicating resources to this work item would come at the expense of many other features and innovation. Additionally, if we removed this limitation from our first party tools it will still likely exist elsewhere in Visual Studio’s ecosystem of extensions and tools. For these reasons, we are declining this suggestion and returning return everyone’s votes so they can be applied to other items. In the interest of delivering the most value to our customers we sometimes have to make very difficult cuts, and this is one of them.

    Thank you,

    Will Buik,
    Visual Studio – Project and Build Team

    212 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...
      • Eric BrownEric Brown commented  ·   ·  Flag as inappropriate

        I'm wondering how this issue is going to be fixed given the .NET framework has been open sourced and Microsoft is actively working on Linux versions of the various classes in the framework.

      • 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

      • Scott GallowayScott Galloway commented  ·   ·  Flag as inappropriate

        With node, npm and other tools becoming core to the VS 2015 web build process this is now an issue which will impact EVERY user. It's a ridiculous joke...

      • Reinhard KuhnReinhard Kuhn commented  ·   ·  Flag as inappropriate

        Having followed the discussion for quite some while I can't help but conclude, that this entire "uservoice" site in the meantime is nothing more than a joke that entirely gets ignored by Microsoft.

        What a pity!

      • Anonymous commented  ·   ·  Flag as inappropriate

        Howsoever long the path may be, you can always rely on Long Path Tool. Its sure to sort out your problem.

      • giongion commented  ·   ·  Flag as inappropriate

        This is a serious issue, not only for VS but for all MS products.
        I recently had to port my code to Scala and move to a Unix machine because the service that I was running was depending a lot on file concatenation. Because of this situation I had to move to a different OS. Is this normal? The NodeJS community suffers from the same issue with their npm. And things are becoming more and more vocal. Besides this, messing with the system PATH is what gives Windows that feeling of slowing down with time(the more you use it, the slower it gets). I have just tested this on 2 machines, their OS was not reinstalled in 2 years now, and the findings are relevant. I am really questioning if this issue is something that will stay as long as windows exists. So far, from your explanations and the way it affects all of your products it seems so.

      • SamCPPSamCPP commented  ·   ·  Flag as inappropriate

        "This response is a ******* joke, frankly. You know it's a problem: fix it."
        Very much agreed. This is a problem that could have been solved at the time the UNICODE API calls were released. How long ago that was? I'm guessing at the very minimum for consumer OS, that was in WinXP.

      • SamCPPSamCPP commented  ·   ·  Flag as inappropriate

        @WillBuik This needs to be addressed at some stage. Yes it will be at the cost of something else but that is always a reality. This is a massive limitation in Visual Studio and simply needs to be addressed at some stage. When are resources planned for it? 2020? 2030? 2050?

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        FYI, every single one of these references to "Long Path Tool" are from the same person, the author. Whenever you see a post like those, please click the "FLAG AS INAPPROPRIATE" link, as he is trying to sell his tool through this and other sites.

      • julias4julias4 commented  ·   ·  Flag as inappropriate

        This is nothing short of pathetic. You can try long path tool for getting a good solution. Hope it will be works good. Thanks

      • Anonymous commented  ·   ·  Flag as inappropriate

        Microsoft is just like this they make all kinda bs. Cortanan coding your software but they will NEVER EVER dare to fix anything which annoys the living **** out of everybody. I hope there will be new king in town some day and MS is just a bad memory after that.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Maybe with the advent of MS open sourcing .Net and bringing the runtime to Linux, we will finally have the sane IDE with MonoDevelop

      • Andrew ClancyAndrew Clancy commented  ·   ·  Flag as inappropriate

        Have you done an estimate of the cost of not doing this vs doing it? In the scheme of things, the cost of not doing it could run into billions, if it means further erosion of your already far-too-late-to-the-market cross-platform support

      • PaulPaul commented  ·   ·  Flag as inappropriate

        Anyone trying to work on multiple operating systems knows what a pain ********** this arbitrary restriction can be. It is, as many people have said, 2014. More to the point, it is not the mid-90s. People have a choice, and so long as the Windows ecosystem throws up annoyances like this, more and more people are going to move to OSX or Android/Chrome OS. So lame!

      ← Previous 1 3 4 5 10 11

      Feedback and Knowledge Base