No tsconfig.json file found using .NET scanner

[SamuelBlickle]

When using sonarscanner for .NET version 6.2.0 to analyze a C# .NET project, containing multiple TypeSycript files, the sonarscanner does not analyze any TypeScript content.

Taking a look into the debug logs, I see that the scanner doesn’t detect any tsconfig.json files. To be fair, the (multiple) tsconfig files are located in a subdirectory of the root folder, but setting the path to said files manually also doesn’t change that fact.

I even created a tsconfig file in the root folder of the project, containing universal dummy content like

{ "include": ["**/*.ts", "**/*.tsx"] }

but it still doesn’t recognize any tsconfig files.

The logs keep saying:

14:55:42.800 INFO: Resolving TSConfig files using 'tsconfig.json' from property sonar.typescript.tsconfigPath 
14:55:42.800 DEBUG: Using 'tsconfig.json' to resolve TSConfig file(s) 
14:55:42.808 INFO: Found 0 TSConfig file(s): [] 
14:55:42.813 INFO: Found 0 tsconfig.json file(s): [] 
14:55:42.814 INFO: No tsconfig.json file found

What else could I be missing here?

[ganncamp (G Ann Campbell)]

Hi,

Welcome to the community!

I think these docs may be relevant:

the SonarScanner for .NET will analyze all file types that are supported by the project type (for example, esproj), MSBuild, and the available language plugins unless explicitly excluded.

If you have an esproj project type, make sure to use Microsoft.VisualStudio.JavaScript.SDK version 0.5.74-alpha or later to ensure the SonarScanner for .NET recognizes the esproj contents for scanning.

 
HTH,
Ann

[SamuelBlickle]

Thank you very much for your reply!

The project(s) in the analyzed solution isn’t (aren’t) a .esproj, so that shouldn’t be problematic.

Furthermore, i see no entry in our .csproj that would specifically exclude tsconfig files. Also, I’ve explicitly added them with

  <ItemGroup>
    <Content Include="**/tsconfig.json" />
  </ItemGroup>

as the last entry of the file.

Shouldn’t that enable their detection - no matter what?

I’ve also taken a look into the .sonarqube\out\sonar-project.properties file. The tsconfigs as well as the .ts files are listed as sources there. Nevertheless they aren’t getting analyzed.

[ganncamp (G Ann Campbell)]

Hi,

Could you provide full debug job logs?

Share the Scanner for .NET verbose logs

• Add /d:"sonar.verbose=true" to the…
  • SonarScanner.MSBuild.exe or dotnet sonarscanner begin command to get more detailed logs
    • For example: SonarScanner.MSBuild.exe begin /k:"MyProject" /d:"sonar.verbose=true"
  • “SonarQubePrepare” or “SonarCloudPrepare” task’s extraProperties argument if you are using Azure DevOps
    • For example:

      - task: SonarCloudPrepare@1
          inputs:
            SonarCloud: 'sonarcloud'
            organization: 'foo'
            scannerMode: 'MSBuild'
            projectKey: 'foo_sonar-scanning-someconsoleapp'
            projectName: 'sonar-scanning-someconsoleapp'
            extraProperties: |
              sonar.verbose=true
      

• The important logs are in the END step (i.e. SonarQubeAnalyze / SonarCloudAnalyze / “Run Code Analysis”)

Share the msbuild detailed logs

MsBuild.exe /t:Rebuild /v:d

or

dotnet build -v:d

 
Thx,
Ann

[SamuelBlickle]

Hi, I have taken your advice and logged with verbose set to true, resulting in very detailed logs. Thank you very much for that hint.

Unfortunately, I cannot post full logs (due to them containing a lot of sensitive data, and being way too long to properly redact and reduce them), but I’ve gathered some more insight into the problem thanks to these logs:

As it seems, the problem is not (as I initially expected) that SonarQube isn’t picking up tsconfig files. Our solution consists of many projects, sometimes nested into each other.

We have a project on the very first level. Let’s call this project “Web”. In Web, there is a tsconfig file, as well as several sub projects (let’s say “Web.A”, “Web.B”, “Web.C” and so on). These sub projects do not contain tsconfig files, but they do contain ts files. Naturally, SonarQube doesn’t detect tsconfig files for these projects.

Unfortunately, the analysis of these sub-projects (or modules, as they’re called in the SonarQube logs) happens before the analysis of the Web project, leading to them being logged first. That’s the reason why I assumed no tsconfig file being found is the problem. However: It isn’t.

The tsconfig file of the Web project gets detected properly and SonarQube interprets it’s contents correctly. But here’s the real reason why the ts files in question are not being analysed: They don’t get counted as a part of the Web project (which in fact they really aren’t. They are part of the sub-project they belong to.). So the logs print File not part of the project for every single one of them, when analyzing the Web project.

On the other hand, in the analysis of a sub-project (to which the ts files belong), there is no tsconfig. Hence, SonarQube is (again) skipping the analysis of the ts file.

What would be the best approach to resolve this problem of “one of the two conditions always missing”?

[ganncamp (G Ann Campbell)]

Hi,

Would you be willing to share the logs privately?

 
Ann

[SamuelBlickle]

Sure thing! Drop me an email adress or a Signal ID or something and I’ll send them over tomorrow.
Thank you very much, I really appreciate your help

[ganncamp (G Ann Campbell)]

Hi,

I’ve referred this to the experts. They’ll contact you for logs.

 
Ann

[Mary_Georgiou]

Hello @SamuelBlickle,

I’ve contacted you regarding the logs.

Best Regards
Mary

[SamuelBlickle]

Hi, thank you very much for taking over this thread.

It has (fortunately) been solved by now. For the sake of maybe helping out other community members that might come across the same problem in the future, here’s what was going on:

In our case, we are having a solution structure of projects nested in projects. For example:

MainProject/
├─ SubProjectA/
│  ├─ some.ts
│  ├─ someMore.ts
│  ├─ SubProjectA.csproj
├─ SubProjectB/
│  ├─ some.ts
│  ├─ SubProjectB.csproj
├─ SubProjectC/
│  ├─ some.ts
│  ├─ SubProjectC.csproj
├─ MainProject.csproj
├─ tsconfig.json

When SonarQube analyses a solution, it (correct me if I’m wrong) seems to simply analyse each project one by one, as if they would be totally independent from each other. Analysis doesn’t necessarily follow a meaningful order in the context of the solution.

Furthermore, in order to have the .NET scanner analyse non-dotnet languages as well (here: TypeScript), the files in question need to be part of the corresponding project (here: defined by the .csproj file).

In order to analyse TypeScript, it is also necessary to have a referring tsconfig in the project the .ts file belongs to.

This is what was missing in our case.

We have a global tsconfig file in the project of the very first hierarchy level. In all subprojects, we do not carry around tsconfig files. The tsconfig we have in place looks about like this:

	"include": [
		"./SubProject*/**/*.ts",
        # ...
	], # ...

SonarQube isn’t able to conclude that this tsconfig is also applicable to the nested subprojects.
When it analyses the solution, it either analyses

• a project with a tsconfig but no ts files in the project scope (in case of the top level project)
• or a project with ts files in the project scope but without a tsconfig (in case of any subproject).

However, both preconditions must be fulfilled for a project, in order for SonarQube to analyse the TypeScript files as well.

In order to fix this issue, we had to put a tsconfig file (we otherwise wouldn’t need) in every subproject, referencing any .ts file.

[Mary_Georgiou]

Hello @SamuelBlickle,

Thanks a lot for taking the time to come back and write down your findings.

When SonarQube analyses a solution, it (correct me if I’m wrong) seems to simply analyse each project one by one, as if they would be totally independent from each other. Analysis doesn’t necessarily follow a meaningful order in the context of the solution.

In the case of analysis with the scanner for .NET, the analysis is done during project compilation by MSBuild, and it’s MSBuild to decide the order of project compilation. You can modify the order by setting the dependencies between projects.
The files to be analyzed are the files included in the compilation (.cs/.vb files).

We pick up non-C#/VB.NET files, like *.ts, when they are referenced in the project files (for example, *.csproj).

Another way to tell the scanner to include *.ts files, is with the help of the MSBuild property $(SQAdditionalAnalysisFileItemTypes) during the scanner build step. For example, msbuild /p:SQAdditionalAnalysisFileItemTypes=TypeScriptCompile (the list of types currently supported is here).
Let me know if you used one of these ways and if it worked.

I have a couple of questions to understand this case:
So, does your solution not have an actual TypeScript project? Did you only have typescript files in C # projects and one tsconfig file in the root? You do not reference the tsconfig files in the project file?

What commands do you run for the analyses in these two cases?

• a project with a tsconfig but no ts files in the project scope (in the case of the top-level project)
• or a project with ts files in the project scope but without a tsconfig (in case of any subproject).

Ideally, please provide me with a toy project with this structure!

Thanks a lot!