Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Conditionally referenced project fails to build
Options
Previous Topic Next Topic
MihaMarkic
#1 Posted : Monday, November 11, 2024 9:01:20 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/8/2015(UTC)
Posts: 16
Location: Slovenia

Thanks: 3 times
Was thanked: 2 time(s) in 2 post(s)
So I have this solution C64 Assembler Studio and in C64AssemblerStudio.Engine.csproj I have this ItemGroup:

Code:
<ItemGroup Condition=" '$(Configuration)' == 'Local Debug' ">
  <ProjectReference Include="..\..\..\..\retro-dbg-data-provider\src\Righthand.RetroDbgDataProvider\Righthand.RetroDbgDataProvider\Righthand.RetroDbgDataProvider.csproj" />
  ...
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' != 'Local Debug' ">
  <PackageReference Include="Retro.Debug.Data.Provider" Version="0.1.5-alpha" />
...
</ItemGroup>


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.

Code:
'[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
Code:
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.

TIA
Back to top
Remco
#2 Posted : Monday, November 11, 2024 11:30:52 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi, thanks for sharing this issue.

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.
Back to top
 |  Edit by user
MihaMarkic
#3 Posted : Monday, November 11, 2024 1:25:08 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/8/2015(UTC)
Posts: 16
Location: Slovenia

Thanks: 3 times
Was thanked: 2 time(s) in 2 post(s)
Hi Remco,

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.

PROBLEMATIC_ROOT
|- SRC
|- SLNROOT
|- PROJROOT
.csproj
C64ASS_ROOT
|- SRC
|- SLNROOT
|- REFERNCEE_PROJ
|- .csproj

Could this be the issue and not path length?
Back to top
Remco
#4 Posted : Monday, November 11, 2024 10:52:15 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
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?
Back to top
MihaMarkic
#5 Posted : Tuesday, November 12, 2024 7:51:18 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/8/2015(UTC)
Posts: 16
Location: Slovenia

Thanks: 3 times
Was thanked: 2 time(s) in 2 post(s)
Remco;17709 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):
Code:
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.
Back to top
MihaMarkic
#6 Posted : Tuesday, November 12, 2024 8:05:34 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/8/2015(UTC)
Posts: 16
Location: Slovenia

Thanks: 3 times
Was thanked: 2 time(s) in 2 post(s)
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:
Code:
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.
Back to top
Remco
#7 Posted : Tuesday, November 12, 2024 11:16:51 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
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.
Back to top
MihaMarkic
#8 Posted : Tuesday, November 12, 2024 11:41:46 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/8/2015(UTC)
Posts: 16
Location: Slovenia

Thanks: 3 times
Was thanked: 2 time(s) in 2 post(s)
Hey, setting workspace base path does the trick (didn't know what to look for before), thanks!

Yet another paper cut from Windows long paths implementation I guess...
Back to top
1 user thanked MihaMarkic for this useful post.
Remco on 11/12/2024(UTC)
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.049 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download