The short answer is very probably not. The longer answer with a couple of long-shot suggestions that you could try is as follows…
Our C#/VB rules are written as Roslyn analyzers, which means they need to be executed as part of the MSBuild phase by a Roslyn-based version of the compiler.
It’s been a long time since I looked at a web site project (and I don’t have an old enough version of VS installed to be able to create one to look at!), but I’ve had a look at some of the docs. A website project is normally compiled on the fly by the ASP runtime, but can be precompiled using
aspnet_compiler.exe doesn’t seem to support analysis of any kind. I’ve had a quick peek inside the exe, and it looks like it’s not using MSBuild to the build; it seems to be using the legacy System.CodeDom.Compiler framework classes directly.
I can think of two hacky approaches you could try, neither of which is particularly simple or guaranteed to work:
a) create a dummy MSBuild project purely for analysis purposes that references the files in the website directory. If you can cruft up a suitable project file that builds, you could then analyse that project using the Scanner for MSBuild. However, you might not be able to create a buildable project since the code generated by the
aspnet_compiler.exe won’t be available.
b) use the
aspnet_compiler to precompile the exe, then use the now-obsolete FxCop exe to analyse the binary(ies) that are produced. You’d have to install the community FxCop SonarQube plugin since FxCop is no longer supported by SonarSource.
However, you still don’t have an MSBuild project file so you still can’t use the Scanner for MSBuild. Instead, you’ve have to create an appropriate
sonar-project.properties file and call the command line Sonar Scanner directly.
Of the two options, (a) would be better if you could get it to work. It’s probably slightly less effort, and at least you would be running our up to date C# analysis rules rather than the legacy FxCop rules.
I’d be interested to hear if you can get something working!