When sonar.projectBaseDir is UNC path, the sonar.working.directory is always c:\windows\.sonarqube

SonarQube
1

I’m using:
sonarqube server 9.9.1
dotnet-sonarscanner 6.0.0 nuget as a tool.

  1. we are working on windows 10, and the code is located on the network path (UNC path) located on \\someplace\somefolder
  2. after running the command “dotnet-sonarscanner begin” command, we see the file sonar-project.properties file is located in the folder c:\windows.sonarqube on the computer running the scan.
  3. in the properties file from section 2, we see that
    a. the sonar.working.directory is set to c:\windows.sonarqube<some path>
    b. the sonar.projectBaseDir is set to the correct UNC path (e.g. \\someplace\somefolder)
  4. we need the property sonar.working.directory to point to the UNC as well, and in addition, it should reside in that UNC path (and NOT in the c:\windows folder.

my questions are:

  1. is there a variable I can add to the dotnet-sonarscanner begin command in order to set the working directory to the UNC path? (we cannot set this parameter manually).
  2. is there a way to set the path in which the sonar-project.properties file will be created?
  3. does dotnet-sonarscanner support UNC paths at all?
3

Hello @amidar,

Welcome to the community!

There is currently no variable to set the working directory. To do so you would have to execute SonarScanner for .NET in the directory you want.

Unfortunately, today, SonarScanner for .NET does not support being executed within a UNC path.

There are no options to set the path where the sonar-project.properties file will be generated. It will always be generated in .sonarqube/out relative to the working directory.

SonarScanner for .NET supports UNC when set in the sonar.projectBaseDir property. But, as I said, it does not support being executed from a UNC path.

sonar.working.directory is overridden by SonarScanner for .NET so you cannot force the value.

May I ask what your use case is that you need to override this value?

4

hi sebastien, thanks for detailed answer!
our use case is as follows:

  1. e have about ten static (not dynamically provisioned) windows 10 virtual machines, with very little storage on each of them, enough just for operating system and a couple of required installations.
  2. in addition, we have a very large network storage (more than 10 terrabytes) which can be accessed from all the machines mentioned in section 1 (as UNC path).
  3. during work hours, there are hundreds of pipelines running on the machines in section 1, using the storage mentioned in section 2 (for code, compilation, artifacts, etc…).
  4. we currently started using sonarqube dotnet scanner, and came across the problem I mentioned at the opening post of this thread.

we are trying to avoid using mapped network storage (“net use” command in windows) since pipelines may break in the middle, leaving the drive letter occupied.

the code we are compiling is mostly c#, with windows specific usage.
dockers on windows is not a viable solution for us.
the entire environment is airgapped.

can you point us to decent solution?

thanks!

5

Hello @amidar,

During my investigation, I was not able to do a full analysis. The end step is always falling with the following errors:

'\\some\unc\path'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

and

java.lang.IllegalStateException: Failed to create lock in \\some\unc\path\.sonarqube\out\.sonar\.sonar_lock

Are you able to do a full analysis from the begin step to the end step?
Are the results showing up on SonarQube?

Thanks,

6

hi sebastien, thanks for your input and investigation.

  1. our end step ends successfully. we DO see the first message you mentioned (CMD.EXE was started…) but DO NOT encounter the exception you mentioned in the second message. I guess you should check the properties file to see exactly what is created there, or at least review the code which is running to make sure this exception is thrown for a good reason and not due to a missing end case implementation.
  2. the results are showing up on SonarQube as expected.

like I mentioned in the opening post, we are able to run the analysis, but it looks like the UNC path handling is not well covered (or not covered at all…).

if you need additional information - please let me know and I’ll do my best to provide it. solving this issue will enable us to perform a lot of work using your software - which now we are not able to perform.

7

Hello @amidar,

Did you try to run SonarScanner for .NET inside the UNC path?

cd \\some\unc\path\project
dotnet sonarscanner begin ...
dotnet build
dotnet sonarscanner end ...

I said that it was not supported, but I might have made an assumption.
If you could give it a try and tell me what is happening.

When I am trying, I have the same errors as I mentioned.
I am accessing WSL with a UNC path for my tests, as I have no alternative for now, so the behavior might be different.

Thanks,

8

hi sebastien,
I will try what you mentioned tomorrow and update regarding the results.

1 Like
9

Hi sebastian,

I tried what you suggested.
sadly - nothing changed.

where do we go from here?

10

Hello @amidar,

I am surprised. The scanner should generate the .sonarqube folder in the current working directory, so after the begin step, you should see the folder in your project folder.
Are you sure the scanner process working directory is the same as your project?
Did you keep the /d:projectBaseDir option?

Could you also give me your logs (both for the begin and end) when executing within the UNC path?
If you can provide me with the logs, don’t forget to enable the verbose mode by adding the /d:sonar.verbose=true to the begin step of the scanner.
I might spot something.

Thanks,