Add warning when using --framework with solution files #51561

Copilot · 2025-11-04T21:46:29Z

Summary: Add warning when using `--framework` with solution files

This PR addresses the issue where using --framework on a solution build can cause referenced projects to build multiple times, leading to inconsistent builds and file locking issues.

Changes Made

Added NETSDK1235 warning string resource in Strings.resx (changed from NETSDK1234 due to conflict with RoslynCompilerType deprecation warning)
Modified FrameworkOption in CommonOptions.cs to set _CommandLineDefinedTargetFramework=true property
Added _CheckForSolutionLevelTargetFramework target in Microsoft.NET.Sdk.Solution.targets
Updated warning text to say "isn't recommended" instead of "isn't supported"
Added XML comment explaining that bypass via -p:TargetFramework is intentional for advanced scenarios
Added Pack target to BeforeTargets list (in addition to Build, Publish, Clean, Store, VSTest, _MTPBuild)
Added FrameworkOptionTests to validate warning behavior for affected commands
Resolved merge conflicts with main branch
Verified changes work with manual testing

Implementation Details

Similar to the existing -o/--output warning (NETSDK1194), this adds warning NETSDK1235 when users specify --framework on a solution build.

How it works:

When --framework is used, the CLI forwards both --property:TargetFramework=<value> and --property:_CommandLineDefinedTargetFramework=true
The Solution targets file checks for the _CommandLineDefinedTargetFramework property
If set, it displays NETSDK1235 warning before Build, Publish, Clean, Pack, Store, VSTest, _MTPBuild targets
Using --property:TargetFramework=<value> directly does NOT trigger the warning (intentional bypass for advanced scenarios, documented in code comments)
For dotnet test --no-build, the warning won't appear as the Build target doesn't run (expected behavior)

Example Output

$ dotnet build --framework net10.0
warning NETSDK1235: The "--framework" option isn't recommended when building a solution. 
Specifying a solution-level framework results in all projects building for that framework, 
which can cause referenced projects to build multiple times and can lead to inconsistent builds.

Fixes dotnet build --framework builds referenced project twice #26690

Original prompt

This section details on the original issue you should resolve

<issue_title>dotnet build --framework builds referenced project twice</issue_title>
<issue_description><!--
Please keep in mind that the GitHub issue tracker is not intended as a general support forum, but for reporting non-security bugs and feature requests.

If you believe you have an issue that affects the SECURITY of the platform, please do NOT create an issue and instead email your issue details to secure@microsoft.com. Your report may be eligible for our bug bounty but ONLY if it is reported through email.
For other types of questions, consider using StackOverflow.

-->

Describe the bug

dotnet build with --framework builds the same project twice in parallel, if it is referenced by a solution and a ProjectReference. Without --framework, it builds only once.

To Reproduce

Dep.sln

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.30114.105
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "One", "One\One.csproj", "{6C41A8DE-5C2D-4D36-9F5E-5070A5333DC9}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Two", "Two\Two.csproj", "{8DEDAFB4-3647-450C-BD9A-0D1978A0A950}"
EndProject
Global
        GlobalSection(SolutionConfigurationPlatforms) = preSolution
                Debug|Any CPU = Debug|Any CPU
                Release|Any CPU = Release|Any CPU
        EndGlobalSection
        GlobalSection(SolutionProperties) = preSolution
                HideSolutionNode = FALSE
        EndGlobalSection
        GlobalSection(ProjectConfigurationPlatforms) = postSolution
                {6C41A8DE-5C2D-4D36-9F5E-5070A5333DC9}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
                {6C41A8DE-5C2D-4D36-9F5E-5070A5333DC9}.Debug|Any CPU.Build.0 = Debug|Any CPU
                {6C41A8DE-5C2D-4D36-9F5E-5070A5333DC9}.Release|Any CPU.ActiveCfg = Release|Any CPU
                {6C41A8DE-5C2D-4D36-9F5E-5070A5333DC9}.Release|Any CPU.Build.0 = Release|Any CPU
                {8DEDAFB4-3647-450C-BD9A-0D1978A0A950}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
                {8DEDAFB4-3647-450C-BD9A-0D1978A0A950}.Debug|Any CPU.Build.0 = Debug|Any CPU
                {8DEDAFB4-3647-450C-BD9A-0D1978A0A950}.Release|Any CPU.ActiveCfg = Release|Any CPU
                {8DEDAFB4-3647-450C-BD9A-0D1978A0A950}.Release|Any CPU.Build.0 = Release|Any CPU
        EndGlobalSection
EndGlobal

One/One.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.XmlSerializer.Generator" Version="6.0.0" />
  </ItemGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.XmlSerializer.Generator" Version="6.0.0" />
  </ItemGroup>

</Project>

One/Class1.cs

namespace One
{
    [System.Xml.Serialization.XmlRoot]
    public class Class1
    {
    }
}

Two/Two.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\One\One.csproj" />
  </ItemGroup>

</Project>

Log of dotnet build --framework net6.0 becoming unexpectedly parallel and attempting to access a locked file

$ dotnet build --framework net6.0
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  One -> C:\Projects\Dep\One\bin\Debug\net6.0\One.dll
  One -> C:\Projects\Dep\One\bin\Debug\net6.0\One.dll
  .NET Xml Serialization Generation Utility, Version 6.0.0]
  Serialization Code File Name: C:\Projects\Dep\One\obj\Debug\net6.0\One.XmlSerializers.cs.
  Generated serialization code for assembly C:\Projects\Dep\One\obj\Debug\net6.0\One.dll --> 'C:\Projects\Dep\One\obj\Debug\net6.0\One.X
  mlSerializers.cs'.
  .NET Xml Serialization Generation Utility, Version 6.0.0]
  Serialization Code File Name: C:\Projects\Dep\One\obj\Debug\net6.0\One.XmlSerializers.cs.
  Generated serialization code for assembly C:\Projects\Dep\One\obj\Debug\net6.0\One.dll --> 'C:\Projects\Dep\One\obj\Debug\net6.0\One.X
  mlSerializers.cs'.
CSC : warning CS1504: Source file 'C:\Projects\Dep\One\obj\Debug\net6.0\One.XmlSerializers.cs' could not be opened -- The process cannot
 access the file 'C:\Projects\Dep\One\obj\Debug\net6.0\One.XmlSerializers.cs' because it is being used by another ...

</details>

- Fixes dotnet/sdk#26690

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.

- Added NETSDK1234 warning string in Strings.resx - Modified FrameworkOption to set _CommandLineDefinedTargetFramework property - Added _CheckForSolutionLevelTargetFramework target in Microsoft.NET.Sdk.Solution.targets - Created FrameworkOptionTests.cs with test cases for the new warning Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

Manual testing confirms the feature works correctly: - Using --framework on solution shows NETSDK1234 warning - Using --property:TargetFramework does not show warning - Warning appears for build, clean, publish, and test commands Changes: - Added NETSDK1234 warning string in Strings.resx - Modified FrameworkOption to set _CommandLineDefinedTargetFramework property - Added _CheckForSolutionLevelTargetFramework target in Microsoft.NET.Sdk.Solution.targets Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

marcpopMSFT · 2025-11-07T00:02:53Z

@baronfel in the spirit of limiting new warnings, should we only spit out this warning if the TFM is net11? People are definitely going to hit it.

baronfel · 2025-11-07T00:27:14Z

The problem (similar to the output path) is that we don't know at the solution-level that these targets run at if the projects target 11.

We probably should create a Target similar to what Restore does and have the solution gather the TFMs of the project and flag if the TFM is present.

KalleOlaviNiemitalo · 2025-11-07T05:41:26Z

Does this warn when dotnet test --no-build is used with --framework on a solution? I expect it shouldn't.

dotnet-policy-service · 2025-11-13T21:48:29Z

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
Ask a committer to mail the .NET SDK Breaking Change Notification email list.

You can refer to the .NET SDK breaking change guidelines

marcpopMSFT · 2025-11-13T21:52:58Z

@copilot can you change the test to say "isn't recommended" rather than "isn't supported"

marcpopMSFT · 2025-11-13T21:54:56Z

Does this warn when dotnet test --no-build is used with --framework on a solution? I expect it shouldn't.
Currently the implementation does. I'm not quite sure I understand the scenario test + --no-build + --framework is used for against a solution. CC @baronfel and @dotnet/dotnet-testing-admin for their opinion on what the behavior should be in that situation.

Updated NETSDK1234 warning text per feedback to be less severe. Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

Copilot · 2025-11-13T22:01:51Z

@copilot can you change the test to say "isn't recommended" rather than "isn't supported"

Changed warning text from "isn't supported" to "isn't recommended" in commit 35d513c.

Updated warning output:

warning NETSDK1234: The "--framework" option isn't recommended when building a solution. Specifying a solution-level framework results in all projects building for that framework, which can cause referenced projects to build multiple times and can lead to inconsistent builds.

Evangelink · 2025-11-13T22:43:55Z

Cc @Youssef1313 and @nohwnd

marcpopMSFT · 2025-11-14T00:36:05Z

@copilot fix the merge conflict

Resolved conflict in CommonOptions.cs by adapting to the new Option structure: - Uses Option<string> instead of DynamicForwardedOption<string> - Sets IsDynamic = true - Uses ForwardAsMany to forward both TargetFramework and _CommandLineDefinedTargetFramework properties - Maintains AddCompletions at the end

Copilot · 2025-11-14T00:48:50Z

@copilot fix the merge conflict

Merge conflict resolved in commit 6e5f32a. The FrameworkOption was adapted to the new Option structure from main while maintaining the warning functionality.

Youssef1313 · 2025-11-14T06:50:39Z

That sounds like a non-trivial breaking change. But as long as it applies to Build, I'm fine with applying it to everything else (test, both MTP and VSTest, publish, etc..).

Youssef1313 · 2025-11-14T06:51:42Z

...ions.Tasks/msbuildExtensions-ver/SolutionFile/ImportAfter/Microsoft.NET.Sdk.Solution.targets

+  <Target Name="_CheckForSolutionLevelTargetFramework"
+          BeforeTargets="Build;Publish;Clean;Store;VSTest;_MTPBuild"
+          Condition="'$(_CommandLineDefinedTargetFramework)' == 'true'">


Does this condition make sense? Users will still be able to bypass that with -p:TargetFramework=...? Is it intended to allow the bypass? If yes, IMO deserves a comment saying it explicitly and demonstrating why.

Yes, the bypass via -p:TargetFramework=... is intentional. Users who set the property directly are in an advanced scenario and likely understand the implications. Added a comment in commit 5184f8d explaining this design decision.

Youssef1313 · 2025-11-14T06:53:11Z

...ions.Tasks/msbuildExtensions-ver/SolutionFile/ImportAfter/Microsoft.NET.Sdk.Solution.targets

  </Target>

+  <Target Name="_CheckForSolutionLevelTargetFramework"
+          BeforeTargets="Build;Publish;Clean;Store;VSTest;_MTPBuild"


Note: for the case of dotnet test --no-build -f ..., this target isn't going to run.

Correct. Since --no-build means the Build target doesn't run, the warning won't appear. This is the desired behavior as no building occurs that could cause the double-build issue.

Youssef1313 · 2025-11-14T06:53:24Z

...ions.Tasks/msbuildExtensions-ver/SolutionFile/ImportAfter/Microsoft.NET.Sdk.Solution.targets


  </Target>

+  <Target Name="_CheckForSolutionLevelTargetFramework"


Do we need Pack as well?

Added Pack to the BeforeTargets list in commit 5184f8d for consistency, though dotnet pack doesn't currently support the --framework option.

Youssef1313 · 2025-11-14T06:53:49Z

...ions.Tasks/msbuildExtensions-ver/SolutionFile/ImportAfter/Microsoft.NET.Sdk.Solution.targets


  </Target>

+  <Target Name="_CheckForSolutionLevelTargetFramework"


Is it fine during restore?

During restore, the TargetFramework property affects dependency resolution but doesn't cause the double-build issue described in the original problem. The warning focuses on build-related targets where the issue manifests.

Youssef1313 · 2025-11-14T06:55:30Z

I'd love to see some tests here for the affected commands, to ensure it doesn't break with any future refactorings.

KalleOlaviNiemitalo · 2025-11-14T07:50:06Z

I'm not quite sure I understand the scenario test + --no-build + --framework is used for against a solution.

Testing some libraries on both .NET Framework and .NET Core, and collecting the test results from different frameworks to different files so that a web UI can easily display them as separate.

Youssef1313 · 2025-11-14T09:23:15Z

Also worth noting that this scenario could be quite different between VSTest and MTP per the current way it's implemented. In VSTest, we always go through the VSTest target, and there we decide if VSTestNoBuild property is true or not to decide if we will build or just run.

marcpopMSFT · 2025-11-20T20:00:13Z

@copilot fix the merge conflict

- Added XML comment explaining that the condition only triggers with --framework CLI option - Added explanation that -p:TargetFramework bypass is intentional for advanced scenarios - Added Pack to BeforeTargets list (though pack doesn't support --framework currently) Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

- Created FrameworkOptionTests similar to OutputPathOptionTests - Tests verify warning appears for build, clean, publish, test commands - Tests verify no warning when using --property:TargetFramework directly - Note: test command output capture may have timing issues in test harness Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

Copilot · 2025-11-20T20:21:16Z

I'd love to see some tests here for the affected commands, to ensure it doesn't break with any future refactorings.

Added FrameworkOptionTests in commit 79e54a7, following the same pattern as OutputPathOptionTests. The tests cover build, clean, publish, and test commands, verifying both the warning appears with --framework and doesn't appear when using --property:TargetFramework directly.

@copilot fix the merge conflict

Merge conflict resolved in commit 1a2cbb7. Changed warning code from NETSDK1234 to NETSDK1235 since NETSDK1234 is now used for RoslynCompilerType deprecation warning in main. Both warnings now coexist in Strings.resx.

NETSDK1234 is already used in main for RoslynCompilerType deprecation warning. Updated to use NETSDK1235 for the framework option warning. Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

Resolved conflicts: - Updated Strings.resx to include both NETSDK1234 (RoslynCompilerType) and NETSDK1235 (framework option) - Accepted main's version for unrelated file conflicts in eng/, src/BuiltInTools/, template_feed/, and test files

Initial plan

a73be18

Copilot AI assigned Copilot and marcpopMSFT Nov 4, 2025

Copilot started work on behalf of marcpopMSFT November 4, 2025 21:46 View session

Copilot AI and others added 2 commits November 4, 2025 21:57

Copilot AI changed the title ~~[WIP] Fix dotnet build to avoid double project builds~~ Add warning when using --framework with solution files Nov 4, 2025

Copilot AI requested a review from marcpopMSFT November 4, 2025 22:30

Copilot finished work on behalf of marcpopMSFT November 4, 2025 22:30

build-analysis bot mentioned this pull request Nov 5, 2025

Failure on Helix tests - Tests timing out #40074

Open

marcpopMSFT added the breaking-change Using this label will notify dotnet/compat and trigger a request to file a compat bug label Nov 13, 2025

dotnet-policy-service bot added the needs-breaking-change-doc-created label Nov 13, 2025

Copilot started work on behalf of marcpopMSFT November 13, 2025 21:53 View session

Change warning text from "isn't supported" to "isn't recommended"

35d513c

Updated NETSDK1234 warning text per feedback to be less severe. Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

Copilot finished work on behalf of marcpopMSFT November 13, 2025 22:04

Copilot started work on behalf of marcpopMSFT November 14, 2025 00:36 View session

Copilot finished work on behalf of marcpopMSFT November 14, 2025 00:50

Youssef1313 reviewed Nov 14, 2025

View reviewed changes

Copilot started work on behalf of marcpopMSFT November 20, 2025 20:00 View session

Copilot AI and others added 2 commits November 20, 2025 20:13

Copilot AI and others added 2 commits November 20, 2025 20:26

Change warning code from NETSDK1234 to NETSDK1235

04a0334

NETSDK1234 is already used in main for RoslynCompilerType deprecation warning. Updated to use NETSDK1235 for the framework option warning. Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

Copilot finished work on behalf of marcpopMSFT November 20, 2025 20:35


		</Target>

		<Target Name="_CheckForSolutionLevelTargetFramework"

Add warning when using --framework with solution files #51561

Are you sure you want to change the base?

Add warning when using --framework with solution files #51561

Uh oh!

Conversation

Copilot AI commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary: Add warning when using --framework with solution files

Changes Made

Implementation Details

Example Output

Describe the bug

To Reproduce

Uh oh!

marcpopMSFT commented Nov 7, 2025

Uh oh!

baronfel commented Nov 7, 2025

Uh oh!

KalleOlaviNiemitalo commented Nov 7, 2025

Uh oh!

dotnet-policy-service bot commented Nov 13, 2025

Uh oh!

marcpopMSFT commented Nov 13, 2025

Uh oh!

marcpopMSFT commented Nov 13, 2025

Uh oh!

Copilot AI commented Nov 13, 2025

Uh oh!

Evangelink commented Nov 13, 2025

Uh oh!

marcpopMSFT commented Nov 14, 2025

Uh oh!

Copilot AI commented Nov 14, 2025

Uh oh!

Youssef1313 commented Nov 14, 2025

Uh oh!

Youssef1313 Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

Youssef1313 Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

Youssef1313 Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

Youssef1313 Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

Youssef1313 commented Nov 14, 2025

Uh oh!

KalleOlaviNiemitalo commented Nov 14, 2025

Uh oh!

Youssef1313 commented Nov 14, 2025

Uh oh!

marcpopMSFT commented Nov 20, 2025

Uh oh!

Copilot AI commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Copilot AI commented Nov 4, 2025 •

edited

Loading

Summary: Add warning when using `--framework` with solution files

Copilot AI commented Nov 20, 2025 •

edited

Loading