Ecco un modo per farlo (che pure di solito copre Managed C++ applicazioni che si P/Invoke da C# o altro):
internal class OutputSink : IDisposable
{
[DllImport("kernel32.dll")]
public static extern IntPtr GetStdHandle(int nStdHandle);
[DllImport("kernel32.dll")]
public static extern int SetStdHandle(int nStdHandle, IntPtr hHandle);
private readonly TextWriter _oldOut;
private readonly TextWriter _oldError;
private readonly IntPtr _oldOutHandle;
private readonly IntPtr _oldErrorHandle;
public OutputSink()
{
_oldOutHandle = GetStdHandle(-11);
_oldErrorHandle = GetStdHandle(-12);
_oldOut = Console.Out;
_oldError = Console.Error;
Console.SetOut(TextWriter.Null);
Console.SetError(TextWriter.Null);
SetStdHandle(-11, IntPtr.Zero);
SetStdHandle(-12, IntPtr.Zero);
}
public void Dispose()
{
SetStdHandle(-11, _oldOutHandle);
SetStdHandle(-12, _oldErrorHandle);
Console.SetOut(_oldOut);
Console.SetError(_oldError);
}
}
Questa classe può essere chiamato come segue:
using (new OutputSink())
{
/* Call 3rd party library here... */
}
Ciò avrà un impatto. Qualsiasi logica dell'applicazione che tenta di utilizzare la console da un altro thread durante il periodo di using
OutputSink
non funzionerà correttamente per scrivere sullo standard output, errore standard, output della console o errore della console.
Questo funziona nella maggior parte dei casi. Tuttavia, nel mio caso non è così. La libreria esterna crea un oggetto COM e almeno un altro thread, forse anche un altro processo, in modo da complicare il mio problema. – noctonura
Ah. Sarebbe stato bello sapere che in origine ... se sta creando altri processi o scrivendo la console in modi diversi dall'uso di 'Console.WriteLine' ecc, ciò rende le cose molto più difficili ... –
Sì - mi dispiace, Non avevo capito che era importante fino a quando non hai provato il tuo suggerimento. – noctonura