Path too long error still prevents project from building

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?

idarroch wrote: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?

Maybe setting the Workspace base path variable of NCrunch to something like C:\Temp\NC could help.
br.: https://www.ncrunch.net/documentation/reference_global-configuration_workspace-base-path

idarroch wrote:
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).

Hi Remco. I can absolutely confirm that VS can build a solution in a deep path.

I tried turning off the LongFilePath setting, and rebuilding using VS. It failed with long file path errors.
Closed VS, re-enabled LongFilePath, then restarted VS & rebuilt. This time it was successful.

As a side note, Windows Explorer is unable to copy the entire solution folder, as it reports long path errors. I suspect Windows Explorer does not use (or properly handle) the LongFilePath setting.

Note the article I linked contains a comment about 32bit apps needing to have a manifest entry to indicate support of long file names. Not sure if this is relevant, but I mention it as I think VS is still 32bit.

idarroch wrote:
Note the article I linked contains a comment about 32bit apps needing to have a manifest entry to indicate support of long file names. Not sure if this is relevant, but I mention it as I think VS is still 32bit.

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.

Is there a way to shift NCrunch's build workspace? It is the paths of files embedded in third-party nuget packages which are long, and which I have no control over.

My own solution path is ok, & VS can build it without the LongFilePath enabled (I think all the files fit the length with 1 or 2 chars to spare).

My own path to the solution is C:\Development\xy_pricing_engine.
The path to NCrunch's workspace is C:\Users\ian.darroch\AppData\Local\NCrunch\5134\2
The NCrunch path is thus 17 chars longer, and this makes the package file paths just too long.

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

I still see this issue with vstudio2022 and NCrunch v4.13 (when introducing NCrunch to colleagues that have not reconfigured workspace path).

Is there any plan of to resolve this? The solution builds fine with dotnet build and in vstudio, but NCrunch fails (with default settings).

Modifying workspace path config to use e.g. C:\WS works for solutions I've tested so far, but it is a pity if trying to make more users NCrunch and it is not working "out of the box" for them.

I think a better user experience when this error occurs also would help, some suggestions:
1. Improve error message when this happens. Users have no clue currently of how to resolve it (e.g. hint to modifying workspace path in config in error message).
2. (minor UI thing) The "Browser for folder" dialog for this setting is outdated right? Prefer using a dialog where you can e.g. paste the path instead of having to click.

Thanks.

GreenMoose wrote:
Is there any plan of to resolve this? The solution builds fine with dotnet build and in vstudio, but NCrunch fails (with default settings).

Modifying workspace path config to use e.g. C:\WS works for solutions I've tested so far, but it is a pity if trying to make more users NCrunch and it is not working "out of the box" for them.

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.