I'm happy to announce that in about a month, we'll be releasing a version of NCrunch that is fully integrated with JetBrains Rider.

Right now we have an internally functional build that is near feature parity with NCrunch under Visual Studio.  It builds projects, runs tests, reports coverage and works with all the engine features under the hood (such as distributed processing, performance tracking, etc).  We need a few more weeks to iron out some rough edges and set up a release system that will allow us to quickly deploy and manage builds that are aligned with the latest version of Rider.

Why was this such a challenge?

JetBrains Rider is a fusion of two very different products - IntelliJ IDEA and ReSharper.  IntelliJ IDEA is a JVM based application and ReSharper runs on .NET.  JetBrains bridged the two products using IPC over shared memory, allowing them to have an IDE that is fully independent of Visual Studio.

Although integration with ReSharper has been relatively straightforward (owing to both NCrunch and ReSharper being .NET applications), tying our UI into IntelliJ IDEA has been extremely problematic, because our entire UI is built on a fusion of Winforms and WPF, neither of which can run inside IntelliJ's environment.

Compounding the issue is that the performance requirements for NCrunch's UI are extremely strict.  For most applications, it's OK if the UI thread loses 50ms to a quick refresh of a grid control.  Under NCrunch, such a delay can cause a noticeable degradation of IDE performance.  We spent years cycling through off-the-shelf UI controls for NCrunch before eventually writing our own, as we simply couldn't find anything that would perform in just the way we needed it to.

So we have a significant investment in our UI, and replicating its entirety in swing (or something similar) was a pretty daunting task.  Maintaining two separate UIs also would cut into our future development capacity, likely rendering us incapable of adding new features to NCrunch.

Additionally, there are all of the other challenges involved in tying a tool as complex as NCrunch into an IDE, such as consistently synchronising projects and source code, integrating all the menus and actions, tracing systems, and engine lifecycle.

Wormhole and COVID19

Without a feasible way to replicate our UI in IntelliJ IDEA, support for Rider didn't seem achievable for us.  Then we discovered a new tool that the teams at JetBrains were working on to help overcome this problem for .NET based plugins, something called 'wormhole'.

Wormhole allows a plugin in a .NET process to 'beam' its UI through a shared memory pipe directly into the IntelliJ/Rider IDE.  The IDE captures user actions (such as mouse clicks, keystrokes, etc) and then pushes messages associated with these actions back through the pipe so that they can be processed as normal by the .NET process.  As you can imagine, this system isn't simple and when we first started using wormhole, there were still a lot of issues that needed to be solved.  Over time, we worked with the teams at JetBrains as they solved these problems and wormhole is now much more reliable.  We also ended up building our own parallel shared memory pipes for specific elements that we couldn't fit through wormhole.

Overall, this means we can have roughly the same UI experience under Rider as we do in Visual Studio.  It also makes it much easier for us to maintain the UI.

A second thing also happened that made this possible: COVID19.

For all the misery that it brought, the pandemic also slowed down much of the development happening on toolsets we've integrated NCrunch with, particularly in .NET and Visual Studio.  This allowed us to step off the treadmill of platform related maintenance and invest time on building new features into NCrunch.  I don't have a way to know if we could have integrated with Rider had COVID19 not happened, but I can say that in the 2 years following its outbreak, the platform changes did slow down.  The home schooling definitely didn't help though.

.NET 6 Issues

Something that tripped us up late in the process was the sudden need to migrate the entirety of the NCrunch engine (a .NET Framework v4 application) to run on .NET 6.  Because we built the engine to be hosted under older versions of Visual Studio, we're effectively stuck on older technology.  Most of the components of NCrunch responsible for test execution are built to run on .NET Framework v3.5 (which dates back to 2006), because we need to support customers that use NCrunch to maintain old systems.  The gap between .NET Framework v3.5 and .NET 6 is massive and includes a wide range of differences - most of which are only found through trial and error.

Of course, it also hasn't been just a migration for us - we still need to maintain support for hosting under older versions of .NET, so the entire engine is now cross-compiled and maintained for both NET6 and .NET Framework v4.  Additionally, we now cross-compile and maintain all test execution components for 3 different toolsets (.NET6, .NET Framework v4, and .NET Core 1.0!).  These components all need to be compatible with one another (for example, we might have a NET6 engine that runs tests that are built for .NET Framework v4, or vice versa).

This was going to be necessary for the next version of Visual Studio anyway (VS2024?), but as JetBrains began migrating ReSharper during our development, it jumped on us early.  The good news is that it should make handling the next version of Visual Studio much easier.  We now also have the ability to integrate with versions of MSBuild that are hosted in .NET6 or later.

Why do this quiet?  Why not tell everyone sooner?

There's a couple of reasons for this.

Firstly, from the outset, we didn't know if it would actually be possible for us to deliver this.  We spent the first year of this project navigating a maze of dead-ends and disappointment.  Because we didn't have the JVM experience in-house, we needed to contract outside support to help us find options for the integration.  Eventually, we did get a solution that we are very happy with, but it wasn't until about 18 months of development that we had any level of expectation that we could achieve what we wanted.

Secondly, once we became more confident that we could actually do it, we had absolutely no idea how long it would take.  There was no basis on which we could form estimates on the effort required to fully integrate with Rider, and the cost of maintaining our existing software on an evolving platform is something we can never accurately predict.  At any time, a platform change could pull us away from the project for 2 months, stretching the timeline further.

All the data I have available to me says that support for Rider is the most desired feature for NCrunch.  Imagine having thousands of people wanting something very badly, knowing that you are working on it, and being unable to tell them when you can ship it.  Then imagine it taking 3 years to get there.  This was something I very badly wanted to avoid.

Of course, the fact that we've been working on this is probably the worst kept secret in the history of badly kept secrets.  Up until now, we've never confirmed it, but everyone still expected it.  We couldn't reputably ship V5 without Rider support, and I think everyone knew that.

When can we use Rider with NCrunch?

Right now our integration with Rider is in an alpha state.  We don't have any critical issues left, but we have a lot of niggling ones that are detrimental to the UX.  We also don't have a proper deployment system that we need for publishing the software.

We need a month to iron out some of these issues so the product doesn't feel as rough-cut, and to build the deployment system.

I'm sorry that we can't ship this right now.  You've been patient for a long time.  I will ask for one more month of this patience.

What else is shipping with this?

Support for Rider is one of the two major features forming NCrunch v5.  We also have another feature that we've been working on over the same timeframe which will be present in both the Visual Studio and Rider plugins.  This concept for this feature predates the work I've done on NCrunch v1 and actually goes back to 2009, but it wasn't achievable until modern hardware became available and it requires the entirety of NCrunch's infrastructure to properly function.  You could call it the overall goal of the project.  I'm extremely excited about this feature and will be revealing more about it as we get closer to the V5 release next month.

Edit: This won't include support for MacOS or Linux

As much as we'd love to be able to run NCrunch on non-windows OSs, sadly we are heavily reliant on old Win32 to make things happen right now.  We could probably abstract away much of this and lean on .NET's new cross platform capabilities, but unfortunately this won't solve our problem of needing to port our Winforms/WPF UI.

The wormhole technology we're using to beam the UI into Rider won't work outside Windows as we still need to have a process that can render on Win32.

This means right now we don't have a clear path to allowing us to run on non-windows OSs and no timeline for it exists.  Sorry.

Introducing v4.19

Although I had hoped that we would release V5 much earlier and v4.18 and v4.19 wouldn't need to exist, the realities of high risk software projects continue to blow holes in all my expectations.  Although we can't ship V5 today, we are at least shipping something!  V4.19 is a maintenance release containing a range of fixes for recently reported problems.  It also includes the NET6 build system integration that we've brought forward from V5, as this is something we can confidently ship now.

v4.19 includes a new project-level configuration setting, 'Build Sdk', which can be used to tell NCrunch which version of MSBuild you want to use.  This includes installed versions of Visual Studio and the .NET SDK, which now ships with its own versions of MSBuild.  As you can imagine, this setting is quite important for Rider, but it can also be used to set up grid nodes and console build systems able to function without Visual Studio installed.  This should make it much easier to set up grid nodes without needing to be concerned about Visual Studio licensing headaches, and allow these nodes to have a much smaller install footprint.

The full release notes can be found here, and v4.19 is downloadable from here.