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

Configuration mechanisms of gendarme and fxcop plugins for assemblies locations

    Details

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

      Description

      Right now there are two pairs of configurations keys duplicated between these two plugins :

      1. sonar.fxcop.assemblies, sonar.fxcop.assemblyDependencyDirectories
      2. same thing for gendarme

      These properties are specified at the Visual Studio solution level, whereas now fxcop and gendarme are launched once for each project of a solution.

      Also, usage of relative paths must be documented in the wiki.

        Activity

        Hide
        Alexandre Victoor added a comment - - edited

        In order to be able to specify several assemblies at project level, and not a solution level, flat key/value properties files are not rich enough.
        Considering using json into those files.
        http://wiki.fasterxml.com/JacksonInFiveMinutes

        Using Jackson it would be very easy to implement the following conf structure :
        sonar.dotnet.assemblyDependencyDirectories=

        {"projectName":["SomeAssembly.dll"],"secondProject":["foo.dll","bar.dll"]}
        Show
        Alexandre Victoor added a comment - - edited In order to be able to specify several assemblies at project level, and not a solution level, flat key/value properties files are not rich enough. Considering using json into those files. http://wiki.fasterxml.com/JacksonInFiveMinutes Using Jackson it would be very easy to implement the following conf structure : sonar.dotnet.assemblyDependencyDirectories= {"projectName":["SomeAssembly.dll"],"secondProject":["foo.dll","bar.dll"]}
        Hide
        Marko Lahma added a comment -

        For same cases that could be even overly complex (even though powerful). A solution usually contains related projects which have the tendency to refer to same set of libraries.

        Say you have 20 external lib dependencies (20 dlls) and each project would refer to 50% them, some more specific ones like web or data access. In this case if you'd only have to point to some dir (or even wildcards like lib/*/.dll) you'd just be saying to analyzer that "look there, might be more than you need but at least they're there).

        I'd say it's rarely the case that you would need to say "don't use dll found in this directory, even though the analyzed assembly refers to it". They usually are the correct ones to link to.

        In short, I'd prefer to point to lots of dlls and tell analyzer to use what it needs for whichever project. And this configuration should be easy to end user too.

        I believe VS project already tells the mandatory dependencies (the format you suggest) so it's already there. The problem for us is that we have lib dir (and sub-dirs) that are not copied to project's output directory (copy local = false, for performance reasons) so we need to tell analyzer the original location of dependency (lib and its sub-dirs).

        Show
        Marko Lahma added a comment - For same cases that could be even overly complex (even though powerful). A solution usually contains related projects which have the tendency to refer to same set of libraries. Say you have 20 external lib dependencies (20 dlls) and each project would refer to 50% them, some more specific ones like web or data access. In this case if you'd only have to point to some dir (or even wildcards like lib/* / .dll) you'd just be saying to analyzer that "look there, might be more than you need but at least they're there). I'd say it's rarely the case that you would need to say "don't use dll found in this directory, even though the analyzed assembly refers to it". They usually are the correct ones to link to. In short, I'd prefer to point to lots of dlls and tell analyzer to use what it needs for whichever project. And this configuration should be easy to end user too. I believe VS project already tells the mandatory dependencies (the format you suggest) so it's already there. The problem for us is that we have lib dir (and sub-dirs) that are not copied to project's output directory (copy local = false, for performance reasons) so we need to tell analyzer the original location of dependency (lib and its sub-dirs).
        Hide
        Alexandre Victoor added a comment - - edited

        Thanks a lot Marko
        I understand that you would like to see two things :

        1. wildcard support
        2. global configuration for each project of a solution in addition to specific project configurations

        Is that correct ?

        Show
        Alexandre Victoor added a comment - - edited Thanks a lot Marko I understand that you would like to see two things : wildcard support global configuration for each project of a solution in addition to specific project configurations Is that correct ?
        Hide
        Marko Lahma added a comment -

        Yes, I know at solution level that all my project respect pattern lib/*/.dll from solution root point of view. My projects might be scattered on different levels of sub-folders so I'd like to specify this as solution level wild card.

        Show
        Marko Lahma added a comment - Yes, I know at solution level that all my project respect pattern lib/* / .dll from solution root point of view. My projects might be scattered on different levels of sub-folders so I'd like to specify this as solution level wild card.
        Hide
        Alexandre Victoor added a comment -

        Implementation is 99% done. Former parameters need to be handle properly and doc on the wiki needs to be updated.

        Show
        Alexandre Victoor added a comment - Implementation is 99% done. Former parameters need to be handle properly and doc on the wiki needs to be updated.
        Hide
        Alexandre Victoor added a comment -

        done

        Show
        Alexandre Victoor added a comment - done
        Hide
        Fabrice Bellingard added a comment -

        Tested.

        Show
        Fabrice Bellingard added a comment - Tested.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: