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
Related
Structural search in IntelliJ IDEA is not only powerful, but also not trivial at all to get right. Now when I have created a working template of my own, I might want to use it in multiple projects.
I do not see a way to save globally. Is there anything I can do short of copying the relevant bits from one workspace.xml to another?
Unfortunatelly, it's not supported at the moment, please follow this feature request for updates.
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.
Is there a way to do so ? I searched Google but couldn't find any answer, so I guess the answer would be no. Is there anything close ? If not, would it be easy to extend red-lang to do so ?
From http://www.rebol.com/docs/setup.html
Startup Scripts
When REBOL starts it will automatically run the rebol.r and user.r files, if they exist.
The system looks for these files first in the current directory (or the directory of the script being run), then in the directory that contains the REBOL executable program.
Note that REBOL/Core runs fine without the rebol.r and user.r files. They simply provide an easy way to include additional code and data on startup, such as your network preferences.
If you compile your own Red interpreter you can add an autoloading file, maybe in console.red after system/console/init "Red Console" and before system/console/launch Best advice is to ask on the https://gitter.im/red/help site to ask for help. I guess this was already discussed.
By default all I get in intellisense are the functions and its signature. I would prefer if I could also get documentation with the intellisense. I realise that I am supposed to place an xml file that contains this documentation along with my dll.
From where can I get this is file? Or is there some other way for me to achieve this?
For the immediate future, there's no way to get the XML documentation short of grabbing the Structuremap source and building it yourself.
As for why that's not included with the distribution, I'm not sure. My only guess is that back when xml-based configuration with SM was more prevalent, Jeremy was concerned about confusion between StructureMap.xml the intellisense file, and StructureMap.xml the configuration file.
That's pure speculation however. For the real scoop you'd have to post on the SM-mailing list. Regardless, for the time being, you have to roll your own from the source. I've done this as well for the same reason, and it wasn't too painful.
-Scott
Edit - Instructions for doing this follow.
Using your favorite SVN client (if you don't have one, I recommend TortoiseSVN) grab the latest from https://structuremap.svn.sourceforge.net/svnroot/structuremap/trunk/ . If you want the same bits that are in 2.5.3, I think you'll want revision 234. Otherwise, just grab the head and build from that. (If you aren't familiar with SVN, find a tutorial that explains what I'm talking about)
Open up the StructureMap solution in Visual Studio (under the Source subdirectory). Right click the StructureMap project, Go to Properties > Build and ensure the option for XML output documentation is checked.
Build and enjoy.
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.