Youssef Victor

Currently, `TestName` is always non-null. I think we can mark it non-null in a minor release. I don't see any breaking impact by that. **However** is it actually correct that...

Thanks for reporting this @SamuelMuellerKMS. Is this somehow a regression? Or that's how it always behaved? The current behavior makes sense to me. MSTest doesn't (and shouldn't) plug any custom...

We may actually consider changing STAThreadAttribute behavior so that it either sets a single threaded synchronization context so that continuations are pushed back to the original thread (needs careful implementation,...

@SamuelMuellerKMS Meanwhile, you can try something like the following, which implements a new custom attribute, `ExSTATestMethod` that uses a single threaded synchronization context. ```csharp internal sealed class ExSTATestMethodAttribute : TestMethodAttribute...

@AArnott Can I have your thoughts please on modifying MSTest's STATestMethodAttribute per the above implementation? Today, what we do is very simple, we simply create a new STA thread, and...

Thanks @fforjanAVEVA. As mentioned before, today's behavior of STA is that it just starts the test method in a STA thread and it doesn't set a synchronization context that schedules...

> I've never used `[STATestMethod]` in MSTest, so I can't speak on compatibility for your proposed change. I can tell you that `[StaFact]` is probably one of the least popular...

@fforjanAVEVA You could still plug the synchronization context in assembly initialize, and hopefully it should work? My implementation above might need to be tweaked if it's to be used with...

Today, `ExecutionThreadApartmentState` won't handle async properly. It only ensures that the tests are run in STA, without setting a SynchronizationContext that ensures you will get back to STA as well....

This should have never worked, even in 3.8.3. Can you show an example of how it works in 3.8.3? Following is the behavior I see in 3.8.3, which makes sense...