SonarException: Unknown metric: temp-method-lines - c#

I was searching for answer many hours but I haven't found any solution.
I'm running sonar for C# project, I using Sonar 3.4 and sonar-runner 2.0 and C# plugins:
sonar-csharp-core-plugin-1.4
sonar-csharp-fxcop-plugin-1.4
sonar-csharp-gallio-plugin-1.4
sonar-csharp-gendarme-plugin-1.4
sonar-csharp-ndeps-plugin-1.4
sonar-csharp-squid-plugin-1.4
sonar-csharp-stylecop-plugin-1.4
and after running the analysis by sonar-runner I getting that exception
Exception in thread "main" org.sonar.runner.RunnerException: org.sonar.api.utils.SonarException: Fail to decorate 'org.sonar.api.resources.File#243e2c21[key=ApplicationName.cs,dir=,filename=ApplicationName.cs,language=C#]'
at org.sonar.runner.Runner.delegateExecution(Runner.java:288)
at org.sonar.runner.Runner.execute(Runner.java:151)
at org.sonar.runner.Main.execute(Main.java:84)
at org.sonar.runner.Main.main(Main.java:56)
Caused by: org.sonar.api.utils.SonarException: Fail to decorate'org.sonar.api.resources.File#243e2c21[key=ApplicationName.cs,dir=,filename=ApplicationName.cs,language=C#]'
at org.sonar.batch.phases.DecoratorsExecutor.executeDecorator(DecoratorsExecutor.java:84)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:70)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:63)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:63)
at org.sonar.batch.phases.DecoratorsExecutor.execute(DecoratorsExecutor.java:55)
at org.sonar.batch.phases.Phases.execute(Phases.java:92)
at org.sonar.batch.bootstrap.ProjectModule.doStart(ProjectModule.java:129)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.bootstrap.BatchModule.analyze(BatchModule.java:147)
at org.sonar.batch.bootstrap.BatchModule.analyze(BatchModule.java:141)
at org.sonar.batch.bootstrap.BatchModule.doStart(BatchModule.java:136)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.bootstrap.BootstrapModule.doStart(BootstrapModule.java:83)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.Batch.execute(Batch.java:106)
at org.sonar.runner.internal.batch.Launcher.executeBatch(Launcher.java:6
at org.sonar.runner.internal.batch.Launcher.execute(Launcher.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.sonar.runner.Runner.delegateExecution(Runner.java:285)
... 3 more
Caused by: org.sonar.api.utils.SonarException: Unknown metric: temp-method-lines
at org.sonar.batch.index.DefaultIndex.addMeasure(DefaultIndex.java:184)
at org.sonar.batch.DefaultDecoratorContext.saveMeasure(DefaultDecoratorContext.java:111)
at org.sonar.plugins.uselesscodetracker.decorator.TempMethodLinesDecorator.computeDistributionFromChildren(TempMethodLinesDecorator.java:58)
at org.sonar.plugins.uselesscodetracker.decorator.TempMethodLinesDecorator.decorate(TempMethodLinesDecorator.java:49)
at org.sonar.batch.phases.DecoratorsExecutor.executeDecorator(DecoratorsExecutor.java:79)
... 24 more

I don't know what this "temp-method-lines" metric can be, never heard of it...
Please install the latest version of the .NET & C# Plugins Ecosystem: version 2.0. Also, make sure you uninstall any other plugin that could have brought this unknown metric (maybe a custom plugin that you wrote??).
And please upgrade to Sonar 3.4.1 as version 3.4 suffers from a critical bug.

Related

sonar.host.url not valid in end phase of C# plugin in SonarQube for Bamboo 1.17

We updated our SonarQube for Bamboo plugin to the latest version, 1.17.0, and now our SQ integration is broken. No reports are sent to our Sonar Qube server. I get these errors in the Bamboo build output:
This setting is not valid in the "end" phase in this version of the C# plugin: sonar.host.url
Failing task since return code of [C:\sonar\bin\MSBuild.SonarQube.Runner.exe end /d:sonar.host.url=http://[ip-address]:9000/sonar /d:sonar.login=*** /d:sonar.password=*** was 1 while expected 0
And:
SONAR4BAMBOO: was not able to find a SonarQube result URL
It seems like somewhere in the process it's passing sonar.host.url as an argument to executing the runner, but in the latest SonarQube for Bamboo plugin this is, for some reason, not allowed anymore? Has anyone updated SonarQube for Bamboo and come up against similar problems?
I'm the author of the plug-in. We've just released a bug fix version 1.7.1 which only sets the sonar.login parameter in the MSBuild end task, thus resolving this issue.
Best regards,
Michael

Sonarqube evaluation: License error scanning a .Net Project?

I downloaded SonarQube, set it up and installed the C# and VB plugins. I downloaded the MSBuild.SonarQube.Runner. I followed the instructions for Analyzing with SonarQube for MSBuild when I enter the MSBuild.SonarQube.Runner.exe end command I receive the following error:
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher
.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102
)
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53)
Caused by: com.A.vb.XYZ.A.A.A: Missing or bad plugin license. Please check logs.
Is licensing required for the C# plugin or the MSBuild.SonarQube.Runner?
No license is required for the C# plugin or for SonarQube Scanner for MSBuild. But a license is required for the VB plugin. So uninstall that plugin and you should be good to go.
Alternately, you can ask for a trial license.

CUDAfy.NET giving Win32Exception: The system cannot find the file specified

I've added a reference to the CUDAfy.NET library via NuGet.
<package id="CUDAfy.NET" version="1.12.4695.21111" targetFramework="net45" />
When I run my program, I hit a Win32Exception:
The system cannot find the file specified
This happens on the first actual line of the program:
CudafyModule km = CudafyTranslator.Cudafy();
There's no indication from the exception object as to what file they're attempting to load.
How can I get past this problem?
EDIT
I see the same exception when running the bundled examples from the Codeplex download in VS2010 using .NET 4.0.
The strack trace is:
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at Cudafy.CudafyModule.Compile(eGPUCompiler mode, Boolean deleteGeneratedCode)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Version cudaVersion, Boolean compile, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy()
Setting VS to break on thrown exceptions shows the ProcessStartInfo object at the top of the stack in the locals pane of the debugger.
The relevant properties are:
FileName = nvcc
Arguments = -m64 -arch=sm_12 "c:\<path>\CUDAFYSOURCETEMP.cu" -o "c:\<path>\CUDAFYSOURCETEMP.ptx" --ptx
Some information from this article explains that the CUDA Toolkit must be installed. Fair enough.
Ensure that the C++ compiler (cl.exe) is on the search path. This set-up of NVCC is actually the toughest stage of the whole process, so please persevere. Read any errors you get carefully - most likely they are related to not finding cl.exe or not having either 32-bit or 64-bit CUDA Toolkit.
That article discusses version 4 of the toolkit, but version 5 is available now and supported since CUDAfy v1.1.
Download from https://developer.nvidia.com/cuda-downloads
Note that the 64-bit version of the CUDA Toolkit 5.0 is a 942 MB download. If you install everything you'll need an additional 2815 MB. The toolkit alone requires 928 MB.
EDIT After installing the CUDA Toolkit 5.0, the program failed with a CudafyCompileException at the same source line:
Compilation error: nvcc : fatal error : Cannot find compiler 'cl.exe' in PATH
Searching my system drive:
C:\>dir /s cl.exe
This shows many different versions of the compiler/linker, both from VS 10.0 and 11.0. Apparently only cl.exe versions 9 and 10 are supported, so I opted for the VS10.0 amd64 version, I included the following in my PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
Your path may be different, depending upon your CPU. I recommend running the search to see your options.
Note that you will have to restart VS after changing the PATH environment variable if you already have it open.
After taking these steps, my basic program ran successfully.
This may also happen if you had at some point installed CUDA Toolkit v7.5, but realized that the most recent version of CUDAfy supports CUDA 7.0.
On uninstalling CUDA 7.5 from the control panel, some files/folders may still remain. You should delete these manually. You may use CUDAfyViewer to see which version of CUDA Toolkit is being accessed.

Compiling mono-2.6 (or later) on Ubuntu?

I am having to building mono from sources, since the Ubuntu package from badgerports is outdated (does not support .Net 4.0)
This is what I have done so far (mostly following instructions here):
cloned mono git repository
switched to branch tagged 2.6 (git checkout mono-2-6)
installed minimal mono on my machine so mono and mcs are available on machine
run ./autogen.sh --prefix=/usr/local
run make
After a few modules compile correctly, I get this error:
make[4]: Entering directory `/home/oompah/work/dev/mono/mono/mini'
CC mini.lo
CC liveness.lo
liveness.c: In function ‘mono_liveness_handle_exception_clauses’:
liveness.c:137: error: ‘MonoCompile’ has no member named ‘header’
make[4]: *** [liveness.lo] Error 1
make[4]: Leaving directory `/home/oompah/work/dev/mono/mono/mini'
make[3]: *** [all] Error 2
I have looked at the offending code, and indeed a header member is being accessed ...
void
mono_liveness_handle_exception_clauses (MonoCompile *cfg)
{
MonoBasicBlock *bb;
GSList *visited = NULL;
MonoMethodHeader *header = cfg->header;
...
}
Has anyone managed to build mono-2.6 (or later) on Ubuntu?
I've used the scripts provided at integratedwebsystems successfully to compile a recent version of mono on my system and run .net 4.0 applications.
an improved version of the script can be found on firegrass' github account
Joe Shields is packaging Mono 2.10 and is patching everything to default to .NET 4.0 for Ubuntu, you might want to poke him on twitter #directhex.

Mono 2.8.1 assertion mono_wsq_count (wsq) == 0

we are currently having serious problems running a pure c# application on mono 2.8.1 on debian 5.
We are using .net webservices as well as async sockets and probably found a race condition in the mono threadpool.
I would be thankful for every idea.
if someone has informations if mono 2.8.1 has known problems on debian 4/5 that might have something to do with this, please answer too:)
Assertion at mono-wsq.c:73, condition `mono_wsq_count (wsq) == 0' not met
Stacktrace:
Native stacktrace:
mono [0x48f582]
/lib/libpthread.so.0 [0x2abe8f8d2a80]
/lib/libc.so.6(gsignal+0x35) [0x2abe8fb12ed5]
/lib/libc.so.6(abort+0x183) [0x2abe8fb143f3]
mono [0x5cd042]
mono [0x5cd21a]
mono [0x5f271a]
mono [0x5924ca]
mono [0x58c24b]
mono [0x5bd83b]
mono [0x5e9ed6]
/lib/libpthread.so.0 [0x2abe8f8cafc7]
/lib/libc.so.6(clone+0x6d) [0x2abe8fbb064d]
Debug info from gdb:
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
I fixed this in mono 2.8.2. Someone has reported that they still see it in 2.8.2 (we don't see it in our servers any more) and we are working to debug it.

Categories

Resources