Еще один похожий проект, в котором можно использовать форматируемые прослушиватели, которые вы можете использовать, это Essential Diagnostics , который изначально был вдохновлен Ukadc.Diagnostics.
Однако вы указали, что неЯ не хочу внешних зависимостей, но у вас все еще есть несколько вариантов без переписывания частей Framework:
(A) Вместо того, чтобы переписывать TraceSource, разработанная точка расширения в .NET Framework заключается в написании собственного TraceListener.
Если вы пишете собственные прослушиватели трассировки «ConsoleWithoutPrefixListener» и «FileWithoutPrefixListener», то вы можете переопределить методы TraceEvent (), чтобы просто переслать сообщение в TraceWrite () (и удалить префиксы).
На самом деле ни ConsoleTraceListener, ни TextWriterTraceListener не запечатаны, поэтому я думаю, что вы могли бы наследовать их и заставить работать с переопределением на одну строку метода TraceEvent () (плюс конструктор).
(B) Другойальтернативой будет оставить EventLogTraceListener настроен по отношению к источнику, но сконфигурирован для двух других слушателей (а не источника трассировки).
Недостаток этого заключается в том, что в вашем коде вам необходимо каждый раз дважды регистрироваться, например:
_traceSource.TraceEvent (_buffer.EventType, id, _buffer.Text) Trace.TraceWrite (_buffer.Text)
Если вы хотите написать несколько сообщений с префиксами, а некоторые без, вам понадобятся два источника трассировки: один, который будетнастроен для всех трех прослушивателей, а один - только для прослушивателя журнала событий.
Затем в вашей оболочке либо пишите в источник A (все три), либо в источник B + статические методы трассировки.
(C) Лично я бы не советовал использовать трассировку для записи в журнал событий - если проблемы достаточно важны для записи в журнал событий, вы обычно не хотите, чтобы пользователь мог отключить их через конфигурацию.
В этом случае ваша оболочка записывает в журнал событий напрямую (EventLog.WriteEntry или что-то еще), а затем ваш код записывает в траСтатические методы источника и / или трассировки для файла и консоли.
Обратите внимание, что для правильной работы записи в журнал событий необходимо учитывать разрешения.Для создания источника журнала событий вы должны быть с правами администратора .Как разработчик, вы, вероятно, обычно имеете права администратора, поэтому вам нужно правильно проверить это в контексте того, кто этого не делает.
Также обратите внимание, что только начальное создание требует прав администратора, и этоавтоматически выполняется при написании первого сообщения, поэтому, если вы уже сделали это как администратор разработчика, вам нужно найти чистую машину для тестирования.
Из-за этого, как правило, вам нужно иметь EventLogInstaller как частьвашего кода, который запускается с помощью InstallUtil (или эквивалентного MSI или любого другого), который создает источник журнала событий во время установки (поскольку установка выполняется администратором).Затем, когда программа запускает исходный код, существует.
Итак, как это связано с записью в трассировку? Хорошо, если единственное, что вы делаете, это конфигурируете EventLogTraceListener в вашей конфигурации, то для обычных пользователей этоне сработает;он попытается записать события в источник (в атрибуте initializeData), который затем попытается создать источник, и, если он не запущен от имени администратора, произойдет сбой.
Если вы добавите установщик для источника события, тоу вас все еще есть проблема, если кто-то изменяет конфигурационный файл.
Из-за этого я бы рекомендовал, чтобы и EventLogInstaller, и EventLog создавались непосредственно в коде, чтобы гарантировать совпадение имен, а не проходить через инфраструктуру трассировки..