Hi @ganncamp and @Andre_Hansen
We got a related request earlier from the community
I have introduced SonarCloud in my organization, and we would like to have a rule, that prevents having code dependencies on pre-release packages.
It doesnt seem to exist in the Sonar Rules base, does anyone know if such a rule is already there?
If not, what would it take to make a custom rule?
We created an issue to track the rule request here:
opened 01:46PM - 13 Nov 23 UTC
Type: Rule Idea
[Community request](https://community.sonarsource.com/t/rule-for-avoiding-pre-re… lease-packages-in-c/103876)
### Reasoning
Adding [pre-release](https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#pre-release-versions) 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](https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assemblyinformationalversionattribute?view=net-7.0)
Some packages like [Fody](https://nuget.info/packages/Fody/6.6.5-beta2) or [EF core](https://nuget.info/packages/Microsoft.EntityFrameworkCore/8.0.0-rc.2.23480.1) apply the Nuget version also to the assemblies via the AssemblyInformationalVersionAttribute. We could use [Compilation.References](https://learn.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.compilation.references?view=roslyn-dotnet-4.7.0) to find the AssemblyInformationalVersionAttribute via the metadata reader of the module of the PortableExecutableReference of external DLLs.
Pros:
* Would work in the IDE
* No "additional files" magic needed
Cons:
* We would warn pre "DLL" which is not the same as per Nuget package (A single package can contain multiple references, see e.g. [PDFsharp](https://nuget.info/packages/PDFsharp/6.0.0-preview-4))
* The message would be about some dll, which the user needs to map to the Nuget package. We need proper RSpec to help the user do so.
* We rely on the AssemblyInformationalVersionAttribute which is not present in all Nuget packages (e.g. [Syncfusion.Xamarin.Pdf](https://nuget.info/packages/Syncfusion.Xamarin.Pdf/17.3.0.9-beta)) or does not include the "pre-release" keywords (e.g. [GraphQL](https://nuget.info/packages/GraphQL/3.0.0-preview-1719))
* Where do we report the issue?
* Transitive dependencies would show up as well (packages depending on other packages or references caused by packages of a dependent project)
#### 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:
* We would get the version from the `<PackageReference Version>` attribute, which is the only reliable source of truth
* No problem with transitive dependencies and multiple DLLs per package
* We can report on the package reference in the csproj
* We can create other rules for csproj
Cons:
* We would rely on changes in the scanner (We need to add the csproj to the additional files, which would need changes in our scanner target file)
* This will likely not work in the IDE (maybe connected mode would work)
We also did a short investigation on how to implement such a rule in the .Net analyzer back then. We only checked how such issues are reported in the IDE but not on the SonarQube/SonarCloud servers. We should consider adding *csproj, *.config, *.sln, and similar files by default. Without such files, the code view on the server is missing important artifacts anyway.
The two rules shown by @Andre_Hansen are interesting. Unfortunately, they are very noisy with a high false positive rate. If we add such rules, they will have to be disabled by default, and users will need to opt in explicitly.