I think we should inherit stdio streams to get incremental input/output/errors, instead of writing something at the end.

Do we need that having RedirectStandardOutput set to true?

@kblok the default is false - so I think we do, if we want to see the input/output

sorry. I mean, if we have RedirectStandardOutput = true do we need to write the output to the console. Doesn't RedirectStandardOutput do that for us?

So, I assumed that too, but it didn't. I'll give it another go, though.

Heh, look at that, turns out you have to call BeginOutputReadLine, to get anything on the event handlers :D

This is done, now. For now, I'm assuming that what I get is a direct WriteLine, so I don't support some scenarios, like the app clearing the output. But I think this will be fine for v1.

Who sets this env variable?

This would be the user calling the tool. If there's none set, we get a null and do fallback.

Will the tool pick up Playwright from my project, if I am at src/?

I've changed the behaviour and doc now:

• traverse current folder and find .playwright
• NuGet cache

Stackoverflow says this is going to block, and so we won't see live updates. Perhaps we should await for process.Exited event to unblock the thread so it can perform live streaming of the output? I am also not sure what WaitOne(5000) is for?

It'll block the calling thread, yes, but it launches the process from a different thread and the callbacks happen on other threads:

The WaitOne is to ensure that we don't make the same mistake as our tests did initially - disposing stuff before we get all the content. We either wait for null to be sent as the payload, when the stream is done, or 5 seconds after the process exited which likely means there was a problem in the stream.

FWIW, the Process implementation uses AsyncStreamReader underneath, and that queues the work using this.

So, it's possible that we get a piece of text dispatched when the call to WaitForExit already returns - hence the AutoResetEvent :-).