BootstrapperSettings class does not use projectBaseDir property

Hi,

Sorry for the long post. The bottom line is in the final paragraph, the paragraphs in between are meant to explain the background.

For my customer, I am currently migrating several large C# projects (most of them using VS2019) to a new sonarqube version.
Some of those projects are using nant as a wrapper of MSBuild, and are using two-way relative directories (i.e. calling nant from a subdirectory of project workspace, referencing file paths such as “…/…/Sources/Module/Foobar.cs”).

With those projects, msbuild does not find the .sonarqube directory created by the “begin” step, and thus the “end” step complains about missing data.
I experimented with various properties (e.g. “sonar.projectBaseDir”), but to no avail.

While checking the source, I found something. In this module/file:
sonar-scanner-msbuild/src/SonarScanner.MSBuild/BootstrapperSettings.cs
The function BootstrapperSettings.CalculateTempDir() seems to do exactly the needed calculation, to determine the location of .sonarqube directory. This code also consults the environment variable AGENT_BUILDDIRECTORY.

Now if I set that variable to my workspace (which is different from the CWD in my problematic cases), the msbuild target “SonarQube.Integration.ImportBefore” seems to properly find the .sonarqube directory, so this seems to be a usable workaround. However, that variable is intended for TFS2015, but I am using Jenkins. So I am reluctant to rely on an undocumented feature.

Long story short: would it be possible to extend the code quoted above to consider not only the environment variables mentioned there, but also the property sonar.projectBaseDir?
My understanding is that this would bring quite a benefit to the users. If you are reluctant to reuse that specific property, I would also be happy with a new property.

Regards,
Stefan

(Edit: typo, and path formatting)

Hey @stefan.rink ,

Before I discuss with my team about your suggestion, could you give me some more information about what exactly is your usecase?

(i.e. calling nant from a subdirectory of project workspace, referencing file paths such as “…/…/Sources/Module/Foobar.cs”).

I do not have any knowledge of NAnt, and from what you mentioned it seems to do the build in an unconventional way. I am curious to know why you need to call NAnt from a subdirectory and then back-reference files like ../../modules/foo.cs.

There are two things you can do:

  • Do the begin step at the root of the current project. Then do all the setup you need by cd-ing to deeper levels. When you are about to call the build step, go back to the directory that you did the begin step at. This is the expected behavior. The scanner expects the build to be run at the same level that .sonarqube was generated by the begin step.
  • If you cannot use the conventional way, because of how NAnt operates, you can do the hacky fix you suggested. The logic should not be TFS-specific, it’s just supported for Azure Devops/TFS because it’s the most popular one (and we have an extension that works out of the box). But by setting $env:AGENT_BUILDDIRECTORY to your desired root, you should be able to call build from anywhere, and it should prioritize it over the MSBuild working directory.

Regards,
Let me know if I can help more.