Vstest: Running tests as x86?

[ig-sinicyn]

Description

It looks like dotnet vstest does not honor --platform:x86 switch

Steps to reproduce

1. Create new test project (references MSTest.TestFramework)
2. Add following test:

    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMethod1()
        {
            Assert.AreEqual(IntPtr.Size, 4);
        }
    }

1. Compile the library; run the test via dotnet vstest bin\Release\netcoreapp2.0\MsUnitTestProject1.dll --platform:x86

Expected behavior

Test should run without errors

Actual behavior

Test fails with

Assert.AreEqual failed. Expected:<8>. Actual:<4>

I've tried to add

    <PlatformTarget>x86</PlatformTarget>

to the csproj. In that case test run fails with

No test found. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.

message.

Environment

Win 10 x64 (with all updates), VS 2017.3.5 + net core sdk 2 installed.

Code: MsUnitTestProject1.zip

[pvlakshm]

vstest picks up the dotnet.exe from the path. If that exe happens to have a bitness of 64 bit, then the tests will not honour x86 settings. This behaviour is the same as trying to launch an x86 app with the x64-based dotnet.exe.
This is by design.

[ig-sinicyn]

Well, it looks like regression for me. MSTest runner does support target platform selection, NUnit runner has --x86 switch for it. xUnit includes xunit.console.x86.exe runner. As it is for now vstest is the only test runner that does not support tests for x86 assemblies on x64 system.

[ig-sinicyn]

UPD
Documentation says the --platform switch should work with vstest.

[codito]

@ig-sinicyn vstest does work as advertised for net46 or other desktop targets, because it can run the appropriate process (these are just *.exe or *.x86.exe). For dotnet, the scenario is different, it picks up dotnet from path; at a time only one of the x86 or a x64 dotnets can be in path.

[ig-sinicyn]

@codito thanks!
Is there any way to get path for specific version (x86|x64) of dotnet command on buildserver?
Other, than hardcoding the path, of course:)

[codito]

I am not sure if there's a clean way. Default installers usually push the dotnet executable to %ProgramFiles%\dotnet\dotnet.exe% or "%ProgramFiles(x86)%\dotnet\dotnet.exe.

Another way is to specifically install the dotnet-cli using script to well known directory. We're using this approach for vstest repo (example). It is possible to install both x86 and x64 side by side and put the version to be used in %PATH% dynamically.

[ig-sinicyn]

Okay, to summarize: for dotnet command there is no way to select target platform (x86|x64) to run.
The %path% does not work (last installed version wins). Explicit paths are fragile and may not work on client machines. Kinda disappointing:)

Thanks again, will use direct paths.

[iskiselev]

Looks like after #2161 was merged, there is only one component to fully support --platform switch. testhost.exe and testhost.x86.dll should be always copied to output directory (on Net Core), at least on Windows.
It will allow to select correct platform at runtime in vstest same way, as it work currently with dotnet test. At least it would be great to provide some msbuild property to allow copy both host to output dir.

[AndrueCope]

And it seems that has come back with 16.8.0 Preview 1

[nohwnd]

@AndrueCope you are right, this has been a long running issue. We were fixing it for 32-bit windows and broke it in visual studio, and vstest.console but it works under dotnet test (or will once preview8 is available, or if you are using net5.0-rc1). We already fixed this in 16.8-preview2. You can work around the issue by specifying the /platform switch in command line, or in VS click the cog in Test Explorer and setting the platform for anycpu projects.

[AndrueCope]

Oh, I didn't see that option. Thank you. I'm in the process of upgrading one of our dependencies so we might be able to move away from targeting x86 finally. I've been programming since the 1980s and when this cropped up it struck me as unfunny that x86 was still a thing in 2020 :)