Youssef Victor

@elgatov Side note: We already have now `RetryAttribute` that you can use with `[TestMethod]`. For test case association though, this is so far not yet prioritized for Microsoft.Testing.Platform. Consider thumbing-up...

Quick profiling (single run, not averaging, but makes it quite obvious 3.11 is significantly faster in multiple scenarios due to #6319) ### Single test class with 10k tests 3.3.1: 10s...

I did two extra runs. So here is the result of 3 runs of each scenario: #### Single test class with 10k tests 3.3.1: 10s 10s 9s 3.4.3: 14s 9s...

Leaving a note here: we are targeting net462: https://github.com/microsoft/testfx/blob/bb3c852afe2e5a43795b9fdbee6f14b445a6d29e/test/UnitTests/MSTestAdapter.UnitTests/MSTestAdapter.UnitTests.csproj#L5 So one important difference that happens with the move from VSTest to MTP is that testhost.exe.config has: ```xml ``` which is...

This happens only under code coverage, specifically with our [coverage.config](https://github.com/microsoft/testfx/blob/f3ec4dde6ee95396a53012dad96885827b7f932b/test/coverage.config). More specifically, removing the `ModulePaths` element in the config file resolves it.

Ping @fhnaseer

Eh, we have a hack in MSTest that might get broken with this. https://github.com/microsoft/testfx/blob/8687e54f761bba78da213cd5ff34562dca3f8945/src/Adapter/MSTestAdapter.PlatformServices/Services/MSTestAdapterSettings.cs#L190-L199

Ah okay right. Those should be fine then :)

@nohwnd Thinking again here. With the current setup, people can have just x64 dotnet.exe installed, and they can run their tests under testhost.x86.exe. If we don't ship that, then I...

> they will have to have an x86 installation of .net runtime But not necessarily having x86 installation of *SDK*?