Quote:If you add the source line:
System.Diagnostics.Debugger.Launch();
... As the first line of code in your source generator, does the debugger prompt appear when you run NCrunch over the solution? This should hopefully be a reliable way to determine whether the source generator is actually being called.
Unfortunatly no. It will launch however when i build it from commandline or VisualStudio.
Edit:
Quote:I've done some more experimentation with this issue, and it's looking more and more like the problem is in the platform itself.
The following error below exists in the log you submitted:
[PID:20612 07:32:13.1395 ?-7] Build output: CompilerServer: server failed - server rejected the request due to analyzer / generator issues 'analyzer assembly 'C:\Users\mgrun\AppData\Local\NCrunch\21060\1\CodeGenerator\bin\Debug\netstandard2.0\CodeGenerator.dll' has MVID '6c3cd6a2-49e1-4a1f-8209-f45baaefe1a1' but loaded assembly 'CodeGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' has MVID '6547d188-b8dc-479e-b0e1-871eec991ac3'' - 97140365-82f5-41d2-8990-85309c19a5ec
Yeah that would explain the TargetInvocationException.
Quote:Interestingly, I can produce the same error myself under NCrunch by running multiple VS sessions and having them build the solution in the foreground with NCrunch spinning. The error appears to relate to the behaviour of the VBCSCompiler.exe process, which is a process shared between build sessions. To implement the source generators, MS are loading the source generator binary into the VBCSCompiler process and calling it as part of the compiler system. This means that the binary stays resident in a compiler process that is shared between _all_ processes on the system that try to compile anything. This seems to result in source generator state bleeding between build systems, resulting in version inconsistencies of the source generator being loaded .. hence the error.
I played also around a little bit, by launching a fresh installation of VS 2022 Community inside the Windows Sandbox. After installing VS with the workloads: .NET Desktop, ASP.Core and VS Extension Development, and installing NCrunch, cloning the fresh repo. The issue is 100% reproducable on my side, every single time.
Quote:
What is quite confusing about this error is that even though I can reproduce it on my system, the build still passes and the tests work OK under NCrunch. I haven't yet been able to establish if this is due to some kind of residual state, but it suggests this could be a red herring. Setting the 'UseSharedCompilation' build property to 'False' eliminates the problem for me as it forces the build system to avoid using a shared process between sessions.
I tried setting the `UseSharedCompilation` to False and True on a solution level, and made sure to restart even VS between the runs, but it does not make any difference in my tests, because NCrunch complains about not able to build the `SourceGenApp`project at all, but the `CodeGenerator`. I Also tried to update those nuget packages, and switching to net6 and other configurations, but was not able to make NCrunch happy at all.
Quote:
Something else I've noticed is that in the sample solution you've provided, I actually can't get Visual Studio to update the generation logic without completely reloading the IDE (this is without NCrunch involved at all). If you change the messages in the generation code, it has no impact on the logic even after rebuilding the solution.
This is documented and expected behavior inside VisualStudio for the Intellisense (so if a generator changes some API surface (adding new methods, changing overloads, etc.) it will not be reflected until a restart of VS. As for building, you should be able to change the generator and just hit F5 which should work 100% fine. I Just confirmed that behavior in my Sandbox.
Thats why i like to do SourceGenerators in a TDD style, and it works fine with VS Test runner or CodeRush Test runner, but is by no way near the comfort of NCrunch :)
The normal cycle for me is: Write tests and change SourceGenerators until they are covered with tests as expected, then try them out in a real project. Especially with the new capability to Debug right into a source generator.
Quote:From the side of NCrunch, all logs are confirming that the analyzers are being handed to the compiler with all parameters intact. At the moment, I feel like we're chasing ghosts in what seems to be a platform implementation that's full of holes. I'm wondering what your experience has been with source generation on your side.
I am not sure what changed. But a i worked with NCrunch and VS Studio a couple of months ago, and is was working fine, besides the instrumentation warning.
