📋Develop Roslyn Source Generator in Rider

What’s .NET source generator

• retrieve compilation representing user code
• with syntax trees
• with semantic models

• new source code can be added to the compilation as additional source code
• 0..n
• as strings

• additive only, which means source generator could not change the code in the project.

• can produce diagnostics

• you may access additional files (non-C# source texts)

• unordered
• no access to files created by other source generators

• are technical analyzers

Sample solution

GitHub - luckyBricks/SampleGenerator

Contribute to luckyBricks/SampleGenerator development by creating an account on GitHub.

https://github.com/luckyBricks/SampleGenerator

• The SampleGenerator project is a .NET Standard 2.0 class library. Declared in .csproj file.

• The TestGenerator is a console app, invoke generated SampleCodeGenerator namespace, please notice it’s not as same as source generator’s namespace. When opening the project in Rider, since SampleCodeGenerator hasn’t generated, it will show errors in TestGenerator project.

Development workflow in Rider

• Debug source generator itself:

{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "Generators": {
      "commandName": "DebugRoslynComponent",
      "targetProject": "../TestGenerator/TestGenerator.csproj"
    }
  }
}

• Debug generated source:
First, build the project using the source generator. Then users will be able to add breakpoints in generated source files directly.
An alternative way is to add breakpoints in the project and step into the generated source file.

Known issues / Limitations / Workarounds

1. Debugging generated project files.
In some cases, users may want to set breakpoint in *.g.cs generated sources that are used for navigation, and the final target implementations are in the project files. It’s impossible to add breakpoints directly in the *.g.cs which is used for navigation.
To work around this issue, the user needs to use System.Diagnostics.Debugger.Break() in source generator, so that the debugger could attach to the generated source and step into the project source files. Or, in the latest Rider, user can set breakpoints in *.g.cs directly.



Rider can’t map generated files to files embedded in pdb, it only uses the version from pdb for the debugger. Step from the navigation code to the target source could be time taken, but it is the only solution in current stage.
Existing feature request: RIDER-72249 Cannot set breakpoint in source generated code used for navigation

2. Code changes in source generator are not taking effect
When developing a solution including source generator projects, it requires building the entire solution to make sure the source generator taking effects. Sometimes changes in source generators will not take effect and lead to the wrong build result—although code could be generated normally.
It’s a known issue described in the two tickets:
• RIDER-94207 Source generators don't update when being changed
• RIDER-101933 Code changes in source generator could not be reflected in Rider
The solution is refreshing the build server with the below steps:
1. Execute dotnet build-server shutdown in solution root folder.
2. Execute dotnet clean to delete all build results.
3. Build the solution in Rider so that code changes will be reflected as expected.
To simplify the operations, the following Run/Debug Configurations could be added for the project.
4. Add the steps in Before launch configuration



5. The External Tools/Build Server Shutdown config looks something like this.

3. Missing Roslyn Syntax Visualizer in Rider
The integrated Roslyn Syntax Visualizer in Visual Studio is very handy when developing Roslyn analyzer and source generator. There are some third party implementations of the tool in Rider, but most of them are outdated and do not support the latest C # version.
Existing feature request: RIDER-29517 Syntax visualizer should be available in Rider

Some problems related to Roslyn Analyzer