NCrunch v5.11 is now available for download.

JetBrains Rider 2024.3 Support

This build extends support to the Rider 2024.3 release that went out a few hours ago.  2024.3 contained several breaking changes and it took a bit of effort to bring us into alignment, so there's no way of running this version of Rider without an NCrunch update.  Note that each NCrunch build is only intended to target a single version of Rider, though in some cases we are able to support a range of versions depending on what has changed between them.

When running with Rider, you should always install the version of NCrunch that has been marked as tested against that particular version (this is noted on the NCrunch download page).  If you are installing NCrunch via the JetBrains Market, this should be resolved automatically.

Visual Studio 2022 17.12 Support

This week also saw the release of another version of VS, which includes the introduction of .NET 9.0.  We've been forwards compatible with .NET 9.0 for a while now, though prior to VS 17.12 hitting RTM, it was necessary to make a configuration adjustment (Build SDK) for this to work reliably with NCrunch.  Now that 17.12 is properly released, this adjustment should no longer be needed.

17.12 saw some internal changes in how previously opened tool windows are initialised during IDE startup, which required a fix from NCrunch's side.  Earlier versions of NCrunch should also work with 17.12, but you'll need to close and reopen your tool windows if you open a solution directly without going through the IDE's startup solution selection screen.

Xunit v3 Adjustments

NCrunch v5.11 saw some changes in how we handle integration with Xunit v3.  Previously, we were packaging the Xunit runner binaries with NCrunch and relying on these to interact with the Xunit binaries being referenced from open test project(s).  This created a problem when the packaged binaries were not the same version as the version of Xunit being targeted, which could cause instability inside Xunit, usually resulting in weird errors or tests not being discovered.

Under v5.11, we no longer distribute Xunit binaries.  Instead, we fish them out of the Nuget package cache directory on the machine responsible for executing tests, according to the version being referenced by the test project.  In this way, the versions are always consistent and we shouldn't have instability.  The drawback of this approach is that it will only work if the Xunit runner binaries are installed in the package cache.  To mitigate this issue, our change has been matched on the Xunit side where the runner binaries should now always be resolved and installed along side the xunit.v3.core package.

It's important to note that if the above setup doesn't work for you, it's still possible to force NCrunch to resolve Xunit v3 binaries by simply adding an assembly reference to them.  Assembly references will always take precedence over package cache resolution.

NCrunch's integration with Xunit v3 is late bound and is not statically tied to any version.  This means that as long as the Xunit v3 APIs stay stable (which they generally do), NCrunch should be both forwards and backwards compatible with all versions of Xunit v3 from the upcoming RTM release onward.