Using 8.4.1.35646 of SQ, JS and C# scanners mostly
what are you trying to achieve: keeping my loc count down
what have you tried so far to achieve this: upgrading to 1m loc It’s not enough, however.
In accordance with good practice, we have common VS projects which are shared across solutions, e.g. a MyCompany.Common namespace, containing 10k lines of code.
The common project is used in SolutionA, and SolutionB. SolutionA is 15k loc and SolutionB is 25k loc, giving me a total loc count of 40k
When analysing these in SonarQube, the total loc is also 40k, despite the same code (MyCompany.Common) being, well, common. I understand that the loc count isn’t affected by different branches, but double-counting the same project seems a bit off, unless I’m missing something?
Do I need to reconfigure my builds, perhaps? I have had a look around at the documentation and forum and can’t find anything that suggests a way of doing it…
Hello - we have SolutionA and SolutionB in one SQ project, SolutionA and SolutionC in another SQ project, and Solution B and SolutionD in another SQ project
In that case, you should have each Solution in a separate SQ project. You can have multiple begin/end scanners steps in a single build around your solution builds.
Like that, it will fix your LOC problem and enable independent management of each solution. Imagine you introduce some issueX in SolutionA while working on SQProject1:
There will be an issue in your SQProject1 and second duplicate in SQProject2
Somebody can investigate and close the SQProject1/SolutionA/issueX as FP or Won’t fix
Somebody else will have to manage the SQProject2/SolutionA/issueX and can use different state that would lead to inconsistency.
SQ projects are isolated by design. Imagine you have two different departments working on different projects with coincidently same names, unaware of each other: \\server1\d\projects\common\file.cs \\server2\d\projects\common\file.cs
There’s no way to merge these d:\projects\common\file.cs on SQ side even when it’s really the same file, because they’re analyzed in different point in time and have different content/configuration/issues from SQ point of view.
There are other ways how to deal with it (like exclusions) but those have significant drawbacks.