NCrunch currently ships with xUnit 2.1. xUnit 2.2 contains numerous performance enhancements, over 2.1 -- I would strongly suggest updating to that.
Remco NCrunch Developer
#10014
18 Mar 2017 22:44 UTC
Hi, yes this is on the list of things to address.
Note that if you are using NCrunch with .NET Core, it will always use the version of xunit you are referencing from your test project.
Note that if you are using NCrunch with .NET Core, it will always use the version of xunit you are referencing from your test project.
I saw that there are binding redirects for the desktop version. In consultation with Brad Wilson, we don't think that should be needed and could break things. Runners like NCrunch should be using the xunit.runner.utility library, the abstractions library and that's it -- they should definitely not have any direct dependency on xunit.core or xunit.execution.*. We'd be happy to work offline with you on recommended usage patterns.
Cheers!
Oren
Cheers!
Oren
Remco NCrunch Developer
#10019
19 Mar 2017 07:37 UTC
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.
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.
Edited 19 Mar 2017 07:58 UTC
What you're doing goes against the explicit design goal of xUnit. Runners are not supposed to dictate which version of xunit.core a library author uses. Xunit.runner.utility, is version independent and xunit.runner.utillity 2.1 *can* launch tests against xunit.core 2.2, for example. That's why abstractions exists, to have a locked assembly version with interfaces that are shared across that divide.
NCrunch itself should not depend on xunit.core or execution, for example.
Happy to discuss on Slack if you want: https://xunit-slackin.herokuapp.com/
NCrunch itself should not depend on xunit.core or execution, for example.
Happy to discuss on Slack if you want: https://xunit-slackin.herokuapp.com/
Post a reply
Log in to reply.