Closed PeterMortensen closed 7 years ago
You mean you don't care about the GUI? Or you want to control the GUI? I'm not sure I understand your question. IMHO, OutputDebugString is and old useless thing, and people should use ETW instead. I say that because capturing ETW programmatically is pretty easy, it's basically located here: https://github.com/Dependencies/TraceSpy/blob/master/TraceSpy/EventRealtimeListener.cs
Yes, I don't care about the GUI for this particular use case. OutputDebugString is a given for now for the .NET application I want to use it for.
(ETW looks interesting, but isn't it for C++ applications? https://msdn.microsoft.com/en-us/library/windows/desktop/bb968803(v=vs.85).aspx says "ETW is designed for C and C++ developers.".)
No, ETW can be very easily used by .NET app, using the standard EventProvider class. And in fact, Microsoft uses it everywhere. It's much better than OutputDebugString (wich is slow, is common to all tracers, has limits in length, cannot cross some service processes, like IIS, etc.). Check the read.me on this repository.
Here is how you can initalize a provider (once in an app lifetime):
Guid providerGuid1 = new Guid("01234567-01234-01234-01234-012345678901");
var prov = new EventProvider(providerGuid1);
And here is how you send a trace (plus you can add a trace level):
prov.WriteMessageEvent("hello world", 0, 0);
See, it's not more complicated than OutputDebugString. And to read it, you can just use TraceSpy (or reuse TraceSpy code and put it somewhere in yours)
For use in automation (say, from a PowerShell script) it would be nice to have a command-line interface (like DebugViewPP, https://github.com/CobaltFusion/DebugViewPP).
Or some other kind of interface that allows programmatic access to the debug information.