Thanks. It looks like you can’t just include .csx files in a project to have them analysed by building the project with dotnet/MSBuild. This is nothing to do with the SonarScanner - it’s how the MSBuild/dotnet build targets work.
This isn’t unexpected: the compiler takes in source files to compile them to a single output assembly, and it calls the Roslyn analysers as part of the compilation pipeline. It expects all of the source files to contribute to the output assembly, and each source file needs to be a valid compilation unit.
.csx files can contain snippets of code that aren’t directly compilable. I had a look at the detailed build logs from your project, and dotnet does “see” the
Program.csx, but it adds it to the ItemGroup “None” so it isn’t passed to the compiler.
I don’t use C# script code so I’m not familiar with the tooling that’s available. There might be a way of running Roslyn analysers against files containing snippets of C# script code, but referencing them in a “normal” C# library project and invoking a normal build isn’t it.
.csx files analysed on SonarCloud that @Colin_SonarSource referred to, I suspect they are a red herring. The only
.csx files that have been analysed are ones that contain complete C# classes; the files containing partial code snippets have all of the code commented out.
My guess is that the user did pretty much what you did, but then had to change the snippets to be valid classes and changed the build action for the file to “C# compiler” i.e. the files are effectively just normal
.cs files, apart from the file extension: