I see you're linking against xunit.runner.utility so there's likely a conflict there, since xunit.runner.visualstudio also includes that and copies it into your output folder: https://github.com/xunit/visualstudio.xunit/blob/26ed962977078c0328351a0e3e0c4313ee672bd0/src/xunit.runner.visualstudio/build/xunit.runner.visualstudio.dotnetcore.props#L14-L18 That would explain the binary compatibility issue.

So you're probably stuck on xunit 2.4.2 as a result until you move away from .NET 5. I'll add a bug to ILMerge xunit.runner.utility, though that won't help you since that'll be for newer builds (which don't support .NET 5).

xunit/visualstudio.xunit#383

Thanks. Appreciate the help.

@egil So, bad news.

The change I did in 383 broke 3rd party reporters. There's no way for me to reconcile those changes and have third party reporters still work. Here is my description of the problem over there: xunit/visualstudio.xunit#385 (comment)

I think the design of the system today is broken because of this need to share xunit.runner.utility for both runners and runner extenders, because we've made no effort to ensure that we don't have breaking changes between versions of xunit.runner.utility; specifically, we would need a frozen assembly like xunit.abstractions to define the extensibility points here, but the time to do that was about 8½ years ago. The need is the same (frozen contracts) but for different reasons (xunit.abstractions exists as it does today because of the frozen contracts that cross the AppDomain boundaries between the runner and the test execution engine; the hypothetical interface-definition library for third party runner extensibility would need to be frozen so that its contract never changed).

In theory, the problem of how to test a runner from a runner in the past hasn't been an issue, because with AppDomain isolation you could have separate versions of xunit.runner.utility, but that changed with VSTest and .NET Core. No more AppDomains means no more isolation, and since .NET Core unit test projects in v2 are not separate processes, you have this assembly collision. Worse, the compiler can't help you here, because you don't link against xunit.runner.visualstudio; instead, we copy those binaries into your output folder because there's no other way for VSTest to work outside of Visual Studio (inside of Visual Studio, it relies on its ability to traverse your package references via the object model that VS provides, but this capability does not exist from the command line, and definitely not outside of Windows).

So there's no way for me to solve this problem. Unfortunately, I have to re-break you to un-break others. You will be suffering from the same problem I describe in the other issue of conflicting versions of xunit.runner.utility maybe not being compatible. It may work, and it may not; you're basically running a gamble without hard-sticking your xunit.runner.utility dependency to be the exact same version as what's in the version of xunit.runner.visualstudio that you choose to use. I don't know how much that might break the design of bUnit.

Depending on what your consumption of xunit.runner.utility means, you may be able to take the approach I did in 383 and use ILRepack to merge xunit.runner.utility directly into your bUnit libraries, and then the collision disappears (for the same reason as we accomplished in 383, but on the reverse end of the relationship). This would work if the reason you're consuming xunit.runner.utility is to be a runner and not to plug into our runners.

I'm about to commit the revert of 383, which may be useful for you if you wish to go down this path.

Apologies, but there's really no good path here. Someone's gotta break, and undoing the work from 383 at least gives all of us the possibility to start working again, albeit with more work on your end.

@bradwilson, appreciate the effort. Please don't make any changes on our behalf. The part of our codebase that uses xunit.runner.utility is a legacy package we are keeping around for completeness sake, and it could just as well be deprecated and taken out of our build step completely.