With NCrunch V5 in the pipeline this dream might come true... 👀

Like many here I have moved from VS to Rider/VS Code. The only thing I miss is NCrunch, it's a great shame that it doesn't seem to be viable.

My licence has lapsed now but it could and would be renewed if NCrunch was avalable for Rider.

Rider adaptation is growing rapidly based on the JetBrains report: https://blog.jetbrains.com/blog/2021/03/03/jetbrains-2020-21-annual-highlights-10-million-users-30-tools-and-more/

Please consider the integration of NCrunch with Rider.

I understand the complexity of doing an integration with another IDE in another language. Still, it's sad for me - the only reason I don't use Rider is because I can't use NCrunch.

Would love to see ncrunch on rider! It's the only feature I'm missing from VS, and riders continuous testing is soooo much slower than ncrunch that it's useless ... :(

I left Visual Studio years ago and have never looked back. The only thing I miss with VS is being able to use NCrunch and it is quite sad there is no NCrunch for Rider. But if I have to chose between Rider without NCrunch or VS with NCrunch I chose Rider all day long... So, until there is no Rider support I will not renew my NCrunch license.

As a long time NCrunch user, leaving it behind has been very tough. There's a wodge of money sitting here waiting to be spent on it again.

What Joseph Woodward said.

We would love to have NCrunch supported too! Many of our Engineers use Rider as their primary IDE.

I had to leave NCrunch behind when I moved to Rider. Would love to see it working in Rider one day.Damian Hickey summed up my feelings on it.

Have you considered talking to the JetBrains people to see if they can accommodate the move in any way? The .NET landscape really is in a massive shift at the moment and tying this great plugin to a single IDE on a single OS because it'll take work to migrate it seems like something that will need to change eventually.

NCrunch and OzCode are two reasons I haven't uninstalled VS yet. Please, guys, make this happen.

FWIW, from https://blog.jetbrains.com/dotnet/2018/02/27/rider-2018-1-eap-open/#comment-507525
>>February 28, 2018 at 12:00 pm
>>Could you please give any kind of an ETA for either some sort of continuous testing tool or dotCover support for Rider?

>February 28, 2018 at 12:24 pm
Lauri,
>We are expecting to get this done around mid-year.

btw on the other side https://youtrack.jetbrains.com/issue/RIDER-3824#comment=27-2707192 ;)

any news on this?

I strongly support this. it would be awesome having the possibility to use ncrunch in rider

IMHO Damian Hickey described it perfectly.
Also the suggestion to partner with JetBrains is a very interesting idea that you should seriously consider IMHO.
Another option is to open up the "protocol" for other to implement the UI they want for tools they use. I'm sure that VSCode people would be very happy to do it and JetBrains IDEs have a lot of plugins as well.
I'm aware this imposes some limitations on your work and future NCrunch development, but it might be a good choice regardless of those.
From your forum response I'm guessing that you did couple NCrunch to VS too much and that's probably something you should fix ASAP in this changing landscape to continue to have success apart from keeping up with testing framework to make NCrunch work well in the meantime.
At the moment NCrunch is the best tool of its kind so IMHO you should not feel the need to introduce a lot of new features and use this time to ensure that NCrunch is safe for the next couple of years.

I've put 3 votes on this and on

The .NET ecosystem is diversifying, becoming competitive and growing in new directions (i.e. xplat). Limiting ncrunch to Visual Studio is quite disappointing and I'm willing to bet, limiting your business in the longer run. The pace of VS code and Rider is rapidly catching up with VS and will soon leave it behind, with it's burden of legacy support.

The early adopters, the same people that helped bootstrap ncrunch when _it_ was new kid on the block, have jumped. The early majority is not far behind. VS now has it's own continuous tests and I don't doubt that Jetbrains one will improve and will work xplat (for xplat projects).

> impossible to carry with the existing structure of the NCrunch business.

Then you need to re-tune this. From an outside perspective, a partnership / co-development sponsorship with JetBrains to bring ncrunch to Rider makes sense. While it competes with their own dotCover/continuous tests (which is not a patch on ncrunch, _yet_) from their perspective it would reduces barrier / friction of Rider adoption for NCrunch users who are "stuck on VS". Just a suggestion.

Anyway, you need to consider your position on VSCode/Rider carefully. Not supporting will create a gap and a competitor will fill it.

I would like to bring light to an other Idea https://ncrunch.uservoice.com/forums/245203-feature-requests/suggestions/31360174-standalone-ui-which-can-be-used-with-every-other-i

At the moment, there are no plans to implement this in the immediate future.

Despite the number of people that I'm sure would love to see this, it's unfortunately also the largest feature ever requested for NCrunch. Support for Rider would require rewriting ~30% of the product in Java, and would naturally include a promise to simultaneously support ALL future versions of Rider in the same way that VS is currently supported. So we'd basically be looking at 1 year+ of development up front, plus a massive maintenance burden that would likely be impossible to carry with the existing structure of the NCrunch business.

I'm going to leave this feature request up here rather than reject it outright, as it's still useful to know how many people want this ... but please understand that at the moment, I can't deliver what is being asked for.

NCrunch is THE ONLY reason I stick to Visual Studio.
I hate VS and will leave it as soon as NCrunch works with Rider or Rider does Continous Testing well.