Hi @Remco,

Are you still looking for a working solution with the problem? I can probably cook one up if that helps.
Source generators have just been introduced in our solution, and I now find myself in the same situation as tkarlsen, with NCrunch now being simply unusable :-(.

Cool; there you go: https://github.com/nicodeslandes/SourceGenApp

That's about as basic as it gets; it has a console app and an NUnit project that both use the "CodeGenerator" project in the solution to generate a "HelloWorldGenerated.HelloWorld" class that gets called by them.

Visual studio and dotnet test are both fine with it. NCrunch fails to build both projects:

Great, thanks Remco!

It worked fine on my solution. I'm just getting these warnings, but they don't seem to cause any issues:

Thanks for confirming! I don't think the compiler packages warning is related to this work. If you aren't getting any errors, it's nothing to worry about. There are use cases related to the compiler packages that can cause NCrunch to bomb out with weird errors. If you aren't seeing these, then you can ignore the warning.



This is to be expected. Right now we don't have a way to instrument the generator assemblies, as the build system for these projects doesn't seem to support having references to additional assemblies. You'll need to manually execute your tests after changing the source generator, or rely on the automatic/aggressive execution mode instead.

Thanks for sharing these reports. You may have just saved a great many people a lot of pain.

I'm sifting through the logs but cannot find a clear reason for why the engine process is crashing on you. I think this might be something more systemic. If this is still happening consistently for you, could you check the memory consumption of the process during your initialisation, and examine the contents of your windows event viewer to see if there is more detailed error information? I'm wondering if this might be an OutOfMemoryException or something similarly traumatic.

It would also be great if you could confirm whether this build of NCrunch works for you on different solutions (i.e. smaller ones). We aren't able to reproduce this issue on our side, so right now the focus is on narrowing it down. I really appreciate your help on this. I was hoping to release 4.9 today but will hold it back until we can be sure of shipping it without a critical crash issue.

Reinstall and reboot didn't help - I initially suspected it might be due to the file locking issue I got when installing originally but it seems not.

There's nothing in Event Viewer when the process ends, so maybe it's not crashing?

Memory usage seems unlikely - system memory is sitting at 40% used.

I have tried a couple of smaller solutions in 2022 and both work without any issue.

My other thought was that maybe it was a corrupt cache or something, so I wiped the NCrunch cache directory completely, but the issue still happens on this particular solution of about 90 projects. The .crunchsolution.cache file did get generated before the process dies if that helps?

Based on the UI, it seems like it's dying at the "building..." stage, at least based on what the tests panel is telling me.

I'm going to try .1/.2 in 2019 and see if that narrows it down at all for you

Unfortunately not. Setting this value to 1 did not seem to have any effect. I assume changing CPU cores assigned to NCrunch probably won't help either then?

I've tried all the combinations for older versions, here's the rundown:

VS2019
4.9.0.1 - working
4.9.0.2 - crashing
4.9.0.3 - crashing

VS2022
4.9.0.1 - N/A
4.9.0.2 - crashing
4.9.0.3 - crashing

So it looks like something between 4.9.0.1 and 4.9.0.2.

Contrary to my earlier bug report, VS2022 does appear to restart the engine process in a loop now. I'm not sure why it wasn't doing that when I first tried.

EDIT: I think I have made some sort of progress narrowing it down. Using a default .ncrunchsolution / .ncrunchsolution.user file does not produce the issue. I'll see if I can work out if it's a particular option.

Gotcha!!!

As you posted this, I was just writing up a reply with a theory that our settings file sync could be causing this, and I was going to lead you down a path of removing settings files to figure out which setting was causing the problem. You beat me to the punch.

This is making sense to me now. I'm going to try and build a use case to reproduce it.

Can confirm this build is working well on both 2019 and 2022, thanks Remco!

We've had some odd reports with the new VS2022 preview build lately. I think they still have a bit of stuff in the oven with it. I recommend holding off on using it for the moment. We'll be doing an assessment on it closer to its release date.