We’re using SonarCloud integration with Azure DevOps and PRs are having comments from SonarCloud scan. Our project is written in C# and we have CQRS library which has Apply methods in Aggregates. Those Apply methods are being called when there is an event occurred. Apply methods are called but it looks like unused. Scan results are correct. We want to keep S1144 and at the same time we don’t want to see comments for those Apply methods.
We could suppress S1144 warnings but we don’t want to do it manually in all Apply methods that we’re implementing. Suppressing S1144 generally in solution will also suppress other issues and we don’t want to suppress all S1144 issues. We’re looking for general solution to override/suppress rule for specific method names.
Is there any way to configure rules with method names that will be excluded from scans?
It’s not possible to suppress these issues based on the method name.
It might be useful for you to provide some specific code samples where the issue is raised (and it shouldn’t) so we can see if a more general solution is possible (fixing the false positives, rather than applying a band-aid).
You can find a sample project here: GitHub - dogukandemir/S1144FalsePositiveSampleProject
In TestAggregate class there are 2 private methods with the following names and signatures:
private void Apply(UpdateTestDataEvent event)
private void Apply(TestAggregateCreatedEvent event)
Both of these Apply methods are called by AggregateRoot class when ApplyChange methods are called with matching type parameter. This AggregateRoot class comes from an open-source library.
Even both Apply methods are called by that library by calling Invoke method on aggregate base class, those are caught by SonarCloud as unused methods. We’re using this pattern heavily and it creates so much noise in PRs. We don’t want to disable S1144 rule but at the same time we don’t want to see PR comments for the methods that are called by Invoke from it’s base class.
An alternative would be a suppression of the rule at the file level using .editorconfig.
Related to this rule, we have a few exception that are documented on the rule description but no way for the user to extend them.
An option would be to implement a new exception for
Apply methods from types derived from
AggregateRoot that have one single parameter that implements
CQRSlite.Events.IEvent. This is very specific, we’ll have to discuss with the team if this makes sense for us.
I had a similar ‘problem’. I solved it by making my
Apply methods internal.