Hi Oren,
The binding redirections were needed because the xunit components have been split between libraries, for example, there is xunit.core.dll which is the assembly used for attribute declarations, then there are xunit.abstractions.dll and xunit.execution.desktop.dll for the runtime execution.
This creates a problem, because a user can have a reference to xunit.core.dll without either of the other components present. This meant that the other xunit components had to be distributed with NCrunch itself, which opened the door to potential cross version issues (i.e. if the user is making use of xunit.core.dll v2.2 while the other binaries shipping with NCrunch are v2.1).
The above problem doesn't exist under .NET Core, because this works using package references that ensure all xunit runtime libraries are installed on the dev machine. This allows NCrunch to just use whatever the user feeds it, so everything is consistent. I expressed my reservations about the splitting of functionality between xunit libraries in the early stages of xunit integration (other frameworks use a single library), though I think I raised this either too late or there were reasons for why it couldn't be changed.
When I introduced the integration with xunit v2 3 years ago, integrating directly with xunit.core/xunit.execution proved to be the most effective way to make NCrunch work with xunit. Because this was quite some time ago, I don't remember many of the details behind this reasoning, but I can say that I'm reluctant to redesign the integration with xunit without a very good reason for doing so. The current implementation took several months of hard troubleshooting to get working reliably and with acceptable performance. I'd prefer not to go through that again unless we have a serious functional issue.
