I'm happy to announce the release of NCrunch v5.21.

While mostly a maintenance release, this new version also includes a niche feature area that may appeal to people running large tests in resource constrained environments.

Control Cores Used For Test Execution

The Control Cores Used For Test Execution setting defines a new mode of operation for the NCrunch engine, in which the engine will attempt to control the CPU cores on which test code will run.  In this way, tests are allocated fixed CPU resources for their execution, rather than relying on the O/S to pool CPU resources across all runner processes.

This approach comes with both advantages and disadvantages.

A test that has been allocated a CPU core will be limited by it and all threads underneath the test will be scheduled to run on the same core.  This helps to prevent overstepping, where a test would otherwise be able to take over all CPU resources on the system, causing resource starvation and timeouts.

The main drawback of this approach is that is can cause underutilisation.  Tests that might have all their threads in a waiting state won't use the entire core they've been allocated, which might otherwise have been available for other tests that could make use of it.

So enabling this setting could be expected to improve the predicability of testing cycles, while also reducing the throughput of the engine.  It may also offer some potential for performance improvement in NUMA based environments, though this is largely theoretical and will likely be extremely context-specific.

This setting is relevant in the global and grid node levels only.  I realise this is somewhat limiting, as it would be more useful to also be able to configure it at solution level.  However, I couldn't find a practical way to make it work in this way due to it being impossible to design a grid node that could cater for clients connecting with different values for this setting.  If the setting proves popular, maybe I can find a way to have a solution-level option that isn't used for distributed processing.

I'll note that NCrunch's implementation of this setting is best effort only.  The design of the Windows operating system makes it impossible to fully control all processing activity on the system, and the APIs used to control core affinity have serious limitations that require some degree of compromise.

I strongly recommend having a read of the documentation for this setting before you put it to use.

JetBrains Rider 2026.1 Support

NCrunch v5.21 introduces support for Rider 2026.1.  This was a relatively straightforward upgrade with minimal changes necessary, so I'm hopeful there won't be any unexpected issues.  As usual, note that NCrunch only supports the latest version of Rider at the time of its release, so v5.21 will work only on Rider 2026.1.

Discontinued Support for Visual Studio 2010-2015

Those paying close attention to the download options for v5.21 will notice that this is the first release of NCrunch that does not have support for versions of VS prior to 2017.

Although I'm not particularly happy about discontinuing support for these older IDEs (it took a lot of effort to introduce it!), I've eventually come to accept that the cost of maintaining integration with them is no longer worth the effort.

Very few people still use these older IDEs, and the ones that do can still be well serviced by v5.20 of NCrunch, which will remain accessible on the download page of this site.

Maintaining support for these IDEs complicates many areas of NCrunch, particularly around the management of test environments.  Microsoft no longer support these IDEs or platforms they run on, so the only way to test for them is to lean on decaying environments running ancient (and often insecure) versions of software.  Pulling the plug has allowed me to upgrade NCrunch's test infrastructure to improve reliability and performance.  It also means that I won't need to implement complex workarounds for features and fixes that might need to work differently for older VS versions.

I apologise to anyone impacted by this, but please understand that eventually things need to move on.

Lots of Fixes

A lot of fixes have been rolled into the new version.  Most of these are targeted to Rider, but there are also some important improvements that are relevant to Visual Studio.

See here for a full list of changes.  V5.21 is available here.