Schreiben von prozessorbewussten Loggern

Die Möglichkeit von MSBuild, mehrere Prozessoren zu nutzen, kann die Projekterstellungszeit verringern, aber es erhöht auch die Komplexität beim Erstellen der Ereignisprotokollierung. In einer Einzelprozessorumgebung kommen Ereignisse, Nachrichten, Warnungen und Fehler auf vorhersehbare, sequenzielle Weise an den Logger. In einer Multiprozessorumgebung können Ereignisse aus unterschiedlichen Quellen jedoch gleichzeitig oder außerhalb der Sequenz eingehen.

Das Generieren eines binären Protokolls (-binlog oder -bl Switch) und das Anzeigen mit dem strukturierten Protokoll-Viewer löst dieses Problem weitgehend. Mit MSBuild, Version 17.8 oder höher, können Sie auch den Terminalprotokollierer (-tl Switch) für eine benutzerfreundlichere Protokollierungsausgabe in Echtzeit auf der Konsole testen.

Für eine allgemeinere Lösung bietet MSBuild einen multiprozessorfähigen Logger und ein Protokollierungsmodell, mit dem Sie benutzerdefinierte "Weiterleitungsprotokollierer" erstellen können.

Herausforderungen bei der Protokollierung mit mehreren Prozessorn

Wenn Sie ein oder mehrere Projekte auf einem Multiprozessor- oder Multi-Core-System erstellen, werden MSBuild-Buildereignisse für alle Projekte gleichzeitig generiert. Eine Lawine von Ereignismeldungen kann gleichzeitig oder außerhalb der Sequenz am Logger ankommen. Da ein MSBuild 2.0-Logger nicht für diese Situation konzipiert ist, kann er den Logger überwältigen und zu erhöhten Buildzeiten, falschen Logger-Ausgaben oder sogar zu einem fehlerhaften Build führen. Um diese Probleme zu beheben, kann der Logger Out-of-Sequence-Ereignisse verarbeiten und Ereignisse und deren Quellen korrelieren.

Sie können die Protokollierungseffizienz noch besser verbessern, indem Sie einen benutzerdefinierten Weiterleitungsprotokollierer erstellen. Ein benutzerdefinierter Weiterleitungsprotokollierer fungiert als Filter, indem Sie vor dem Erstellen nur die Ereignisse auswählen können, die Sie überwachen möchten. Wenn Sie einen benutzerdefinierten Weiterleitungsprotokollierer verwenden, können unerwünschte Ereignisse den Logger nicht überlasten, Ihre Protokolle nicht überladen oder die Erstellungszeiten verlangsamen.

Protokollierungsmodelle mit mehreren Prozessorn

Um mit mehrprozessorbezogenen Build-Problemen umzugehen, unterstützt MSBuild zwei Protokollierungsmodelle: Zentral und verteilt.

Zentrales Protokollierungsmodell

Im zentralen Protokollierungsmodell fungiert eine einzelne Instanz von MSBuild.exe als zentrale Instanz, wobei untergeordnete Instanzen, die als "sekundäre Knoten" bezeichnet werden, an den zentralen Knoten angehängt werden, um die Erstellungsaufgaben auszuführen.

Logger verschiedener Typen, die an den zentralen Knoten angeschlossen werden, werden als "zentrale Logger" bezeichnet. An den zentralen Knoten kann jeweils nur eine Instanz eines jeden Loggertyps angeschlossen werden.

Wenn ein Build auftritt, leiten die sekundären Knoten ihre Buildereignisse an den zentralen Knoten weiter. Der zentrale Knoten leitet alle zugehörigen Ereignisse und auch die der sekundären Knoten an einen oder mehrere der angefügten zentralen Logger weiter. Die Logger erstellen dann Protokolldateien, die auf den eingehenden Daten basieren.

Obwohl nur ILogger vom zentralen Logger implementiert werden muss, empfehlen wir, auch INodeLogger zu implementieren, damit der zentrale Logger für die Anzahl der Knoten, die am Build teilnehmen, initialisiert wird. Die folgende Überladung der Initialize Methode wird aufgerufen, wenn die Engine den Logger initialisiert.

public interface INodeLogger: ILogger
{
    public void Initialize(IEventSource eventSource, int nodeCount);
}

Bereits vorhandene ILogger-basierte Logger können als zentrale Logger fungieren und in den Build eingebunden werden. Zentrale Logger, die ohne explizite Unterstützung für Szenarien zur Protokollierung mit mehreren Prozessoren geschrieben wurden, und Out-of-Order-Ereignisse können jedoch einen Build unterbrechen oder eine bedeutungslose Ausgabe erzeugen.

Verteiltes Protokollierungsmodell

Im zentralen Protokollierungsmodell kann zu viel eingehender Nachrichtendatenverkehr den zentralen Knoten überfordern, z. B. wenn viele Projekte gleichzeitig erstellt werden. Dies kann Systemressourcen belasten und die Buildleistung verringern. Um dieses Problem zu beheben, unterstützt MSBuild ein verteiltes Protokollierungsmodell.

Mit dem verteilten Protokollierungsmodell wird das zentrale Protokollierungsmodell erweitert, indem Sie einen Weiterleitungsprotokollierer erstellen können.

Weiterleitung von Loggern

Ein Weiterleitungs-Logger ist ein sekundärer, leichter Logger mit einem Ereignisfilter, der an einem sekundären Knoten angebracht ist und eingehende Build-Ereignisse von diesem Knoten empfängt. Es filtert die eingehenden Ereignisse und leitet nur diejenigen weiter, die Sie an den zentralen Knoten angeben. Dadurch wird der Nachrichtenverkehr, der an den zentralen Knoten gesendet wird, reduziert. Dies verbessert die Gesamtleistung des Build-Prozesses.

Es gibt zwei Möglichkeiten, die verteilte Protokollierung wie folgt zu verwenden:

• Passen Sie den vordefinierten Weiterleitungsprotokollierer mit dem Namen an ConfigurableForwardingLogger.

• Schreiben Sie Ihren eigenen benutzerdefinierten Weiterleitungsprotokollierer.

Sie können ConfigurableForwardingLogger an Ihre Anforderungen anpassen. Rufen Sie dazu den Logger über die Befehlszeile mit MSBuild.exe auf, und listen Sie die Buildereignisse auf, die der Logger an den zentralen Knoten weiterleiten soll.

Alternativ können Sie einen benutzerdefinierten Weiterleitungsprotokollierer erstellen. Durch die Erstellung eines benutzerdefinierten Weiterleitungsprotokollierers können Sie das Verhalten des Loggers optimieren. Das Erstellen eines benutzerdefinierten Weiterleitungsprotokollierers ist jedoch komplexer als nur das Anpassen des konfigurierbarenForwardingLoggers. Sie können ein Weiterleitungsprotokoll erstellen, indem Sie die IForwardingLogger-Schnittstelle implementieren, welche von ILogger abgeleitet ist. Die Schnittstelle wird wie folgt definiert:

public interface IForwardingLogger: INodeLogger
{
    public IEventRedirector EventRedirector { get; set; }
    public int NodeId { get; set; }
}

Rufen Sie die ForwardEvent-Methode der IEventRedirector-Schnittstelle in Ihrem weiterleitenden Logger auf, um ein Ereignis weiterzuleiten, das Ihren Logger interessiert. Übergeben Sie das entsprechende BuildEventArgs, oder ein Abgeleitetes als Parameter. Die Ereignisse werden dann an den zentralen Logger weitergeleitet und können dort bearbeitet werden.

Weitere Informationen finden Sie unter Erstellen von Weiterleitungsprotokollen.

Verwenden des konfigurierbarenForwardingLoggers für einfache verteilte Protokollierung

Verwenden Sie zum Anfügen eines ConfigurableForwardingLogger oder eines benutzerdefinierten Weiterleitungsloggers den -distributedlogger-Schalter (-dl-Kurzform) in einem MSBuild.exe-Befehlszeilenbuild. Das Format zum Angeben der Namen der Loggertypen und -klassen ist identisch mit dem für den -logger Switch, mit der Ausnahme, dass ein verteilter Logger immer zwei Protokollierungsklassen anstelle von einer, der Weiterleitungsprotokollierer und der zentrale Logger aufweist. Im Folgenden sehen Sie ein Beispiel für das Anfügen eines benutzerdefinierten Weiterleitungsprotokollierers namens XMLForwardingLogger.

msbuild.exe myproj.proj -distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*XMLForwardingLogger,MyLogger,Version=1.0.2,Culture=neutral

Die Verwendung des ConfigurableForwardingLogger ist wie bei der Verwendung eines anderen Loggers (wie in den Erstellungsprotokollen beschrieben), mit der Ausnahme, dass Sie den KonfigurierbarenForwardingLogger-Logger anstelle des typischen MSBuild-Loggers anfügen und als Parameter die Ereignisse angeben, die der KonfigurierbarenForwardingLogger an den zentralen Knoten weiterleiten soll.

Wenn Sie beispielsweise nur benachrichtigt werden möchten, wenn ein Build beginnt und endet und wenn ein Fehler auftritt, übergeben Sie BUILDSTARTEDEVENT, BUILDFINISHEDEVENT und ERROREVENT als Parameter. Mehrere Parameter können übergeben werden, indem sie durch Semikolons getrennt werden. Im Folgenden sehen Sie ein Beispiel dafür, wie Sie den ConfigurableForwardingLogger verwenden, um nur die BUILDSTARTEDEVENT, BUILDFINISHEDEVENT und ERROREVENT Ereignisse weiterzuleiten.

msbuild.exe myproj.proj -distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*ConfigureableForwardingLogger,C:\My.dll;BUILDSTARTEDEVENT; BUILDFINISHEDEVENT;ERROREVENT

Nachfolgend finden Sie eine Liste der verfügbaren ConfigurableForwardingLogger-Parameter.

Verwandte Inhalte

• Erstellen von Weiterleitungsloggern