You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow more flexibility in where output is printed to.
Specifically, I am looking for the output to be sent to Debug or Trace. Trace would probably be better, since it will be written to in more situations.
Rationale
When debugging a console application in Visual Studio, VS has the rather annoying behavior that it launches a new independent window for the application that closes immediately on completion. To work around this, I usually set up my code to write messages to either Trace or Debug (depending on if I'm using a logging library or something and what it supports). Doing so does not seem to be possible for all outputs in PowerArgs, let alone simple. I believe a large number of .NET developers would appreciate this feature; maybe it should even be the default behavior.
My findings on implementing this without core changes to PowerArgs
I've been able to extend HelpHook to make the help usage print out to a sink that VS will preserve:
public class TraceHelpHook : HelpHook
{
public TraceHelpHook() : base()
{
this.UsageWritten += (help) => { Trace.WriteLine(help.StringValue); };
}
}
But I haven't been able to figure out a way to intercept other outputs, though, like usage messages that result from invalid command lines. That behavior is hard coded to use ConsoleString functionality, it looks like.
It looks like I could implement my own IConsoleProvider and setting ConsoleString.ConsoleProvider, but I'd have to do so as a full wrapper around StdConsoleProvider since it doesn't allow overriding the methods that call Console.WriteLine, but that's really cumbersome just to add an additional sink for output. The user also has to implement 24 methods and properties to do that, adding the other sink (Trace) calls to 6 of the methods.
Implementation strategies that come to mind
Hard code additional Trace calls direct in StdConsoleProvider.
Add an event or two to StdConsoleProvider that a string was written, allowing callers to intercept these events and do whatever they wish with them.
Modify StdConsoleProvider to allow overriding a specific, minimal set of methods that would allow users to intercept all calls to Write. It looks like this would include Write(object output), WriteLine(object output), and WriteLine(), from a short glance.
Add some kind of wrapper implementation of IConsoleProvider that does one of the above strategies and then passes through to the wrapped IConsoleProvider.
I don't really have any strong feelings about which of these is the best option. I can definitely say that some give callers more flexibility than others, but I don't know if that's a good or bad thing.
The text was updated successfully, but these errors were encountered:
Feature request
Allow more flexibility in where output is printed to.
Specifically, I am looking for the output to be sent to
Debug
orTrace
.Trace
would probably be better, since it will be written to in more situations.Rationale
When debugging a console application in Visual Studio, VS has the rather annoying behavior that it launches a new independent window for the application that closes immediately on completion. To work around this, I usually set up my code to write messages to either Trace or Debug (depending on if I'm using a logging library or something and what it supports). Doing so does not seem to be possible for all outputs in PowerArgs, let alone simple. I believe a large number of .NET developers would appreciate this feature; maybe it should even be the default behavior.
My findings on implementing this without core changes to PowerArgs
I've been able to extend
HelpHook
to make the help usage print out to a sink that VS will preserve:But I haven't been able to figure out a way to intercept other outputs, though, like usage messages that result from invalid command lines. That behavior is hard coded to use
ConsoleString
functionality, it looks like.It looks like I could implement my own
IConsoleProvider
and settingConsoleString.ConsoleProvider
, but I'd have to do so as a full wrapper aroundStdConsoleProvider
since it doesn't allow overriding the methods that callConsole.WriteLine
, but that's really cumbersome just to add an additional sink for output. The user also has to implement 24 methods and properties to do that, adding the other sink (Trace
) calls to 6 of the methods.Implementation strategies that come to mind
Trace
calls direct inStdConsoleProvider
.StdConsoleProvider
that a string was written, allowing callers to intercept these events and do whatever they wish with them.StdConsoleProvider
to allow overriding a specific, minimal set of methods that would allow users to intercept all calls toWrite
. It looks like this would includeWrite(object output)
,WriteLine(object output)
, andWriteLine()
, from a short glance.IConsoleProvider
that does one of the above strategies and then passes through to the wrappedIConsoleProvider
.I don't really have any strong feelings about which of these is the best option. I can definitely say that some give callers more flexibility than others, but I don't know if that's a good or bad thing.
The text was updated successfully, but these errors were encountered: