There's a new version of NCrunch that's been in the oven for a few months now.  I'm very excited about this version as it introduces a number of important structural changes to NCrunch's internals that have been long overdue - more specifically, introducing the ability to host the engine itself outside the IDE process, communicating with devenv.exe through IPC.

So why is this so important that it needs to happen before other features?

Well, because Visual Studio is a bit of a monster.  It's a very, very complex process containing lots of interactions between many very different pieces of software, written by different teams working in different companies.  VS has its roots in unmanaged code hooked up through COM, and this history no doubt makes life very difficult for the people at Microsoft moving the core of this product forward.  Every successive release of Visual Studio introduces new demands on system resources, including higher memory utilisation and more memory traffic.  This isn't helped by tools such as NCrunch, which also eats its own share of resources out of poor devenv.exe.

One of the biggest problems facing the future of VS development lies in the fact that it is still a 32-bit process.  This process has been compiled as a Large Address Aware (LAA) application allowing it a higher memory ceiling, but its memory address range is physically limited to 3GB regardless of the capabilities of the host machine.  Once memory allocation reaches around 2.7GB, instability and OutOfMemory exceptions appear.  This creates a hard limit that needs to be respected by the VS teams and all VS tool developers.

I don't doubt that at some stage Microsoft will work some magic and manage to get VS to run in x64, but unfortunately this isn't the only problem we have with trying to do so much in one process.

If you've ever tried to use Visual Studio with many other plugins (including NCrunch), you may at some stage have had some annoying and seemingly random jarring in the UI while working.  The first thing many developers will think when they see this is that something in VS (likely a tool or 3rd party package) is over-consuming processing on the UI thread.  While this is certainly possible, most VS package/plugin developers are well aware of how precious the UI thread is inside VS and will usually take steps to stay off it as much as possible.  The jarring is most likely to be caused instead by memory traffic.

Memory traffic exists inside every .NET application.  It's basically caused by allocating and deallocating objects.  Most of the time this is no big deal, but when the number of allocations reaches a certain threshold, .NET's garbage collector needs to perform heavy compactions of the heap to keep its size under control.  These compactions cannot always be performed in the background - they can require the UI thread to be locked.  This means that the 'jarring' you are experiencing in the IDE is likely to be the result of the combined memory traffic of VS and every plugin/package you have installed.

So anyway, hosting the NCrunch engine outside the IDE allows it to have a higher memory ceiling (important for really big solutions), and will also prevent it contributing to VS memory traffic problems.

Does this mean that you're opting for the lazy approach instead of keeping NCrunch's resource utilisation under control?

Absolutely not.  Resource utilisation has always been a huge issue for NCrunch and similar tools.  It is always a design goal to keep both memory and CPU utilisation as low as possible while maximising throughput and feature set.  Every version of NCrunch introduces new optimisations and improvements to improve speed and reduce memory footprint.  2.11 will be the leanest build yet.

Unfortunately resource utilisation does also need to balanced against complexity and feature set.  Allowing NCrunch to have a higher memory ceiling creates the opportunity to have new optional features that may require more memory in exchange for greater productivity payoff.

What other advantages go with separating the engine from the IDE?

Stability! When NCrunch lives inside the IDE, its fate is tied to that of the IDE process.  If VS crashes, NCrunch goes down with it - taking all its recent metrics data with it.  If NCrunch crashes, it takes VS with it .. that isn't good for anyone.

Now, when VS crashes, NCrunch still has time to perform a clean exit - saving any data to disk and shutting down nice and tidy.

.. and when NCrunch crashes, all you need to do is re-enable the engine from inside Visual Studio.  No restarts required.

Is there a performance penalty involved in hosting the engine outside the IDE? (i.e. IPC overhead)

Yes, but this is not significant enough that I expect people will notice it.  The biggest challenge in making 2.11 work outside the IDE was optimising the engine so that it would exchange the absolute minimal amount of data necessary to make the NCrunch UI work.  This involved rebuilding many of the connections between the engine and the UI, creating plenty of opportunities for performance optimisation.  This optimisation has more than made up for any data exchange penalties and I expect that many people will find 2.11 works much better on large solutions while working with the NCrunch UI windows open.

What if I still want to host the engine inside the IDE?

Then you can.  It's entirely configurable.  NCrunch 2.11 has a new global configuration option - 'Engine hosting strategy'.  Changing this setting allows you to control how the engine is hosted.

By default, NCrunch will host the engine in a satellite process.  This can be either an x86 process (with a 2GB memory limit) or an x64 process (with a super-high memory limit).  x86 hosting is still necessary for some users that don't have x64 systems (really!?) and for those working on machines with very low physical memory available.  The x86 hosted option has a somewhat smaller memory footprint because .NET objects under x86 have a smaller allocation size.  NCrunch will default to x86 for machines that have less than about 5GB of RAM.

Does this mean that we'll see NCrunch support for other IDEs?  Will I see NCrunch working with Notepad?

While it's true that physically hosting the engine outside VS has enabled abstractions that make support for other hosts much easier, I don't see NCrunch escaping from VS any time soon.  Visual Studio is the development environment for the MS tool stack.  We rely on it not only for its feature set, but also the assurance that it sits right in the path of future MS development.  It would be very unfortunate to invest time in making NCrunch work with a different IDE only to have Microsoft release a new toolset that this IDE couldn't handle.

Can I use 2.11 with VS2015?

Yes.  2.11 is the first build of NCrunch to have an installer for VS2015.  I'm hesitant to say that it supports VS2015, just because VS2015 is technically still under development and is only in a preview state.  Early testing has been very encouraging.  2.11 does also integrate with the new version of MSBuild, so you can start using CSharp 6 features in NCrunch!

When will I see 2.11?

At the moment I'm expecting a proper release with ceremony early in the new year, probably in the first couple of weeks of January.  Meanwhile, there is an early build available for anyone that wants to give it a try:

http://downloads.ncrunch.net/NCrunch_Console_2.11.0.12.msi

http://downloads.ncrunch.net/NCrunch_Console_2.11.0.12.zip

http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.11.0.12.msi

http://downloads.ncrunch.net/NCrunch_GridNodeServer_2.11.0.12.zip

http://downloads.ncrunch.net/NCrunch_VS2008_2.11.0.12.msi

http://downloads.ncrunch.net/NCrunch_VS2010_2.11.0.12.msi

http://downloads.ncrunch.net/NCrunch_VS2010_2.11.0.12.zip

http://downloads.ncrunch.net/NCrunch_VS2012_2.11.0.12.msi

http://downloads.ncrunch.net/NCrunch_VS2012_2.11.0.12.zip

http://downloads.ncrunch.net/NCrunch_VS2013_2.11.0.12.msi

http://downloads.ncrunch.net/NCrunch_VS2013_2.11.0.12.zip

http://downloads.ncrunch.net/NCrunch_VS2015_2.11.0.12.msi

http://downloads.ncrunch.net/NCrunch_VS2015_2.11.0.12.zip