Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

3 Pages<123
Support for C# source generators?
mgrundner
#42 Posted : Friday, January 28, 2022 7:53:55 AM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
Remco;15950 wrote:
mgrundner;15949 wrote:
Seams the problem is back with https://github.com/nicodeslandes/SourceGenApp and 4.11.0.2 in VisualStudio 2022 Preview :(


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.


I did a quick check with 4.11.0.2 in VisualStudio 2022 (17.0.5) and it's the same issue
Remco
#43 Posted : Friday, January 28, 2022 8:36:35 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,970

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
mgrundner;15952 wrote:

I did a quick check with 4.11.0.2 in VisualStudio 2022 (17.0.5) and it's the same issue


Testing this on VS2022.17.0.5 it seems to work on my end with your sample solution. Can you confirm the error you're seeing? Do you have any extra configuration?
mgrundner
#44 Posted : Friday, January 28, 2022 12:00:31 PM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
Remco;15953 wrote:
mgrundner;15952 wrote:

I did a quick check with 4.11.0.2 in VisualStudio 2022 (17.0.5) and it's the same issue


Testing this on VS2022.17.0.5 it seems to work on my end with your sample solution. Can you confirm the error you're seeing? Do you have any extra configuration?


No basically its a fresh clone and then enable NCrunch.

Code:
NCrunch: If you are experiencing problems in getting this project to build, have a look at http://www.ncrunch.net/documentation/troubleshooting_project-build-issues
Program.cs (9, 13): Der Name "HelloWorldGenerated" ist im aktuellen Kontext nicht vorhanden.


WARNING - CSC (0, 0): CS8032: Eine Instanz des CodeGenerator.MySourceGenerator-Analyzers kann nicht aus C:\Users\mgrun\AppData\Local\NCrunch\5456\1\CodeGenerator\bin\Debug\netstandard2.0\CodeGenerator.dll erstellt werden: Ein Aufrufziel hat einen Ausnahmefehler verursacht..


Should i send a bug report log?
Remco
#45 Posted : Friday, January 28, 2022 10:58:54 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,970

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
mgrundner;15955 wrote:

Should i send a bug report log?


Yes please!
mgrundner
#46 Posted : Friday, January 28, 2022 11:30:06 PM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
Remco;15956 wrote:
mgrundner;15955 wrote:

Should i send a bug report log?


Yes please!


Done! :)
Remco
#47 Posted : Saturday, January 29, 2022 3:32:57 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,970

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Thanks for sending this through. According to the log, things appear to be functioning normally - except the output from the source generator doesn't seem to exist.

We need a more detailed capture of the build system on your side from when the source generator is supposed to be executing.

Can you do the following for me?

- Go to your NCrunch solution-level configuration
- Set the 'Build log verbosity' setting to 'Diagnostic'
- Reset the engine, let the builds run
- Open the NCrunch processing queue, find the Build Assembly task for SourceGenApp
- Copy/paste the log contents on the lower pane to a notepad. Save to disk
- Zip up the log, then submit it through the NCrunch contact form

I do also recommend reviewing the log yourself for any errors related to analysers. It's a mystery to me why I can't reproduce this issue on my side with the same configuration, solution and toolset.
mgrundner
#48 Posted : Saturday, January 29, 2022 1:22:52 PM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
Remco;15958 wrote:
Thanks for sending this through. According to the log, things appear to be functioning normally - except the output from the source generator doesn't seem to exist.

We need a more detailed capture of the build system on your side from when the source generator is supposed to be executing.

Can you do the following for me?

- Go to your NCrunch solution-level configuration
- Set the 'Build log verbosity' setting to 'Diagnostic'
- Reset the engine, let the builds run
- Open the NCrunch processing queue, find the Build Assembly task for SourceGenApp
- Copy/paste the log contents on the lower pane to a notepad. Save to disk
- Zip up the log, then submit it through the NCrunch contact form

I do also recommend reviewing the log yourself for any errors related to analysers. It's a mystery to me why I can't reproduce this issue on my side with the same configuration, solution and toolset.


Done.

Quote:

As proposed. Included the logs of 2 machines.

As side notice:
Log_A.txt is a fresh install of windows 11
With DevExpress & CodeRush installed (latest version) latest NCrunch 4.11.0.2
Log_B.txt is a older installation (windows 11) also with DX & CR latest NCrunch 4.11.0.2
Both machines are DE-AT (Windows, but VS installation is English).

LOG_C.txt is 16.11.9 Preview 1.0 with latest NCrunch 4.11.0.2 (on same machine as LOG_B.txt)

All machines build the sample fine.

not sure if it makes any difference, just to make sure the config is clear.

Both logs are with the latest NCrunch 4.11.0.2 and NOT preview VS 2022

I could not find any clue in the logs so far.

Kind regards & thanks for your amazing product,
Manuel
Remco
#49 Posted : Sunday, January 30, 2022 12:09:02 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,970

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Thanks for sending through these logs.

Can you try setting the 'UseSharedCompilation' build property to 'false' for the 'Custom build properties' setting in your NCrunch shared solution settings and let me know if this makes any difference for you?
mgrundner
#50 Posted : Sunday, January 30, 2022 10:42:25 AM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
Remco;15960 wrote:
Thanks for sending through these logs.

Can you try setting the 'UseSharedCompilation' build property to 'false' for the 'Custom build properties' setting in your NCrunch shared solution settings and let me know if this makes any difference for you?


No that doesn't make a difference
Remco
#51 Posted : Sunday, January 30, 2022 1:03:08 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,970

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
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.

Edit:

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

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.

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.

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.

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.
mgrundner
#52 Posted : Monday, January 31, 2022 10:50:56 AM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
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.
Remco
#53 Posted : Tuesday, February 1, 2022 3:17:45 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,970

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Can you confirm whether turning off NCrunch's 'Instrument output assembly' setting for the code generation project resolves the issue?
1 user thanked Remco for this useful post.
mgrundner on 2/1/2022(UTC)
mgrundner
#54 Posted : Tuesday, February 1, 2022 9:10:30 AM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
Remco;15968 wrote:
Can you confirm whether turning off NCrunch's 'Instrument output assembly' setting for the code generation project resolves the issue?


In deed, this does the trick.
It builds fine and runs the tests.
But ofc now coverage for the generator is gone. I can live with that for now :)
A little bit annoying that i need to reload the Generator project by hand when i change it, but at least it picks up the changes after the reload :)

Thanks for your help Remco!
However I hope you somehow can improve this situation in the future.
Remco
#55 Posted : Wednesday, February 2, 2022 10:43:21 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,970

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
1 user thanked Remco for this useful post.
mgrundner on 2/2/2022(UTC)
mgrundner
#56 Posted : Wednesday, February 2, 2022 12:16:28 PM(UTC)
Rank: Member

Groups: Registered
Joined: 2/25/2016(UTC)
Posts: 17
Location: Austria

Thanks: 4 times
Was thanked: 3 time(s) in 2 post(s)
2 users thanked mgrundner for this useful post.
Remco on 2/2/2022(UTC), UppSol on 2/8/2022(UTC)
Users browsing this topic
Guest
3 Pages<123
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.110 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download