Build --project setting does not respect --os or --arch settings

[marek-safar]

Try to build an individual project using command line like

./build.sh --arch wasm --os Browser --configuration release --projects <path-to-some-project-like-/src/libraries/System.Net.Http/src/System.Net.Http.csproj>

The build produces output for all System.Net.Http targets

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

We don't filter based on TargetOS or TargetArchitecture but on BuildTargetFramework which is derived from TargetFramework: https://github.com/dotnet/arcade/blob/b5f1c06d542d947d38ead87640040d81d55a0290/src/Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk/src/build/Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk.targets#L14.

In this case, as no BuildTargetFramework is set, no filtering happens.

@Anipik is this something that we want to support? We would need to change the condition to also respect TargetOS and make filtering possible without a target framework specified.

cc @ericstj

[ericstj]

I guess we need to consider what the build.sh script does. Normally it will filter to netcoreappcurrent when -allconfigurations isn't specified, but it's not doing that here. I suspect folks don't really want the behavior of "build all possible TargetFrameworks that have this arch" when they are invoking build.sh in this way.

[ViktorHofer]

I suspect folks don't really want the behavior of "build all possible TargetFrameworks that have this arch" when they are invoking build.sh in this way.

This isn't isolated to build.sh or build.cmd. This happens when invoking dotnet build on a project as well when supplying TargetOS. Regarding build.cmd/sh, I would even remove the --projects switch as we have our dotnet.cmd/sh helper scripts in the repo root which we advertise and support.

[ericstj]

The interface to a project is TargetFramework | TargetFrameworks. If we wanted to provide a shortcut for OS it should probably assume some TargetFramework (NetCoreAppCurrent). Note that what you are calling filtering is not actually filtering for many TargetFrameworks, it is actually best applicable TargetFramework . The best TargetFramework for browser might actually be a TargetFramework that doesn't target browser. The best TargetFramework for all possible browser TargetFrameworks might actually be all TargetFrameworks in the project. This is why we would need to assume some TargetFramework.

[ViktorHofer]

That makes sense. I don't think we should have diverging behaviors between build.cmd/sh -projects and dotnet build. Are we fine with requiring devs to filter based on the TargetFramework, in this case dotnet build -f net5.0-Browser? I'm unsure if we should support other inputs besides TargetFramework.