Не удается получить доступ к стандартному выводу процесса

У меня есть приложение (не принадлежащее мне), которое может выполнять «плагины», скомпилированные как библиотеки DLL, если они реализуют определенный интерфейс в качестве точки входа.

В этой конфигурации процесс, управляющий выполнением кода моей подключаемой DLL, совпадает с этим приложением (поэтому задействован один процесс), но я не контролирую запуск этого процесса. Это означает, что я не могу установить

StartInfo.UseShellExecute = false;
StartInfo.RedirectStandardOutput = true;

как кажется, требуется для получения доступа к стандартному выводу (на основе других ответов, которые я нашел)... процесс, который выполняет мой плагин, похоже, уже имеет те, которые установлены на «неправильные» значения (UseShellExecute = true и RedirectStandardOutput = ложный).

Итак... мой плагин может вызывать функцию, используя API этого приложения, которая заставляет приложение выполнять длительные вычисления. Вызов этой функции приводит к приостановке выполнения моего кода до тех пор, пока эта функция не завершит свою обработку (т.е. она не станет синхронной).

Я хотел бы добавить индикатор выполнения в отдельный поток, но единственное сообщение от родительского приложения, похоже, записывается в стандартный вывод. Причина, по которой я говорю это, заключается в том, что когда Visual Studio отлаживает приложение, я вижу обновления «Progress X%» на вкладке «Вывод», даже если мой код «заморожен» при выполнении этой функции (см. здесь)

Итак, мой вопрос: есть ли способ зафиксировать этот вывод? я пытался

process.ErrorDataReceived += Process_ErrorDataReceived;
process.OutputDataReceived += ProcessOnOutputDataReceived;

но они, похоже, никогда не вызываются (поскольку родительское приложение запускается с UseShellExecute = true и RedirectStandardOutput = false, и я не контролирую запуск процесса)

Я также пробовал собственный ConsoleWriter (в отдельном потоке)

 consoleWriter = new MyConsoleWriter();
 consoleWriter.WriteEvent += MyCustomWrite;
 consoleWriter.WriteLineEvent += MyCustomWriteLine;
 Console.SetOut(consoleWriter);

Но он никогда не используется, несмотря на очевидные выходные сообщения, которые я вижу в Visual Studio (я полагаю, это означает, что родительское приложение не использует консоль .NET?)

Учитывая, что у меня нет контроля над process.StartInfo.UseShellExecute и process.StartInfo.RedirectStandardOutput (ну, я могу изменить их когда угодно, но я не думаю, что это имеет какой-либо эффект, кроме как когда процесс запущен), но я делаю используют тот же процесс, что и родительское приложение (т. е. мой код выполняется одним и тем же процессом), кто-нибудь знает, как я могу записать эти записи в (что кажется) стандартный вывод этого родительского приложения?


person itWouldBeWise    schedule 25.08.2019    source источник
comment
К сожалению, с таким неполным вопросом невозможно узнать, что именно сработает в вашем сценарии. Если вы имеете дело с управляемым процессом, вы можете использовать Console.SetOut(), если нет других методов. Во всех случаях вы должны действовать очень осторожно; перенаправление вывода процесса, которым вы не владеете, может привести к конфликтам с другим кодом, пытающимся сделать то же самое, включая фактического владельца процесса.   -  person Peter Duniho    schedule 25.08.2019
comment
Эти события будут срабатывать, только если вы начали асинхронное чтение (BeginOutputReadLine() и BeginErrorReadLine()). В противном случае вам придется читать из соответствующих потоков синхронно (через свойства StandardOutput и StandardError).   -  person Jeff Mercado    schedule 25.08.2019


Ответы (1)


Мне пришло в голову, что на вкладке «Вывод» Visual Studio должно быть больше, чем просто вывод консоли, что привело меня сюда: https://docs.microsoft.com/en-us/visualstudio/debugger/diagnostic-messages-in-the-output-window?view=vs-2019

И действительно, когда я добавил TraceListener (я начал только с консоли, я смог зафиксировать этот вывод. Я начал с простого ConsoleTraceListener, и это сработало.

Остерегайтесь предупреждений о TraceListeners, которые все еще висят (я видел, что это проблема для моего приложения) https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.trace?view=netframework-4.8

person itWouldBeWise    schedule 25.08.2019