I'm happy to announce the release of the first new minor version of NCrunch for this year.

NCrunch v4.7 brings a wide range of small improvements.  It's my hope that this release has a bit of something for everyone.

New Trace Navigation Bar

We've added a new navigation bar to the right side of the trace output in the Tests Window.  This bar can be used to easily find significant points in the trace output, particularly the hyperlinks as generated from stack traces that are dumped out during test execution.

This makes it much easier to find important information when troubleshooting tests with large amounts of trace data.  Clicking on the little black bars will navigate the trace output to the appropriate hyperlink/exception.

New Context Menu for 'Current Line' Actions

For several years now, NCrunch has had a range of contextual actions that can be performed for the line of code occupied by the caret in the VS editor window.

One of the problems with these actions is that it's difficult to remember their shortcut keys, so they tend to be underused.  To help address this, we've added a new shortcut that opens a special menu containing all the applicable actions for the current line of code.  In this way, you only need to remember one shortcut instead of a whole bunch of them.

By default, the new shortcut is Ctrl+M, Comma.  You can also change this to whatever you like in the VS keyboard settings.

Azure Function Project Support

We've added tentative support for Azure Function projects.  Although we'd like to simply say that we support them outright, the reality is that the build system for Azure projects is quite extensive and there are likely to be use cases that we aren't aware of and have not catered for.

At this stage, we cannot promise that we will have full support for Azure-based projects in future.  This will depend heavily on the sorts of problems that get raised with the new handling and whether we can find acceptable ways of solving them.

So if you're running with an Azure Function project and you want to use NCrunch with it, please give v4.7 a try and let us know if you have problems with it.  This is a new area for us and we're doing our best to find a way to make it work.

New Internal Tracing System

NCrunch v4.7 introduces very significant internal improvements in the form of a new engine trace system.

The Old System

Since the first publicly available version of NCrunch, we've had an extensive trace logging system that captures all activity within the engine in text form with the ability to pipe this into the Processing Queue and VS output windows.

This trace data is also stored in an internal buffer that is rolled up into the bug report system so that when people encounter problems, we can trace through the engine behaviour to figure out what happened.  Without this trace system, there is no way NCrunch would have ever become stable enough to be a product people would pay money for.  Over time, many users have also found the trace logs useful when troubleshooting NCrunch or configuration related problems.

The existing trace system works by accumulating trace data in the various NCrunch related processes (devenv.exe, NCrunch.BuildHost, NCrunch.TestHost, etc) then piping this to the engine process (NCrunch.EngineHost.x64.exe) over IPC channels.

The biggest problem with the tracing system is that it's quite expense in terms of resources and performance.  When running at full speed on a system with many cores (or a large grid), the trace system churns out text by the hundreds of megabytes.  Even with sensible limits and optimisation, the trace system is a significant contributor to memory traffic in the NCrunch engine process and it does have an effect on test execution times and the overall responsiveness of the engine.

The New System

We've completely replaced the old tracing system with a new internally developed solution based on shared memory between the various NCrunch processes.

All NCrunch related processes now share a single area of memory.  The log is stored in this memory and is accessible by all processes for both reading and writing.

The new system has the following advantages:

• Because the shared memory exists outside the scope of the .NET garbage collector, it no longer contributes to memory pressure in the NCrunch engine process.
• With very extensive optimisation and concurrency handling, we've managed to remove any noticeable bottlenecks from the system.  No longer will tracing drag on the engine or cause heap compactions.
• Because trace data can now be piped directly from the satellite processes (such as NCrunch.TestHost and NCrunch.BuildHost) into the log, it no longer needs to be serialised over an IPC channel.  This means tracing will no longer impact test or build run times.
• The accumulation of trace data in a shared place makes it resilient to unexpected termination of processes.  If your test process explodes and suddenly disappears, any trace data related to it is still held in the log and will be available in bug reports and the Processing Queue Window.
• As we no longer need to concatenate large chunks of log data, the logs are themselves now properly chronological and are much easier to read.
• NCrunch Grid Node servers will now use the log verbosity as specified by the client when deciding which logs to report back with build/test data.  This means you can now have a grid node server that won't log much for itself but will still provide detailed logs for a client that is trying to troubleshoot a problem.  Note that this won't override the log verbosity for the server when it decides which logs to write to file.
• For better targeting of log data, build logs are now controlled separately via the new Build log verbosity setting.
  

Although relatively simple in concept, I was personally surprised by how hard it was to implement a high performance logging system built on shared memory.  Even simple concurrency scenarios become much harder when the easily available thread-safe options are either too slow or do not work in a multi-process scenario.  Even after 12 years in development, the NCrunch project still provides its challenges!

More Fixes and Compatibility Improvements

As usual, we've included another round of bug fixes and compatibility improvements in NCrunch v4.7.

The most significant fix in this release is targeting an AccessViolationException that can appear in some environments running under .NET5.

We've also replaced the text output control used on the Processing Queue Window, so that this is now aligned with the newer control we built for the Tests Window some time ago.

Check out the full list of changes here, and go grab v4.7!