How to write my own Razor Analyzer

[tesar-tech]

Hey,

I would like to write my own Razor analyzer. For example, consider this code:

<MyComponent>
    <ComponentThatShouldNotBeHere/>
</MyComponent>

My analyzer would detect and warn that the <ComponentThatShouldNotBeHere> should not be inside <MyComponent>.

I know I can use a Roslyn analyzer to check the generated code, but there are some challenges:

• The code generator doesn't provide #line directives for mapping the location of <ComponentThatShouldNotBeHere>, so the warning is inaccurate or references the g.razor.cs file.
• Without the exact location, I can't produce a code fix to remove <ComponentThatShouldNotBeHere> from the Razor file. I'm not even sure if code fixes for Razor files are possible with Roslyn analyzers.

There are several Razor analyzers, such as this one for the RZ2012 warning. This warning checks for the usage of EditorRequired without a specified parameter. It also supports code fixes, which is exactly what I want to achieve.

How can I create similar custom behavior? Is it possible to write and use my own analyzer specifically for Razor files?

Additionally, this Stack Overflow question discusses similar topics.

I’m aware of projects like Meziantou.Analyzer, which provides warnings for Razor files. However, these are based on the generated code and don’t really offer mapping back to the Razor files or provide corresponding fixes.

Thank you.

[ryzngard]

Hi @tesar-tech , thanks for posting an issue for this! Currently writing custom analyzers for Razor is unsupported. We have looked into possibilities for adding them but have not prioritized that work. Unfortunately, Roslyn analyzers/code fixes do not support working on AdditionalDocuments which is what razor files are to them.

If you have specifics for what you're trying to achieve we might be able to help unblock you, but no promises.

[tesar-tech]

Hey, thanks for the response.

I am working on creating a migration tool for the Blazorise component library to simplify the process of upgrading a codebase from version 1.* to the soon-to-be-released 2.0, which includes many breaking changes.

Examples of Breaking Changes

1. Changed parameter name:

   <!-- Before -->
   <TextEdit @bind-Text="@value" />
   
   <!-- After -->
   <TextEdit @bind-Value="@value" />

2. Avoid using AccordionToggle inside the Collapse component:

   <!-- Before -->
   <Collapse>
       <AccordionToggle>Some text</AccordionToggle>
   </Collapse>

More examples of breaking changes can be found here: Blazorise Issue #5871 (note that this is not the complete list).

Goal

Using Roslyn analyzers seems like a natural fit for this task because it allows users to stay in their IDE and work within an environment they’re already familiar with. Ideally, they could just press Ctrl+. to apply the suggested code fix.

While not all breaking changes are automatically fixable, providing at least a warning with a link to relevant documentation would still significantly improve the upgrade experience.

Challenges and Current Approach

Unfortunately, implementing the "perfect solution" entirely through Roslyn analyzers doesn’t seem feasible due to:

• The complexity of certain breaking changes.
• The need for Razor-specific parsing and understanding beyond what Roslyn analyzers directly support.

However, Roslyn analyzers are still helpful—they can accurately point out files where some action is necessary. Based on this, the current best approach appears to be developing a custom CLI tool.

• This tool would use the output from Roslyn analyzers to locate issues.
• It would perform Razor file parsing and attempt to fix the code automatically where possible.

Am I overlooking anything here, or do you see a better way to utilize Roslyn analyzers to make the migration tool? Any suggestions or ideas for improving this process would be greatly appreciated.

Thank you for your time—I truly appreciate your help!

[davidwengier]

If writing a Roslyn analyzer, then reporting diagnostics on the generated code is the appropriate action, and the IDE tooling will take care of mapping the location to the Razor file, and the Error List and squiggles will follow. Of course, if the location can't be mapped, then unfortunately you're out of luck.

Code fixes are currently on a very small allowlist, and would only work for changes to the generated C#, not to the Razor file. Eventually we want to be able to remove this allowlist, but interpreting generated code changes such that Razor component elements change is unlikely to ever work.

In the long run, it would be great to have an API for the Razor compiler so syntax trees can be used etc., analyzers and code fixes on additional files could be hooked up via Roslyn, etc. All good things, but sadly nothing we are able to prioritize right now.

Related issues and discussions:
#10375
#6641