Issues with MsBuild Scanner

[oliver...@mailbox.org]

Hi there,

we are providing a Jenkins / SQ installation as a service for a bunch of different projects with ~900 projects in SQ, their corresponding build jobs in Jenkins and additional build and deploy jobs. As you can imagine this is only possible by enforcing several conventions, especially naming conventions. A a consequence, these names tend to be somewhat longer.

Recently some colleagues working on a .NET project approached us to include a SQ analysis into their build process. And as there is SQ support in form of the SQ Scanner for MsBuild we assumed it would not take too long. Little did we know...

As the SLNs were not available in the root folder, we were unable to use Jenkins Plugin and had to resort to manually installing and invoking the scanner.

But whatever we tried, we could not get the analysis to work due to the following error:

ERROR: Error during SonarQube Scanner execution
java.lang.RuntimeException: java.io.FileNotFoundException: d:\export\xxx\jenkins-slave\workspace\xxx\xxx-public-project-template-msbuild-sq-master\foobar-msbuild\.sonarqube\out\.sonar\xxx.xxxxxxxx.xxx.templates_msbuildtemplate_xxx.xxxxxxxx.xxx.templates_msbuildtemplate_6CF2B6D9-03DC-49A0-8643-ABF701F21A66\StyleCop-report.xml (The system cannot find the file specified)

Moving the SLN and the accompanying directories one level up, everything worked fine.

It  took quite some time before we realised much to our suprise that this error was due to the path being too long (The length in the file name above has been preserved). I remember Windows having some limitiations on the path length, but I was under the impression these limitations were a thing of the past. Could you please explain whether the limitations in some Windows internal thing or "just" the scanner itself not being able to handle a file name that long?

As this error leads to the SQ analysis being aborted, it is the most important issue we are facing right now. We can work around it for a while by trying to keep the project name as short as possible, but compared to the length of the path component containing the GUID we do not have that much potential. Would it be possible to come up with another naming scheme for that directory which does not take up almost 50% of the path  length?

Another problem we are facing is the impossibility to perform a FxCop analysis due to the following warnings:

 MSBUILD : warning : CA0064 : No analysis was performed because the specified rule set could not be loaded or did not contain any managed code analysis rules. [d:\export\xxx\jenkins-slave\workspace\xxx\xxx-public-project-template-msbuild-sq-master\foobar-msbuild\FoobarConsole\FoobarConsole.csproj]
 MSBUILD : warning : CA0063 : * Failed to load rule set file 'd:\export\xxx\jenkins-slave\workspace\xxx\xxx-public-project-template-msbuild-sq-master\foobar-msbuild\.sonarqube\conf\\SonarQubeFxCop-cs.ruleset' or one of its dependent rule set files. The file does not conform to the rule set schema. [d:\export\xxx\jenkins-slave\workspace\xxx\xxx-public-project-template-msbuild-sq-master\foobar-msbuild\FoobarConsole\FoobarConsole.csproj]

Does anybody have an idea why this could happen?

This happens with Win 7, SQ 5.6.3, C# Plugin 5.5.2.537, FxCop Plugin 1.0, StyleCop 1.1, MsBuild Scanner 2.2.0.24, MsBuild 14.0.23107.0

Kind regards,

Oliver Brandt

[oliver...@mailbox.org]

Hi,

one additional information I only discovered after posting the above:

It ssens the StyleCop Sensor uses a different msBuild version:

INFO: Sensor org.sonar.plugins.stylecop.StyleCopSensor
Microsoft (R) Build Engine version 4.6.1087.0

Kind regards,

Oliver Brandt

[valeri....@sonarsource.com]

Hi Oliver,

There is a Group Policy setting included with the latest updates of Windows 10 which can enable paths longer than 260 characters, but I don't know if it is available in previous versions:

http://superuser.com/a/1119980

As far as I can judge from the comments, however, this option may be unavailable in some editions of Windows (non-Pro for example).

The excessively long paths are probably a problem on our side, the folder name below \.somarqube\out seems to contain duplicate parts, I will log an issue and we will investigate.

The CA0063 and CA0064 errors are StyleCop errors, you could find more information here:

https://msdn.microsoft.com/en-us/library/ms245349.aspx

All the best,

Valeri Hristov

[oliver...@mailbox.org]

Hi Valeri,

thanks for you response. I had a look at the spueruser link and did some more serchin along those lines. According to https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath the functions in the Windows API taking Unicode string allow for much longer file names (32k characters) than the simple ones. And that without manually setting some policy (which may not even possible in the corporate environment.

I also stumbled upon https://jira.sonarsource.com/browse/SONARMSBRU-224 which might solve the path length problem.

Have a nice weekend,

Oliver

[Amaury Leve]

Hi Olivier,

Thanks for pointing out the Jira ticket. Unfortunately we can't give you any date about when it will be implemented.

Cheers,
Amaury

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/e3e2fa3d-fd42-442c-be5a-c194125d2e37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Amaury LEVE | SonarSource
Software Developer

http://sonarsource.com