Well, I guess the title of this post says it all!  It's time for another NCrunch release, with new features, fixes, and lovely automated testing happiness!

The intention of the 1.41b release is to address a number of niggling usability issues and feature gaps, while still continuing to address general stability and compatibility issues.  The release of the VS 2012 RC also introduced a new range of challenges for NCrunch and 1.41b moves NCrunch a few steps closer to full 2012 support.

Anyway, let's take a look at some of the more prominent features of 1.41b ...

Test Starting Points

NCrunch will now show the starting points of tests inline as a special coverage marker.

So you should now start seeing these little arrows appear next to your code inside your test projects.

How is this useful? This isn't always obvious if you have a suite of fast executing tests and you're running NCrunch in its default engine mode, 'Run all tests automatically'.  After all, the normal coverage markers give you the same options as the little arrows do.

However, if you're using NCrunch in a different engine mode (for example, if you prefer to kick off your tests manually), then you'll probably be familiar with a particularly annoying feature gap that makes it impossible to run a test without code coverage unless you use the Tests Window.  This can be frustrating if you've just written the test and you're looking for some kind of handle next to it in order to kick it off.

The arrows solve this problem very tidily, as they are always visible regardless of whether NCrunch has recorded any code coverage for the tests they represent.  They also work with NCrunch's inline hotkeys, so you can just bash "Ctrl+M, R" when you've positioned the cursor over a new test you want to run.

Pausing for Foreground Builds

One of the biggest features of NCrunch is its ability to run builds and tests in an isolated sandbox without interfering with Visual Studio.  While this works very well in practice, NCrunch is still constantly competing for resources with Visual Studio - especially on slower computers.  This competition can create problems when Visual Studio becomes spontaneously resource hungry, for example, when rebuilding the foreground solution.

Because foreground builds seem to be near infinitely resource hungry, NCrunch will now pause its processing to wait for Visual Studio to finish building before resuming its happy crunching.  You should see this represented in the corner spinner with a little 'Pause' icon.

The lack of background churning should allow foreground builds to complete much quicker, while also reducing the risk of surfacing any isolation problems that may exist in the build process.

Code Coverage Suppression

One of the biggest requested features for NCrunch over the last few months has been for the ability to turn off code coverage analysis for selective regions of code.  1.41b now allows this through the use of inline comments.

By specifying the 'ncrunch: no coverage start' and 'ncrunch: no coverage end' comments around the block of code, you can effectively tell NCrunch not to instrument this code or analyse it in any way.

You can also turn off code coverage for a single line only by ending the line with an inline comment that doesn't have the start/end keyword.  For example: //ncrunch: no coverage

Code that is marked in this way will not be considered for the metrics shown in the NCrunch Metrics View.  Because the code isn't instrumented, it should also execute faster, which makes this a useful way to improve NCrunch performance by sacrificing code coverage inside particularly CPU heavy loops of code.

The notation is also language agnostic, so VB developers can simply use VB comment syntax, i.e: 'ncrunch: no coverage start

Coverage Marker Performance Aggregation

Since early this year, NCrunch has had the ability to profile code to measure its performance under test.  This performance has always been shown with the useful 'hot spot' indicators atop the code coverage markers.  However, it hasn't been possible to completely control how the hot spots are calculated.

1.41b introduces a new global configuration option, 'Marker performance aggregation type', which allows you to choose the aggregation function used to calculate the saturation of hot spots.

This means you can now adjust the hot spot behaviour to make performance issues more visible on solutions with an unusually high coverage density (as previously the hot spots would only be calculated using the 'Average' type).

Improved Configuration Property Editors

NCrunch 1.41b includes some badly needed improvements to the 'Additional files to include' property editor inside the configuration pane.  The new editor is more friendly and harder to make mistakes with.

Other property editors have also seen some work, such as the selection dialog for the 'Workspace base path'.

Task Runner Process Memory Limits

As part of the neverending quest to keep NCrunch's memory footprint as small as possible, 1.41b includes two new global configuration options of interest:

'Build process memory limit' and 'Test process memory limit'.

The options can be used to configure NCrunch to enforce a limit to the amount of memory that can be consumed by build and test processes before the processes are automatically recycled by the engine.  This is particularly useful if you are making use of build tasks or tests that leak memory over time.

Note that NCrunch will only enforce memory limits passively on completion of task execution, so you won't see it interrupt the execution of memory gobbling tests.  This makes these options useful only for solving problems with accumulated memory utilisation rather than policing test behaviour.

New Installer

I know this is probably background news to many people, but 1.41b includes a complete rewrite of the MSI installer.  The new installer isn't able to automatically remove old versions of NCrunch, so you'll need to uninstall these manually using the Add/Remove Programs dialog before you can upgrade to 1.41b.

Other Stuff

There's lots more in the 1.41b release that isn't shown here.  1.41b contains 25 distinctive fixes and compatibility improvements, making this a very worthwhile upgrade if you're serious about a stable development environment.

Anyway, quit reading blogs and start playing with the new build!