Set PlatformTarget to AnyCPU for modern .NET

[am11]

Fixes #42558.

cc @jkotas, @baronfel

[baronfel]

Thanks for starting this! It looks like the tests got removed in one of the more recent commits, though?

[jkotas]

Is UseNativeCode a pre-existing property or is this a new property introduced by this PR?

If it is a new property introduced to disable the new behavior, it should have a specific name, something like UseSpecificPlatformTargetIfPossible.

[am11]

It is used in a test project which is failing on .NET Framework, so I added it here temporarily to check if that's the only issue. It turned out it's not the only problem there. Tests are written in a way that diverging behavior is tricky to assert.

[jkotas]

Given the latest conversation (#48599 (comment)), should the UseNativeCode condition be deleted here?

[Youssef1313]

Did you verify the impact of this on VSTest?

For modern .NET, we determine which testhost will be copied to output directory based on that.

https://github.com/microsoft/vstest/blob/main/src/package/Microsoft.TestPlatform.TestHost/Microsoft.TestPlatform.TestHost.props

I think the usage in VSTest is bad, but we need to understand how we will approach handling this breaking change.

It's also passed to VSTestTask here:
https://github.com/microsoft/vstest/blob/dbcd471883202088496ab81d3ec2d3f3be0981b5/src/Microsoft.TestPlatform.Build/Microsoft.TestPlatform.targets#L53

But for the specific usage in this task, I don't know if it's .NET Framework only or if it also affects .NET Core. @nohwnd will be the best contact here.

[nohwnd]

Looks like the effect of this change is that we will copy always testhost.exe (the x64 testhost) to the output, and then when we see that the preference of the user is to run x86 tests, we will search for testhost.86.exe and won't find it, and will fall back to resolving dotnet for x86 architecture, and running x86/dotnet.exe testhost.dll.

https://grep.app/microsoft/vstest/main/src/Microsoft.TestPlatform.TestHostProvider/Hosting/DotnetTestHostManager.cs?q=dotnettesthostmanager#L469

But who knows what other things we will see fail in the wild, we've seen users checking the process name to be testhost.exe and testhost.x86.exe, which was the reason we keep shipping those exes, but did not add one for arm64 or other architectures.

If we go down this path it would be nice to detect that the fix is in place, and never copy the testhost.exe to output when new dotnet SDK is used, to unify how we run tests in the future, to always go through dotnet.exe.

[baronfel]

@Youssef1313 / @nohwnd if we target this for .NET 11, would that be a clear enough check for VSTest? If SDK version is at least 11 then don't copy testhost.exe?

[baronfel]

@Youssef1313 / @nohwnd Broadly, for SDK-style projects I'd say that RuntimeIdentifier is the correct way to pivot these kinds of arch-specific assets. In 11 you can use the SelectRuntimeIdentifierSpecificItems Task to actually do the RID-validation logic for you, so you could have an MSBuild Item list of testhost binaries, tag them each with a RuntimeIdentifier, and let the SDK handle choosing the most-compatible item.

[nohwnd]

Sounds good to me, I am okay with not shipping testhost.exe at all in the nuget package. At least we get compatible with how we run on non-windows.

[baronfel]

Rebased this to get a fresh build so we can see the test results - they'd expired since the last time this ran.

[baronfel]

Did a quick perusal of the test failures - most of them are explicitly validating that platform-specific binaries were used/provided/selected during the compilation/build/publish. We'll need to go into each of those scenarios in more detail and decide if the test is expressing an actual design constraint, or just pinning the behavior at that point in time and can be safely updated/removed/etc.