10

Good evening,

I am using the .Net Core 2.0 version from here https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+MSBuild on a 2.1 project in Jenkins with: 

withSonarQubeEnv('SonarQubeMain') {
    bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll begin /k:\"${globals.SONAR_QUBE_PROJECT}\" /d:sonar.host.url=${globals.SONAR_HOST_URL} /d:sonar.cs.xunit.reportsPaths=\"XUnit.xml\" /d:sonar.cs.opencover.reportsPaths=\"coverage.xml\"
}

bat "dotnet build --version-suffix ${env.BUILD_NUMBER}"

dir('test/mytestprojecthere') {
    bat 'D:\\OpenCover\\OpenCover.Console.exe -target:"c:\\Program Files\\dotnet\\dotnet.exe" -targetargs:"xunit --no-build -xml XUnit.xml" -output:coverage.xml -oldStyle -filter:"-[*Tests*]*" -register:user'
}
withSonarQubeEnv('SonarQubeMain') {
    bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll end"
}

It works the first build but on the next build it fails with: 

Failed to create an empty directory 'D:\Jenkins\workspace\xxxxxxxx\.sonarqube'. 
Please check that there are no open or read-only files in the directory and that you have the necessary read/write permissions.

Detailed error message: Access to the path 'SonarScanner.MSBuild.Common.dll' is denied.

and checking my windows server I can see multiple .Net Core Host Background process. If I kill these I can build again..

I readed about msbuild /nodereuse:false for MSBuild but seems is not working for the dotnet core version?

Nauzet
  • 661
  • 8
  • 20

5 Answers5

9

We were just faced with this issue, and found out that it's related to dotnet's and msbuild's reuse of nodes that were left running by a previous multi-threaded build.

To avoid the problem, use either /nodereuse:false or /nr:false on your command line as the following:

msbuild /m /nr:false myproject.proj

msbuild /m /nodereuse:false myproject.proj

dotnet restore myproject.sln /nodereuse:false
fsteff
  • 543
  • 5
  • 19
6

FYI @Nauzet opened an issue open for this in the Scanner for MSBuild repo: #535.

To summarise:

  • the begin and end steps seem to run fine, and dotnet.exe shuts down as expected for those processes
  • when building a complex solution, multiple instances of dotnet.exe are started and are do not shut down immediately when the build completes. The issue does not seem to occur on simpler solutions.
  • the issue occurs if you trigger the build phase using dotnet build or dotnet msbuild
  • workarounds: build using msbuild directly, or build using dotnet build /nodereuse:false

FYI the Scanner for MSBuild has a couple of custom tasks that are called during the build phase. These use the assembly that is being locked. There's nothing unusual about the custom tasks; they just read data from a file on disk. At this point, I'm not convinced it's an issue with the Scanner for MSBuild.

duncanp
  • 1,572
  • 1
  • 10
  • 8
3

I faced same issue and running following command solved the issue.

dotnet build-server shutdown

This happens due to msbuild node re-use. we leave msbuild nodes alive with the intent of saving on startup time when doing consecutive builds.

It can turned off by setting an following environment variable too.

MSBUILDDISABLENODEREUSE=1
Janith Widarshana
  • 3,213
  • 9
  • 51
  • 73
0

Please edit your pipeline script as shown below and it should work properly:

    withSonarQubeEnv('SonarQubeMain') {
    bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll begin /k:\"${globals.SONAR_QUBE_PROJECT}\" /d:sonar.host.url=${globals.SONAR_HOST_URL} /d:sonar.cs.xunit.reportsPaths=\"XUnit.xml\" /d:sonar.cs.opencover.reportsPaths=\"coverage.xml\"

bat "dotnet build --version-suffix ${env.BUILD_NUMBER}"

dir('test/mytestprojecthere') {
    bat 'D:\\OpenCover\\OpenCover.Console.exe -target:"c:\\Program Files\\dotnet\\dotnet.exe" -targetargs:"xunit --no-build -xml XUnit.xml" -output:coverage.xml -oldStyle -filter:"-[*Tests*]*" -register:user'
}

bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll end"
    }

UPDATE

Here is a dotnet core app pipeline build script that I use, which works well without any issues:

bat "dotnet ${sqScannerMsBuildHome}\\SonarScanner.MSBuild.dll begin /k:yoursonarprojectkey /n:yoursonarprojectname /v:1.0 /d:sonar.host.url=%SONAR_HOST_URL%"
bat 'dotnet build'
bat "dotnet ${sqScannerMsBuildHome}\\SonarScanner.MSBuild.dll end"
Isaiah4110
  • 9,855
  • 1
  • 40
  • 56
  • does not work either. But I spent some hours trying things and I can say for sure the problem is caused by `dotnet build` after running the scanner. I assume is because my build is .Net Core 2.1 so I will wait for an update. The file seems to get unlocked after some minutes anyway. As this is my homelab and I am the only one using jenkins I can do this for now at the end of my pipeline: `bat "taskkill /FI \"MODULES eq SonarScanner.MSBuild.Common.dll\" /FI \"USERNAME eq Jenkins\" /F"` but this is obviously working coz there will be only 1 build at the same time for me – Nauzet Jun 01 '18 at 23:47
  • I have a dotnet core app and I run this without any issues, so it’s definitely not dotnet build. Can you take out the open cover part and just do the app compilation and see? That’s what I have and it doesn’t have any issues. – Isaiah4110 Jun 02 '18 at 00:06
  • Also what’s your project like? Any post build or pre build steps? – Isaiah4110 Jun 02 '18 at 00:08
  • I have added my pipeline script. Please check – Isaiah4110 Jun 02 '18 at 00:20
  • I tested it without opencover, without the unit tests, running on a different machine, removing projects from the solutions.. My solution have: library1 (netstandard2.0) library2 (netstandard2.0, dependency to library1) consoleApp1(netcoreapp2.1 dependency to library2) consoleApp2(netcoreapp2.1 dependency to library2) UnitTests (netcoreApp2.1 dependency to library2) I removed everything but library1 -> build correctly do not lock. Added library2 -> dotnet build locks the sonarscanner dlls for minutes. – Nauzet Jun 02 '18 at 09:20
  • Will test it out today and let you know. – Isaiah4110 Jun 02 '18 at 12:47
  • Seems this got fixed after I split the solution in multiple ones to reference them as nuget packages instead projects. – Nauzet Jun 06 '18 at 18:34
  • ah okay, sorry I didnt get time to test this thats why I didnt respond back – Isaiah4110 Jun 06 '18 at 19:51
0

I just ran into it myself and "solved" it by running dotnet build-server shutdown as the first task in my build plan. That's not ideal for multiple reasons, one big one being that it'll likely cause issues if I attempt to run multiple .NET Core builds at once on the same machine. This does seem to be a bug in the scanner -- hopefully it'll be fixed soon.

IGx89
  • 872
  • 7
  • 18