dotnet format for very large codebases

[KirillOsenkov]

dotnet format is using MSBuildWorkspace to read the .sln file and instantiate all projects in memory at once. For large solutions with thousands of projects this approach does not scale (I ran into this issue earlier with https://github.com/KirillOsenkov/SourceBrowser)

I prototyped a simple tool that instead uses an MSBuild binlog to read compiler invocations from the binlog and then processes each project in isolated (by creating a ProjectInfo from Csc command line arguments for that project).

Here's the prototype:
https://github.com/KirillOsenkov/CodeCleanupTools/tree/main/CodeFixer

For a small-ish 50 project solution it takes 51 seconds (vs. 1:07 for dotnet format). For larger solutions the difference will be more and more pronounced, to the point where dotnet format will choke altogether while my tool will continue to work fine.

Another problem with dotnet format is that it effectively does two passes over the solution to find diagnostics: first pass to find all diagnostics, and then when it does Fix All it effectively scans the solution for diagnostics again. Roslyn might cache things, but it's still double the work.

I'm not sure how actionable this issue is, I contemplated contributing a PR that adds support for a new type of workspace (BinlogWorkspace) but the way dotnet format is currently written it would need to be refactored in a non-trivial way because currently it assumes there's a single large solution and not many individual projects.

At the very least I'm filing this issue so that people for whom dotnet format chokes on their solution have a workaround.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.