C# rules not applied to cshtml

Scanning a web project containing asp.net webpages (.cshtml) files, the scanner detects the files but does not apply the C# rules.

14:45:37.664 DEBUG:   * HTML => "web"
14:45:39.700 DEBUG: Declared extensions of language C# were converted to sonar.lang.patterns.cs : **/*.cs
14:45:39.700 DEBUG: Declared extensions of language HTML were converted to sonar.lang.patterns.web : **/*.html,**/*.xhtml,**/*.cshtml,**/*.vbhtml,**/*.aspx,**/*.ascx,**/*.rhtml,**/*.erb,**/*.shtm,**/*.shtml
14:45:46.253 DEBUG: 'dev\migration\Home.cshtml' indexed with language 'web'

Is it not possible to analyse .cshtml files against the C# ruleset?

Hi @brett.postin,

Which scanner are you using ?


We are using the msbuild scanner.

It is difficult from the verbose logs to determine what files are actually scanned/dismissed by the sensors.

Just to clarify, is it expected that a file be analysed by multiple sensors, or does it only get analysed by the sensor it is indexed to?

To expand on the original query, we have a simple project containing an asp.net “webpage” (.cshtml) and for testing purposes an asp.net webforms page (.aspx + .aspx.cs).

Example issues have been copied from the rules browser into the .cshtml and .aspx.cs files.

We are actually seeing two issues:

  1. The .cshtml file and the .aspx file get indexed as “web”, and only HTML issues are detected. No C# issues are detected and it does not appear they are analysed by the C# analyser.

  2. The .aspx.cs file gets indexed as “cs”, but none of the example issues are detected and it does not appear that the file is analysed by the C# analyser.

Hello Brett,


Currently, it is only analysed by the sensor it is indexed to. There are a few exceptions to this, but rule of thumb is that a file will be analyzed by a single analyzer.

Following the previous answer, this is the expected behaviour. The .cshtml files are assigned to HTML sensor by default, as the C# analyzer would not be able to analyze them. This is due to the fact that our C# analyzer is based on roslyn and running at build time, which happens at a different time than the ASP.NET precompilation (if any). (C# analysis of these files should be possible inside SonarLint for VisualStudio)

This is definitely not the expected behaviour. .aspx.cs files should get analyzed normally.
Can you please share with us the following, so we can help you better:

  • Which versions of MSBuild and SonarScanner for MSBuild are you using ?
  • Which steps (command lines) you do to analyze your project
  • Could you please add /d:sonar.verbose=true to the begin step of the scanner, and share with us the full log of the end step


Thanks for the detailed explanation.

Firstly, are there any plans to support multiple sensors analysing a given file?

Secondly, in terms of the precompilation the asp.net webpages (.cshtml) are part of a modern sdk-based Web Application Project (not Website project). So compilation should be explicit ahead of time. In this case, assuming multiple sensors were supported, are there any other reasons why the C# couldn’t be analysed in the .cshtml files?

Background Information

We have an old “Website” project which we want to bring under SonarCloud analysis. As SonarCloud does not support Website projects, we have tried to workaround this by creating an sdk .csproj with wildcard patterns to include the desired files.

The hope was that we could build this project for SonarCloud analysis purposes only, in order to get complete SonarCloud coverage of our product lines.

This appears to work, and results are being submitted to SonarCloud, except with the gotchas outlined above.

Can you think of any additional unforeseen issues in this approach? Alternatively do you have any other suggestions as to how we could get the legacy Website project under analysis?

Hello Brett,

.cshtml Razor files
As Chris mentioned in his previous post, our analysis depends on build in Roslyn analyzer options. And that does not provide access to cshtml files during normal build time. No matter what kind of build do you use (build as precompiled or copy to output without any compilation).

This is currently the technical limitation we have. We will investigate HOW we could do the analysis, this topic is already on our radar for security analysis. After that we’ll have more information about what can be done to solve this problem.

Legacy Website

Adding csproj * file is a good idea to deal with this issue.

1 Like

@Pavel_Mikula security analysis is our primary reason for wanting this coverage so that’s encouraging to hear. Is there anywhere to follow progress on this?

With regards to the 1-to-1 mapping between file and sensor, this makes huge assumptions that codebases have perfectly clean content separation. The likelihood is that many codebases, especially legacy ones, will have inline css / inline javascript / mixed server and client side code (webforms?) etc.

This seems like a significant limitation, are there any plans to address this?

Hi Brett,

we currently don’t know HOW we’ll do it. We’ll have to investigate this topic and we’ll see.

Hi Bret,

Regarding the 1-to-1 mapping between file and sensor, we’d like to remove this constraint on long run. It was already specified for Vue.js scenario (see MMF-1441).

Hello @brett.postin,

Our plan is to scan .cshtml files mainly to detect XSS issues. This is what we gonna start to support thanks to https://jira.sonarsource.com/browse/MMF-1979. The good news is that we will work on it in the coming weeks.
We want to start by bringing ASP.NET MVC / Core MVC support and will extend this support to older frameworks if we see traction (and your request is well considered).

Once this step will be done, we will know how to scan properly .cshtml not for its HTML content but for its C# / Razor content and hopefully that opens the door to scan C# code itself.

When you are talking about “security analysis is our primary reason”. I guess you want to detect XSS issues. What else do you want to detect on .cshtml files?


XSS is the obvious catch given the nature of those .cshtml files. Though as any C# code can be written in the cshtml files it would be preferable to analyse the code with the same rulesets as any .cs file.

We have manual code review but obviously an automated tool helps police those changes, just as we enjoy with plain C# files.

Hi Brett,

do you still have the problem with .aspx.cs files not being analyzed? If yes, can you share some small sample project showing the overall situation?

With the .NET Core SDK 6.0 and above, more of this mixed construct will need to be supported. Being tied to a single sensor is possibly one of the most limiting architecture decisions I’ve seen.

XSS is not sufficient. This is .NET code that must be analyzed like any other similar code (probably most similar to aspx–although the model is a bit different).