-
Notifications
You must be signed in to change notification settings - Fork 849
Description
Description
The Microsoft.Extensions.StaticAnalysis package currently references fairly old versions of its dependent analyzer packages.
As of version 10.0.0, it lists:
- Microsoft.VisualStudio.Threading.Analyzers (>= 17.10.48) (from 5/1/2024)
- SonarAnalyzer.CSharp (>= 8.56.0.67649) (from 4/18/2023)
However, both of these have much more recent versions:
- https://www.nuget.org/packages/SonarAnalyzer.CSharp/10.16.0.128591 (from today)
- https://www.nuget.org/packages/Microsoft.VisualStudio.Threading.Analyzers/17.14.15 (from 6 months ago)
This means that by default, when consuming the Microsoft packages, we are subject to many bugs and issues from those dependent libraries that have since been resolved.
It could also mean that Microsoft.Extensions.StaticAnalysis is missing some new rules that could be useful to be enforced as part of the library.
Reproduction Steps
- Install latest version of
Microsoft.Extensions.StaticAnalysis - Observe that very old bugs from the dependent Sonarqube analyzer are still present
Expected behavior
Microsoft.Extensions.StaticAnalysis should bring up-to-date dependencies of its child analyzers (preferably the most up-to-date possible version compared to when it is released).
Actual behavior
Microsoft.Extensions.StaticAnalysis brings very old versions of its dependent analyzers.
Regression?
From what I can see, the packages were initially added when Microsoft.Extensions.StaticAnalysis was created, but then never maintained.
Known Workarounds
For now, I'll just add the latest versions of both dependent packages explicitly on our Directory.Packages.props file. Since we are using the CentralPackageTransitivePinningEnabled setting, this should be easy enough to manage.
Configuration
Not relevant.
Other information
I started experimenting with adding Microsoft.Extensions.StaticAnalysis to one of our smaller solutions with the intent to later expand its usage to more projects on our company.
After adding and configuring the package, I started to fix the violations and quickly stumbled upon this issue:
Since we are using primary constructors in many places, it was affecting us significantly. Initially, I thought it must just be an unsolved bug in the Sonar analyzer, but then I noticed it had already been fixed, but on a version that is much more recent than the one referenced by Microsoft.Extensions.StaticAnalysis.
I believe it would be beneficial if Microsoft made sure that whenever there was a new release for Microsoft.Extensions.StaticAnalysis (like the very recent 10.0.0) that the dependent analyzer libraries were also updated to their latest versions. This would reduce maintenance on consumers as they wouldn't necessarily need to explicitly include the most up-to-date versions of the dependencies in their packages.