Scanner command: SonarCloudAnalyze@4 (with scannerMode: 'dotnet' in SonarCloudPrepare@4)
Languages of the repository: C#, XAML, XML, YAML, SQL
Only if the SonarCloud project is public, the URL: private
Error observed: See below
Steps to reproduce: See below
Potential workaround: Unknown
My project does nightly builds with SonarQube Cloud analysis. Up until 2026-07-01 I didn’t have any warnings in the analysis/scanner. Starting with the nightly build on 2026-07-02 - where I didn’t change any code in my main branch - the analysis summary page now shows this warning:
There are problems with file encoding in the source code. Please check the scanner logs for more details.
The scanner logs show multiple lines like this:
02:12:20.890 WARNING: WARN: Invalid character encountered in file path/to/some/binary/file at line 1 for encoding UTF-8. Please fix file content or configure the encoding to be used using property ‘sonar.sourceEncoding’.
I see the warning for many binary file types (.jpg, .png, .docx, .pdf, .zip, …).
The version number of the scanner didn’t change between those two dates. So I don’t know what could have caused this other than a change on SonarQube Cloud server side.
SonarCloudAnalyze@4 Version : 4.2.5
SonarScanner for .NET 11.2.1
Binary files should not show this warning. Please fix this.
The warning itself isn’t new, the scanner generates WARN: Invalid character encountered for any binary file it indexes but can’t read as UTF-8, which is expected behavior since binary files aren’t text. What’s new as of July 2 is that these binary files are apparently now being included in the analysis scope when they weren’t before.
I’m flagging this for the team to investigate what changed on July 2 that would have widened the file indexing scope for .NET dotnet scanner mode projects.
In the meantime, the immediate fix is to explicitly exclude binary file types from your analysis. Add the following to your sonar-project.properties or pipeline configuration:
This will prevent the scanner from trying to read those files and suppress the warnings. See Excluding files based on file paths for the full exclusion syntax.
Could you also confirm: did anything change around July 2 in your Azure DevOps pipeline YAML, the SonarCloudPrepare@4 task version, or any project-level settings in SonarQube Cloud? Even a minor task version pin change could be the culprit.
No, I didn’t change anything. The 2 builds that I compared were from the same commit, which includes the YAML file (I run nightly builds, even when nothing changes).
I also compared the task version and “SonarScanner for .NET” version in both build logs. They were the same (that I included in my initial message).
But what I didn’t notice previously are the following version differences in the log of the SonarCloudPrepare task:
Without encoding warnings:
SonarQube Cloud: Server version: 8.0.0.94190
Processing plugin: securitycsharpfrontend version 11.35.0.47322
Processing plugin: securityvbnetfrontend version 11.35.0.47322
With encoding warnings:
SonarQube Cloud: Server version: 8.0.0.94653
Processing plugin: securitycsharpfrontend version 11.36.0.47442
Processing plugin: securityvbnetfrontend version 11.36.0.47442
(Other “Processing plugin” versions were the same.)
I did find that a scanner engine update deployed around July 2 (reflected in the server version jump from 8.0.0.94190 to 8.0.0.94653) unified some code between SonarQube Server and SonarQube Cloud. One side effect is that the analysis warning for unreadable characters in binary files, which already existed on SonarQube Server, is now also emitted on SonarQube Cloud.
Whether binary files should trigger this warning at all is a fair question, and I’ve flagged the behavior change for the relevant team to review. In the meantime, the practical fix remains the same, explicitly exclude binary file types from the analysis scope so the scanner doesn’t attempt to read them:
Add this to your pipeline’s SonarCloudPrepare@4extraProperties or to a sonar-project.properties file at the root of your repo. This will stop the warnings from appearing regardless of what the server-side behavior does.