SonarQube Visual Studio 2013 C++ Plugin - c++

I have the following setup...
TeamCity 7.1.5
Visual Studio 2013
SonarQube 3.7.4
SonarQube C++ Community plugin 0.9.1
We have a number of Visual Studio C++ solutions / projects. They all process successfully through TeamCity - Compile, Unit Test, Nuget Package generation, etc. I am now trying to add the Sonar analysis of those project, using the C++ Community plugin.
Now I understand that the plugin itself does not perform any analysis, that must be done separately and the plugin only imports the results. The plugin is successfully able to identify and import all the Source files, I can seem them listed in within the SonarQube dashboard.
The actual build and analysis is done via Visual Studio / Visual C++ compiler using MSBuild. I have enabled Code Analysis via MSBuild and I can see that it is generating a list of issues. However, I cannot get SonarQube to import that list of issues.
For the MSBuild command I am using the following parameters...
/t:Build
/p:Configuration=Debug
/p:RunCodeAnalysis=True;CodeAnalysisRuleSet=AllRules.ruleset;verbosity=normal
/filelogger
/flp:verbosity=diagnostic
I have confirmed that a MSBuild.log file is being generated and it is finding issues.
The Sonar-Runner steps has the following options...
-Dsonar.language=c++
-Dsonar.projectKey=MYProject
-Dsonar.projectName=MYProject
-Dsonar.projectVersion=0.0.1
-Dsonar.sources=Src
-Dsonar.cxx.compiler.reportPath=*.log
-Dsonar.cxx.compiler.charset=UTF-8
-Dsonar.exclusions=**/packages/**/*
-Dsonar.cxx.includeDirectories=Src/Packages "
-Dsonar.cxx.compiler.parser='Visual C++'"
I have also tried using -Dsonar.cxx.compiler.reportPath=MSbuild.log
The Sonar appears to run fine, but just doesn't pick up the code analysis issues.
Could anyone please suggest what I could be doing wrong, or what else to try.
Any help would be greatly appreciated.
Thanks & Regards,
RG

try the last version of the plugin and make sure all compiler related rules are enabled in your profile. And check your compilation build log, if the paths are relative in there you need to pass /FC flag to the compilation

Related

Building and running unit tests with Visual Studio build tools

I am adding unit tests to an existing C++ Visual Studio projects, using the Google Test adapter.
It's all running fine on my computer with Visual Studio 2019, but when I try to run them on the build server I get the following error
error : This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.3\build\native\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.targets.
However, we're not using NuGet for package management. I tried installing it but complained about missing folders. This is not a .NET project, so I think that's a red herring.
I was able to install the Google Test adapter on my computer using the Visual Studio Installer, but it does not show up as a part of the VS Build Tools on the build server.
Running msbuild -t:restore does not help, it just reports "nothing to do."
I don't understand why the Google Test adapter isn't available for VS Build Tools, since it seems to be required in order to build the unit tests. Does anyone know why it doesn't work? What's the best practice for handling this?
Thanks!
The problem is that your c++ project has missed the content of googletest nuget package. So the solution is to restore the whole nuget package in your c++ project.
Update 1
First of all, take a brand new backed up project and restore it to when the problem started.
Besides, msbuild -t:restore command applies to projects with PackageReference nuget management format.
Since your c++ project used packages.config nuget management format, msbuild -t:restore will not work. See this official document.Instead, you should use nuget restore command.
This command works for your current project and running this command will restore the nuget packages and then you will never face the issue.
Before using it, you should download nuget.exe CLI and config its path into System Environment Variable PATH so that CMD can invoke nuget.
The steps about configing nuget.exe, you can refer to this link.
Steps
1) delete packages folder under the solution folder
2)Then, open build tool, run:
nuget restore xxx\xxx\xxx.sln(the full path of solution file containing the c++ project and the unit test project)
Then, you can build the project with the command. And I hope the error will disappear.

Error while building AutoMapper source code

I'm trying to build the source code for AutoMapper so I can better understand it, but I'm getting the following errors:
I've tried Visual Studio 2017 since it was recommended here, but it's using the wrong version of C# and gets syntax errors. And the above errors were generated in Visual Studio 2019. I also tried running the Build.ps1 PowerShell script, but this failed as well.
The Contribute.md indicates that I should run psake.cmd to build the solution, but I don't see that file in the source.
Can someone provide tips on how to build AutoMapper source code?

Visual Studio Live Testing - Start failed because TestPlatform V2 can not be located

No matter what I do, I can't seem to get live testing to start in Visual studio 2017 (15.3.5)
I get this error:
Start failed because TestPlatform V2 can not be located. Please try to modify your Visual Studio installation through Microsoft Visual Studio Installer, and make sure Testing tools core features is selected under Individual components -> Debugging and testing
[13:23:22.396 Info] For more information, see https://go.microsoft.com/fwlink/?linkid=852911.
I have installed the required component and it still won't run. Although the tests will run if I manually run them.
Any help is appreciated.
Hi i also had the similar problem. After checking Extentions and Updates in Vs 2017, the extention Dotnet Extention for test explorer disabled. After enabling this its worked

Can't get XUnit tests working with Visual Studio 2017 RC

For the life of me I can't get unit testing working in Visual Studio 2017 from the new msbuild-based netcoreapp1.0 xunit project template.
The requirement is for unit tests to work both inside Visual Studio (for the devs) and from dotnet test on the CLI for the automated build process however, I can't get either working consistently.
Here is what I have tried:
In an existing solution, create a new project and select .NET Core > xUnit Test Project.
Build project from Visual Studio, default test appears and runs successfully, now run dotnet test from powershell prompt, get:
> dotnet test
Test run for D:\...\bin\Debug\netcoreapp1.0\MyProj.dll(.NETCoreApp,Version=v1.0)
dotnet exec needs a managed .dll or .exe extension. The application specified was 'C:\Program'
Or dotnet test with csproj file:
> dotnet test MyProject.csproj
(same error as above)
> dotnet test ..\MySolution.sln
Couldn't find a project to run test from. Ensure a project exists in D:\...
Or pass the path to the project
If I add the xunit.runner.console or xunit.runner.msbuild nuget packages, it stops the unit tests working from inside Visual Studio.
How do I get both working at the same time?
Thanks!
The bug you're hitting is present in Preview 3 and fixed in Preview 4. They didn't escape the command line when executing it, and since dotnet.exe is installed into C:\Program Files\dotnet by default, it always fails.
If you want to continue to use Preview 3, the simplest work-around is to edit your system PATH environment variable, and replace C:\Program Files\dotnet with C:\Progra~1\dotnet.
I know this isn't a very good answer, but dotnet-test-xunit only support project.json files. VS 2017 forces you to switch to csproj files.
I found this on xunit twitter feed:
If you're trying use #xunit in VS2017 RC w/ .NET Core, remove dotnet-test-xunit and use xunit.runner.visualstudio 2.2 beta 4 instead.
With the latest RC.3 I was having issues with the tests not being discovered, and found out that when you run the built-in Test Explorer it says in the output that Microsoft.DotNet.InternalAbstractions 1.0.0 is missing. This was also issue in the previous versions of .NET Core, and the solution is the same, install the package from Nuget.

How can I disable code coverage / assembly instrumentation in Visual Studio 2012?

I have a project upgraded from Visual Studio 2010 to 2012 and the .testrunconfig file was included in the upgrade process.
I noticed that it was possible to click "Analyze code coverage" on any of the unit tests that I had run and it would correctly display the result. However, my test run configuration (originally from VS 2010) had code coverage disabled.
After doing a bit of research I learned that the VS 2010 configuration files have been deprecated and replaced by .runsettings files. It would appear that VS 2012 enforces assembly instrumentation by default which has a massive overhead associated with it.
Therefore, I would like to know how I can disable code coverage in VS 2012. Based upon my current findings it does not seem to be a trival task. One recent article I read had me creating an XML file manually and naming it "MYCONFIGURATION.runsettings" and manually manipulating XML attribute values.
Does anyone know how this should be done?
This is what I understand from your post:
You have a Test project with .testsettings file. You have not enabled code coverage in the test settings.
Code coverage instrumentation is not enabled by default in your scenario. Binaries will be instrumented if you do 'analyze code coverage' from VS.
Additional Info:
You can confirm that .coverage file is not generated by running the following command from visual studio developer command prompt:
vstest.console.exe /Settings:<your test settings file> test.dll
A coverage file will only get generated if you have enabled coverage in test settings.
Code coverage is only enabled through the Test Explorer using data driven adapters. The metadata for tests ran through the test explorer is almost completely different than that of tests ran straight from the unit test session window. Have you tried simply running it straight from the code (the MSTest gui bubbles) or from the unit test session window?