[3.0 regression] Unable to run a test with timeout in STA ApartmentState

[cremor]

Describe the bug

MSTest v2 ran all tests in STA ApartmentState when executed in a .NET Framework runtime. v3 runs "normal" tests still in STA, but tests that have a TimeoutAttribute applied now run in MTA.

Steps To Reproduce

Run these tests with various versions of MSTest and runtimes:

[TestMethod]
public void TestMethod1()
{
    // Outputs:
    // MSTest   net7.0   net48
    // 2.2.10   MTA      STA
    // 3.0.2    MTA      STA
    Console.WriteLine(Thread.CurrentThread.GetApartmentState());
}

[TestMethod, Timeout(1000)]
public void TestMethod2()
{
    // Outputs:
    // MSTest   net7.0   net48
    // 2.2.10   MTA      STA
    // 3.0.2    MTA      MTA    <-- Problem
    Console.WriteLine(Thread.CurrentThread.GetApartmentState());
}

Expected behavior

Either MSTest v2 behavior should be retained, or I should have a way to force STA on an unit test.

Actual behavior

Tests with timeout always run in MTA.

Additional context

I need STA to run UI (WPF) tests. Those tests try to execute WPF commands which now fail with InvalidOperationException: The calling thread must be STA, because many UI components require this.

This is most likely a side effect of #1296
The package "MSTest.STAExtensions" which is mentioned in #21 does not help/work, see saikrishnav/testfxSTAext#5
Related: #320

AB#1822144

[engyebrahim]

Hi @cremor, thanks for your feedback!
I confirm I can reproduce the issue with mstest v.3.0.2.

[cremor]

@engyebrahim Thanks for confirming. But why did you tag this issue as a feature? I'd say that this is a bug.

[engyebrahim]

@cremor because it's related to this one #320 and also to making something like this MSTest.STAExtensions inside mstest.

by making default behaviour and a decorator to use the other behaviour.

[cremor]

But the default behavior worked in 2.2.10.
So it was an intentional change in v3 to have different ApartmentStates when running with or without a TimeoutAttribute?

[cremor]

@engyebrahim Thanks for reclassifying this as a bug.

Is there a chance that this will be fixed in a 3.0.x release?
If not, is there any kind of workaround?

[engyebrahim]

Hi @cremor we will discuss it and let you as soon as possible

[fforjan]

@engyebrahim any update on this ? I'm doing some porting between .net framework and .net 6.0 on my unit test with WPF and i'm getting
System.InvalidOperationException: The calling thread must be STA, because many UI components require this.

It seems there is a different of behavior between .net framework and .net 6.0 and would like to know what is the expectation.

Seems you were having some discussion. Let me know if you need a different issue

[Evangelink]

Hey @cremor, @fforjan,

We are still investigating the issue (more precisely the fix).

I confirm @cremor investigation that the change is a side-effect of merging the timeout behaviors hence using Task.Run instead of a Thread which helped with cancellation token but cause a change in the current apartment.

We will get back to you asap.

[fforjan]

Salut @Evangelink !
Any update on the issue ?

This is blocking us we are trying to have the same WPF unit test compiled and running with 2 different framework - .NET Fwk/.NET 6.0 with the differene MTA/STA between both frameworks.

[Evangelink]

Hi @fforjan,

Sorry it's taking some time but we are exploring the solution to fix this issue. If we don't find something reasonable quickly we will probably revert the linked change in a bug fix version and plan to reapply the change in a later update when we have a proper upgrade path for users.

[Evangelink]

Might be related to microsoft/vstest#1865

[fforjan]

@Evangelink in my case, yes !

[Evangelink]

I haven't been able to make lots of progress on that today but I noticed that depending on target framework the testhost was using different mode and I found the linked issue.

[Evangelink]

@cremor we have reverted the change and will include the fix in 3.0.3 (we hope to ship it next week).

@fforjan I believe this revert won't be enough for you as you would want to run some tests with STA using .NET 6 and this won't be possible (it was not possible in previous versions of MSTest). I have created #1674 to track providing a good solution for this use case.

[dotMorten]

I'm still seeing async tests that timeout will deadlock the test process on .NET Framework using 3.0.4. No issue on 2.2.10

I'm guessing it is most likely caused by this

testfx/src/Adapter/MSTest.TestAdapter/Extensions/MethodInfoExtensions.cs

Line 168 in d74733f

task?.GetAwaiter().GetResult();

This is such great way to do deadlocks. I think the only way to truly fix this is to introduce a new ITestMethodAsync interface that has a proper Task<TestResult[]> ExecuteAsync() method instead of just the synchronous Execute ITestMethod provides.