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

Notification

Icon
Error

NUnit failed to discover the tests in this assembly
spolonski
#1 Posted : Thursday, February 19, 2026 1:27:20 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
I don’t know why, but the tests in one assembly suddenly stopped working.

An error occurred while analysing this project after it was built: NUnit failed to discover the tests in this assembly: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
----> Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
----> Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

I’m not sure where to investigate. The tests run as expected in Rider and Visual Studio, but they do not work in NCrunch.

As far as I can tell, nothing changed on the build server. O:-)


Logs are too long for a chat, so i trimmed some lines....

Code:

[PID:4808 14:08:21.6154 LocalAnalysisTask-103] Launching task: Analysing Sagede.OfficeLine.ControlCenter.MetadataProvider.Test
[PID:4808 14:08:21.6464 LocalAnalysisTask-103] Creating a Dynamic Proxy for System.Web.UI.ICallbackEventHandler handled by assembly C:\Users\spolonski\AppData\Local\NCrunch\Engine\engine_d9090c25-bfc8-4615-94a3-10ea33d73792\Modules\NUnit3\nCrunch.Module.NUnit3.dll
[PID:4808 14:08:21.6464 LocalAnalysisTask-103] Cannot generate proxy.  Target proxy type System.Web.UI.ICallbackEventHandler not found in assembly
[PID:4808 14:08:21.6464 LocalAnalysisTask-103] Process could not be found in pool with signature matching: [ProcessSignature:
C:\Users\spolonski\AppData\Local\NCrunch\4808\26\Shared\Sagede.OfficeLine.ControlCenter.MetadataProvider.Test.dll
nCrunch.TestExecution.RemoteTaskRunner
C:\Users\spolonski\AppData\Local\NCrunch\4808\26\Shared\Sagede.OfficeLine.ControlCenter.MetadataProvider.Test.dll.config.ncrunchconfig
x86
(local)
nCrunch.Core.ProcessManagement.DefaultProcessLoader
Framework48
[PID:4808 14:08:21.6464 LocalAnalysisTask-103] Adding external process with Id '8200f4b188374a30b5f3a6f46b04df6a'
[PID:4808 14:08:21.6464 LocalAnalysisTask-103] Starting external process '"C:\Users\spolonski\AppData\Local\NCrunch\Engine\engine_d9090c25-bfc8-4615-94a3-10ea33d73792\nCrunch.TestHost48.x86.exe"' with arguments '4808 nCrunch_c6c78b6d9ecf4b82be12e427aeb4f4a0 8200f4b188374a30b5f3a6f46b04df6a "C:\Users\spolonski\AppData\Local\NCrunch\Engine\engine_d9090c25-bfc8-4615-94a3-10ea33d73792\nCrunch.TestExecution.Net6.dll" nCrunch.TestExecution.RemoteTaskRunner "C:\Users\spolonski\AppData\Local\NCrunch\4808\26\Shared" "False" "C:\Users\spolonski\AppData\Local\NCrunch\4808\26\Shared\Sagede.OfficeLine.ControlCenter.MetadataProvider.Test.dll.config.ncrunchconfig"'
[PID:4808 14:08:21.6624 LocalAnalysisTask-103] Process ID '13084' initialised
[PID:4808 14:08:21.6624 LocalAnalysisTask-103] Connecting to external process '8200f4b188374a30b5f3a6f46b04df6a' with id 13084
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Process '8200f4b188374a30b5f3a6f46b04df6a' with id 13084 is connected and tethered
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\26 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\25 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\24 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\23 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\19 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\6 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\18 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\12 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\7 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\15 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\20 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\17 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\21 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\14 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\13 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\11 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\5 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\4 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\16 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\8 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\9 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\10 (now 3 usages)
[PID:4808 14:08:21.8344 LocalAnalysisTask-103] Registered usage of workspace: C:\Users\spolonski\AppData\Local\NCrunch\4808\22 (now 3 usages)
[PID:4808 14:08:22.1314 LocalAnalysisTask-103] Publishing Event: [TaskProcessIdAssignedEvent:4f6e380c-5894-4671-a452-05c460427978:13084]
[PID:4808 14:08:22.1314 LocalAnalysisTask-103] Event [TaskProcessIdAssignedEvent:4f6e380c-5894-4671-a452-05c460427978:13084] is being published on thread Core to subscriber: ProcessingQueue.taskProcessIdAssigned
[PID:4808 14:08:22.1314 LocalAnalysisTask-103] Calling into task runner to analyse target assembly: C:\Users\spolonski\AppData\Local\NCrunch\4808\26\Shared\Sagede.OfficeLine.ControlCenter.MetadataProvider.Test.dll
[PID:13084 14:08:22.1314 ?-6] Loading tests into NUnit3
[PID:13084 14:08:22.2244 ?-6] Exploring tests using NUnit3
[PID:13084 14:08:22.2714 ?-6] Discovered a total of 0 tests
spolonski
#2 Posted : Thursday, February 19, 2026 1:30:10 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
<PackageReference Include="NUnit">
<Version>4.4.0</Version>
</PackageReference>
<PackageReference Include="NUnit3TestAdapter">
<Version>5.2.0</Version>
</PackageReference>
spolonski
#3 Posted : Thursday, February 19, 2026 1:33:38 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
NCrunch Version on BuildServer: 5.15.0.4
Local: 5.20.0.2
Remco
#4 Posted : Thursday, February 19, 2026 10:24:12 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 1021 times
Was thanked: 1370 time(s) in 1271 post(s)
Thanks for sharing this issue. This here is a red flag:
[PID:4808 14:08:21.6464 LocalAnalysisTask-103] Cannot generate proxy. Target proxy type System.Web.UI.ICallbackEventHandler not found in assembly

Are you able to make any guesses as to what change might have caused this? Did you upgrade your NUnit dependency? Is there any chance you could submit a bug report right after the failure?
spolonski
#5 Posted : Friday, February 20, 2026 4:53:39 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
Remco;18651 wrote:
Are you able to make any guesses as to what change might have caused this? Did you upgrade your NUnit dependency? Is there any chance you could submit a bug report right after the failure?

I have no idea (maybe dot net sdk 10, but not on Grid Server), as far as i can say it is the same version, done.
Remco
#6 Posted : Friday, February 20, 2026 6:49:02 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 1021 times
Was thanked: 1370 time(s) in 1271 post(s)
Thanks for sending through the log.

I've confirmed that the ICallbackEventHandler proxy error is not related to this problem (it isn't required for the platform version you're on, so it's benign).

Unfortunately the log doesn't provide enough detail to understand what's happening here, but I think there is a type loader issue in the test domain. In the past, I've seen this caused by attributes or static constructors that throw exceptions. Because it happens before any of the error handling is fully online, it doesn't get reported in a sensible way.

Does starting the test with a debugger attached and wide settings on exception filters cause the exception to be trapped?

If you have a previous source code version that used to work, you might be able to isolate the problem by checking what could have changed between versions of your source code.
spolonski
#7 Posted : Friday, February 20, 2026 7:19:38 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
Remco;18654 wrote:
Thanks for sending through the log.
Does starting the test with a debugger attached and wide settings on exception filters cause the exception to be trapped?

If I right‑click an assembly in the NCrunch Test Window and choose Debug, the debugger does not attach at all.
I suspect the exception occurs during the analysis phase, so the debugger isn’t involved at that point.
Should I instead attach to another process, e.g. the NCrunch runner?
I can try to attach to it using Visual Studio without NCrunch and with Entrian Attach. https://entrian.com/attach/.

Remco;18654 wrote:
Thanks for sending through the log.

Does starting the test with a debugger attached and wide settings on exception filters cause the exception to be trapped?

If you have a previous source code version that used to work, you might be able to isolate the problem by checking what could have changed between versions of your source code.

I’ve already tried that as well — same behavior.
spolonski
#8 Posted : Friday, February 20, 2026 8:33:35 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
I can reproduce failures and passes at different code stages, but I have to restart the NCrunch engine to see the difference.
spolonski
#9 Posted : Friday, February 20, 2026 12:11:03 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
I tracked it down to the commit causing the issue. It was a change to the NCrunch settings in another assembly. That assembly is no longer supposed to be instrumented. I changed in UI InstrumentOutputAssembly = false. Unsure about PreventSigningOfAssembly.
Code:

diff --git a/Application/Source/.NET/Shared/Sagede.OfficeLine.Data/Sagede.OfficeLine.Data.v3.ncrunchproject b/Application/Source/.NET/Shared/Sagede.OfficeLine.Data/Sagede.OfficeLine.Data.v3.ncrunchproject
index 272ced7688f..0ac5956d8ab 100644
--- a/Application/Source/.NET/Shared/Sagede.OfficeLine.Data/Sagede.OfficeLine.Data.v3.ncrunchproject
+++ b/Application/Source/.NET/Shared/Sagede.OfficeLine.Data/Sagede.OfficeLine.Data.v3.ncrunchproject
@@ -1,27 +1,6 @@
 <ProjectConfiguration>
-  <AutoDetectNugetBuildDependencies>true</AutoDetectNugetBuildDependencies>
-  <BuildPriority>1000</BuildPriority>
-  <CopyReferencedAssembliesToWorkspace>false</CopyReferencedAssembliesToWorkspace>
-  <ConsiderInconclusiveTestsAsPassing>false</ConsiderInconclusiveTestsAsPassing>
-  <PreloadReferencedAssemblies>false</PreloadReferencedAssemblies>
-  <AllowDynamicCodeContractChecking>true</AllowDynamicCodeContractChecking>
-  <AllowStaticCodeContractChecking>false</AllowStaticCodeContractChecking>
-  <AllowCodeAnalysis>false</AllowCodeAnalysis>
-  <IgnoreThisComponentCompletely>false</IgnoreThisComponentCompletely>
-  <RunPreBuildEvents>false</RunPreBuildEvents>
-  <RunPostBuildEvents>false</RunPostBuildEvents>
-  <PreviouslyBuiltSuccessfully>true</PreviouslyBuiltSuccessfully>
-  <TrackFileDependencies>false</TrackFileDependencies>
-  <InstrumentAssembly>true</InstrumentAssembly>
-  <PreventSigningOfAssembly>false</PreventSigningOfAssembly>
-  <AnalyseExecutionTimes>true</AnalyseExecutionTimes>
-  <DetectStackOverflow>true</DetectStackOverflow>
-  <IncludeStaticReferencesInWorkspace>true</IncludeStaticReferencesInWorkspace>
-  <DefaultTestTimeout>60000</DefaultTestTimeout>
-  <UseBuildConfiguration></UseBuildConfiguration>
-  <UseBuildPlatform></UseBuildPlatform>
-  <ProxyProcessPath></ProxyProcessPath>
-  <UseCPUArchitecture>AutoDetect</UseCPUArchitecture>
-  <MSTestThreadApartmentState>STA</MSTestThreadApartmentState>
-  <BuildProcessArchitecture>x86</BuildProcessArchitecture>
+  <Settings>
+    <InstrumentOutputAssembly>False</InstrumentOutputAssembly>
+    <PreventSigningOfAssembly>False</PreventSigningOfAssembly>
+  </Settings>
 </ProjectConfiguration>
\ No newline at end of file


Without this change in the third assembly, NCrunch fails during compilation with:

Code:
NCrunch: This project was built on server '(local)'
MainDeviceExtensions.cs (15, 42): The type 'ISecureDatabaseUserManager' is defined in an assembly that is not referenced.
You must add a reference to assembly 'Sagede.OfficeLine.Data, Version=9.0.0.0, Culture=neutral, PublicKeyToken=4ad8971889b881a9'.
Remco
#10 Posted : Friday, February 20, 2026 10:45:18 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 1021 times
Was thanked: 1370 time(s) in 1271 post(s)
Good find.

So it was triggered by a config change that was introduced to work around a different issue.

There is something unusual in the way your assembly references are working. I haven't seen instrumentation cause this kind of problem before, since it doesn't tamper with the references themselves. I would be interested to know why turning off prevent signing of assembly was needed here.

I think there's a likelihood that the runtime problem you're getting is related to the same core issue, and by turning off instrumentation it's just been pushed downstream.

If you set your Log Verbosity to Detailed and examine the log for the failed test run inside the Processing Queue Window, do you get more exception details?
spolonski
#11 Posted : Monday, February 23, 2026 10:54:08 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
Quote:
So it was triggered by a config change that was introduced to work around a different issue.

Yes.

Quote:
There is something unusual in the way your assembly references are working. I haven't seen instrumentation cause this kind of problem before, since it doesn't tamper with the references themselves. I would be interested to know why turning off prevent signing of assembly was needed here.

This became necessary because this assembly needed access to protected resources, and such access is only possible from signed assemblies.

Quote:
I think there's a likelihood that the runtime problem you're getting is related to the same core issue, and by turning off instrumentation it's just been pushed downstream.

I don't think so, I rolled the code back to a state where this access was not yet required, and even there the previously described configuration change leads to an error.
What’s strange is that NCrunch needs to be restarted to see a change in behavior and old (working) Configuration is without <Setting> tag. Is it same as an an Empty configuration?

Quote:
If you set your Log Verbosity to Detailed and examine the log for the failed test run inside the Processing Queue Window, do you get more exception details?

I didn’t notice anything suspicious. I send you logs of working/failing Build/Analyse Tasks per Suport form with the same name as a Topic here.
Remco
#12 Posted : Monday, February 23, 2026 11:05:10 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 1021 times
Was thanked: 1370 time(s) in 1271 post(s)
Thanks for sending through the logs.

The logs confirm that NUnit is eating the inner exception details, which is unfortunate as it means they won't be accessible through any logging mechanism that I'm familiar with.

I wonder if we can try to force the exception to occur earlier, outside of NUnit. Could you try turning on the Preload assembly references config setting for this test project? This will tell NCrunch to forcefully load all referenced assemblies into the environment before calling NUnit, which might trigger the issue in a state where we can trap the error and identify the dependency responsible. There is also a small chance it could actually solve the problem, as resolving assemblies up-front can give more dependable behaviour.

Regarding the settings file, it looks like your NCrunch settings file is actually a v1 settings file that has been somehow renamed into the v3 format. Under v3+, the settings need to be inside a 'Settings' tag. I would expect the engine is quietly ignoring all the other settings in the file, which at a glance seem to more or less align with their default values anyway. The v1 settings file tended to include setting values that hadn't changed from their defaults, where the v3 one is much more concise.
spolonski
#13 Posted : Tuesday, February 24, 2026 6:54:06 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 7/11/2016(UTC)
Posts: 53
Location: Germany

Thanks: 7 times
Was thanked: 7 time(s) in 7 post(s)
The Setting Preload assembly references didn’t change the exception behavior. I did migrate the project from NUnit to xUnit (AI did this automatically), and that’s when I noticed that another assembly couldn’t be loaded because it wasn’t signed.

Thanks for helping me investigate the issue.
1 user thanked spolonski for this useful post.
Remco on 2/24/2026(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.061 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download