dotnet CLI should return a list of target frameworks of the project or use target framework as a filter.

[voroninp]

Is your feature request related to a problem? Please describe.

When my solution contains a mix of projects which target different framework versions (or multitargeted projects)
I have no standard way to select projects by target framework version. I need this for CI/CD pipeline.
For example, to run tests for .NET 9 I need to select only the projects which target it.
If I specify the target framework, I get an error:

dotnet test -f net9.0
Common.Infrastructure.Persistence.Tests net9.0 failed with 1 error(s) (0.3s)
C:\Program Files\dotnet\sdk\9.0.200\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file 'tests\Common.Infrastructure.Persistence.Tests\obj\project.assets.json' doesn't have a target for 'net9.0'. Ensure that restore has run and that you have included 'net9.0' in the TargetFrameworks for your project.
  Common.Domain.Tests net9.0 failed with 1 error(s) (0.3s)

Sure it does not, because this project does not target .NET 9.

In other words, now I cannot say: "Run all tests in solution targeting .NET 9 for projects which support .NET 9"

Describe the solution you'd like

Provide either a standard way to list the target frameworks of a project or an option to use the framework version as a filter in commands that accept template paths, solutions, or lists of projects.

[Youssef1313]

@MiYanni This is quite linked to a discussion I had very recently with @mariam-abdulla.

Is it a bug that dotnet test (and dotnet build as well!) fail with NETSDK1005?

My feeling is that -f should be passing this as a global property to both restore and build steps, so it shouldn't really matter what target framework is defined in csproj. Does RestoringCommand work differently? Is it intentional? Is the problem somewhere else?

[Youssef1313]

I also want to add a note that dotnet test -f whatever is for sure not selecting projects that target the given TFM. What I think it should do is force building and running tests on all projects with the given TFM.

[baronfel]

I'd expect this behavior as soon as you have a graph of project dependencies that don't have the framework specified by -f. This also happens if you try to build or publish for a given -f on a solution, for example.

In this case, I do think that the -f is intended by users to say "run all projects that support this TFM". I'd be supportive of

• flowing that -f value through any implicit restore/build operations (since restore and build do TargetFramework negotiation and should handle this correctly)
• changing the implementation of the test command to then gather all the testable projects, filter them by those that are compatible with the given -f value, and then just test those.

[Youssef1313]

Interesting. @baronfel Does this mean, for the new dotnet test we shouldn't forward TargetFramework global property to Restore?

[baronfel]

Need to check with @nkolev92 for sure, but I think Restore is aware of target framework compatibility/negotiation during Restore, so it won't force transitive project references to use that Framework.

[nkolev92]

In the past, we actually did work so that -f is interpret as restore this project for the framework passed in -f, so this goes counter the ask in the issue.

See NuGet/NuGet.Client#4587 and NuGet/Home#11653.

I'm not sure I've wrapped my head around all the scenarios without testing/debugging, so we might need to chat more about this to figure out how we want to proceed.