Source Generator Files with debugger

The new debugger works correctly and flawless until an invocation happens to a method that is in a file that is source generated


lets say i have an object which source generated and i invoke a method on it and the test runs through that

then i click on the arrow and all that happens is that all the arrows disappear ( probably just a stop call of the debugging )
it would be better if i can jump into the source generated files as well

Hi, thanks for posting.

Can you share some more detail about where this is going wrong and what you would expect to see? Is NCrunch's instrumentation interfering with your debug session, or are you referring to the new RDI features?

Its about the new RDI and ncrunch itself when using source generator.

For Reproduction my repo https://github.com/NexStandard/NexYamlSerializer
( you will have to build Source generator => nexvyaml => core => NexVYaml => restart VS else ncrunch wont work with the nugetting that i have )

here is one test failing Compact_RecordWithMember

When going to the analyzers, generated by my serializer in NexYamlSourceGenerator , not a single class is bubbled, no green no red bubbles , even though i have 80% test coverage and my serializer needs these classes to work, so they are used
all the normal classes are bubbled and checked correctly, just the source generated ones are problematic

When using RDI , the failing test in YamlSerializer<T> in the third invocation cant find the log
this happens always when the next invocation is a source generated class
https://postimg.cc/4HPf739B

Thanks for sharing the codebase. This really helps with understanding what is happening here.

Because the generated source files aren't actually a part of the solution, NCrunch has no representation for them inside the runtime environment. This means that these files can't be instrumented and they aren't represented in the RDI logs.

When projects are loaded, NCrunch establishes a list of all source files for each project (as provided by MSBuild). We then pass representations of these files downstream into the instrumentation system (which happens after projects are built). The instrumentation system then builds metastructures that are used during test execution to tie the execution path of tests back to the source files.

The manner in which this source generator is working sidesteps this process, as the source files can't be discovered until a project has been fully built, so they cannot be included in the representation passed into the instrumentor. As far as NCrunch is concerned, this is external code that isn't a part of your solution.

The only way I could see this system working with NCrunch is if you found a way to include the generated source files inside your solution itself. The source generation step would then need to be performed upfront on the files in your foreground solution, so that NCrunch could then sync the changes into its workspaces and build them as normal. It would be very messy.

I actually cannot suggest a feasible way for you to get coverage data on this code under NCrunch. You may simply need to accept that the code is functional but not browsable with available code coverage, much as we have currently with other external code.