[RFF] Sonar Scanner for MSBuild 2.3

[janos....@sonarsource.com]

Hi All,

We would like to release Sonar Scanner for MSBuild 2.3 soon, and we would like to get your feedback. 

Download link: https://repox.sonarsource.com/sonarsource-public-builds/org/sonarsource/scanner/msbuild/sonar-scanner-msbuild/2.3.0.526/sonar-scanner-msbuild-2.3.0.526.zip

Release notes: https://jira.sonarsource.com/jira/secure/ReleaseNote.jspa?projectId=10941&version=13265

The main color of this release is support for MSBuild15 and .NET Core projects.

There are also several bug fixes around encoding, long paths, and many others.

We appreciate all your efforts that you put into testing this product in your environments. Please provide your feedback by Friday, April 7.

Thanks,

Janos

[Raphaël DUCOM]

Hi,

I tried the MsBuild 2.3 runner on production, it seems we spend 2x more time in the compile step.

On MsBuild.runner 2.2 (Vs2k15, ToolsVersion 14) => 3 min / 3 min 30

On MsBuild.runner 2.3 (Vs2k17, ToolsVersion 15) => 6min 30 / 7 min

Bests,

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/3ab094c9-98f9-4acf-8f72-52cd481ddc90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Janos Gyerik]

Hi,

Can you please be more specific about the "compile step"? When you say "compile step", that sounds like step 2 of the analysis, running msbuild, so the scanner doesn't come into play there.

If you run the complete analysis a second time, is it still that slow?

Thanks,

Janos

--

Janos GYERIK | SonarSource

http://sonarsource.com

[Raphaël DUCOM]

Tried 3 times, each time is about 6min30 and 7min20

Details :
Step : SonarQube.Scanner.MSBuild.exe begin [ 1 second ]
Step : Msbuild.exe [ 6 min 30 sec ]
Step : SonarQube.Scanner.MSBuild.exe end [ 28 seconds ]

Without the msbuild sonar runner, the Msbuild.exe step is about 30 secs.
With the msbuild sonar runner 2.2, the Msbuild.exe is about 3min / 3min 30secs.
With the msbuild sonar runner 2.3, we spend 2times more time in the msbuild step.

We run on Jenkins pipeline (up2date), in bat mode.

No additional tooling in the case reported. (opencover mode applies only on RC/Master).

Bests,

[Janos Gyerik]

Since the compilation step is largely independent from the scanner, the difference probably comes from the different MSBuild versions, doesn't it?

That is, if you use the scanner runner 2.2 and 2.3 with MSBuild 14, you should get similar times.

If you simply build your project without using the scanner at all, a clean build with MSBuild 14 and a clean build with MSBuild 15, probably you will a the big time difference there. It's not related to the scanner.

Makes sense?

Janos

[Raphaël DUCOM]

Yes, you are right.
After some tests, results are consistent between sonar.runner version 2.2 and 2.3 on MsBuild 14.

Results are really different between MsBuild 14 and MsBuild 15 on sonar.runner 2.3. (factor 1.5x / 2x)

However, without sonar, there are really little differences between both msbuild versions...

Thanks Janos

[martin.hvi...@gmail.com]

Thanks for bringing MSBuild 15 support! :)

Are there any way I can test this if I use the sonarqube extension from marketplace on an on-premise server?

Can I install the 2.3 scanner on the build machine and somehow get the build tasks to use 2.3 instead of 2.2?

Best Regards

Martin

[martin.hvi...@gmail.com]

I found a way. Changing out the SonarQubeScannerMsBuild folder in: C:\agent\_work\_tasks\SonarQubeScannerMsBuildBegin{guid}\2.0.0\

Seems to work like a charm so far.

[Jan Sandquist]

Hi Janos,

some short feedback from my fitst quick test on a solution with a mix of C# and C++ projects.

I noticed in SONARMSBRU-174 C# and C++ might be handled differently and get a

NullReferenceException in SonarScanner.Shim.PropertiesWriter.WriteSettingsForProject()

where project.Encoding is null for C++ projects. The C# projects have the proper encoding though.

Content from SonarQube.Common.ProjectInfo as follows:

- project {SonarQube.Common.ProjectInfo} SonarQube.Common.ProjectInfo

+ AnalysisResults Count = 1 System.Collections.Generic.List<SonarQube.Common.AnalysisResult>

+ AnalysisSettings Count = 0 SonarQube.Common.AnalysisProperties

Encoding null string

FullPath "C:\\tfs\\sq\\...\\Abc.Tests.vcxproj" string

IsExcluded false bool

+ ProjectGuid {9757cb21-b840-49a6-b057-9f322e543dd6} System.Guid

ProjectLanguage "C++" string

ProjectName "Abc.Tests" string

ProjectType Test SonarQube.Common.ProjectType

No TFS tasks involved, the scan done locally and built using Visual Studio 2015.

Best Regards // Jan

[Jan Sandquist]

Hi again,

some additional info here - at first I thought maybe the character set was not properly set in my C++ projects file but it seems to be.

In the Visual Studio project file Abc.Tests.vcxproj the character set looks ok I assume:

  <PropertyGroup Label="Configuration">

    <ConfigurationType>DynamicLibrary</ConfigurationType>

    <PlatformToolset>v140</PlatformToolset>

    <CLRSupport>Safe</CLRSupport>

    <CharacterSet>Unicode</CharacterSet>

  </PropertyGroup>

The ...\.sonarqube\out\Abc.Tests_5391\ProjectInfo.xml seems to be missing this info though: 

<?xml version="1.0" encoding="utf-8"?>

<ProjectInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.sonarsource.com/msbuild/integration/2015/1">

  <ProjectName>Abc.Tests</ProjectName>

  <ProjectLanguage>C++</ProjectLanguage>

  <ProjectType>Test</ProjectType>

  <ProjectGuid>9757cb21-b840-49a6-b057-9f322e543dd6</ProjectGuid>

  <FullPath>C:\tfs\sq\...Abc.Tests.vcxproj</FullPath>

  <IsExcluded>false</IsExcluded>

  <AnalysisResults>

    <AnalysisResult Id="FilesToAnalyze" Location="C:\tfs\sq\...\.sonarqube\out\\Abc.Tests_5391\FilesToAnalyze.txt" />

  </AnalysisResults>

  <AnalysisSettings />

</ProjectInfo>

Best Regards,

Jan

[Julien HENRY]

Hi Jan,

This is expected to see a difference between C# and C++. We considered that it would be more likely to have Unicode encoding in a C#/VB.NET project (this is more recent technology), while in C++ we decided to keep platform encoding as a default. This is also to mimic in some way the way Roslyn and C++ compilers work.

Remember that:

  - any file with a BOM will be correctly decoded (with SonarQube 6.2+)

  - you can still manually force the encoding for the complete analysis (= for all projects) using /d:sonar.sourceEncoding=xx in the begin step.

We are already supporting the <CodePage> attribute in the .xxproj file, but I was not aware of this <CharacterSet> attribute. I will play a bit with it (especially to see what happen if both <CodePage> and <CharacterSet> are defined) but I think we could take it into account.

++

Julien

[Julien HENRY]

Hi Martin,

We will release an updated version of the VSTS extension right after final release of the Scanner for MSBuild.

++

Julien

[Julien HENRY]

Here are the results of my experiments:

  - <CodePage> attribute is not considered for C++ projects

  - <CharacterSet>Unicode</CharacterSet> will lead to have the /D UNICODE flag on command line, but in fact that doesn't mean files are encoded in UTF-XX. By default, when creating a new project in VS2017, new files are encoded in ANSI (even if <CharacterSet>Unicode</CharacterSet> is defined). I guess it works because of the fallback mechanism of the C++ compiler (that first try to decode as UTF-16 then fallback to the system codepage (like ANSI in my case). So I'm a bit uncertain about the best strategy for C++ projects... especially with SonarQube not having any fallback mechanism (this will change in 6.4). The long term solution would be to set sonar.sourceEncoding to UTF-16 for C++ projects, and then rely on SonarQube to fallback on platform encoding when decoding fail.

I'll have to think about it.

[emiliano....@gmail.com]

Hi! thanks for your work on the fix! When can we expect this release? If ther's a feed I can subscribe, I will be pleased to.

Kind regards,