VSTS extension autoupdate to v4.4.0, fails build with 'not given a value for the required parameter "Language"'

SonarQube Server / Community Build
,
1
  • versions used
    • SonarQube v5.6.1 on-prem
    • VSTS Marketplace extension v4.4.0
  • error observed (wrap logs/code around triple quote ``` for proper formatting)
    Our VSTS build definition hasn’t changed, but just today we started getting this error in our builds (we executed the build against the exact same changeset that succeeded two days ago):
2018-10-12T14:25:11.1839508Z "D:\a\1\s\src\Audit.Engagements.sln" (default target) (1) ->
2018-10-12T14:25:11.1839690Z "D:\a\1\s\src\Audit.Engagements\Audit.Engagements.sfproj" (default target) (2) ->
2018-10-12T14:25:11.1839864Z (SetRoslynCodeAnalysisProperties target) -> 
2018-10-12T14:25:11.1840054Z   D:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(381,5): error MSB4044: The "GetAnalyzerSettings" task was not given a value for the required parameter "Language". [D:\a\1\s\src\Audit.Engagements\Audit.Engagements.sfproj]

Earlier in the build, the only other piece that looks different between the two logs is the following excerpt:

2018-10-12T14:24:51.3109154Z CreateProjectSpecificDirs:
2018-10-12T14:24:51.3109804Z   Creating directory "D:\a\1\.sonarqube\conf\17".
2018-10-12T14:24:51.3110419Z SetRoslynCodeAnalysisProperties:
2018-10-12T14:24:51.3110567Z   External issues are not supported on this version of SonarQube. SQv7.4+ is required.
2018-10-12T14:24:51.3135877Z CoreCompile:

I see that the build from two days ago ran v4.3.2 of the begin analysis SQ task, while today’s failed build is running the just-released v4.4.0.
The .sfproj mentioned in the above log error is an Azure Service Fabric project. I guess that may be something that wasn’t tested during the development of v4.4.0, but this is a pretty serious issue. Unless there’s some workaround, this essentially means we have to disable all SonarQube analysis for this project.

For reference, our SonarQube server is installed on-prem, and running v5.6.1.

Is there a hotfix you can push to address this?

Thanks

2 Likes
2

We started seeing the same issue about an hour ago in all of our VSTS builds as well.

3

We are having exactly the same issue with. .sfproj (Azure Service Fabric project) in VSTS. It started to happen today October 12, 2018. No code changes.

Version used:

SonarQube 7.1 on-prem
VSTS market place extension 4.4.0

Error: 2018-10-12T15:30:43.3469778Z D:\a\1.sonarqube\bin\targets\SonarQube.Integration.targets(381,5): error MSB4044: The “GetAnalyzerSettings” task was not given a value for the required parameter “Language”. [D:\a\1\s\PremiumManager.Domain\PremiumManager.Domain.sfproj]

2018-10-12T15:30:43.8558435Z Done Building Project “D:\a\1\s\PremiumManager.Domain\PremiumManager.Domain.sfproj” (default targets) – FAILED.

I noticed one difference between yesterday’s working build) and today’s fail build. In SonarQube - Prepare Analysis Configuration step, working builds shows version “4.3.2” and failing build shows “4.4.0”

I also notice that on SonarQube Market place, 4.4.0 version was released or updated on Oct 12, 2018 (today).

Please fix the extension as we are blocked from this.

Thanks,
Dennis

4

Hi Chris, Dennis.

I also posted the issue on the Sonar Scanner MSBuild github repo, and received a workaround there:

Add

<PropertyGroup>
  <SonarQubeExclude>true</SonarQubeExclude>
</PropertyGroup>

to your .sfproj.
It worked for me.

Hope that helps!

1 Like
5

Thank you Balfa. That would work as a workaround to get the build moving, but we’ve just disabled the SonarQube integration in VSTS for the time being. Both solutions though leave the projects not being analyzed in SonarQube, which they need to address promptly.

6

I don’t think sonar would know anything interesting about a .sfproj anyway. There’s no code in it. Ignoring those specific projects is unlikely to miss anything anyway.

That said, sonar should still be smart enough to not break the build when it encounters a .sfproj without us having to put this exclusion in every single .sfproj we maintain.

7

Absolutely. I hadn’t caught that the problem was just with the sfproj projects, so that’s a reasonable enough workaround (although it does break historical builds but we can work around that).

8

There seems to be 2 threads for the same issue, the other being: Azure Devops Build fail with .deployproj with missing parameter "Language" error

Not sure if these can be merged.

My point in the other thread was, making dev changes in ‘x’ number of projects as a work around is not viable. For us it affects each project with a docker-compose.dcproj file. This is 30+ of our repos needing changes, pull requests, approvals etc and going to be far to time consuming as a work around. Hoping for a fix from sonar, or a workaround that can be applied in our azure dev ops task group (common task group for all builds).

9

FYI I’ve posted an updated on the fix in the other thread referred to by @lrobbertse.

10

No direct means to do that, but since @duncanp just gave a more definite update in that other thread I’ll close this one here and let people follow-up below if needed: