[WIP] Breaking changes in dotnet-format 6.x

[JoeRobich]

• We are moving into the .NET 6 SDK (See https://github.com/dotnet/format/issues/1268). There will be no need to install dotnet-format as a global tool or local tool.
• As part of the move into the .NET SDK, we have changed our command line options. (see https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-format)
• Organize imports was moved from being a whitespace formatter to running as a code style formatter.
• CodeStyle and 3rd Party Analyzers will only run if they are specifically configured in your .editorconfig.
• Default severity for CodeStyle and 3rd Party Analysis is now warning.
• We now use the highest version .NET 6 SDK that is installed rather than trying to match the global.json configuration.

[alirezanet]

Hi @JoeRobich, I'm the maintainer of Husky.Net tool, as feedback, you have more breaking changes in the v6. 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

The expected behavior is ignoring everything else except the target file. or providing an option to change its behavior. This is the biggest downside of v6 in my opinion. Thank you

[JoeRobich]

@alirezanet Thanks for bringing this up. There seems to be issues with how our CommandLine options are being parsed by the Dotnet CLI itself prior to them being sent to our tool. As a workaround you can try using dotnet format --include=folder/targetFile.cs. I hope to take a deeper look into this now that I am back from the holiday.

[benbarth]

Hi @JoeRobich, @alirezanet and I have been trying to find a solution to this issue. (https://github.com/alirezanet/Husky.Net/issues/23)

Is it a bug or by design that --include files must be located within the workspace?

[JoeRobich]

Is it a bug or by design that --include files must be located within the workspace?

It is by design that if you are working against a .csproj or .sln that the only files you can include are also part of that project or solution. You can use the dotnet format whitespace --folder --include= to perform whitespace formatting of files not part of a project or solution.

[DavidZidar]

@JoeRobich Hi, please consider reverting that last bullet point:

We now use the highest version .NET 6 SDK that is installed rather than trying to match the global.json configuration.

It seems to break dotnet format completely when preview versions are installed because it is now trying to load the wrong assemblies. See #1500 for logs. When a project has a global.json file in place there is probably a very good reason why, don't side step that and use a different SDK version than what is asked for.

[ftathiago]

Hi @JoeRobich, I'm the maintainer of Husky.Net tool, as feedback, you have more breaking changes in the v6. 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

The expected behavior is ignoring everything else except the target file. or providing an option to change its behavior. This is the biggest downside of v6 in my opinion. Thank you

I'm using lint-staged (node tool) to perform this exactly scenario.

[alirezanet]

I'm using lint-staged (node tool) to perform this exactly scenario.

We had some problems in the previous versions of husky.net, It is solved now. I suggest trying it out since not every dontet project needs npm and node js to be installed.

[jose-tissei]

I'm using lint-staged (node tool) to perform this exactly scenario.

We had some problems in the previous versions of husky.net, It is solved now. I suggest trying it out since not every dontet project needs npm and node js to be installed.

@alirezanet how did you solve this? i'm trying to setup husky .net with dotnet-format on a dotnet 6.0 project and i'm running into the "no workspace" problem. If i do provide a workspace i run into problems like IDE1006 can't fix the whole solution

[alirezanet]

dotnet-format, unfortunately, doesn't work if your csharp file isn't part of a project/solution. this is dotnet-format default behavior which I don't like either, and it is not related to husky. I solved husky compatibility issues with this behavior.

[jose-tissei]

Yeah but even when i do supply a file that is part of a project/solution i get errors like it not being able to apply NamingStyleCodeFixProvider

Cannot fix IDE1006. The NamingStyleCodeFixProvider code fix does not support the Fix All option in the Solution.

[JoeRobich]

@jose-tissei Currently dotnet-format cannot fix NamingStyle issues as Roslyn does not provide a support for it. See Roslyn issue https://github.com/dotnet/roslyn/issues/14983.

Is dotnet-format logging this warning causing issues?

[jose-tissei]

@JoeRobich i thought it was more of a generalized error and that the way i was running the tool was wrong, now that i know that it's just a limitation from roslyn i can use it just fine, thank you!