Schreiben von multiprozessorfähigen Protokollierungen
Die Fähigkeit von MSBuild, mehrere Prozessoren zu verwenden, kann die Dauer der Projekterstellung deutlich verringern, jedoch auch die Komplexität der Buildereignisprotokollierung erhöhen. In einer Umgebung mit nur einem Prozessor gehen Ereignisse, Meldungen, Warnungen und Fehler auf vorhersehbare, geordnete Weise bei der Protokollierung ein. In einer Umgebung mit mehreren Prozessoren können jedoch Ereignisse aus verschiedenen Quellen gleichzeitig und ungeordnet eintreffen.
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 Terminal Logger (-tl-Switch) ausprobieren, um die Benutzerfreundlichkeit der Logging-Ausgabe in Echtzeit auf der Konsole zu erhöhen.
Für eine allgemeinere Lösung bietet MSBuild einen Multiprozessor-Logger und ein Protokollierungsmodell, mit dem Sie benutzerdefinierte „Weiterleitungs-Logger“ erstellen können.
Anforderungen bei der Multiprozessorprotokollierung
Wenn Sie ein oder mehrere Projekte in einer Umgebung mit mehreren Prozessoren oder mehreren Prozessorkernen erstellen, werden die MSBuild-Buildereignisse für alle Projekte gleichzeitig erzeugt. Die Protokollierung erhält eine Unmenge von Ereignismeldungen zur gleichen Zeit und ohne bestimmte Reihenfolge. Da eine Protokollierung von MSBuild 2.0 nicht für diese Situation ausgelegt ist, kann die Protokollierung überlastet werden. Dies wiederum kann zu einer längeren Builderstellungsdauer, falschen Protokollierungsausgaben oder sogar einem beschädigten Build führen. Um dieses Problem zu beheben, kann die Protokollierung ungeordnete Ereignisse verarbeiten und Ereignisse ihren Quellen zuordnen.
Sie können die Protokollierungseffizienz noch erhöhen, indem Sie eine benutzerdefinierte Weiterleitungsprotokollierung erstellen. Eine benutzerdefinierte Weiterleitungsprotokollierung funktioniert wie ein Filter, der Ihnen vor der Builderstellung ermöglicht, nur die zu überwachenden Ereignisse auszuwählen. Durch die Verwendung einer benutzerdefinierten Weiterleitungsprotokollierung wird vermieden, dass die Protokollierung durch nicht benötigte Ereignisse überlastet, die Protokolle mit überflüssigen Daten gefüllt oder die Builderstellung verlangsamt wird.
Multiprozessor-Protokollierungsmodelle
MSBuild unterstützt zwei Protokollierungsmodelle, die zentrale und die verteilte Protokollierung, um Probleme mit Mehrprozessorbuilds behandeln zu können.
Zentrales Protokollierungsmodell
Im zentralen Protokollierungsmodell fungiert eine einzelne Instanz von MSBuild.exe als „zentraler Knoten“, und untergeordnete Instanzen des zentralen Knotens („sekundäre Knoten“) werden an den zentralen Knoten angehängt, um ihn beim Durchführen von Buildaufgaben zu unterstützen.
Logger verschiedener Typen, die an den zentralen Knoten anfügen, werden als „zentrale Protokollierung" bezeichnet. Nur eine Instanz jedes Protokollierungstyps kann gleichzeitig an den zentralen Knoten angefügt werden.
Bei der Builderstellung leiten die sekundären Knoten die Buildereignisse an den zentralen Knoten weiter. Der zentrale Knoten leitet alle seine Ereignisse sowie die Ereignisse der sekundären Knoten an eine oder mehrere der angehängten zentralen Protokollierungen weiter. Die Protokollierungen erstellen dann Protokolldateien, die auf den eingehenden Daten basieren.
Obwohl nur ILogger von der zentralen Protokollierung implementiert werden muss, wird empfohlen, auch INodeLogger zu implementieren, sodass die zentrale Protokollierung mit der Anzahl Knoten, die am Build beteiligt sind, initialisiert wird. Die folgende Überladung der Initialize-Methode wird aufgerufen, wenn die Engine die Protokollierung initialisiert:
public interface INodeLogger: ILogger
{
public void Initialize(IEventSource eventSource, int nodeCount);
}
Bereits vorhandene Protokollierungen, die auf ILogger basieren, können als zentrale Protokollierungen verwendet und an den Build angehängt werden. Zentrale Protokollierungen jedoch, die ohne ausdrückliche Unterstützung für Protokollierungsszenarien mit mehreren Prozessoren und ungeordnete Ereignisse erstellt wurden, können zu einer Beschädigung des Builds führen oder eine bedeutungslose Ausgabe produzieren.
Verteiltes Protokollierungsmodell
Beim zentralen Protokollierungsmodell kann ein zu hohes Aufkommen von eingehenden Meldungen zu einer Überlastung des zentralen Knotens führen, wenn zum Beispiel mehrere Projekte gleichzeitig erstellt werden. Dies kann zu einer Belastung der Systemressourcen und zu einer reduzierten Buildleistung führen. Um dieses Problem zu verringern, unterstützt MSBuild ein verteiltes Protokollierungsmodell.
Das verteilte Protokollierungsmodell erweitert das zentrale Protokollierungsmodell, indem es Ihnen ermöglicht, eine Weiterleitungsprotokollierung zu erstellen.
Weiterleitungsprotokollierungen
Eine Weiterleitungsprotokollierung ist eine sekundäre, einfache Protokollierung mit einem Ereignisfilter. Diese Protokollierung wird an einen sekundären Knoten angehängt und empfängt eingehende Buildereignisse dieses Knotens. Sie filtert die eingehenden Ereignisse und leitet nur die Ereignisse weiter, die im zentralen Knoten festgelegt sind. Dies reduziert den Meldungsverkehr, der zum zentralen Knoten gesendet wird, und verbessert insgesamt die Buildleistung.
Es gibt zwei Möglichkeiten für die Verwendung der verteilten Protokollierung:
Passen Sie die vordefinierte Weiterleitungsprotokollierung ConfigurableForwardingLogger an.
Schreiben Sie eine eigene benutzerdefinierte Weiterleitungsprotokollierung.
Sie können ConfigurableForwardingLogger so ändern, dass sie Ihren Anforderungen entsprechen. Rufen Sie hierzu die Protokollierung in der Befehlszeile mit MSBuild.exe auf, und führen Sie die Buildereignisse auf, die von der Protokollierung an den zentralen Knoten weitergeleitet werden sollen.
Alternativ können Sie auch eine benutzerdefinierte Weiterleitungsprotokollierung erstellen. Durch die Erstellung einer benutzerdefinierten Weiterleitungsprotokollierung können Sie das Verhalten der Protokollierung genauer bestimmen. Das Erstellen einer benutzerdefinierten Weiterleitungsprotokollierung ist jedoch komplexer als das Anpassen von ConfigurableForwardingLogger. Sie können Weiterleitungsprotokollierungen erstellen, indem Sie die IForwardingLogger-Schnittstelle implementieren, die von ILogger abgeleitet ist. Die Schnittstelle wird wie folgt definiert:
public interface IForwardingLogger: INodeLogger
{
public IEventRedirector EventRedirector { get; set; }
public int NodeId { get; set; }
}
Um ein Event weiterzuleiten, für das sich Ihr Logger interessiert, rufen Sie die ForwardEvent-Methode der IEventRedirector-Schnittstelle in Ihrem weiterleitenden Logger auf. Übergeben Sie entsprechende BuildEventArgs oder eine Ableitung als Parameter. Die Events werden dann an den zentralen Logger weitergeleitet und können dort weiterverarbeitet werden.
Weitere Informationen finden Sie unter Erstellen von Weiterleitungsprotokollierungen.
Verwenden von ConfigurableForwardingLogger zur einfachen verteilten Protokollierung
Um entweder einen ConfigurableForwardingLogger oder einen benutzerdefinierten Weiterleitungslogger anzuhängen, verwenden Sie den -distributedlogger-Switch (kurz -dl) in einem MSBuild.exe Befehlszeilen-Build. Das Format zum Angeben der Namen von Protokollierungstypen und -klassen ist identisch mit dem für den -logger-Schalter, mit der Ausnahme, dass eine verteilte Protokollierung immer über zwei Protokollierungsklassen statt einer verfügt, d. h. die Weiterleitungsprotokollierung und die zentrale Protokollierung. Nachfolgend ist ein Beispiel dafür aufgeführt, wie eine benutzerdefinierte Weiterleitungsprotokollierung mit dem Namen XMLForwardingLogger angefügt wird.
msbuild.exe myproj.proj -distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*XMLForwardingLogger,MyLogger,Version=1.0.2,Culture=neutral
Hinweis
Ein Sternchen (*) muss zum Trennen der beiden Protokollierungsnamen im -dl-Schalter verwendet werden.
Die Verwendung von ConfigurableForwardingLogger ist mit der Verwendung anderer Protokollierungen identisch (wie erläutert in Erhalten von Buildprotokollen), mit der Ausnahme, dass die ConfigurableForwardingLogger-Protokollierung anstelle der normalen MSBuild-Protokollierung angehängt wird und dass Sie als Parameter die Ereignisse festlegen, die ConfigurableForwardingLogger an den zentralen Knoten übergeben soll.
Wenn Sie zum Beispiel nur dann 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. Nachfolgend ist ein Beispiel für die Verwendung von ConfigurableForwardingLogger dargestellt, um nur die Ereignisse BUILDSTARTEDEVENT, BUILDFINISHEDEVENT und ERROREVENT weiterzuleiten.
msbuild.exe myproj.proj -distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*ConfigureableForwardingLogger,C:\My.dll;BUILDSTARTEDEVENT; BUILDFINISHEDEVENT;ERROREVENT
Nachfolgend ist eine Liste der verfügbaren ConfigurableForwardingLogger-Parameter aufgeführt.
| ConfigurableForwardingLogger-Parameter |
|---|
| BUILDSTARTEDEVENT |
| BUILDFINISHEDEVENT |
| PROJECTSTARTEDEVENT |
| PROJECTFINISHEDEVENT |
| TARGETSTARTEDEVENT |
| TARGETFINISHEDEVENT |
| TASKSTARTEDEVENT |
| TASKFINISHEDEVENT |
| ERROREVENT |
| WARNINGEVENT |
| HIGHMESSAGEEVENT |
| NORMALMESSAGEEVENT |
| LOWMESSAGEEVENT |
| CUSTOMEVENT |
| COMMANDLINE |
| PERFORMANCESUMMARY |
| NOSUMMARY |
| SHOWCOMMANDLINE |