I saw this issue was raised a couple of years back Path too long error prevents project from building, but I have run into it today.

One of my colleagues (who does not have NCrunch) was having a problem with Visual Studio 2019 not building a project that pulls in a package which has files in long paths. He altered the setting as mentioned in this link how to make windows 10 accept file paths over 260 characters (which sets the registry value shown by the OP), and found that VS could now compile the project.

For myself, I was not originally having the problem with VS, as my solution path was just short enough to allow the build to proceed, but I was having a problem with NCrunch, as the build worker path was slightly longer. I enabled the LongPathsEnabled setting on my machine (and restarted to make sure it took effect), but NCrunch still complains the path is too long.

I then tried to verify my colleague's experience by shifting the solution to a longer path. VS still built the project ok.

The third party package is for PACT testing, and results in errors like this when building from NCrunch:
..\..\..\program files (x86)\microsoft visual studio\2019\professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets (4643, 5): Unable to copy file "C:\Users\ian.darroch\.nuget\packages\pactnet.linux.x64\2.5.2\tools\pact-linux-x86_64\lib\vendor\ruby\2.2.0\gems\pact-provider-verifier-1.30.0\lib\pact\provider_verifier\provider_states\remove_provider_states_header_middleware.rb" to "bin\Debug\netcoreapp3.1\pact-linux-x86_64\lib\vendor\ruby\2.2.0\gems\pact-provider-verifier-1.30.0\lib\pact\provider_verifier\provider_states\remove_provider_states_header_middleware.rb". Could not find a part of the path 'bin\Debug\netcoreapp3.1\pact-linux-x86_64\lib\vendor\ruby\2.2.0\gems\pact-provider-verifier-1.30.0\lib\pact\provider_verifier\provider_states\remove_provider_states_header_middleware.rb'.

So now it appears that VS2019 properly supports the long paths, but NCrunch does not. Is it possible to have another look at this?

Do you have complete confirmation that VS can build your solution if you place it under a very deep level path with the registry setting enabled?

When I examined this issue two years ago, it didn't look like we'd be seeing this fixed any time soon. The path length issues ran deep within the build system. The error you're quoting is one that is actually raised by the build system when trying to build your project under NCrunch. Unlike in the earlier thread, this is not an exception raised by NCrunch (it's in the MS code).

This is very interesting, thanks for letting me know. I'm noting this down for another look when we have time. It's possible that the manifest entry isn't being applied for our own build processes, in which case we may be able to fix it.

For the time being, I recommend moving you workspace closer to the disk root. By doing this, you can avoid the problem until we've found a way to fix it.

You can change where NCrunch stores its workspaces by changing the configuration setting "Workspace base path" under NCrunch Configuration=>General=>Workspace base path.

For this problem, I'd say we're probably limited to just trying to improve the error so that users know how to fix it with the config setting.

It wouldn't surprise me if this problem was becoming more common with the increasing size of toolsets and the way they're nesting derived files.

I'll take a look to see if I can make the message a bit better. Thanks for your feedback.