dotnet format throws because it can't determine file encodings in 9.0.200

[DavidZidar]

Describe the bug

It is no longer possible to use dotnet format without arguments to format code in certain projects because it has started throwing an error in 9.0.200. dotnet format --verify-no-changes does still work however.

What's worse, it doesn't specify what file might be the issue so it is very hard to figure out what might be going wrong.

To Reproduce

I'm not exactly sure since it doesn't tell me what file it has a problem with, but I'm just running dotnet format in an ASP.NET Core 9 project with about 1500 C# files.

Exceptions (if any)

Unhandled exception: System.Exception: source text did not have an identifiable encoding
   at Microsoft.CodeAnalysis.Tools.Formatters.CharsetFormatter.IsEncodingEquivalent(SourceText sourceText, Encoding encoding)
   at Microsoft.CodeAnalysis.Tools.Formatters.CharsetFormatter.<>c__DisplayClass10_0.<FormatFileAsync>b__0()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
   at Microsoft.CodeAnalysis.Tools.Formatters.DocumentFormatter.GetFormattedSourceTextAsync(Document document, OptionSet optionSet, AnalyzerConfigOptions analyzerConfigOptions, FormatOptions formatOptions, ILogger logger, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.Tools.Formatters.DocumentFormatter.<>c__DisplayClass8_1.<<FormatFiles>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.CodeAnalysis.Tools.Formatters.DocumentFormatter.ApplyFileChangesAsync(Solution solution, ImmutableArray`1 formattedDocuments, FormatOptions formatOptions, ILogger logger, List`1 formattedFiles, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.Tools.Formatters.DocumentFormatter.FormatAsync(Workspace workspace, Solution solution, ImmutableArray`1 formattableDocuments, FormatOptions formatOptions, ILogger logger, List`1 formattedFiles, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.Tools.CodeFormatter.RunCodeFormattersAsync(Workspace workspace, Solution solution, ImmutableArray`1 formattableDocuments, FormatOptions formatOptions, ILogger logger, List`1 formattedFiles, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.Tools.CodeFormatter.FormatWorkspaceAsync(FormatOptions formatOptions, ILogger logger, CancellationToken cancellationToken, String binaryLogPath)
   at Microsoft.CodeAnalysis.Tools.FormatCommandCommon.FormatAsync(FormatOptions formatOptions, ILogger`1 logger, CancellationToken cancellationToken)
   at Microsoft.CodeAnalysis.Tools.Commands.RootFormatCommand.FormatCommandDefaultHandler.InvokeAsync(ParseResult parseResult, CancellationToken cancellationToken)
   at System.CommandLine.Invocation.InvocationPipeline.InvokeAsync(ParseResult parseResult, CancellationToken cancellationToken)

Further technical details

The error started showing up after installing Visual Studio 17.3, but it is also happening in WSL2 with the latest .NET SDK.

[DavidZidar]

I did try running dotnet format --verbosity diag but did not receive any additional actionable information.

[adam-knights]

Incase its useful in fixing this, we see similar today having taken 9.0.200, but on Windows only, our Mac arm64 users do not see the errors. May not apply to all cases, but if someone is looking at this and can't reproduce, try Windows.

[caleblloyd]

I am hitting this on linux after the 9.0.200 upgrade today. Same deal, --verbosity diag doesn't show any other useful information. Reverting to 9.0.103 fixes.

[ChrisTTian667]

Incase its useful in fixing this, we see similar today having taken 9.0.200, but on Windows only, our Mac arm64 users do not see the errors. May not apply to all cases, but if someone is looking at this and can't reproduce, try Windows.

I'm a Mac ARM 64 User and have the same issue. I don't think that its related to the platform.

[MattEdwardsWaggleBee]

I'm seeing this on my Windows 11 machine and my GitHub action running on "ubuntu-latest"

update: I'm on 9.0.200 co-worker doesn't see this on 9.0.103

[swharden]

Thanks for opening this issue and following-up with your suggestions!

I'm here to report I fixed this by locking the dotnet version to 9.0.103 too, as shown in ScottPlot/ScottPlot@57c9b02

[david-driscoll]

I'm also hitting this as well on a mac m4.

[Kiruyuto]

This happened to me today, Win11 and .NET 9.0.200.
In my case, it was related to the fact that some files had UTF-8-BOM encoding which they should not (Per .editorconfig). Running dotnet format --severity info -v diag --verify-no-changes to locate them and then removing it via Rider fixed the usual dotnet format.

[WernerMairl]

Same here!
Please fix this asap, it breaks some working projects/builds!

[zce]

When I moved the charset option to the root node, the issue was solved:

root = true
charset = utf-8

[*]
end_of_line = lf
insert_final_newline = true

# ...

[just-jim]

Are you sure? Rider says that you are not allowed to have multiple declaration in the top level

[redbit86k]

Rider shows this error/warning but i can confirm, with this dotnet format runs without the error.
I can't say if its correct or good to have the charset in the editorconfig at the root level but it is a workaround at the moment.
I didn't notice any side effects besides the warning so far 🤞

[DavidZidar]

The charset trick didn't work on my machine unfortunately, and neither did checking for files with unnecessary BOM-headers. I re-wrote all C#-files to disk without BOM to make sure.

[just-jim]

Until this is fixed, I will force my project to run on 9.0.100. To do so go to the root of your project and run:
dotnet new globaljson --sdk-version 9.0.100
(make sure you have 9.0.100 installed. Check the installed versions by: dotnet --list-sdks)
dotnet format works normally in version 9.0.100.

[WernerMairl]

Running dotnet format --severity info -v diag --verify-no-changes to locate them and then removing it

this helped me a lot: basically i had a single file somewhere in between that had a unexpected BOM ( "UTF8+BOM" instead of "UTF8")

If the Exception can be avoided : nice!!
If not, then i suggest to provide better exception message that avoids the extra step with dotnet format --severity info -v diag --verify-no-changes

the first class exception should

• contain the path/filename of the involved file
• show the expected encoding and the existing encoding!

Side note: Visual Studio is not showing the BOM status currently, i had to use VS-Code for deeper analysis.

BR Werner

[caleblloyd]

Here is a bash script to remove BOM from git tracked text files - tested on Linux but may work fine on macOS or WSL also:

# Process all tracked files
while read -r file; do
    # Check if file is binary using git-diff
    if ! git diff --no-index --numstat /dev/null "$file" | grep -q "^-"; then
        # Check if file has BOM
        if head -c3 "$file" | grep -q $'\xEF\xBB\xBF'; then
            echo "Removing BOM from: $file"
            sed -i '1s/^\xEF\xBB\xBF//' "$file"
        fi
    fi
done < <(git ls-files)

dotnet format seems to be working for me again after running this.

[cfbao]

Just to clarify - removing BOM doesn't fix real the problem.

If dotnet format (in 9.0.200) catches any formatting problem (BOM is just one of them), it will fail to auto format the files.

[sharwell]

@mattmc3 Thank you that is exactly what I needed

[rubo]

When will the fix be released? v9.0.201 still has this problem.

[mattmc-jtb]

Agreed rubo. I'm surprised this wasn't considered a critical fix since dotnet format has been effectively broken for a month.

[just-jim]

So when should we expect to see the fix? In which version?

[JoeRobich]

The fix merged into the 9.0.2xx branch and will be in the 9.0.202 SDK. I have verified the fix in the 9.0.300 nightly SDK (see https://github.com/dotnet/sdk/blob/main/documentation/package-table.md) build as well.

[dqwork]

When would 9.0.202 be included with Visual Studio - Just updated to the latest (17.13.5) and only got SDK 9.0.201 which still has this bug

[mtmk]

fyi I was having the same issue (even after removing BOM) and wasted about an hour before I found this issue.

Upgrading to latest (as of today 9.0.203) fixed it for me.

> dotnet --version
9.0.203

[idgogoasa]

Running
dotnet format --verify-no-changes
will list the files that need encoding changes
Did that, fixed the encoding using Notepad++ and all is OK.

[jantrmer]

fyi I was having the same issue (even after removing BOM) and wasted about an hour before I found this issue.

Upgrading to latest (as of today ) fixed it for me.9.0.203

> dotnet --version
9.0.203

I was having the same issue, and downloading and installing SDK 9.0.300 fixed it. Release date: May 13, 2025. Thanks.