SonarQube Scanner for MSBuild 4.0.2
SonarQube Server 6.7.1
SonarC# 6.7.1
I am trying to exclude files with a specific pattern, e.g. when I find a hint to a 3rd party contribution in a source.
I pass following parameters
/d:sonar.issue.ignore.allfile=ExcludeStuff
/d:sonar.issue.ignore.allfile.ExcludeStuff.fileRegexp="Vendor.*Name"
So I am seeking to catch all files that have "VendorName", "Vendor Name" or "Vendor Name" in their content.
In the SonarScanner end step I get outputs like
INFO: '<filename...>' generating issue exclusions
for almost all files -- I have failed understand which files produce that output. I do not see a relation to the regex pattern.
Eventually the summary is always that all files are indexed and none are excluded.
So here are my specific questions:
How can I tell whether or not a files is excluded for all issues?
What is the correct syntax of the regex?
Is there a working example / documentation on the sonar.issue.ignore.allfile stuff?
I cannot use sonar.exclusions because due to the path structure I would need absolute paths which are -- for whatever reason -- not available in the scanner anymore.
I spent quite some time doing research on the sonar.issue.ignore.allfile usage without success. Perhaps I have missed it, but I would gladly take any advice.
Related
I am writing a program in Java for a university project, part of the write up report states:
'You must provide listings for your program'
Can anyone provide me with some clarification on what is meant by this?
I have looked high and wide online but nothing i've come across has helped clear this up for me. I found a definition 'With computer programming, a program listing is the complete listing of a computer program, source code, and all files that make up the software program', but his hasn't helped with my understanding of what is being asked in the report.
Should I be providing screen-grabs of my code? Or a screen-grab of the folder with all related files?
Any help would be appreciated, thanks.
A listing of your program used to mean the code of your program rendered into printed form; i.e. on paper. These days, it could also mean that the source code is formatted and included as a PDF file, or a Word document or something else.
Should I be providing screen-grabs of my code?
It is unclear if that is what your lecturer wants. I don't expect so, because screenshots are harder to read than formatted text.
Or a screen-grab of the folder with all related files?
That is highly unlikely, IMO. If that is what your lecturer wanted they would have said "directory listing" not "listings for your program". (And that would be useless for assessment purposes.)
But my advice is to ask your lecturer if you are at all unclear what is required of you.
And if your lecturer is unwilling to explain, just do what you think is correct.
What you find is correct, you need to give source code and any other resources needed to build and run the softaware.
One options could be to :
- pack my project with some build manager (maven, gradle, etc)
- push it to some repository (like github) with a README.md for building and running
- give the github project reference.
If you prefer not to make public the code, just pack it and send an archive with the maven project.
They are looking for a nice printed output of your source code. In olden days (pre 2K) compilers would produce a output, well formatted (often with a list of symbols and line number to aid in understanding the code.
Latest:
This is definitely a bug in msbuild. Other than that there cannot be any other explanation. This could only be happening on Linux or possibly on a wider range.
So i decided to just build one single project with absolutely no dependencies on others in the solution.
Looking at the captured diagnostics, I see these lines which are very promising:
Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
Input files: Annotations.cs;Auth.cs;AuthorizationConfig.cs;Backend.cs;Billing.cs;Code.cs;...
Output files: .obj/TheAgent.dll;.obj/TheAgent.pdb
Set Property: NoWarn=;1701;1702
15:23:27.396 1>Done building target "CoreCompile" in project "TheAgent.csproj".: (TargetId:40)
It looks like my dll and my pdb weren't built which is what I expected.
However, something must be happening before or after causing the timestamp to change (be that of this build time and not the last).
The timestamp of the dll is updated both in the intermediate object folder (.obj/) and also in the output folder.
Is there a known way of stopping msbuild right after its CoreCompile task?
Update:
I decided to search for is newer this time and found instances of these. I don't know how they have got to the solution/project files though:
Input file ".obj/Common.csproj.CoreCompileInputs.cache" is newer than output file ".obj/Common.pdb".
Further to the above, I came across this:
https://github.com/dotnet/project-system/issues/4736
Thinking that this was the issue, I upgraded to dotnet sdk version 2.2.402.
The end result is still the same :(
Original:
I need some pointers on how to troubleshoot this issue. I am using /t:build to build a solution file.
The resulting executable keeps getting refreshed each time.
First i thought the package restore was causing this. I have removed that step however it didn't make a difference.
Then I looked at this:
https://oz-code.com/blog/visual-studio-keeps-rebuilding-projects-no-good-reason/
I'm basically looking for some text in the diagnostics output which tells me if a target or a file is out of date and needs to be rebuilt. The above link talks about "project 'B' is not up to date". I don't have a not up to date in my msbuild output.
I already had two resources with CopyAlways which I changed to CopyIfNewer.
The above article also talks about circular dependencies. I am checking everything manually. And yes the references to dependent project are actually references to the project outputs (dll's /exe's). So Finding a circular dependency by just checking for that pattern seems a little odd.
There was one more problems in the dotnet platform and/or msbuild causing this to fail.
One of those was this https://github.com/dotnet/project-system/issues/4736
Installing SDK 3.0.100-preview7-012821 or better solved the problem
I've been trying for a number of days now to exclude some files from a sonarqube scan. I have tried editing the exclusions list in the sonarqube UI, and passing them as a /d:exclusions parameter to SonarScanner-start.bat but nothing is working. This is the file I'm trying to exclude : Content/bootstrap/js/bootstrap-datepicker.js. Sonarqube insists on reporting this as a critical bug in the UI, despite my best efforts. Please can someone let me know how I can exclude this from the analysis.
The name of the property is sonar.exclusions and I suspect if you set it like this it should work:
/d:sonar.exclusions=**/bootstrap-datepicker.js
There are some examples for patterns here:
https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus#NarrowingtheFocus-Patterns
If this does not help, please, edit your answer to include the full command line of SonarQube.Scanner.MsBuild.
I'm working with gendarme for .net called by Sonar (launched by Jenkins).
I've a lot of AvoidVisibleFieldsRule violations. The main violations are found in the generated files. As I can't do anything on it, i would like to exclude *.designer.cs from the scan.
I can't find a way to do that. There is a properties in Sonar to exclude generated files but it doesn't seem to be applied for gendarme.
Is there a way to do such a thing ?
Thanks for all
Gendarme expects you provide an ignore list,
http://www.mono-project.com/Gendarme.FAQ
https://github.com/mono/mono-tools/blob/master/gendarme/self-test.ignore
The ignore file format is bit of weird, but you can learn it by experiments.
Indeed that is actually not normal at all. Generated code is excluded by the plugin with the standard configuration. What version of the C# plugins are you using ?
Anyway, the configuration property you can try is "sonar.exclusions" (see http://docs.codehaus.org/display/SONAR/Advanced+parameters).
If you do not solve your problem right away, the best thing would be to drop a mail to the user mailing list (see http://www.sonarsource.org/support/support/) and send the verbose output of your build. To get this output simply add "-X" to the command line.
Hope it helps
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.