Open martin-strecker-sonarsource opened 11 months ago
A PoC was implemented here
Important:
See how Analyzer.targets
adds the csproj to AdditionalFiles
and how the nuget spec adds the target file to the build
directory of the nuget
https://github.com/martin-strecker-sonarsource/ExampleAnalyzer/tree/master/Analyzer/Analyzer.Package
Still open to discuss:
targets
file is not picked up. But the scanner adds AdditionalFiles itself, so we may just need to change the scanner targets file.@martin-strecker-sonarsource Ideally you want to rely on additional files. However, is some cases, files are not available as such. You then still want to be able to do the analysis. This can be done by (also rergestering on the compilation action):
We did it like this: https://github.com/dotnet-project-file-analyzers/dotnet-project-file-analyzers/blob/main/src/DotNetProjectFile.Analyzers/Extensions/Microsoft.CodeAnalysis.Diagnostics.AnalysisContext.cs
Thank you, @Corniel. I looked at the project, and there are some interesting ideas about including some common files for the analysis.
@martin-strecker-sonarsource I know. I started a year ago with this project, and it has been successfully used within my company (and some others) already. I'm working on some rules for the .editorconfig
too, and consider adding rules for appsettings, but there nothing concrete yet has been implemented.
It would be nice if Sonar would support its output too, as mentioned: https://community.sonarsource.com/t/suport-roslyn-analyzers-on-additional-files/123957.
Community request
Reasoning
Adding pre-release package dependency to a project can cause maintainability and security issues. There is a high risk of changing or dropping APIs before a new stable version is released.
Description
Pre-release is a Nuget and not an assembly concept. There are two options for implementing this (further investigation is needed).
Use the AssemblyInformationalVersionAttribute
Some packages like Fody or EF core apply the Nuget version also to the assemblies via the AssemblyInformationalVersionAttribute. We could use Compilation.References to find the AssemblyInformationalVersionAttribute via the metadata reader of the module of the PortableExecutableReference of external DLLs.
Pros:
Cons:
Instrument msbuild in the scanner to add the csproj as an additional file
This would allow us to access the csproj (and reporting there should also just work).
Pros:
<PackageReference Version>
attribute, which is the only reliable source of truthCons: