3 ms·

Thanks. Personally, I found that most efficient way to develop source generators was by utilizing in memory compilation in unit tests. That way, I was able to u

by dgpy 3y ago

Thanks. Personally, I found that most efficient way to develop source generators was by utilizing in memory compilation in unit tests. That way, I was able to use debugger to understand AST provided by Roslyn and quickly iterate. Not sure how it works within VSCode but in Rider it was really fine. Also, sometimes Visual Studio and Rider doesn't regenerate code (likely because internally msbuild decides that dlls are up-to-date). Unit test + in memory compilation way described above assured that latest code was really used in test.

CharlieDigital 3y ago
> That way, I was able to use debugger to understand AST provided by Roslyn and quickly iterate. Interesting; would love to see a video of your workflow and process. With VSC, I found that I had to do some "hacks" to drop output as comments into a generated file so I could see what was happening.
- dgpy 3y ago
  General usage is as in this short video: https://streamable.com/3oqxhf https://streamable.com/3oqxhf `QueryGeneratorTestUtil.GenerateCompileAndAssert` internally uses `Microsoft.CodeAnalysis.CSharp.CSharpCompilation.Create()` and `Microsoft.CodeAnalysis.MSBuild.MSBuildWorkspace.Create()`. I get an interactive, debuggable source generator development environment this way. Same as you, initially I used "comments as debugging" hacks but above way is way more efficient.