codacy / codacy-sonar-csharp Goto Github PK

The configuration file is running with all available patterns instead of the specified due to reading it in the wrong path.

CodacyCSharp.Analyzer.Utilities.RuleFinder is using some functionality in SonarAnalyzer.Common.AnalyzerLanguage that were removed in SonarSource/sonar-dotnet#5662.

We are currently seeing multiple issues being reported in our code, caused by bugs in SonarAnalyzer.CSharp that has already been fixed in newer versions.

Currently the engine is on 5.x which lacks support for C# 7.0. Support was introduced starting Sonar 7.5.

Sonar C# is asking to remove the using statement but it's required for System.Uri

using System;

namespace Users
{
    public class UserRecord
    {
        public UserRecord(
            string authId,
            string email,
            string displayName,
            **Uri** photoUrl,
            CustomClaims customClaims,
            bool isDisabled)
        {
            AuthId = authId;
            Email = email;
            DisplayName = displayName;
            PhotoUrl = photoUrl;
            CustomClaims = customClaims;
            IsDisabled = isDisabled;
        }

        public string AuthId { get; }
        public string Email { get; }
        public string DisplayName { get; }
        public **_Uri_** PhotoUrl { get; }
        public CustomClaims CustomClaims { get; }
        public bool IsDisabled { get; }
    }
}

Not sure whether it's the right place to report it, I tried below keywords without luck.
// NOSONAR
// eslint-disable-line no-eval

Temporary config file should be with the same name, otherwise parameters don't work.

Also, the logic about the config file is not working properly. When patterns exists on .codacyrc, should ignore tool config file, except if the user request it.

We want to start identifying security issue categories, therefore we should include this in the patterns.json file.

As referred here: codacy/codacy-tsqllint#1 (comment)

Currently the tool has versions coded in a nonstandard way.
It has in:

• In a .SONAR_VERSION
• Hardcoded in a path

The version should be instead in one single place (the csproj file)

Not sure if this is the correct place, but as it's csharp related I opted to create it here.

Later releases of the .NET SDK ships with a integrated codeanalyser, roslyn.

From https://learn.microsoft.com/en-us/visualstudio/code-quality/install-net-analyzers?view=vs-2022

NET compiler platform (Roslyn) analyzers inspect your C# or Visual Basic code for code quality and code style issues. The first-party .NET analyzers are target-platform agnostic.

Is there any feature requests/work currently in adding support for the roslyn analyser in codacy?

It looks like this project is missing a massive number of sonar patterns. I believe this could be fixed by simply running https://github.com/codacy/codacy-sonar-csharp/blob/f4aca01560f918c194c60e02fa70276264cd1b5a/scripts/update-docs.sh and updating the repository.

An interface is defined in a separte file. A unittest has a mocked implementation of that interface, with parts of the mock throwing a NotImplementedException.

Using codacy, sonar warns S1144 (remove unused member) and S2325 (make implementation static) for the not implemented members. Both are false positives as the member must be there and it cannot be static.

The warning doesn't occur with the sonar plugin for visual studio.

I've tracked that down to the fact, that codacy-sonar-csharp creates a new solution for each file, so effectively it's a file by file and not a solution wide analysis. As the interface definition is not present, the sonar analyzer treats the interface as empty and then the reported error makes sense.

The false positive in my solution

See also my original issue on sonar-dotnet, which is already closed.

Make sure it's clear the configuration files we support for this tool (AnalysisInput and not RuleSet structures)

I just added codacy to one of my .NET projects and it's really awesome. It provides a lot of useful information, however after running the analysis I get a lot of false positive issues on the make Method a static method rule. There are two scenarios I see issues for this rule that don't make sense. The first one is classes that implement an interface. Interface implementations must be instance methods, so this rule should not apply to those methods. Secondly, I have hundreds of these issues in my test projects. Test methods must be instance methods for the test framework to run them, so this rule should not apply to test methods.

I can deal with the false positives on interface implementations, but getting having to deal with the test issues becomes unwieldy and floods my codacy dashboard with noise, making it not very useful. Is there a way to disable a specific rule for a project for a filename pattern?