FileLoadException for NUnit 4.3.2: System.Buffers 4.0.4 missing

[SFrank1966]

We encountered the same problem as in fixed issue 4887 still with version 4.3.2 of NUnit. Our nightly build on the Devops stops some of the unit tests with the missing System.Buffers 4.0.4. Looking at the Nuget-package of NUnit 4.3.2 with dotpeek, you can see dependencies to System.Buffers 4.0.4 and System.Memory 4.0.2. I attached an image with the dotpeek output.

[mikkelbu]

Relates to #4887

[stevenaw]

@manfred-brands has pointed out that a newer version of System.Buffers has been released which could be causing conflicts again

Up to now we've been suggesting tackling this via assembly bindings. One option raised in the linked issue is if we continue to keep a direct reference on this dependency. Another idea: have we considered specifying this dependency as a ranged version? I haven't validated this as an option yet myself but may have time to tomorrow.

@nunit/framework-team If a change is made to fix this then I assume we want to try to get it into 4.4?

[manfred-brands]

Another idea: have we considered specifying this dependency as a ranged version? I haven't validated this as an option yet myself but may have time to tomorrow.

Range version are only checked at compile time and do not affect runtime.
We don't have a compile time problem, but a runtime problem.
See redirect-assembly-versions

When specifying "4.6.0" we allow >=4.6.0 our binaries get a hard-reference to "4.6.0"
It means that if the users specifies a version <4.6.0 you get a build error saying that nunit needs at least 4.6.0.
But often then the user version is upgraded to the latest required unless specifically disallowed.

When specifying "[4.6.0, 5.0.0)", we allow >=4.6.0 and < 5.0.0, our binaries are still compiled against "4.6.0".
It means that if the users specifies a version >5.0.0 you get a build error saying that nunit doesn't allow >5.0.0.

Microsoft discourages the use of upper range for packages we don't control.

If the user uses 4.6.1 and we have a dependency on 4.6.0 the only way the user can solve this is with a binding redirect.
If the user target is an executable, the compile automatically generates binding redirects.
However this is not done for library targets because those are not "runnable"
At my work, our build script copies the auto-generated ".exe.config" to all ".dll.config" files so we can nunit test the libraries.
See redirect-versions-for-tests-plugins-or-libraries-used-by-another-component

[stevenaw]

Ah. Thanks for confirming that @manfred-brands . That saves me from investigating it myself

[OsirisTerje]

@manfred-brands

We might want to reconsider removing this dependency

You mean we should not include the dependency in the package ?

That would mean that users would have to include that themselves, which would be very confusing too.

[OsirisTerje]

@SFrank1966 Just looked at the package with dotPeek, and I don't see the same as you do:

[manfred-brands]

@manfred-brands

We might want to reconsider removing this dependency

You mean we should not include the dependency in the package ?

That would mean that users would have to include that themselves, which would be very confusing too.

No, I mean not needing the dependency in nunit. If we only use it for ArrayPool we can replace that.

[OsirisTerje]

Thanks for the clarification @manfred-brands . If we can do that, I think we should. That would solve all these issues and also reduce the overall dependencies we have.

[SFrank1966]

Thank you all for your helpful comments.
I've checked our projects again to find a possible direct reference to System.Buffers or System.Memory, but I've found none. But when I clear the binary folder, restore the Nuget packages and do a rebuild, I get very old assemblies of System.Buffers and System.Memory.
System.Buffers is from 19.02.2020 , filesize 20.856, file version 4.6.28619.1,
System.Memory is from 08.05.2022, filesize 142240, file version 4.6.31308.1.
So it seems that we have indirect references to these assemblies which may cause the problems.
I will do some further investigations to clarify this.
Temporarily, we switched back to NUnit 4.1.0, which has no references to System.Buffers and System.Memory, so the tests are running properly.

[manfred-brands]

I found an alternative to MemoryExtensions.SequenceEqual which is Array.SequenceEquals.
Benchmark results show performance is similar:

| Method             | Size  | Mean     | Error     | StdDev    | Ratio |
|------------------- |------ |---------:|----------:|----------:|------:|
| Original           | 32768 | 9.461 us | 0.0501 us | 0.0444 us |  1.00 |
| Vectorized         | 32768 | 1.549 us | 0.0246 us | 0.0293 us |  0.16 |
| ArraySequenceEqual | 32768 | 1.600 us | 0.0152 us | 0.0135 us |  0.17 |

This then brings us to new byte[] vs ArrayPool.Rent vs LocalPool, where the latter is a private pool only used for StreamsComparer.

| Method          | Size  | Mean     | Error     | StdDev    | Ratio | RatioSD |
|---------------- |------ |---------:|----------:|----------:|------:|--------:|
| NewByteArray    | 32768 | 1.575 us | 0.0309 us | 0.0317 us |  1.00 |    0.03 |
| StackAlloc      | 32768 | 1.273 us | 0.0169 us | 0.0150 us |  0.81 |    0.02 |
| ArrayPool       | 32768 | 1.163 us | 0.0089 us | 0.0079 us |  0.74 |    0.01 |
| StreamLocalPool | 32768 | 1.306 us | 0.0083 us | 0.0073 us |  0.83 |    0.02 |

[mikkelbu]

@SFrank1966

I've checked our projects again to find a possible direct reference to System.Buffers or System.Memory, but I've found none. But when I clear the binary folder, restore the Nuget packages and do a rebuild, I get very old assemblies of System.Buffers and System.Memory.

After a restore of nuget packages you should have a project.assets.json file in the obj folder. In this file it should be possible to see the (recursive) references to the nuget packages