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
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 →

    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

    287 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...
      • 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?
        SUCK IT UP, FIX IT AND STOP WHINING ... YOU STUPID BI** !!!!!

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

      • Matthew MorganMatthew Morgan commented  ·   ·  Flag as inappropriate

        Incorporating tools outside of the Visual Studio and Windows ecosystem is the theme of most of Microsoft's recent efforts. At the very least, improve the error messaging around file path length. Telling me there is some file somewhere with a path greater than 260 characters is the most frustrating part. The compiler simply says the file is "DNX" - go figure it out. Definitely a conflict with NPM and Bower which don't see Windows / VS as first class citizens, though VS sees these tools as first class package managers.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Is there a way to use long file/dir names with _stat function? I've tried to prepend path with \\?\ and use _wstat (it works for _wopen) -- it not works: in this case _wstat returns -1 and errno == ENOENT even for short pathes. If not prepend path -- function works nice (but only with short names).

      • Anonymous commented  ·   ·  Flag as inappropriate

        Boys, if you want people to use npm and JS on VS you might reconsider. ****, if you open the needed code the community will fix it for you. Otherwise you just lose customers.

      • RogerRoger commented  ·   ·  Flag as inappropriate

        This is driving me nuts! I cannot figure out a way to open my build process definition in MSBuild because Team Foundation Server copies something to "c:\users\myname\AppDta\LONG_GUID_HERE\Telerik Extensions for ASP.Net MVC Q1 2013\Source\Telerik.Web.Mvc\Infrastructure Implementation\Expressions\Filtering\FilterDescriptionExpressionBuilder.cs"

        I want to figure out a way to shorten the path, but I'm not finding anything in my solution that is in my control to tweak.

        PLEASE FIX THIS - I can't us MSBuild!

      • Anonymous commented  ·   ·  Flag as inappropriate

        Almost 2016 and this is still a problem. I've been a Microsoft supporter since the start of my career 20 years ago. This is really making me want to leave for the *nix world.

      • Anonymous commented  ·   ·  Flag as inappropriate

        So make the large and complicated architectural change across different product and features including Visual Studio. You act like that's not what we were asking for in the first place.

      • TegmanTegman commented  ·   ·  Flag as inappropriate

        Translation: We don't want to spend the money to bring our trash code to the 21st century. We make more money building buggy 'features' on top of it, so we'll just keep pretending that decision is somehow a benefit to you. Suck it.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Was this seriously declined? We already shortened the paths however we could, but our build is still failing. EPIC FAIL.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Shockingly stupid... Why did I get away from developing in Linux environments?

      ← Previous 1 3 4 5 14 15

      Feedback and Knowledge Base