moving to different command structure

[jmarolf]

This will require similar change to the dotnet/sdk repo once this is merged.

[jmarolf]

@JoeRobich I am merging main to release/6.x to clean up the changes a bit. May want to wait to review this until then.

One wild change I am making is having the 6.0 release target .NET 6. Let me know if there are giant unforseen problem here.

[JoeRobich]

One wild change I am making is having the 6.0 release target .NET 6. Let me know if there are giant unforseen problem here.

One downside is anyone using still using dotnet-format as a global tool with .NET 3.1 or .NET 5 will need to stick with the 5.x release. If we decide to keep the change, we may want to publish an updated 5.x with a newer Roslyn compiler.

[jmarolf]

If we decide to keep the change, we may want to publish an updated 5.x with a newer Roslyn compiler.

My preference would be to not continue to support older versions. We just ship the SDK and simplify the support structure (i.e. we only support running on the SDK we insert into).

[JoeRobich]

we only support running on the SDK we insert into

K then we will need to tweak the how we use MSBuildLocator. Currently it will try and load the SDK that is pinned in the global.json, and this branch falls over if that is 3.1 or 5.0.

[jmarolf]

K then we will need to tweak the how we use MSBuildLocator. Currently it will try and load the SDK that is pinned in the global.json, and this branch falls over if that is 3.1 or 5.0.

Got it. I think we don't want to support that anymore for the tool that is installed in the SDK.

[JoeRobich]

@jmarolf Any reason to hold on merging this?

[mihai-unity]

I just noticed this PR lost -f alias for --folder.

[JoeRobich]

@mihai-unity Yes, this was an intentional breaking change taken to better incorporate into the dotnet CLI. Breaking changes are being tracked on issue #1292.