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 →

    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)
      • dandan commented  ·   ·  Flag as inappropriate

        weird, I'm dealing with this now, trying to make it work on TFS Build Server.

      • PeterPeter commented  ·   ·  Flag as inappropriate

        "Declined - Visual Studio UV Site Admin" 2013 -- Unbelievable answer!!

        Currently, one of my tfvc 2013 repositories has several files with paths so long they don't show in any repository browser I use. I only see it in the errors that prevent building as a path too long error. This is unacceptable. Apparently you haven't found a way to deal with this internally, as my issue should never have been released with the TFVC product.

        The VS product chain costs a lot of money and this issue has been around for a long time. As a release engineer I have to resolve this issue over and over again. I need improvements that make spending that money worthwhile.

      • JimJim commented  ·   ·  Flag as inappropriate

        Yes, well, I want to vote for this. Can you please re-open it or should we create a brand new suggestion?

      • Stijn SpijkerStijn Spijker commented  ·   ·  Flag as inappropriate

        This needs to be fixed ASAP, as 255 characters is DOS era, and I'd like to think Microsoft has moved on since then.

      • mdgrkbmdgrkb commented  ·   ·  Flag as inappropriate

        It's really disappointing this issue being declined. You should at least consider providing an alternate mechanism that modern apps can invoke, and leave the old compatibility for older apps.

      • Matthew KrulutsMatthew Kruluts commented  ·   ·  Flag as inappropriate

        You mean to tell me that Microsoft doesn't implement best standards and have something like the maximum character limit set as a globally defined constant in your projects? Meaning, change it once and every where in the project it updates? I expected better from a company trying to enforce best practices on its users.

      • Na'anNa'an commented  ·   ·  Flag as inappropriate

        Ok. I've taken a deep breath. Commit the freaking resources! How hard can it be to increase the path length across a handful of products. Sigh.

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

      • Hung NguyenHung Nguyen commented  ·   ·  Flag as inappropriate

        Stupid Limitation!
        Really frustrating!
        MS, this is really a stupid limitation of Windows in compared with Unix-based OS, you need to fix it, regardless how expensive / how difficult it is.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        FYI, the changes to .NET Core have been completed: https://gist.github.com/cartermp/e2950be56ef3341ade56

        My best guess would be that it will take up to a year for this to propagate to all of Microsoft's products, and hopefully ALL versions of the .NET Framework. As stated in the proposal for this fix, making this change should have zero effect on existing code. Adding the code to the framework will just make everything silently "Work".

        This only affects .NET applications, it does not affect C++ applications which have had this ability since 2002.

      • jpo38jpo38 commented  ·   ·  Flag as inappropriate

        Very annoying, and even more when the path gets extended by Visual Studio itself! I end up with file test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.dir\Debug\test_cpp.94C82ABC.tlog\test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.lastbuildstate

        not being created and then my build fails...

      • Anonymous commented  ·   ·  Flag as inappropriate

        This is would be comical if I didn't need to use 3rd party package managers but because I do it's just extremely frustrating. Goodbye Visual Studio.

      • perforatorperforator commented  ·   ·  Flag as inappropriate

        Remember that not long ago somebody said "nobody will ever need more than 640K ram"
        Would you like to find your precious studio together with your ****** os in the pile of abandon-ware?

      • Markus EngelhardtMarkus Engelhardt commented  ·   ·  Flag as inappropriate

        Ok, now I am getting in this line too, we got the same error and it is really frustrating.
        How am I supposed to build up a clean project structure, e.g. by naming sub projects according to their namespaces when I cannot even deploy an ASP.NET 5 REST Service to C:\tmp as my paths are too long then?
        Keeping this bug (as I cannot see it as anything else) over multiple Visual Studio versions is really ignorant and I would also call it kind of stubborn.

      ← Previous 1 3 4 5 15 16

      Feedback and Knowledge Base