Sonar .NET Ecosystem

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Alexandre Victoor added a comment -

done

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

Tested.

Show
Fabrice Bellingard added a comment - Tested.

People

  • Assignee:
    Alexandre Victoor
    Reporter:
    Alexandre Victoor
Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: