Skip to content

Added --framework arg to "dotnet format" to set TFM #53202

Open
Hextaku wants to merge 3 commits intodotnet:mainfrom
Hextaku:format-framework-arg
Open

Added --framework arg to "dotnet format" to set TFM #53202
Hextaku wants to merge 3 commits intodotnet:mainfrom
Hextaku:format-framework-arg

Conversation

@Hextaku
Copy link

@Hextaku Hextaku commented Mar 1, 2026

I was really annoyed by #41899 which describes a problem with "dotnet format" when projects have multiple target frameworks, so I added support for a --framework argument to it to specify a single TFM.

Implemented Solution:

New argument "--framework" with alias "-f" which takes a TFM and restricts restore and analysis to the specified framework only.
Unit tests similar to existing dotnet format tests.

Remarks

  • The translations in 'src\BuiltInTools\dotnet-format\xlf' were done with AI(Claude Sonett 4.6) and are not further confirmed.
  • This does not work with the --folder argument.

- Alias -f is set
- does only work without --folder
@Hextaku Hextaku requested a review from a team as a code owner March 1, 2026 09:23
@Hextaku
Copy link
Author

Hextaku commented Mar 1, 2026

@dotnet-policy-service agree

Passing a target framework to `dotnet restore` causes the dotnet CLI in SDK 10.0.x to emit a bare --framework switch in its internal MSBuild.dll invocation. MSBuild does not recognise
that switch and exits with MSB1001.

The framework argument is unnecessary for restore: dotnet restore on a
solution or project already restores all target frameworks. Framework
filtering is handled downstream by MSBuildWorkspaceLoader, which sets the
TargetFramework MSBuild property when opening the workspace.
</trans-unit>
<trans-unit id="Cannot_specify_the_folder_option_with_framework">
<source>Cannot specify the '--folder' option with '--framework'.</source>
<target state="translated">Non è possibile specificare l'opzione '--folder' con '--framework'.</target>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove these translations. Our translation team will handle it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the translations in 61e6c2d

{
internal static class DotNetHelper
{
internal static string BuildRestoreArguments(string workspaceFilePath)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make this a local function of PerformRestoreAsync after the return

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually just revert this change and remove the added tests for it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted the change and the tests in 61e6c2d

Copy link
Member

@JoeRobich JoeRobich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Hextaku Thanks for opening this PR. I had to play around with it a bit to convince myself it was working as expected. Just a few tweaks I would like you to make before we take it.

@jasonmalinowski
Copy link
Member

The original bug called out running into merge conflict issues as a motivation for this flag; is that the motivation here now, or is this needed for some other reason? I can imagine some other needs, but if the only motivation was the merge conflicts, then I'd hope that isn't something we can just address directly.

@Hextaku
Copy link
Author

Hextaku commented Mar 2, 2026

The original bug called out running into merge conflict issues as a motivation for this flag; is that the motivation here now, or is this needed for some other reason? I can imagine some other needs, but if the only motivation was the merge conflicts, then I'd hope that isn't something we can just address directly.

My main motivation here were the merge conflicts. But looking at the problem, I quickly realized that it's also preferable to reduce the target frameworks to only one a lot of times.
My case is that I write mostly framework-independent code that needs formatting. This means running only 1, gives me the same results as running all would, but with fewer analyzers run.

Aside from that, I think it could be quite useful in some CI cases, but there's currently no need on my side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants