Frage

Wir haben einen C # Dienst, der auf einem Remote-Kundensystem bereitgestellt wird. Die Anwendung schreibt eine erhebliche Menge an „Diagnose“ Informationen an die Konsole (d.h. Console.WriteLine ()). Der Service ist nicht „zu tun, was es sein sollte.“ Wie können wir die Konsolenausgabe aus dem Dienst in einer anderen Anwendung erfassen?

Eine WinForm Version kann die Anwendung beim Kunden geladen werden. Es ist leider richtig funktioniert.

Update:

Wir sind in der Lage der Änderung den Dienst zu ändern, aber würde es vorziehen, keine großen Änderungen zu diesem Zeitpunkt zu machen.

Wir protokollieren auch MSMQ, aber nur für „wichtig“ Veranstaltungen. Dieser Dienst interagieren mit MSMQ für den normalen Betrieb. Oder zumindest, es sollte. Der Dienst scheint nicht Elemente von MSMQ zu ziehen, wenn die WinForm Version der Fall ist. Also, um die Nachrichten zu schreiben, die an die Konsole gehen könnte problematisch sein.

War es hilfreich?

Lösung

Sind Sie in der Lage, den Service-Code zu ändern auf allen ? Wenn ja, Console.SetOut Verwendung in eine Datei zu schreiben, anstatt wäre die naheliegendste erste Anlaufstelle sein. Ändern Sie dann eine ordnungsgemäße Protokollierung Bibliothek für die nächste Version zu verwenden:)

Andere Tipps

In der Regel sollten Sie Diagnoseinformationen zu schreiben vermeiden direkt an Konsole, das Ereignisprotokoll, MSMQ oder an anderer Stelle von Anwendungscode. Statt eine Logging-API aufrufen, und verwenden Sie Konfiguration die Ausgabe zu umleiten, wo immer Sie wollen.

Zum Beispiel könnten Sie die ganze Console.WriteLine von Trace.WriteLine (*) ersetzen. Dann können Sie auf die Konsole umleiten, um eine Datei oder an anderer Stelle durch die Anwendungskonfigurationsdatei zu ändern: zum Beispiel für die Ausgabe an die Konsole, verwenden Sie einen Console, so etwas wie:

<configuration>
  <system.diagnostics>
    <trace autoflush="false" indentsize="4">
      <listeners>
        <add name="configConsoleListener"
             type="System.Diagnostics.ConsoleTraceListener" />
      </listeners>
    </trace>
  </system.diagnostics>
 </configuration>

Beim Debuggen Sie Ihre Ausgabe auf der Konsole bekommen -. Am Kundenstandort Sie es so konfigurieren, würden die Trace-Ausgabe in eine Datei, in dem Ereignisprotokoll oder ähnlich zu umleiten

Noch besser ist, verwenden Sie einen 3rd-Party-Logging-Framework (würde ich empfehlen, Log4Net), die Ihnen mehr Möglichkeiten als System.Diagnostics.Trace geben.

(*) Trace.Write / Trace.WriteLine sind die gleichen wie Debug.Write / Debug.WriteLine, mit der Ausnahme, dass letztere nur kompiliert, wenn das Symbol DEBUG definiert ist. So Trace Debug bevorzugen, wenn Sie die Ausgabe verfügbar sein sollen in Release baut.

Sie haben eine Reihe von Optionen bekommen; Umleiten Konsole Ausgabe in eine Datei und eine ordnungsgemäße Protokollierung-Bibliothek wie erwähnt zwei guten sind. Hier ist eine mittlere Option. Schreibt in das Ereignisprotokoll

EventLog log;
string logsource = "MyService";

// execute once per invocation
if (!System.Diagnostics.EventLog.SourceExists(logsource))
{
    System.Diagnostics.EventLog.CreateEventSource(
        logsource, "Application");
}
log = new EventLog();
log.Source = logsource;
log.Log = "Application";

// replace console logging with this
log.WriteEntry(message, EventLogEntryType.Information);

Dann ist für Einträge in dem Anwendungsereignisprotokoll (Verwaltung -> Ereignisanzeige). Wo Source = "MyService"

würde ich Console.WriteLine gar nicht von einem Fenster Service verwenden. Sie sollten wahrscheinlich diese Fehler in einer Protokolldatei protokollieren.

Eine andere Möglichkeit, dies so, dass mehrere Anwendungen zu tun, um die Protokolle verbrauchen kann, ist die Log-Nachrichten an eine MSMQ-Warteschlange hinzuzufügen.

Verwendung Debug.WriteLine und verwenden Sysinternals Debugview?

Ich fand diese Post auf MSDN, die die Konsolenausgabe in eine Rich-Text-Box bindet, war für mich sehr schnell und einfach.

Sie überschreibt Console.WriteLine und könnte erweitert werden, um andere Methoden außer Kraft zu setzen.

Hier ist, wie ich die Konsolenausgabe eines Dienstes betrachten unter Windows 7. Dies könnte helfen, wenn Sie absolut nicht in der Lage sind, den Quellcode des Dienstes zu ändern, um eine Datei zu protokollieren.

  1. Ausführen services.msc und die Eigenschaften des Dienstes bearbeiten. Auf der "Log On" Registerkarte, überprüfen Sie die "Allow Service mit Desktop interagieren"

  2. Gehen Sie zu HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ Services \ [Dienstname] und bearbeiten ImagePath:
  3. Verwenden Sie Registrierungs-Editor den ImagePath Ihres Dienstes zu ändern. Anfügen cmd.exe /c zu Beginn des ImagePath String. Also, wenn Ihr Original ImagePath c:\myService\myservice.exe ist Ihr neues ImagePath cmd.exe /c c:\myService\myservice.exe werden sollte.

  4. Starten Sie Ihren Service. Sie sollten ein Popup-Fenster mit dem Titel „Interactive Services Detection“ erhalten. Wählen Sie „Sehen Sie die Meldung“. Ihr Bildschirm sollte Kontexte wechseln und das Konsolenfenster angezeigt werden soll. Wenn Sie fertig sind, klicken Sie auf den „Return now“.

  5. Wenn das Debuggen abgeschlossen, ändert ImagePath zurück auf den ursprünglichen Wert. Dann deaktivieren Sie die "Dienst und Desktop zulassen zu interagieren" Checkbox in den Service-Eigenschaften und Ihren Dienst neu starten.

Warnung: Ich habe dies nur getan mit einem Service und es funktionierte für mich. Ich weiß nicht, ob es für jeden Dienst funktioniert oder wenn es unerwartete Ergebnisse verursachen, so ich dir dringend empfehlen nur, dass in einer Nicht-Produktionsumgebung.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top