Hi,

It really depends on the generator. NCrunch doesn't have any mechanism to specifically exclude generators, but there is an infinite number of ways in which the generators can work.

How is the test being generated? Is it through a build task?

Does it make any difference if you turn on the 'Copy referenced assemblies to workspace' setting?

Your success with generator will depend entirely on:

- When the generation is performed
- What is being generated
- What dependencies the generation has

You may need to delve into the generation code and reconcile this with the NCrunch constraints. It's impossible for us to warrant whether the product will work with any given generator as code generation allows virtually limitless possibility when it comes to development, and we have no control over the boundaries.

I think that most likely the problem here is going to be the cross-project interaction. This would break NCrunch's project atomicity constraints.

Do you have any option for your code generation to be moved into the test project instead? So that it generates its own tests?

Again, it's impossible for us to warrant which source generators NCrunch supports and which it doesn't, as there are too many options available and there are many ways of using them. I would suggest making sure you are familiar with the constraints described in the documentation and examining how the system works to see whether you can handle it with the various NCrunch configuration options available.

I realise it's not particularly helpful to be given a support response that simply pushes back the problem, but please consider the following:

* We can't say that we can't handle source generation, because many generators do work just fine with NCrunch and some don't even require special configuration
* We can't say we officially support all source generators, because there are so many options available in this area that we can't even test for all possible scenarios, much less work around the compatibility issues that exist with them all
* We can't provide targeted support for every person that has a problem with a source generator, because we'd open ourselves up to limitless amounts of support work investigating niche scenarios, most of which would overwhelming result in no change to the NCrunch codebase and would only help one person at a time. We just don't have the resources to work that way.
* We CAN investigate issues that affect a large number of people using a very widely used toolset. However, in my experience I have yet to encounter a source generation issue that qualifies for this. These tend to be very niche issues. If your source generator is doing something specific that you feel NCrunch should be able to handle, I recommend making a feature request for NCrunch to improve its handling in this area and we will investigate it if enough users vote for the issue.

Actually, it looks like NCrunch's modifications to the csproj might not be correct:







OutputItemType should be kept since it tells the SDK to load that reference into the compiler (so source generation actually happens). ReferenceOutputAssembly prevents tells the SDK to not reference the DLL. Maybe a easy fix would be to copy all elements on Reference's?

Edit: I'm blind - ProjectReference != Reference. Not quite sure how the SDK handles direct DLL references for analyzers.

I would guess NCrunch also breaks with Roslyn analyzers, if referenced as a project.

OutputItemType doesn't look like it's a valid attribute (does nothing during build). Looking deeper, Analyzer looks to be the equivalent:



It appears the `dotnet build` is now executing the source generation:



(ignore the exception being thrown)

Forgive me for saying so, but I think this is the wrong way to look at it. Source generation will become extremely important very soon. Microsoft is already looking at using them for several things, including their JSON serializer, and many other things. They are making a strong push towards solutions that are highly optimized and easily trimmed compared to reflection based solutions. Even before they start shipping their official source generators, many people are already doing their own. I honestly think this needs to be one of your highest priorities, and I don't think you should use user input to gauge importance. Without support for source generators, NCrunch will be impossible to use for almost anyone using even just the latest standard MS libraries and frameworks and not even doing their own generators.

An update here. We've conducted an in-depth assessment of what is required for us to implement support for Roslyn based source generators to make sure we're covering our bases here. At the moment, it looks like this tooling is still in a relatively early preview state. We had difficulty even building test scenarios to examine how they work under the hood. The plan at the moment is to wait until MS fully release this feature, then we'll reassess.

Hi! I'd just like to chime in that I encountered this issue today :)

Basically I've added a project that generates a lot of boilerplate code with regards to custom GraphQL scalar types but projecs won't build in NCrunch because code generation, from the other project, doesn't work.

Code generators from NuGet packages seem to work fine but this is a project in the same solution.

It's added in the csproj (in my case Foo.Serialization.csproj) file like this:

It doesn't seem like there is any interest in fixing this, making NCrunch unfortunately unusable for us. Maybe we will renew our licenses if it ever gets implemented, but this lack of responsiveness is worrying.