Parent: Assemblyloading failures in Version 6.0

[OsirisTerje]

This is a parent issue for all the assembly loading issues in version 6.0

Some issues have been moved to the NUnit.Console project:

✅ 1797 Issue with assembly load context changes in NUnit3TestAdapter v6 & Microsoft.Build.dll dynamic loading
✅ 1796 Assembly load logic changes in v6
✅ 1795 🧪 Assembly loading move to AssemblyLoadContext for net8 and higher (3 of 4 works, 1 not fixed)

@CharliePoole @manfred-brands @stevenaw

Repro projects

Issue	Link repro project	Status 6.0.1	Status 6.0.2
#1374	https://github.com/nunit/nunit3-vs-adapter.issues/tree/master/Issue1374	Fixed	Fixed
#1371	https://github.com/nunit/nunit3-vs-adapter.issues/tree/master/Issue1371	Repro fail, but target sln works	Fixed
#1375	https://github.com/nunit/nunit3-vs-adapter.issues/tree/master/Issue1375	Reproduces the error	Fixed
#1795	https://github.com/SimonCropp/NunitAdaptorAssemblyLoadingRepro	3 out of 4 works	Fixed
#1389	https://github.com/glennawatson/NUnitDoubleUpAssemblyIssue	Reproduces the error	Fixed
#1348	https://github.com/nunit/nunit3-vs-adapter.issues/tree/master/Issue1348		Fixed

[CharliePoole]

My suspicion is that man of these have to do with how the engine resolves dependencies. So, as a start, I've identified the code changes between engine version 3.18.1 and 3.21.0, which may be summarized at a very general level as follows:

1. The same approaches to resolution are used in both versions.
2. In 3.21.0, the various approaches are formalized as strategies and there is logging of which strategy succeeded in resolving a reference.
3. In 3.21.0, the direct references of the target test assembly are examined to determine if either the WindowsDesktop SDK or the AspNetCore SDK is used. If either is used, the corresponding strategy is tried first. In contrast, version 3.18.1 always tried these additional SDKs last.

It seems likely that item 3 is the source of change that is affecting some folks. This change in order of application was introduced to resolve issues where the corresponding Microsoft .NET SDK assembly contained no implementation and also to improve performance.

An important note: this is all speculative based on examination of the differences between the two versions of a single file. Each individual issue still will need to be examined in detail.

[OsirisTerje]

@CharliePoole

I have a working repro here: https://github.com/nunit/nunit3-vs-adapter.issues/tree/master/Issue1371

That also includes a README.md that summarizes the issue (thanks to Claude for helping out with that), and suggested resolutions.

In this specific case (#1371) the problems comes from AppInsights 2.23 which drags in the older 2.X assemblies, and the up coming 3 version - which supports net8+ properly, is still in beta. In the other cases we have, I would assume there are similar issues.

The engine issue is that it loads the assemblies in its own isolated context, and thus ignores the context of the running app under test - which have resolved these dependencies properly. Details in the readme.

To fix it, I believe Option 1 there is the easiest way to go, reuse the Default context.

[Sebazzz]

I ran into something similar in my tests. For some reason, in my .NET 10 app, the 3.x version of Microsoft.AspNetCore.Components.Forms was requested which was then resolved by NUnit's TestAssemblyLoadContext to the oldest version I have on my system (which is 5.x, because I happened to still have the 5.x .NET SDK installed):

I was able to work around by running this code early in the test assembly execution (for instance a static constructor or module initializer):

Assembly assembly = typeof(Microsoft.AspNetCore.Components.Forms.EditContext).Assembly;
TestContext.Progress.WriteLine($"Loaded assembly: {assembly.FullName}");

[OsirisTerje]

@Sebazzz Can you try https://www.nuget.org/packages/NUnit3TestAdapter/6.0.1-alpha.6 ?

[christianheld]

I have experienced similar assembly loading issues in my project and with version 6.0.1-alpha.6 everything works again 🎉

[Sebazzz]

Yup that did it! Very curious to learn what the fix is! Met vriendelijke groet, Sebastiaan Dammann

…

________________________________ Van: Christian Held ***@***.***> Verzonden: Friday, December 19, 2025 3:32:57 PM Aan: nunit/nunit3-vs-adapter ***@***.***> CC: Sebastiaan Dammann ***@***.***>; Mention ***@***.***> Onderwerp: Re: [nunit/nunit3-vs-adapter] Parent: Assemblyloading failures in Version 6.0.0 (Issue #1376) [https://avatars.githubusercontent.com/u/11472622?s=20&v=4]christianheld left a comment (nunit/nunit3-vs-adapter#1376)<#1376 (comment)> I have experienced similar issues in my project and version 6.0.1-alpha.6 solved the issue 🎉 — Reply to this email directly, view it on GitHub<#1376 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAK4FMIEQKZC5GBR6RWMBAT4CQEBTAVCNFSM6AAAAACOWSN7BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZVGI4TIMBUGU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[OsirisTerje]

Awesome!

Very curious to learn what the fix is!

It was in the engine loading, and usage of the AssemblyLoadContext. @CharliePoole wrote about it in the engine somewhere.....
It seems to cover 80% of the cases, so we might still have a bit to go. But it may be enough for a release.