Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Возможность MSBuild использовать несколько процессоров может уменьшить время сборки проекта, но также добавляет сложность для ведения журнала событий сборки. В однопроцессорной среде события, сообщения, предупреждения и ошибки поступают в журнал предсказуемым последовательным образом. Однако в многопроцессорной среде события из разных источников могут поступать одновременно или вне последовательности.
Создание двоичного журнала (-binlog или -bl коммутатора) и просмотр его с помощью структурированного средства просмотра журналов в значительной степени решает эту проблему. С помощью MSBuild версии 17.8 или более поздней можно также попробовать логер терминала (-tl переключатель) для получения более удобного вывода журнала в консоли в реальном времени.
Для более общего решения MSBuild предоставляет многопроцессорное средство ведения журнала и модель ведения журнала, которую можно использовать для создания пользовательских "переадресующих средств ведения журнала".
Проблемы с ведением журнала с несколькими процессорами
При создании одного или нескольких проектов в многопроцессорной или многоядерный системе события сборки MSBuild для всех проектов создаются одновременно. Лавина событийных сообщений может поступать в журнал событий одновременно или вне последовательности. Так как средство ведения журнала MSBuild 2.0 не предназначено для обработки этой ситуации, это может перегрузить средство ведения журнала и вызвать увеличение времени сборки, неправильные выходные данные средства ведения журнала или даже сбой сборки. Для решения этих проблем средство ведения журнала может обрабатывать события вне последовательности и сопоставлять события и их источники.
Вы можете повысить эффективность ведения журнала еще больше, создав настраиваемый логгер для пересылки. Пользовательский средство ведения журнала пересылки выступает в качестве фильтра, позволяя выбирать, прежде чем создавать, только те события, которые требуется отслеживать. При использовании настраиваемого средства пересылки логов нежелательные события не могут перегружать логгер, загромождать логи или замедлять время сборки.
Модели ведения журнала с несколькими процессорами
Для обеспечения проблем сборки, связанных с несколькими процессорами, MSBuild поддерживает две модели ведения журнала, центральные и распределенные.
Центральная модель логирования
В центральной модели ведения журнала один экземпляр MSBuild.exe выступает в качестве "центрального узла", а дочерние экземпляры центрального узла ("вторичные узлы") присоединяют к центральному узлу, чтобы помочь в выполнении задач сборки.
Средства ведения журнала различных типов, которые присоединяются к центральному узлу, называются "центральными средствами ведения журнала". Одновременно можно подключить только один экземпляр каждого типа средства ведения журнала к центральному узлу.
Когда выполняется сборка, вторичные узлы перенаправляют события сборки на центральный узел. Центральный узел направляет все свои события, а также события вторичных узлов, на одно или несколько подключенных центральных средств записи журналов. Затем средства ведения журнала создают файлы журналов, основанные на входящих данных.
Хотя центральному средству ведения журнала требуется реализовать только ILogger, рекомендуется также реализовать INodeLogger, чтобы центральное средство ведения журнала инициализировалось с числом узлов, участвующих в сборке. Следующий вариант перегрузки метода Initialize вызывается, когда механизм инициализирует логгер.
public interface INodeLogger: ILogger
{
public void Initialize(IEventSource eventSource, int nodeCount);
}
Все уже существующие логгеры на основе ILogger могут выступать в качестве центральных логгеров и подключаться к сборке. Однако центральные логгеры, написанные без явной поддержки сценариев ведения журнала для многопроцессорных систем и событий, происходящих вне порядка, могут нарушить сборку или вывести бессмысленные данные.
Модель распределенного ведения журнала
В центральной модели ведения журнала слишком много входящего трафика сообщений может перегружать центральный узел, например при одновременной сборке многих проектов. Это может загрузить системные ресурсы и снизить производительность сборки. Чтобы упростить эту проблему, MSBuild поддерживает модель распределенного ведения журнала.
Модель распределенного ведения журнала расширяет центральную модель, позволяя создавать логгер для пересылки.
Перенаправление логгеров
Средство ведения журнала пересылки — это вторичный упрощенный средство ведения журнала с фильтром событий, который подключается к вторичному узлу и получает входящие события сборки от этого узла. Он фильтрует входящие события и пересылает только те, которые вы указали на центральный узел. Это уменьшает трафик сообщений, отправляемый на центральный узел, и повышает общую производительность сборки.
Существует два способа использования распределенного ведения журнала, как показано ниже.
Настройка предварительно созданного средства ведения журнала пересылки с именем ConfigurableForwardingLogger.
Напишите собственное настраиваемое средство ведения журнала логгирования.
Вы можете изменить ConfigurableForwardingLogger в соответствии с вашими требованиями. Для этого вызовите средство ведения журнала в командной строке с помощью MSBuild.exeи перечислите события сборки, которые требуется перенаправить в центральный узел.
В качестве альтернативы можно создать пользовательский логгер пересылки. Создав пользовательский журнал пересылки, вы можете точно настроить его поведение. Однако создание пользовательского средства ведения журнала пересылки сложнее, чем просто настройка ConfigurableForwardingLogger. Вы можете создать средство ведения журнала пересылки, реализуя интерфейс IForwardingLogger, основанный на ILogger. Интерфейс определяется следующим образом:
public interface IForwardingLogger: INodeLogger
{
public IEventRedirector EventRedirector { get; set; }
public int NodeId { get; set; }
}
Чтобы перенаправить событие, которое важно для вашего средства ведения журнала, вызовите метод ForwardEvent интерфейса IEventRedirector в перенаправляющем средстве ведения журнала. Передайте соответствующий BuildEventArgs или его производную в качестве параметра. Затем события перенаправятся в центральное средство ведения журнала, и с ними можно проводить действия там.
Дополнительные сведения см. в разделе "Создание средств ведения журнала пересылки".
Использование ConfigurableForwardingLogger для простого распределенного ведения журнала
Чтобы подключить ConfigurableForwardingLogger или пользовательский регистратор перенаправления, используйте ключ -distributedlogger (сокращённо -dl) в командной строке сборки MSBuild.exe. Формат указания имен типов и классов логгеров совпадает с форматом для параметра -logger, за исключением того, что распределенный логгер всегда имеет два класса ведения журнала вместо одного: логгер пересылки и центральный логгер. Ниже приведен пример подключения пользовательского средства ведения журнала пересылки с именем XMLForwardingLogger.
msbuild.exe myproj.proj -distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*XMLForwardingLogger,MyLogger,Version=1.0.2,Culture=neutral
Замечание
Звездочка (*) должна разделить два имени логгеров в коммутаторе -dl.
ConfigurableForwardingLogger Используя любое другое средство ведения журнала (как описано в получение журналов сборки), за исключением того, что вы присоединяете средство ведения журнала ConfigurableForwardingLogger вместо типичного средства ведения журнала MSBuild и указываете в качестве параметров события, которые необходимо передать в центральный узел с помощью ConfigurableForwardingLogger.
Например, если вы хотите получать уведомления только при запуске и завершении сборки, и при возникновении ошибки, передайте BUILDSTARTEDEVENT, BUILDFINISHEDEVENT и ERROREVENT в качестве параметров. Несколько параметров можно передать, разделив их точкой с запятой. Ниже приведен пример использования ConfigurableForwardingLogger для пересылки только событий BUILDSTARTEDEVENT, BUILDFINISHEDEVENT и ERROREVENT.
msbuild.exe myproj.proj -distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*ConfigureableForwardingLogger,C:\My.dll;BUILDSTARTEDEVENT; BUILDFINISHEDEVENT;ERROREVENT
Ниже приведен список доступных параметров ConfigurableForwardingLogger.
| Настройка параметров ConfigurableForwardingLogger |
|---|
| СОБЫТИЕНАЧАЛАСТРОИТЕЛЬСТВА |
| BUILDFINISHEDEVENT |
| PROJECTSTARTEDEVENT |
| PROJECTFINISHEDEVENT |
| TARGETSTARTEDEVENT |
| TARGETFINISHEDEVENT |
| TASKSTARTEDEVENT |
| TASKFINISHEDEVENT |
| Событие ошибки |
| WARNINGEVENT |
| HIGHMESSAGEEVENT |
| NORMALMESSAGEEVENT |
| НИЗКОУРОВНЕВОЕСООБЩЕНИЕСОБЫТИЕ |
| CUSTOMEVENT |
| командная строка |
| РЕЗЮМЕ ПРОИЗВОДИТЕЛЬНОСТИ |
| NOSUMMARY |
| SHOWCOMMANDLINE |