Don't run net4x tests with Mono on non-Windows

[akoeplinger]

We'd try to use Mono to run them but most of the tests assume Windows when targetting net4x so they don't work anyway and you'd need to remember to pass the -f net9.0 TFM filter. Instead just skip them on non-Windows platforms.

Fixes #81395

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We'd try to use Mono to run them but most of the tests assume Windows when targetting net4x so they don't work anyway and you'd need to remember to pass the -f net9.0 TFM filter. Instead just skip them on non-Windows platforms.

Fixes #81395

Author:	akoeplinger
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ViktorHofer]

Few questions / observations:

1. This only filters .NET Framework builds out for multi-targeting projects, right? How would we achieve the same when i.e. doing a dotnet test on a traversal project / solution file for non multi-targeting projects? While we only have a few of those, I think we should keep parity between single and multi-targeting builds in regards to test adapter support.
2. Won't this break whenever the SDK or this repo adds to the AdditionalProperties metadata? Is there a more robust way to make this comparison?
3. This reminds me that the current experience is the one that customer hit as well. I would prefer if we could fix this not just for runtime but for all other repositories and our customers as well. If we decide that we only want to fix this for runtime, this would benefit from a comment pointing to a tracking issue on the vstest side.

[akoeplinger]

This only filters .NET Framework builds out for multi-targeting projects, right? How would we achieve the same when i.e. doing a dotnet test on a traversal project / solution file for non multi-targeting projects? While we only have a few of those, I think we should keep parity between single and multi-targeting builds in regards to test adapter support.

I don't know how it works for traversal projects or solution files, does it not run the Test target on the individual projects?
Not sure what you mean with non multi-targeting projects, do we have ones where we only target a net4x TFM?

Won't this break whenever the SDK or this repo adds to the AdditionalProperties metadata? Is there a more robust way to make this comparison?

I've pushed a change to make this more resilient.

This reminds me that the current experience is the one that customer hit as well. I would prefer if we could fix this not just for runtime but for all other repositories and our customers as well. If we decide that we only want to fix this for runtime, this would benefit from a comment pointing to a tracking issue on the vstest side.

For customers the existing behavior makes sense, or at least it'd be a breaking change. In dotnet/runtime we can make different assumptions.

In the end this is a quick fix to stop annoying devs in this repo, we don't need to make it perfect.

[ViktorHofer]

I wasn't aware that this only affects projects that use the Microsoft.DotNet.Buid.Tasks.TargetFramework nuget package. I think it would be better to move this into here: https://github.com/dotnet/arcade/blob/130b08562936277405284145c1befc87bf1e83cb/src/Microsoft.DotNet.Build.Tasks.TargetFramework/src/buildMultiTargeting/Microsoft.DotNet.Build.Tasks.TargetFramework.targets#L40-L41

By doing that, any consumer of that nuget package will benefit from your improvements and the approach is more efficient as we don't need to pass the to be filtered project TFM tuples into the ChooseBestTargetFrameworksTask task.

We already check the TFM values there to not append -$(TargetOS) for .NET Framework so that would be a good place to filter those projects out on non Windows. I think this should be an opt-in so that this only affects desired targets like Test and VSTest but not the Build target. Runtime would then set the property before invoking the GetProjectWithBestTargetFrameworks in outerbuilds.targets in a target (we had this before).

As discussed offline, we should still file an issue on the VSTest side and link to it for the dotnet test code path.

[akoeplinger]

@ViktorHofer updated with the new arcade-based filtering. Also filed a VSTest issue: microsoft/vstest#4908

[ViktorHofer]

One nit, aside from that LGTM. Regarding the portable source build failure, tt might not be possible anymore to just update one dependency from a repo that offers an intermediate source build package.

[akoeplinger]

Regarding the portable source build failure, tt might not be possible anymore to just update one dependency from a repo that offers an intermediate source build package.

Ok, I'll wait for the arcade update to flow into main.