nunit
Assembly load logic changes in v6
Related to https://github.com/nunit/nunit-console/issues/1795 and https://github.com/nunit/nunit3-vs-adapter/issues/1348 probably.
There is another nasty behavior change in assembly loading.
We use CoreWCF in tests and because it targets netstandard2.0 it references very old version of AspNetCore (2.3.0).
With 5.2.0 adapter required assemblies were loaded from currently executing runtime. E.g. we run tests with .net 9 and Microsoft.AspNetCore.Http.Features.dll loaded using 9.0.11 version instead on 2.3.0
With 6.0.0 adapter instead of using current runtime version it loads lowest available version in c:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\ which was 6.0.36 in my case. After I removed it (I don't need net6 anymore) it used next available version (8.0.22) which I cannot remove as I need it.
It doesn't sound too bad, but problem is that it crash in Kestrel later trying to load v9 version of same assembly:
System.IO.FileLoadException: 'Could not load file or assembly 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\9.0.11\Microsoft.AspNetCore.Http.Features.dll'. The requested assembly version conflicts with what is already bound in the app domain or specified in the manifest. (0x80131053)'
As workaround I've added assembly load statements to test assembly OneTimeSetUp method for all incorrectly loaded assemblies, but I prefer old version selection behavior, as new one doesn't make any sense and just doesn't work.
I believe this is also an engine behavior change, so I'll transfer this issue also over to the engine.
Code to reproduce
using CoreWCF.Configuration;
using Microsoft.AspNetCore.WebUtilities;
using Microsoft.Extensions.DependencyInjection;
using NUnit.Framework;
public class TestFixture
{
[Test]
public void Test()
{
MultipartReader xx = null!;
var services = new ServiceCollection();
// use Modules window to see that after this line older runtime libraries loaded
ServiceModelServiceCollectionExtensions.AddServiceModelServices(services);
}
}
@MaceWindu Thanks for the repro... I'll try to make it work with the engine directly, without involving the adapter, and debug through it. The 5.2.0 adapter used version 3.18.1 of the engine, so unfortunately the error isn't necessarily in the most recent engine release.
