We are making .NET Core OS agnostic as a general principle. The 260 char limit seems like an unwelcome Windows behavior to include in the Linux and OS X implementation. With that removed, it makes sense to also remove it from Windows. That was our thinking.

We do hear about this limitations on Windows somewhat frequently in the context of .NET. This comes from internal Microsoft teams about as much as anyone else. We were glad to remove this limitation for .NET Core.

Disclosure: .NET Team member

Here are the two .NET design review meetings where the removal of the MAX_PATH limitations is discussed: https://www.youtube.com/watch?v=lpa2OFauASM and https://www.youtube.com/watch?v=vpMqUBIAnLU

I have dealt with this in an enterprise quite frequently, dealing with people's home areas. If the home area folder is already 80 chars before the user starts creating deep folder structures with long filenames, you will run into this if you deal with a large number of users.

I've run into this problem using TFS on Windows before. Combination of folders within folders and a deep source tree would force me to abbreviate in file names and pull the source directly into C:\ rather than a preferred place.

You can also work around it by using the subst command to map a drive part way down the tree, and then switch to that drive.

Have a large vs solution.

Have a TFS build server that puts your cloned projects at not-the-top-of-the-filesystem.

It's very easy to hit that limit. It's atrocious and a joke. And Microsoft has paid me as an employee to write some ridiculous stupid workarounds for it in completely 100% managed C# code that shouldn't be bound by such stupid legacy decisions.

I hate MAX_PATH with a passion. It's one of those things that basically forces a hacky solution every, god, damn, time.