[v6] dotnet format don't respect --include option

Hi, I’m the maintainer of Husky.Net tool, In big projects using dotnet-format is a real pain, it takes a lot of time to complete. This is one of the reasons that I created Husky.Net. usually, people only want to format changed files( or staged files). In the previous versions (e.g v5) we could’ve easily limited the dotnet-format working area to the specific files using --include but in the last version looks like dotnet-format doing something else in the background and don’t respect that option.

dotnet format --include folder/targetFile.cs folder/targetFile2.cs

The expected behavior is ignoring everything else except the target files. or providing an option to change its behavior. This issue makes dotnet-format v6 almost unusable, how can I fix this problem or change its behavior? Thank you

[JoeRobich]

To handle the options not being parsed correctly, we plan to remove the parsing from the CLI side and simply pass through to the dotnet-format tool. I have opened https://github.com/dotnet/sdk/pull/25541 to get this addressed.

As for performance, we have discussed alternate ways to speed up populating our workspace. Ultimately MSBuild will be involved at some point because .NET builds are so highly customizable the only way not to be wrong is to have MSBuild do the work.

1. We could use a cache of MSBuild .binlog (or other format) containing the code files and dependency information we need. At which point this becomes a staleness problem. If dependencies aren’t being added/removed, then this cache may remain a viable source of information for a long period.
2. We could develop a Project Server of sorts. This service would have an initial slow startup that you experience today but, while it remains running, future invocations wouldn’t have to pay the MSBuild cost.

We are not committing to either approach today, but know that this a problem that we are thinking on.

[sander1095]

@JoeRobich Hey Joe! Giving a quick reply here… I guess my example is bad, because when I use --include with actual supported files in my solution, it’s really slow.

So… to improve my example:

dotnet format solution.sln --include src/WebApi/Startup.cs

still results in other non-relevant projects being built/analyzed…

One workaround is simply using dotnet format whitespace which is super quick, but kinda defeats the point of using editorconfig and specific dotnet rules…

---

Also, what do you mean with the workaround? How is that different than what @alirezanet is posting? The only difference i see is that @alirezanet 's example contain 2 files, where yours only contains one.

I dont think it is a functional workaround to call dotnet format --options here for EACH changed file… this would kill performance even more!

Curious to hear about your reply!