David Matson

> There is no "test adapter" in their new model: the test executable is expected to be able to support their (as yet undocumented) launch command line switch(es) and do...

> As to your comparison: either way, the stand-alone executable has to have some way to communicate with the meta-runner. I doubt choosing console would be "faster" than a protocol...

Thanks for the detailed and helpful discussion here, Brad. > I agree it's not ideal, though I think because the system is purpose built with limited interactions, it can be...

> I'm unaware of any way to opt out of the separate executable in today's VSTest model. That doesn't mean it doesn't exist, but I'm not aware of how it's...

Did VSTS add a solution for the debugging part recently here? https://github.com/microsoft/vstest/blob/9225d88be2aa289cac30a1f7b68b83f592c80344/docs/RFCs/0029-Debugging-External-Test-Processes.md

Cool - glad that helps! It's also possible there's a way to bypass TestHost.exe, using a [.RuntimeProvider.dll](https://github.com/microsoft/vstest/blob/9225d88be2aa289cac30a1f7b68b83f592c80344/src/Microsoft.TestPlatform.Common/Hosting/TestRunTimeExtensionManager.cs#L18). Apparently Python and TAEF (largely an internal Microsoft test framework) had some need...

Makes sense. Thanks for following up, Brad!

>the build outputs an error message when it actually succeeds. >@ davidmatson Thanks for posting this issue, could you please provide me with the error log you output? Sure; the...

@stuartpreston - I just encountered similar symptoms in a different context (outside of Chef) and found a solution - thought I'd drop a note in case that solution works for...