Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support writing messages to other sources #141

Open
bladeoflight16 opened this issue Jan 2, 2019 · 0 comments
Open

Support writing messages to other sources #141

bladeoflight16 opened this issue Jan 2, 2019 · 0 comments

Comments

@bladeoflight16
Copy link

bladeoflight16 commented Jan 2, 2019

Feature request

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant