Skip to content

Conversation

Youssef1313
Copy link
Member

@Youssef1313 Youssef1313 commented Aug 27, 2025

Fixes #50307

FYI @dsplaisted @baronfel

The scenario is:

  • Solution with two projects
  • First project is a test project targeting netX.0
  • Second project is a class lib targeting any other different TFM (e.g, netstandard2.0), and it's not test project.
  • First project references the second project.
  • User does dotnet test --framework netX.0
    • Previous behavior, we will attempt to build the classlib with netX.0. But as netX.0 wasn't part of restore, this fails.
    • New behavior, we will attempt to only build the test projects. This is aligned with the existing behavior for VSTest, and is potentially a performance improvement for scenarios where a solution has some projects that are not present in the dependency graph of test projects, as we will not need to build such projects altogether.

@Youssef1313 Youssef1313 merged commit 705a211 into release/10.0.1xx Aug 27, 2025
28 checks passed
@Youssef1313 Youssef1313 deleted the dev/ygerges/mtp-build branch August 27, 2025 07:55
@Evangelink
Copy link
Member

Evangelink commented Aug 27, 2025

I think the original behavior is correct. If you create a class library project targeting netstandard2.0 and a console app targeting net8.0 and referencing the classlib and you do dotnet build --framework net8.0 you will have the error:

image

The --framework is a build argument so it's flown down and causes a failure. If we want to introduce a new argument for the test that is applied only to test project we could.

@baronfel What's your view on the behavior of SDK? I mean is a higher command that includes lower commands should respect the lower command behavior or change it?

@Youssef1313
Copy link
Member Author

Discussed offline with @Evangelink and we are now both aligned that the change in this PR is okay. I'd still would love hear @baronfel feedback :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Investigate 'dotnet test' behavior on solution when passing --framework
3 participants