Basically, when configuration is 'Local Debug' I'm using source files for building and a NuGet package otherwise. Which doesn't play well with NUnit out of the box because it fails to compile Righthand.RetroDbgDataProvider.csproj because it doesn't copy it to its temporary directory.
'[PATH]\C64\retro-dbg-data-provider\src\Righthand.RetroDbgDataProvider\Righthand.RetroDbgDataProvider\KickAssembler\PreprocessorCondition\gen\Righthand\RetroDbgDataProvider\KickAssembler\PreprocessorCondition\PreprocessorConditionLexer.cs' could not be written to the workspace due to error: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\Miha\AppData\Local\NCrunch\15604\1\retro-dbg-data-provider\src\Righthand.RetroDbgDataProvider\Righthand.RetroDbgDataProvider\KickAssembler\PreprocessorCondition\gen\Righthand\RetroDbgDataProvider\KickAssembler\PreprocessorCondition\PreprocessorConditionLexer.cs'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at nCrunch.Common.IO.FilePath.<>c__DisplayClass39_0.<WriteContent>b__0()
at nCrunch.Core.WorkspaceManagement.WorkspaceBuilder.(SnapshotComponentMember )
In fact the directory
C:\Users\Miha\AppData\Local\NCrunch\15604\1
does not exist. How can I tell NUnit to copy Righthand.RetroDbgDataProvidersources so it can be compiled?
I've tried setting 'Local Debug' configuration for C64AssemblerStudio.Engine project and select Righthand.RetroDbgDataProvider as Project Dependency, but it didn't help.
Conditional project references can be problematic because they can cause misalignment between the project.assets.json file (generated at load time by VS) and the actual build step (executed by NCrunch in the workspace).
The easiest way to confirm whether the conditional reference is the source of the problem is to try commenting out the package reference option, and remove the condition from the project reference so that it's just a project reference. I'll be interested to see if this allows NCrunch to build the project. If it does, we need to make sure that NCrunch is set to use the same build configuration used by VS when it first loads the project and creates the project.assets.json file (via the Nuget restore step).
NCrunch can work fine with relative project references, and it can work with Nuget package references ... but it can't work with a project reference that was represented as a package reference during VS's Nuget restore step (or vice versa).
Edit: I've just checked the path given by the error and found it to be 271 characters long. NCrunch does support long file paths but it is reliant on everything in the toolset to be able to handle it, so in practice support for it is hit-and-miss. Moving your workspace base path closer to the root of your disk might solve the problem.
I've tried removing conditional include and it didn't help.
Now, there is another possibility that I can think of - there problematic projects are not under the root directory of the solution, they are more or less distant siblings, i.e.
NCrunch should be able to handle distant siblings. It does this by nesting the workspace path so that the relative references can still function. However, this will increase the overall path length.
Does moving the workspace base path close to your disk root (i.e. something like 'C:\WS') resolve the problem?
Remco wrote:NCrunch should be able to handle distant siblings. It does this by nesting the workspace path so that the relative references can still function. However, this will increase the overall path length.
Does moving the workspace base path close to your disk root (i.e. something like 'C:\WS') resolve the problem?
Sadly not (tried, but really can't move it up much), but I think it wouldn't anyway because the problematic path is target one, not source.
I guess I'll try creating a simple repro and try different approaches.
Also seen at the bottom of the Trace Output this warning (probably it's not relevant):
NCrunch: v8.0.403 of the Dotnet SDK is being used by the NCrunch client, but this server is using v, which is the closest matching version found installed. This may cause issues with the build system. Consider installing v8.0.403 of the Dotnet SDK on this machine.
It seems that indeed is a path length problem. Argh, Windows and its stupid paths.
However in this particular case it seems that the target directory is the problem, because it's appdata local and starts with quite a long path:
C:\Users\USERNAME\AppData\Local\NCrunch\42900\1
So I wonder, is there a settings that would create NCrunch stuff in a dedicated directory instead, I'd set it to something like D:\NCrunch.
This directory should be controlled via the workspace base path setting (above). The workspace base path defines the root of the path where NCrunch shadow copies files in order to build the projects and run tests. If you're still seeing files under AppData after changing this setting, can you clarify which files they are? There shouldn't be anything from your solution copied there if this setting is effective.