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,987 votes
Sign in
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


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • John Fly (BoxOfNotGoodery)John Fly (BoxOfNotGoodery) commented  ·   ·  Flag as inappropriate

        With the recent push to "allow" cross platform development, and npm to VS 2015+ this is going to get really bad really quick. Most of the web projects I have tried to work on in VS2015 hit this issue immediately.

        GitHub + Linux is not the solution you want to force people into, but it's looking more and more like the one we will have to use.

      • AnishAnish commented  ·   ·  Flag as inappropriate

        Nodejs is basically unusable on windows and you certainly can't deploy a nodejs app to azure, unless its an express "hello world" app.

        Why don't you reallocate the resources being used on the nodejs tools for visual studio? How about reallocating resources working on anything nodejs related for azure?

        What's the point of having nodejs tools in visual studio or supporting nodejs on azure if you cant use nodejs or deploy a nodejs app to azure?

        How is 260 characters an appropriate limit for a file name in this day and age?

      • MarkMark commented  ·   ·  Flag as inappropriate

        Mr Buik,

        I am of the opinion the decision to push this aside is short sighted and can be comparable to our favorite meme "640k of memory is enough for anyone". Is it time for the new meme “The 256 character path limit is enough for any anyone.”

        The fundamental point is we are tired of having to work around this limitation.

        The workarounds are not always zero cost or easy. The situation is when the path limit is reached it breaks progress for a task to be completed on the Microsoft Windows platform. Someone must search for a workaround and then determine if the workaround is practical for their situation. Not everyone is trying to delete a file that is beyond the limit. Not everyone is trying to access a directory that is on a local device. The workarounds are not universal to all situations dealing with accessing a path that is longer than the set limit.

        The reason you see votes for this and people posting is because the workarounds are not making their job easier or helping them complete their tasks. The path limit is causing unexpected issues which to address requires unmeasurable cost to the end users to work around and to avoid.

        I had a simple task I wanted to perform which requires the input of all data in a directory tree. Unfortunately the tree has paths too long for Windows to handle. I have burned time searching for a workaround. I now have to dig into the workarounds and determine which one is going to work for me.

        I have been moving the servers hosting network directory shares away from Windows servers to eliminate dealing with the path issue on the host of the shares.

        The new enhancements do nothing to solve the problem we face when we hit the file path is too long error.

      • EhrykEhryk commented  ·   ·  Flag as inappropriate

        How about implementing separate LongFileInfo, LongDirectoryInfo, and LongPath objects, similar to what AlphaFS did, or LongPath flags in these object constructors defaulted to false, to allow those who want/need this functionality to utilize it right from .NET, and then the ecosystem can start utilizing them?


      • freakydindefreakydinde commented  ·   ·  Flag as inappropriate

        i now use mklink to shorten my path :

        mklink /J C:\ShortPath C:\VERY\LONG\PATH\I\WANT\TO\SHORTEN

        then in TFS you map on C:\ShortPath

      • 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!

      • 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?

      ← Previous 1 3 4 5 11 12

      Feedback and Knowledge Base