NCrunch V5.7.0.3

I'm getting this error when NCrunch is trying to build one of my test projects:



The test project has some txt files that are copied to the build output directory (with appropriate csproj itemgroup). When I look into "D:\ncrunch\workspace\56184\", the directory "132" is not there. ("131" and other "previous" numbered directories, however, are). I've "anonymised" the path above however it is a long path, in case that might be an issue (I've enabled long paths in the OS).

I've tried the "Additional files to include" but that didn't make any difference. I keep coming back to the fact that "\132" doesn't exist is where the problem is. Note this number changes after I perform "Reload and rebuild selected component", but the result is still the same.

Any ideas how to resolve?

Edit: that last message "but this server is using v, " seems it has bugs.

I've set the workspace directory to D:\ws as suggested. The path is 244 characters (under the 260 to be consider 'long') and the exact same error still occurs.

I'm not using Grid Node here, just vanilla plugin (VS and Rider)

I'm a loss here...

Ok will do. I'll try to create a minimal repro. It'll take me a few days.

Thanks for sharing this.

As you can probably guess, NCrunch has a long history when it comes to issues with long paths. After fighting to find ways of improving this for many years, I've come to the conclusion that there isn't a safe way to report this problem without an extremely high chance of misleading false positives.

Part of the problem is that handling for long paths is extremely inconsistent through the platform. What works perfectly fine in some situations will fail in others, and as you've noticed, the failures are often pushed downstream where the error messages are less than helpful.

Years ago, NCrunch had internal restrictions that would prevent any workspace file from exceeding the 259 character path limit. This was later delegated to the platform itself to assess since people were rightly complaining about situations where NCrunch was rejecting long paths that their toolset was otherwise able to work with. So now we have part of the platform that accepts the path, then another part of the platform downstream quietly fails because of it, then a later part throws up a weird error.

If there's a way to make this better without unintentionally making it much, much worse, I haven't been able to find it.

There's broadly two things you can do to shorten the paths involved. One is messy and easy: Set the workspace base path to C:\WS, so it's as close to the disk root as possible.

The second is harder. If you look at the workspace, you'll notice that NCrunch tends to pack it upwards to keep relative paths intact. For example, if you have a project at:
'c:\Dir1\Dir2\Solution\Project\Project.csproj' which references a dependency at 'c:\Dir1\OtherDir\MyFile.txt', the project path will be C:\WS\123\1\Dir2\Solution\Project.csproj.

If you're able to find relative dependencies that require this padding and move them closer to the project referencing them, you can make the workspace paths smaller.

I'm adjusting the documentation page you linked to suggest that path length issues may not have clear error messages attached to them, and to always check paths lengths when build issues don't make sense.

The documentation page has now been updated :)



The .config switch above only applies to older toolsets which aren't hosted on newer versions of .NET (i.e. VS2022 and earlier). Under VS2026, MSBuild is hosted by running dotnet.exe, which I believe is a native executable that has long paths already enabled. If you're seeing this under VS2026, that means that the error is probably being kicked up from a subprocess inside the build system which is almost entirely disconnected from NCrunch. MSBuild itself should generally be thought of as a process tree rather than a singleton, and some of those processes are shared between other build runs (i.e. VBCSCompiler.exe), so it gets really hard to make any guarantees about how the whole system will operate when making declarations at top level.

If you are running on an older toolset, you could try including this in the .config files for the nCrunch.BuildHost processes that are installed with NCrunch (usually at C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\Remco Software\NCrunch for Visual Studio 2022). Make sure you have the IDE closed when you do this. I would be interested to know if this solves the problem. If so, I can include the change in a future NCrunch build.

Agreed. I will check this.