[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.