it-swarm.com.de

Wohin geht Console.WriteLine in Debug?

Ich habe diese Frage gefunden, aber was ich wissen will, ist anders - geht die Ausgabe von Console.WriteLine beim Debuggen irgendwo hin? Ich weiß, dass ich Debug.WriteLine () oder andere Methoden verwenden sollte, um zum Ausgabefenster zu gelangen, aber wohin geht die standardmäßige Console.WriteLine ()?

Edit Beim Debuggen wird das schwarze Konsolenfenster/Testprotokoll nicht angezeigt - also ist die echte Frage Wie kann ich während des Debugging auf diese Ausgabe zugreifen/sie anzeigen?

26
ripper234

Die Konsole kann die Ausgabe an jeden Textwriter umleiten. Wenn Sie einen Textwriter implementieren, der in Diagnostics.Debug schreibt, sind Sie alle festgelegt.

Hier ist ein Texter, der in den Debugger schreibt.

using System.Diagnostics;
using System.IO;
using System.Text;

namespace TestConsole
{
    public class DebugTextWriter : TextWriter
    {
        public override Encoding Encoding
        {
            get { return Encoding.UTF8; }
        }

        //Required
        public override void Write(char value)
        {
            Debug.Write(value);
        }

        //Added for efficiency
        public override void Write(string value)
        {
            Debug.Write(value);
        }

        //Added for efficiency
        public override void WriteLine(string value)
        {
            Debug.WriteLine(value);
        }
    }
}

Da es Diagnostics.Debug verwendet, wird es an die Einstellungen des Compilers gebunden, ob es irgendwelche Ausgaben schreiben soll oder nicht. Diese Ausgabe ist auch in Sysinternals DebugView zu sehen.

So verwenden Sie es:

using System;

namespace TestConsole
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.SetOut(new DebugTextWriter());
            Console.WriteLine("This text goes to the Visual Studio output window.");
        }
    }
}

Wenn Sie die Ausgabe in Sysinternals DebugView sehen möchten, wenn Sie im Freigabemodus kompilieren, können Sie einen TextWriter verwenden, der in die OutputDebugString-API schreibt. Es könnte so aussehen:

using System.IO;
using System.Runtime.InteropServices;
using System.Text;

namespace TestConsole
{
    public class OutputDebugStringTextWriter : TextWriter
    {
        [DllImport("kernel32.dll")]
        static extern void OutputDebugString(string lpOutputString);

        public override Encoding Encoding
        {
            get { return Encoding.UTF8; }
        }

        //Required
        public override void Write(char value)
        {
            OutputDebugString(value.ToString());
        }

        //Added for efficiency
        public override void Write(string value)
        {
            OutputDebugString(value);
        }

        //Added for efficiency
        public override void WriteLine(string value)
        {
            OutputDebugString(value);
        }
    }
}
19
Carl R

NullStream, definiert als "Ein Stream ohne Sicherungsspeicher". Alle Methoden tun nichts oder geben nichts zurück. Es ist eine interne Klasse für Stream. Der folgende Code stammt aus dem Quellcode von Microsoft.

Wenn eine der Console-Schreibmethoden zum ersten Mal aufgerufen wird, wird grundsätzlich die Windows-API-Funktion GetStdHandle für "Standardausgabe" aufgerufen. Wenn kein Handle zurückgegeben wird, wird eine NullStream erstellt und verwendet.

Samuels Antwort ist korrekt und liefert allgemeine Informationen. Um die Console-Ausgabe unabhängig vom Projekttyp tatsächlich umzuleiten, verwenden Sie Console.SetOut(New System.IO.StreamWriter("C:\ConsoleOutput.txt")). Dies ist ein einfaches Beispiel.

Konsole, Debugging und Trace in eine Datei umleiten

Um Ihre Frage direkt zu beantworten. Verwenden Sie die ConsoleTraceListener und eine StreamWriter, um alle drei Ausgaben in eine Datei zu leiten. Ich verwende das Folgende nur für die Entwicklung.

    Dim oLogFile As New System.IO.StreamWriter("C:\ConsoleOutput.txt")
    oLogFile.AutoFlush = True 'so we do not have to worry about flushing before application exit

    Console.SetOut(oLogFile)

    'note, writing to debug and trace causes output on console, so you will get double output in log file
    Dim oListener As New ConsoleTraceListener
    Debug.Listeners.Add(oListener)
    Trace.Listeners.Add(oListener)

NullStream

[Serializable]
private sealed class NullStream : Stream {
    internal NullStream() { }

    public override bool CanRead {
        get { return true; }
    }

    public override bool CanWrite {
        get { return true; }
    }

    public override bool CanSeek {
        get { return true; }
    }

    public override long Length {
        get { return 0; }
    }

    public override long Position {
        get { return 0; }
        set { }
    }

    // No need to override Close

    public override void Flush() {
    }

    public override int Read([In, Out] byte[] buffer, int offset, int count) {
        return 0;
    }

    public override int ReadByte() {
        return -1;
    }

    public override void Write(byte[] buffer, int offset, int count) {
    }

    public override void WriteByte(byte value) {
    }

    public override long Seek(long offset, SeekOrigin Origin) {
        return 0;
    }

    public override void SetLength(long length) {
    }
} 
10
AMissico

Debug und Release steuern nicht, ob ein Konsolenfenster angezeigt wird. Dies wird vom Ausgabetyp des Projekts gesteuert. (Eigenschaften -> Anwendung -> Ausgabetyp). Mit der Konsolenanwendung erhalten Sie ein Konsolenfenster, in dem die Eingabedaten Error, In und Out in System.Console angezeigt und Eingaben vom Fenster empfangen werden.

Die System.Console-Klasse macht mehrere Eigenschaften und Methoden für die Interaktion mit ihren Streams verfügbar, auch wenn Sie sie nicht sehen können. Vor allem: Error, In, Out, SetError (), SetIn (), SetOut () und die Read- und Write-Methoden.

3
Samuel

Die beste Lösung für mich war, Console.WriteLine () in System.Diagnostics.Debug.WriteLine () zu ändern. Zum Beispiel:

 catch (DbEntityValidationException dbEx)
 {
    foreach (var validationErrors in dbEx.EntityValidationErrors)
    {
       foreach (var validationError in validationErrors.ValidationErrors)
       {
          System.Diagnostics.Debug.WriteLine("Property: {0} Error: {1}", validationError.PropertyName, validationError.ErrorMessage);
       }
    }

Anschließend können Sie Ihre Fehler als Objekt im Ausgabefenster anzeigen.

1
Corey Byrum

Ich werde James auf diesen einen zweiten Platz einlassen.

http://www.csharp411.com/console-output-from-winforms-application

beschreibt es grob detailliert (wenn die Ausgabe in eine Datei reicht, reicht es aber aus, die Methode von amissico zu verwenden). Die meisten der beschriebenen Methoden ahmen die in http://dslweb.nwnexus.com/~ast/dload/guicon.htm beschriebenen Methoden nach.

Wenn Sie Ihr Projekt in ein "Konsolen" -Projekt umwandeln, hätte dies einen ähnlichen Effekt. Prost!

1
rogerdpack

Sie gelangen zur Konsole (Standardausgabe) oder zum Stream, auf den die Konsole eingestellt ist.

0
chills42

Visual Studio startet Windows-Programme ( /target:winexe ) mit dem Befehl stdin/stdout/stderr umgeleitet an Named Pipes. Das andere Ende jeder Pipe gehört dem VS-Debugger, und alle Informationen zu stderr/stdout werden im Debug-Ausgabefenster angezeigt. Daher erscheint Console.Write automatisch in der VS Debug-Ausgabe. Beachten Sie, dass dies nicht der Fall ist, wenn Sie anhängen an einen bereits gestarteten Prozess anschließen (da der Umleitungstrick nur zum Startzeitpunkt des Prozesses ausgeführt werden kann).

Beim Starten von Konsolenprogrammen ( /target:exe ) findet diese Umleitung nicht statt, so dass der Console.Write an die tatsächliche Konsole geht (oder wo auch immer die stdout umgeleitet wird).

Ich konnte nichts finden, das dieses Verhalten dokumentiert. Dies ist nur meine Schlussfolgerung aus der Untersuchung, wie VS Apps startet und debuggt.

0
Remus Rusanu