Hi,

There is a request for this on uservoice at the moment.

Right now there are no plans to implement this. It's a massive piece of work that would involve rewriting around ~30% of the product in Java.

Sorry, I know this is a disappointment for you.

The problem has less to do with resources and more to do with feasibility. If it were just a case of throwing a year of development into such a feature and there being no further cost involved, this would look much more appealing.

Unfortunately, because Rider is written in Java, the entire UI of NCrunch would need to be reconstructed, along with the layer that connects this UI into the engine. Because of extremely tight performance constraints, the UI for NCrunch is deceptively complex and is built almost entirely on custom controls. All of this would need to be duplicated into a Java based equivalent with an intricate communication system that would touch almost all areas of the engine. Every time a feature is added to NCrunch, it would need to be implemented twice; once in .NET, and once in Java. Every time Jetbrains release a new version of Rider, NCrunch would need to be adapted to simultaneously support the new version alongside all prior versions. The maintenance burden of this feature would be tremendous, it would almost double the cost of keeping the project running.

When you consider that at least 70% of the time spent on NCrunch is spent maintaining integration with the tool stack and software developed by other parties, it's easy to see how a significant increase in maintenance would strangle further development. It's possible to get more capacity (i.e. by increasing team size, changing business structure, etc), but there are other costs attached to this, especially in the areas of quality control and the potential complexity of future features. Integration with Rider has the potential to be highly detrimental to NCrunch.

A feature of this size would need to have a really strong business case behind it, or it would need to be in the strategic path for the development of the product. In regards to the former, I am not presently convinced that the potential size of user base on Rider would be big enough to warrant the costs involved in integration. In regards to the latter, it's never been the goal of NCrunch to integrate with everything under the sun. I founded the project to push boundaries and discover new ways of working. It's very hard to do this when you're tied down in a web of integration points floating in a sea of moving parts.

Another aspect is Jetbrains' view of having another continuous testing tool in their IDE, competing with their own continuous testing feature with DotCover (not yet available in Rider though). You wouldn't want to invest huge amount of money/time just to see JetBrains closing the door for you in order to sell more DotCover licenses.

This is always a risk when integrating with a product built by another (competing) party, though in this instance I don't think that JetBrains would likely close the door on a plug-in like NCrunch. Integrating NCrunch with Rider would be of value for both products. The same situation currently applies to VS, considering the new Live Unit Testing feature.

Would it be possible to hook up NCrunch Console Runner Output in Rider? Sure it wouldn't be the NCrunch Experience, but I hope this would give us some of the power of NCrunch quickly?

Unfortunately, there's no way to provide an acceptable NCrunch experience in Rider without the following:

1. Being able to extract in-memory code text from the IDE
2. Being able to extract in-memory project details from the IDE (i.e. XML, dependency information, etc)
3. Rendering of coverage markers in the code
4. Correct preservation of the coverage marker positioning when the code changes (frightfully hard to do)
5. Navigation options allowing ability to direct the IDE's UI to different areas of the codebase according to commands by NCrunch (i.e. Go to test, go to exception line, etc)
6. Ability to render stable UI windows in the IDE's process, in a way that won't interfere with the IDE's UI or cause massive frustration by overlapping other windows etc.

Unfortunately, even when cutting the feature-set to its bare minimal, it just isn't possible to deliver the above without deep integration with the IDE. That would mean deep integration and maintained testing with all versions of the IDE and all future versions of the IDE. Which leads us back to the original problems with feasibility and maintainability.

Sorry, I don't see a quick and dirty way to do this that will add value for anyone.

Is there any update on this? We are 2 yeans further now.

It's the most voted item on your UserVoice, together with a standalone version of NCrunch, so I guess it is what most customers want.
I recently switched to Rider as well, mostly because VS seems to slow down on bigger projects, which I am working on for clients now.
NCrunch is alot better than dotCover in many aspects, so I would prefer using it in Rider.

Would be really nice! I'm loving Rider over Visual Studio for several reasons. But for some TDD-intensive projects I keep sticked to Visual Studio because I won't be productive without NCrunch.

Just want to mention that, as a long time NCrunch User, but stopped using VS since 2020. I'm still missing NCrunch in Rider, creating a specific Session with some Tests and run them all on save is not the same ... hopefully @TobbenTM is right, and that @Remco does not say anything about that is also a good sign for now :)

Today I missed the Churn feature because of some flaky test. So hopefully, NCrunch 5.x will not disappoint in that way. Fingers crossed!