Failure to find VS2015 CodeCoverage.exe after searching for nonexistent registry key

[fiveshotsofespresso]

Description

In SonarQube Scanner for MSBuild 4.1, the scanner can no longer find the path to CodeCoverage.exe if the installed version of Visual Studio is 2015. This results in code coverage not being able to convert to the right formats, and no code coverage being uploaded to SonarQube.

Repro steps

Using TFS (although this could probabbly be genericized to a manual build process as well), trigger a common SonarQube build configuration (Prepare Analysis Confugration, Visual Studio Build, Visual Studio Test with Code Coverage Enabled on a solution with Unit Tests, Run Code Anlaysis) on a build agent using VS2015.

Expected behavior

Code Coverage is found, converted to xml, and uploaded to SonarQube.

Actual behavior

The Run Code Analysis logs will indicate that CodeCoverage.exe cannot be found. Turning on sonar.verbose=true, it indicates that it first checks for Visual Studio Configuration and then checks for the registry key.

Known workarounds

Setting the following registry key fixes the issue.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0

Key=ShellFolder
Value=C:\Program Files (x86)\Microsoft Visual Studio 14.0\

Related information

• SonarC# Version - 6.8.1
• Scanner for MSBuild Version - 4.1.0
• SonarQube Version - 7.0
• Visual Studio Version - Enterprise 2015 Version 14.0.25431.01 Update 3
  Usage: TFS 2017 Update 3, SonarQube Extension for TFS/VSTS 4.1.0

VS2017 is not affected
This issue was not present with SonarQube Extension for TFS/VSTS v4.0.2 with SonarQube Scanner for MSBuild 4.0.2

[fiveshotsofespresso]

The correct registry key exists at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0 on the VS2015 machine.

It looks like the scanner is not looking for the key in Wow6432Node.

A possible fix would be making a change in /src/SonarScanner.MSBuild.TFS.Classic/BinaryToXmlCoverageReportConverter.cs

private const string VisualStudioRegistryPath = @"SOFTWARE\Microsoft\VisualStudio";

becomes something like...

private const string VisualStudioRegistryPath = $@"SOFTWARE{(Environment.Is64BitProcess ? @"\Wow6432Node" : string.Empty)}\Microsoft\VisualStudio\

(The bit to determine whether to use Wow6432Node or not came from the hack that made VS2017 Update 3 stop failing tests -- #426

[duncanp-sonar]

@fiveshotsofespresso Many thanks for reporting the issue and suggesting the workaround and fix.

FYI I've done some investigation to work out what changed. The code in the scanner has been moved to a different assembly but is essentially the same. It worked previously because the scanner exe was marked as a 32-bit process so registry redirection meant that the Wow6432Node would be used when the code opened the HKLM\Software\... node.

However, running corflags {exename} against the old and new scanner exes shows the 32BITPREF flags are different. As a result, registry redirection isn't happening in v4.1 and the key isn't being found.

Although the code is the same, in v4.1 we switched to using the new-style MSBuild project format, and it looks like the standard targets used by projects in the old-style MSBuild format set the Prefer32Bit MSBuild property to true by default for exe projects but the targets used by the new-style project set Prefer32Bit to false.