I'm using nCrunch console and MCP from my AI agent client, by using git worktrees.
when in a worktree, I get a System.IO.PathTooLongException.
System.IO.PathTooLongException: The path 'D:\WK\11480\51\.worktrees\feat-worktree-cuddly-goggles\<long_path_that_i_cannot_sorten>\MyClass.g.cs'
at nCrunch.Common.IO.DiskPath..ctor(String absolutePath, Boolean pathIsChecked)
- dotnet build => OK
- VS build => OK
- nCrunch from VS => OK
- nCrunch console tool KO
PS: the registry key LongPathsEnabled is set, and the git config core.longpaths as well.
Does the console tool handle long paths the same way nCrunch VS does ?
Does the console tool handle long paths the same way nCrunch VS does ?
Yes. NCrunch does have limited long path handling, but it does not work because the underlying platform doesn't fully support it.
This exception is being thrown by the Windows platform when it tries to check the path for validity. It's possible for NCrunch to skip this check (it has in the past), but this causes the problem to appear downstream when MSBuild tries to work with the project. It can then fail in extremely ambiguous ways.
Yes, parts of Windows do support long paths. Probably many of the .NET core libraries do too. The build system doesn't, and many parts of the operating system still handle it very poorly. It's 2026 and long file names on the MS platform still represent a lost wish that has been chased for over a decade. NCrunch can't fix it. The only option is to shorten your paths.
You might find that even though you've set your Workspace Base Path to be close to the disk root, there are relative paths going upwards from your project directories and causing the workspace builder to pack the path heavily. There might be structural options you can take that will reduce the packing.
Packing is an unfortunate necessity when trying to build workspaces with a parallel structure to the foreground solution, and they tend to take up quite a bit of space. VS wouldn't need to deal with this constraint.