Scope .editorconfig discovery to included files in dotnet format folder mode by wellWINeo · Pull Request #55248 · dotnet/sdk

wellWINeo · 2026-07-11T15:50:45Z

Summary

dotnet format whitespace --folder scanned the entire workspace tree for .editorconfig files (EditorConfigFinder.GetEditorConfigPaths used GetFiles(".editorconfig", SearchOption.AllDirectories)). In monorepos with large non-.NET subtrees (e.g. node_modules) that whole-tree scan dominates folder-mode runtime, even though the vast majority of those directories contain no file being formatted.

This PR replaces the scan with an upward walk: for the set of files the workspace will actually format, it collects the .editorconfig files in each file's ancestor directories (deduplicating shared ancestors), via EditorConfigFinder.GetEditorConfigPathsForFiles. The full-tree GetEditorConfigPaths(folderPath) is removed.

Correctness. A non-global .editorconfig only affects files in its own directory subtree, so the only configs that can change a file's effective options are those on the path from the workspace root down to the file's own directory. The folder workspace formats exactly the resolved file set, so the union of ancestor walks over that set yields identical analyzer-config resolution for every document; the configs the old scan collected from directories that are not an ancestor of any formatted file could never have matched them. Two edge cases where this differs from the old scan are in Notes.

Measurements

On a large work monorepo (400+ C# projects plus a JS frontend with ~230 node_modules directories), formatting one file. Numbers are the median of 3 timed runs after 1 warmup; "Before" and "After" are two Debug builds of this branch — the parent commit and this change — measured on the same machine:

Command	Before	After
`dotnet format whitespace . --folder --include src/App/Program.cs`	1.09s	0.55s

References

Contributes to Slow performance for --include with single file format#757 (single-file --include performance) and dotnet-format is very slow on larger repos format#1378.
Same spirit as Filter out project early if it doesn't have any formattable documents format#1485, which added early project filtering for --include.

Notes

--exclude and MSBuild (project/solution) workspaces are unchanged; this only affects folder-mode .editorconfig discovery. Both concrete --include lists and glob includes now use the ancestor walk (globs resolve to files under the workspace folder, so their ancestor set is the same the scan would have found).
Out-of-workspace includes: a concrete --include path resolving outside the workspace folder now has the .editorconfig files in its own ancestor directories applied. Previously folder mode discovered configs from the workspace folder's tree only, so such a file was formatted with the workspace folder's configs rather than its own — a behavior change (arguably more correct).
is_global configs: a file named .editorconfig containing is_global = true is treated by Roslyn as a global analyzer config (its top-level options apply regardless of directory). The ancestor walk only visits directories on the path from a formatted file up to the root, so a global-marked .editorconfig in a directory that is not an ancestor of any formatted file is no longer discovered. Rare: the convention for repo-wide configuration is .globalconfig (not discovered by folder mode under old or new code), and is_global is not part of the EditorConfig spec. Use .globalconfig for genuinely global configuration.
On case-sensitive filesystems the ancestor walk's ordinal-ignore-case directory deduplication is not strictly behavior-preserving: configs for distinct included directories differing only by case may be omitted. This follows existing case-insensitive folder-mode matching conventions; making it filesystem-aware would be a wider folder-mode change.

wellWINeo · 2026-07-14T15:26:18Z

@dotnet-policy-service agree

azure-pipelines · 2026-07-14T15:26:34Z

Azure Pipelines: Successfully started running 1 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Copilot

Pull request overview

Improves dotnet format whitespace --folder --include <file> performance by avoiding a full workspace .editorconfig scan when the include set is an explicit list of files under the workspace folder, and instead collecting only ancestor .editorconfig files that can actually apply.

Changes:

Add EditorConfigFinder.GetEditorConfigPathsForFiles(...) to discover .editorconfig files by walking ancestor directories for specific files.
Update folder-mode solution loading to use the file-based .editorconfig discovery when --include is a concrete file list (and --exclude is empty) fully contained under the workspace folder.
Add unit tests covering ancestor-only .editorconfig discovery and duplicate prevention.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
test/dotnet-format.UnitTests/Utilities/EditorConfigFinderTests.cs	Adds unit coverage for the new file-based `.editorconfig` discovery behavior.
src/Dotnet.Format/dotnet-format/Workspaces/FolderWorkspace_FolderSolutionLoader.cs	Switches `.editorconfig` discovery to a fast ancestor-walk when includes are concrete files under the workspace.
src/Dotnet.Format/dotnet-format/Utilities/EditorConfigFinder.cs	Introduces `GetEditorConfigPathsForFiles` to collect applicable configs without scanning the full folder tree.

JoeRobich · 2026-07-14T21:16:13Z

+                // Only configs in the files' ancestor directories can apply to them. Included
+                // files resolving outside the workspace folder keep the original scan so their
+                // behavior is unchanged.
+                var folderPrefix = absoluteFolderPath.EndsWith(Path.DirectorySeparatorChar)


Can you just make this part of calculating the absoluteFolderPath above?

if (!Path.EndsInDirectorySeparator(absoluteFolderPath)) { absoluteFolderPath += Path.DirectorySeparatorChar; }

Obsolete — folderPrefix only existed for the containment check, which is removed.

JoeRobich · 2026-07-14T21:21:10Z

            return editorConfigPaths.ToImmutable();
        }
+
+        public static ImmutableArray<string> GetEditorConfigPathsForFiles(ImmutableArray<string> filePaths)


Can you have GetEditorConfigPaths(string) simply call this method? Update where you set directory name to first check if the path is a directory before calling GetDirectoryName

Removed GetEditorConfigPaths(string) instead of unifying — the loader always calls GetEditorConfigPathsForFiles with the resolved file list, so there's a single discovery path.

jasonmalinowski · 2026-07-14T22:08:03Z

+            foreach (var filePath in filePaths)
+            {
+                var directoryName = Path.GetDirectoryName(filePath);
+                if (string.IsNullOrEmpty(directoryName) || !Directory.Exists(directoryName))


Consider only doing the Directory.Exists() check after visitedDirectories check, so that way we don't pay it once we've already added the directory to the HashSet.

Applied — dropped the guard entirely; File.Exists doesn't throw on a missing directory.

jasonmalinowski · 2026-07-14T22:14:06Z

+                var editorConfigPaths = hasConcreteIncludePaths
+                        && filePaths.All(filePath => filePath.StartsWith(folderPrefix, StringComparison.OrdinalIgnoreCase))
+                    ? EditorConfigFinder.GetEditorConfigPathsForFiles(filePaths)
+                    : EditorConfigFinder.GetEditorConfigPaths(folderPath);


So does this mean that as long as there's one glob then we'll still end up finding all the editor configs in the entire folder instead? What happens if we just always call GetEditorConfigPathsForFiles?

Done — always file-based now; GetEditorConfigPaths(folderPath) removed.

Instead of gating the ancestor walk to concrete --include lists and falling back to a full-tree scan, always collect .editorconfig files by walking up from each formatted file. Remove the now-unused GetEditorConfigPaths(folderPath) full scan and the containment gating. In GetEditorConfigPathsForFiles, use File.Exists instead of DirectoryInfo.GetFiles and drop the redundant Directory.Exists guard.

wellWINeo · 2026-07-15T14:42:44Z

Adopting @jasonmalinowski's suggestion to always use the ancestor walk (dropping the concrete-include gating) removes two things the previous version preserved. Both are now documented in the PR description Notes; flagging here since they differ from what you reviewed.

Out-of-workspace concrete includes. The previous version kept the full scan whenever an --include path resolved outside the workspace folder, so such a file was formatted with the folder's config tree rather than its own. With the ancestor walk it now gets the .editorconfig files in its actual ancestor directories — arguably more correct, but a behavior change (it invalidated the old "outside the workspace also use the original scan" note, now removed).
is_global-marked .editorconfig. Treated by Roslyn as a global analyzer config — top-level options apply regardless of directory. The old scan found such a file anywhere under the workspace folder; the ancestor walk only visits a formatted file's ancestor directories, so a global-marked .editorconfig off that path (e.g. analyzers/.editorconfig when formatting the repo root with no formatted sources under analyzers/) is no longer discovered. Narrow — the convention is .globalconfig (never discovered by folder mode; those come through MSBuild in project/solution mode, which this PR doesn't touch) — and arguably closer to the EditorConfig spec, which doesn't define is_global. I've gone with accept-and-document (see Notes); say the word if you'd rather preserve the old discovery for either case.

jasonmalinowski · 2026-07-15T17:45:56Z

@wellWINeo I think both of those seem like reasonable behavior changes to me (unless @JoeRobich wants to overrule me.) The first behavior seems otherwise pretty broken (you'll format with the wrong settings), and in the second case, if there's multiple global configs in the same repo, you'll get "who knows" behavior (since we won't have the right logic for which one to consume.)

JoeRobich

I like the direction this is headed.

JoeRobich · 2026-07-15T18:12:44Z


-                var filePaths = GetMatchingFilePaths(absoluteFolderPath, fileMatcher);
-                var editorConfigPaths = EditorConfigFinder.GetEditorConfigPaths(folderPath);
+                var hasConcreteIncludePaths = fileMatcher.Exclude.IsDefaultOrEmpty && AreAllFilePaths(fileMatcher.Include);


Lets revert pulling this out of the GetMatchingFilePaths method

JoeRobich · 2026-07-15T18:13:24Z

                }
            }
+
+            private static bool AreAllFilePaths(ImmutableArray<string> globs)


Lets revert pulling this out of the GetMatchingFilePaths method

…gFilePaths With the .editorconfig discovery ternary gone, the flag and helper no longer need to be hoisted to LoadSolutionInfo, so restore GetMatchingFilePaths to its original shape.

…derSolutionLoader.cs Co-authored-by: Joey Robichaud <joseph.robichaud@microsoft.com>

JoeRobich · 2026-07-20T17:12:49Z

/azp run

azure-pipelines · 2026-07-20T17:13:07Z

Azure Pipelines: Successfully started running 2 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions.

wellWINeo added 2 commits July 11, 2026 18:42

Add editorconfig discovery scoped to a set of files

fd6e2c6

Scope editorconfig discovery to included files in folder mode

0c56a73

wellWINeo marked this pull request as ready for review July 14, 2026 15:26

Copilot AI review requested due to automatic review settings July 14, 2026 15:26

wellWINeo requested a review from a team as a code owner July 14, 2026 15:26

Copilot started reviewing on behalf of wellWINeo July 14, 2026 15:26 View session

Copilot AI reviewed Jul 14, 2026

View reviewed changes

Comment thread src/Dotnet.Format/dotnet-format/Workspaces/FolderWorkspace_FolderSolutionLoader.cs Outdated

Comment thread src/Dotnet.Format/dotnet-format/Utilities/EditorConfigFinder.cs Outdated

JoeRobich reviewed Jul 14, 2026

View reviewed changes

jasonmalinowski reviewed Jul 14, 2026

View reviewed changes

JoeRobich reviewed Jul 15, 2026

View reviewed changes

Move hasConcreteIncludePaths and AreAllFilePaths back into GetMatchin…

724b21d

…gFilePaths With the .editorconfig discovery ternary gone, the flag and helper no longer need to be hoisted to LoadSolutionInfo, so restore GetMatchingFilePaths to its original shape.

JoeRobich reviewed Jul 17, 2026

View reviewed changes

Comment thread src/Dotnet.Format/dotnet-format/Workspaces/FolderWorkspace_FolderSolutionLoader.cs Outdated

Update src/Dotnet.Format/dotnet-format/Workspaces/FolderWorkspace_Fol…

ba4ac80

…derSolutionLoader.cs Co-authored-by: Joey Robichaud <joseph.robichaud@microsoft.com>

Merge branch 'main' into format-editorconfig-scoped-discovery

7d68e10

build-analysis Bot mentioned this pull request Jul 20, 2026

GivenDotnetSlnAdd.WhenNestedProjectIsAddedSolutionFoldersAreCreatedBuild: intermittent CS0579 duplicate-attribute build failure on nested .slnx #55358

Closed

Merge branch 'main' into format-editorconfig-scoped-discovery

1f5ae7c

jaredpar requested a review from mwiemer-microsoft July 23, 2026 22:53

Uh oh!

Conversation

wellWINeo commented Jul 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Measurements

References

Notes

Uh oh!

wellWINeo commented Jul 14, 2026

Uh oh!

azure-pipelines Bot commented Jul 14, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wellWINeo commented Jul 15, 2026

Uh oh!

jasonmalinowski commented Jul 15, 2026

Uh oh!

JoeRobich left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JoeRobich commented Jul 20, 2026

Uh oh!

azure-pipelines Bot commented Jul 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

wellWINeo commented Jul 11, 2026 •

edited

Loading