SonarQube C#
  1. SonarQube C#
  2. SONARCS-162

CSharp Plugin does not support Linked Resources

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      In .Net, it is possible to add a source file as a link (file is visible in Visual Studio but kept at the original location). When the project is analysed in sonar, the source files are not imported but the violations are there. So it's impossible to know where the violation was found.

      In the project file (csproj) the source file is referenced like this:

      <ItemGroup>

      ...

      <Compile Include="..\..\..\CrmCommon\AbstractFactory.cs">
      <Link>CrmCommon\AbstractFactory.cs</Link>
      </Compile>

      ...

      </ItemGroup>

      ie: In visual studio I have a folder called CrmCommon that contains the file AbstractFactory.cs, but its location on disk is ..\..\..\CrmCommon\AbstractFactory.cs relative to the project.

      We use this functionality to "embed" common code within an Assembly as it is deployed within a database and it needs to be self-contained.

      Also it is not possible to exclude the files either (I thought I might at least get rid of the violations if I cannot see where they come from). I tried general patterns like */CrmCommon/.cs without success.

      Thanks

        Activity

        Hide
        Daniel Beland added a comment -

        I checked out the source code to see if I could fix the problem and submit a patch, and I'm surprised to find a test that makes sure linked resources are ignored.

        ModelFactoryTest.testSolutionWithLinks

        Is there a reason for this?
        I mean for me it makes more sense to include all resources including linked resources. Then if you don't want to see it (it may be part of another sonar project), then simply exclude it.

        Cheers

        Show
        Daniel Beland added a comment - I checked out the source code to see if I could fix the problem and submit a patch, and I'm surprised to find a test that makes sure linked resources are ignored. ModelFactoryTest.testSolutionWithLinks Is there a reason for this? I mean for me it makes more sense to include all resources including linked resources. Then if you don't want to see it (it may be part of another sonar project), then simply exclude it. Cheers
        Hide
        Alexandre Victoor added a comment -

        Hello
        Yes there is a very good reason for this !
        A file cannot be present several times in sonar resource tree.
        A C# file may be linked several times inside a VS solution.
        At the very beginning of the C# plugins, links were taken in account and because of that many analysis were failing.

        Show
        Alexandre Victoor added a comment - Hello Yes there is a very good reason for this ! A file cannot be present several times in sonar resource tree. A C# file may be linked several times inside a VS solution. At the very beginning of the C# plugins, links were taken in account and because of that many analysis were failing.
        Hide
        Fabrice Bellingard added a comment -

        I think that this certainly has been done because Sonar Core does not know how to handle resources out of the project scope. (=> what would be the id of such resources ?)
        The C# plugin can't do anything about that.

        I think that it would be necessary to modify the plugin to make sure that violations reported for such files are not pushed into the DB. I can understand that this is a real problem to have then reported at project level but to not be able to locate them.
        (Actually, from a general point of view, those violations should appear on the "real" project that contains those external files, not on other projects that include them)

        Show
        Fabrice Bellingard added a comment - I think that this certainly has been done because Sonar Core does not know how to handle resources out of the project scope. (=> what would be the id of such resources ?) The C# plugin can't do anything about that. I think that it would be necessary to modify the plugin to make sure that violations reported for such files are not pushed into the DB. I can understand that this is a real problem to have then reported at project level but to not be able to locate them. (Actually, from a general point of view, those violations should appear on the "real" project that contains those external files, not on other projects that include them)
        Hide
        Daniel Beland added a comment -

        I think I understand the problem, but the way I see it sonar shouldn't know what the actual file is. I mean we link a file from a different directory into the project, the "virtual" name of the file should be as it appears in visual studio. It's only the file contents that need to be retrieved somewhere else in the file system.

        Sometimes those files may not be part of another project on its own, so I'd like to be able to include them as part of the project if I want. I suppose we could add a property (default to false) to be able to include them.

        I'm playing around a bit trying to understand how the plugins work. If I can find a nice way to include what I want without breaking anyone else's projects I'll submit a patch.

        Show
        Daniel Beland added a comment - I think I understand the problem, but the way I see it sonar shouldn't know what the actual file is. I mean we link a file from a different directory into the project, the "virtual" name of the file should be as it appears in visual studio. It's only the file contents that need to be retrieved somewhere else in the file system. Sometimes those files may not be part of another project on its own, so I'd like to be able to include them as part of the project if I want. I suppose we could add a property (default to false) to be able to include them. I'm playing around a bit trying to understand how the plugins work. If I can find a nice way to include what I want without breaking anyone else's projects I'll submit a patch.
        Hide
        Daniel Beland added a comment -

        I can see now how the csharp plugins must work with the sonar Project and it is now as easy as I thought.

        I think the fxcop and gendarme plugins should be modified to stop reporting violations on null resources and it would fix my problem.

        Show
        Daniel Beland added a comment - I can see now how the csharp plugins must work with the sonar Project and it is now as easy as I thought. I think the fxcop and gendarme plugins should be modified to stop reporting violations on null resources and it would fix my problem.
        Hide
        Alexandre Victoor added a comment -

        Ok I see your point now
        This will be fixed asap

        Show
        Alexandre Victoor added a comment - Ok I see your point now This will be fixed asap
        Hide
        Fabrice Bellingard added a comment -

        Alex, be careful on that: null resources may indicate that the violation is at project/assembly level (I mean, truly - not by default), or IIRC, it may also be the case for Web sites where *.cs files are compiled into several DLLs (without always being able to find to which file a violation is associated).

        So IMO, we should be cautious with this fix.

        Show
        Fabrice Bellingard added a comment - Alex, be careful on that: null resources may indicate that the violation is at project/assembly level (I mean, truly - not by default), or IIRC, it may also be the case for Web sites where *.cs files are compiled into several DLLs (without always being able to find to which file a violation is associated). So IMO, we should be cautious with this fix.
        Hide
        Alexandre Victoor added a comment -

        Fabrice, in the situation described by Daniel, the location of the violation in the source code is given by a pdb file. The sonar resource is null because the path of the cs file does not match to anything known by the bridge component.

        Show
        Alexandre Victoor added a comment - Fabrice, in the situation described by Daniel, the location of the violation in the source code is given by a pdb file. The sonar resource is null because the path of the cs file does not match to anything known by the bridge component.
        Hide
        Fabrice Bellingard added a comment -

        Tested.

        Show
        Fabrice Bellingard added a comment - Tested.

          People

          • Assignee:
            Alexandre Victoor
            Reporter:
            Anonymous
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: