Build/Test Issues

Rider extension fails to recognize referenced projects with åäö

Started by Peter Osterdahl on 2,445 views

Hi,
I use Rider 2025.1 with ncrunch 5.16.0.5

One project "DomainApi" references another with:
<ProjectReference Include="..\DomainApi.Försäkring\DomainApi.Försäkring.csproj" />

in Ncrunch.DomainApi_AnalysisBuild.xml this looks like:
<ProjectReference Include="..\DomainApi.F??rs??kring\DomainApi.F??rs??kring.csproj" /> 

and the build fails with
The type or namespace name 'Försäkring' does not exist in the namespace 'Fuse.Features.DomainApi' (are you missing an assembly reference?)


This does not happen if I run in Visual Studio.
The project builds fine in all other pipelines, Rider, visual studio, dotnet build.

Any suggestions?
//Peter
Hi, thanks for sharing this issue.

The localization issue here looks like a red herring. The Ncrunch.DomainApi_AnalysisBuild.xml file is created when the 'Write build log' setting is enabled, and it looks like this file is defaulting to ASCII encoding for some reason (it shouldn't), but this issue doesn't seem to be related to the build problem you've encountered.

I've tried setting up a local test project referencing another project with the same name, and it's working fine on my side. I think there's something else about this project reference that's causing this problem. Are you able to reproduce it with a small sample solution you can share with me?
Thanks for quick response!
I will try to create one on monday.
Hi, sorry for slow reply.
I have tried to replicate this in a new solution but there it works fine. In my old solution it still fails and as I said it works in all other pipelines and even tunning Ncrunch in visual studio.
Hi again!
The weirdest thing happened. I compared my test project settings to the big solution and noted that the only difference was that in my solution I had Use build configuration set to Debug. I did set this for the test project and it failed to build with the same error as in my big solutiion. Then I restarted Rider for the test project but then it built anyway...
So I removed the Use build configuration in my solution, rebuilt in ncrunch and everything was ok. Then I set it back to Debug and solution still builds in ncrunch...

So something must have been cached somewhere.
Cheers
Peter
I found a workaround for this.
In the global setting I changed the Build SDK to VS2022. After that the problem has disappeared.

I haven't been able to reproduce the original problem in a smaller solution unfortunately. I let AI (codex) analyze the logs and this is the output from that:
Environment
- NCrunch version: 5.20.0.2
- Visual Studio: 2022
- Reproduced in: NCrunch Console Tool
- Project type where the failure happens: old-style .NET Framework C# project (`ToolsVersion="14.0"`, `TargetFrameworkVersion v4.7.2`)
- Referenced projects: sibling projects, some with Swedish characters (`å`, `ä`, `ö`) in folder/project names

Observed behavior
- In the original repository, the test project's `.csproj` contains valid UTF-8 `ProjectReference` paths with Swedish characters.
- In the NCrunch workspace copy of that same `.csproj`, those characters are replaced by literal `??`.
- After this rewrite, the directly referenced projects are no longer resolved correctly.
- The build then fails with real compiler errors (`CS0234` / `CS0246`) because namespaces/types from those projects disappear.

Anonymized example of the problem

Original project file:
<ProjectReference Include="..\..\..\Services\Projectå\Projectå.csproj" />
<ProjectReference Include="..\..\..\Services\PaymentMethodä\PaymentMethodä.csproj" />

NCrunch workspace copy:
<ProjectReference Include="..\..\..\Services\Project??\Project??.csproj" />
<ProjectReference Include="..\..\..\Services\PaymentMethod??\PaymentMethod??.csproj" />

What I verified
- The original `.csproj` is correct.
- The NCrunch workspace copy is corrupted.
- The actual compiler errors are missing namespace/type errors, not just reference warnings.
- The `csc.exe` invocation for the failing test project still includes the main application assembly, but not the assemblies from the corrupted direct project references.
- This strongly suggests the failure is caused by the corrupted `ProjectReference` paths in the NCrunch workspace.

Expected behavior
- NCrunch should preserve the original Unicode characters when generating the workspace copy of the project file.
- Direct `ProjectReference` items with `å`, `ä`, `ö` in the path should resolve exactly the same as outside the NCrunch workspace.

Important note
- I tried to isolate this into a minimal public repro using both SDK-style and old-style anonymized solutions, including Unicode in `ProjectReference`, `Compile`, `Content`, and a separate project-under-test
consumed as DLL.
- Those reduced repros all built successfully in NCrunch Console and did not reproduce the corruption.
- So at the moment I can confirm the bug in the real solution, but I do not yet have a minimal standalone repro.

My current conclusion
- The most likely root cause is an encoding or workspace-generation issue in NCrunch affecting certain legacy project files when Unicode characters appear in project-relative paths.

Edited

I lied, changing to VS2022 did not help. The problem came back.
It seems to be connected to changing branches in git, rebasing and stuff, then it seems something gets stale and åäö gets translated to ?? somewhere
NCrunch obtains the content of project files from two places:

1. By reading them from disk

or

2. From the VS CPS project system

The first option is the most simple and probably the most stable. It allows the encoding to be inferred using the file content and the BOM header.

The second options is more complex and subject to a lot of things that are probably outside of NCrunch's control. The CPS project XML is usually used when the project file is modified inside VS and hasn't been written to disk. It's possible that it may continue to be used if the changes are saved to disk, up until the engine is restarted.

It would be interesting to know if making in-memory changes to the project XML inside VS is causing the problem to appear. If so, this would help to narrow down the potential source of the issue. It also might help to identify a workaround (i.e. save and reload).
Is option 2 a visual studio only thing. Visual studio doesnt have this problem, it is Rider only.
Peter Osterdahl wrote:Is option 2 a visual studio only thing. Visual studio doesnt have this problem, it is Rider only.


My apologies. I forgot you were on Rider!

This would then be the Rider equivalent (we do something quite similar here).

I think I may have found it with a code review. Does it happen for newly added projects only?

Edited

No, it goes back and forth.
Two projects will fail to build, I’ll change something in the global build conf, like build ask, then they build.
Then I’ll do something git related, like a rebase or switching branches, then they’ll fail again, maybe but not always.

And to be clear, it isn’t connected to new projects.

Edited

Peter Osterdahl wrote:No, it goes back and forth.
Two projects will fail to build, I’ll change something in the global build conf, like build ask, then they build.
Then I’ll do something git related, like a rebase or switching branches, then they’ll fail again, maybe but not always.


Does a reset of the NCrunch engine suppress the issue?
Not in a reproducible way. Sometimes I only need to change the configuration. Sometimes I need to turn crunch off, rebuild, change the configuration and restart.
The reload button in the test window is never enough
Could you try the build below and let me know if this improves the issue for you?

NCrunch_Console_5.22.0.1.msi
NCrunch_Console_5.22.0.1.zip
NCrunch_GridNodeServer_5.22.0.1.msi
NCrunch_GridNodeServer_5.22.0.1.zip
NCrunch_LicenseServer_5.22.0.1.zip
NCrunch_Rider_5.22.0.1.7z
NCrunch_Rider_5.22.0.1.zip
NCrunch_VS2017_5.22.0.1.msi
NCrunch_VS2017_5.22.0.1.msi.7z
NCrunch_VS2017_5.22.0.1.zip
NCrunch_VS2019_5.22.0.1.msi
NCrunch_VS2019_5.22.0.1.msi.7z
NCrunch_VS2019_5.22.0.1.zip
NCrunch_VS2022_5.22.0.1.msi
NCrunch_VS2022_5.22.0.1.msi.7z
NCrunch_VS2022_5.22.0.1.zip
NCrunch_VS2026_5.22.0.1.msi
NCrunch_VS2026_5.22.0.1.msi.7z
NCrunch_VS2026_5.22.0.1.zip
I couldn't install. You have a later version of Rider than JetBrains. (I installed the latest from their website now)
https://raw.githubusercontent.com/PeterOsterdahl/ncrunch/refs/heads/master/RiderVersion.png
https://raw.githubusercontent.com/PeterOsterdahl/ncrunch/refs/heads/master/NCrunchError.png
Yes, sorry, Rider 2026.1 is mere hours away from hitting RTM, so every NCrunch build is targeting it at the moment. You can either wait a day or two for them to release it fully or grab the EAP from their website.
Hi!
Have been running for a few hours now and the problem seems to be solved. Great rejoicing! ;)

I'll report if it turns back up.

Thank you very much for quick fix!
//P

Post a reply

Log in to reply.