Exclusions in a multi-module C# project

Get help SonarQube
,
#1

Hello, I am trying to use soner.exclusions to skip analysis on a particular folder. I have a folder structure as follows. This is the contents of a git repo that has a Visual Studio solution at the root. Many of the sub folders are individual Visual studio sub projects (csproj)

FolderA
     SubFolder
     Utilities
FolderB
     FolderB.1
           Utilities
Utilities
     Utility1
     Utility2

I want to exclude everything under the top level utilities folder.

I have tried “**\Utilities**” but doing that excludes the other folders with similar names.

I have tried “Utilities***”, but doing so results in the warning
“Specifying module-relative paths at project level in the property ‘sonar.exclusions’ is deprecated. To continue matching files like ‘Applications/CometTray/Utilities/CommonConnectivityManager.cs’, update this property so that patterns refer to project-relative paths.”

Any guidance on how I can specifically exclude the one folder tree but not any other folders with similar names? It seems like the rules are evaluated from the root of every visual studio project, not from the root of the solution/repo

thanks :slight_smile:

#2

Hi,

Welcome to the community!

There are two things of note here. First, exclusions need to exclude files. And ** means 0-n directories. What you want is **\Utilities\**\*.* or perhaps Utilities\**\*.*

 
HTH,
Ann

#3

Thanks @ganncamp,
I have a question. If i tried ‘Utilities**.’, what is Utilities relative to

  1. Relative to the root of the repo / solution?
  2. Relative to where the soner-project.xml file is that contains the rules?
  3. Relative to each project in the visual studio solution?
#4

Hi,

Ehm… So an exclusion starting with ‘Utilities’ is going to be relative to project/analysis root, which should work based on what you provided above. Suggesting **\Utilities\ was just a belt-and-suspenders kinda approach on my part.

TBH, I don’t know the effect of Utilities** since I read that as Utilities[0-n dir] which… I think wouldn’t resolve to anything.

 
HTH,
Ann

#5

If i make the path ‘Utilities**.’, I get a warning like shown below about one of the child directories in which I don’t want the rule to be applied to

Specifying module-relative paths at project level in the property ‘sonar.exclusions’ is deprecated. To continue matching files like ‘Applications/CometTray/Utilities/CommonConnectivityManager.cs’, update this property so that patterns refer to project-relative paths.

#6

Okay, but does it have the desired effect?

TBH, I think that warning is vestigial and not really appropriate here.

 
Ann

#7

it did not have the desirable affect.

I believe this is what worked. I’m trying it out now

.\Utilities\**\*.*

The combination of prefacing with .\ and trailing with *.* might be the magic combination

#8

Hi,

To be clear, no pattern is going to work without *.* at the end, since that’s the part that actually specifies files.

 
Ann

#9

Thanks Ann. That definitely helped. I’m just not clear on how to get the rule to apply to the Root only, and not any subfolders. The documentation isn’t very clear here and a path like Utilities\**\*.* has undesired side effects of applying to any subfolders that have a Utilities folder

#10

Hi,

I’m confused.

So… I guess you didn’t mean recursive then?

That’s easy:

Utilities/*.*

 
HTH,
Ann

#11

@ganncamp When i try that, it would exclude both of the folders below. We don’t want it to exclude the first one.

  1. FolderA\FolderB\Utilities…
  2. Utilities…
#12

You know, the interface, which is what I recommend using, allows you to add multiple exclusion specifications. You can also specify multiple, comma-delimited exclusions.

 
Ann

#13

@ganncamp I am using the rules on the website as shown below.

image
image751×286 7.29 KB

Again, I guess what i’m saying it it either seems like a) there is a bug on SonarQube in how in interprets the rules, or b) I’m looking for advice for how to write the rule correctly.

You can see that I have a rule of Utilities/**/*.*
That rule correctly ignored all of the code in Utilities/FolderA/file.cs
However, that rule also incorrectly ignored the code in SubProject/Utilities/Folder2/file.cs

It seems to me that the rule is applied to every CSProj folder that occurs within a visual studio solution.

Does my problem make sense? It’s frustrating to me that I can’t get this to work.

#14

Okay! You actually do have a multi-module project! I missed that before; thought the error message you were seeing was entirely tangential.

How do you analyze? Is this a Maven project? C#?

 
Ann

#15

@ganncamp I’m happy that there is an understanding of the situation now.

We are using a Visual Studio solution with C#. Essentially we do the following

  1. Run the SonarQube Begin
  2. Compile the entire visual studio solution (sln) which is made of of multiple projects (csproj)
  3. Run our unit tests
  4. Run the SonarQube End statement

Do i need to do something specific to configure the multi-module project?

#16

Hi @ganncamp. Hope you had a nice holiday. I’m checking in on what needs to be don’t to properly configure a visual studio solution as a multi-module ?

#17

@ganncamp I’m checking one last time on this. What is the guidance for these “multi-module” visual studio projects. All of our projects use this and if it’s not supported well, I need to know so that I can look for alternatives.