I'm happy to announce the release of NCrunch v4.17.  This is mostly a maintenance release, but we also slipped a few new things in here.

UsesThreadsAttribute

We've now introduced a new attribute that lets you control the number of threads a test is expected to use when it executes.

When this attribute is specified on a test, NCrunch will internally mark this test as requiring a specific number of processing threads for its execution.  When the test is run, these threads will all be reserved from the processing queue, allowing the test to use additional space in the queue.

This attribute is important when working on large codebases with big integration tests that may eat more than their fair share of system resources.  In such a situation, failing to declare these tests according to their size can result in system-wide CPU starvation, causing tests to time out intermittently.

NCrunch's utilisation of this attribute is respective of distributed processing.  When a node picks up a test requiring additional threads, the test will appropriately consume more of the runners on the node.

If you have a test marked to use more threads than are available on any machine in your grid, the test will never run automatically.  However, it can still be run on your local machine with targeted manual execution.

The attribute can be applied at test, fixture or assembly level.  It only exists in NCrunch.Framework v4.17 and above, so you'll need to update any references you have to this package before using the attribute.

Since the number of tasks being processed and number of threads in use are now not the same thing, the engine corner status window has been updated to give better indication on the number of threads being used.

.NET Framework v4.8.1

NCrunch v4.17 introduces support for .NET Framework v4.8.1.  Yes, we are late on this one, but there are reasons for this.

.NET Framework v4.8.1 only supports newer versions of Windows (20H2 and above).  This was a major problem for us, as we self-host much of our own infrastructure, and we've been reliant on a server built back in 2014 for critical parts of our own build and release system.  Naturally, such a server would never be able to build v4.8.1.  The best option available to us was to fully replace the machine and rebuild our internal systems. 

As we support all versions of VS released in the last 13 years, our build system is very complex, so this has not been a small project.  Not helping this were the deteriorated supply chains going into New Zealand (probably due to COVID hangover), which meant we had a 5-month wait for the hardware to arrive.

The good news is that we're back up and running again with a new, much higher capacity build system that can also build and test .NET Framework v4.8.1 projects.

The new server has also helped us to identify a few scalability issues related to NCrunch grid nodes being installed on high-CPU machines.  As such, we have a range of grid scalability improvements included in v4.17.

NCrunch V5

We're in the late stages now of our development on V5.  By an order of magnitude, V5 will be the largest release in the history of NCrunch.  It's our hope that v4.17 will be the last minor release before we get to show V5 to the world.  We have already been dogfooding many of the features of V5 internally, and we're very excited about this release.  I'll be releasing more information about what's included in V5 as we get closer to the drop.

Anyway, I recommend checking out the full list of release notes for v4.17.  You can download it here.