Каков наиболее надежный способ создания настраиваемого журнала событий и источника событий при установке .Net Service? - PullRequest
Новая
       26

Каков наиболее надежный способ создания настраиваемого журнала событий и источника событий при установке .Net Service?

25 голосов
/ 22 сентября 2008

У меня проблемы с надежным созданием / удалением источников событий во время установки моей .Net Windows Service.

Вот код из моего класса ProjectInstaller: 

// Create Process Installer
ServiceProcessInstaller spi = new ServiceProcessInstaller();
spi.Account = ServiceAccount.LocalSystem;

// Create Service
ServiceInstaller si = new ServiceInstaller();
si.ServiceName = Facade.GetServiceName();
si.Description = "Processes ...";
si.DisplayName = "Auto Checkout";
si.StartType = ServiceStartMode.Automatic;

// Remove Event Source if already there
if (EventLog.SourceExists("AutoCheckout"))
    EventLog.DeleteEventSource("AutoCheckout");

// Create Event Source and Event Log     
EventLogInstaller log = new EventLogInstaller();
log.Source = "AutoCheckout";
log.Log = "AutoCheckoutLog";

Installers.AddRange(new Installer[] { spi, si, log });

Указанные методы фасадов просто возвращают строки для имени журнала, службы и т. Д.

Этот код работает большую часть времени, но недавно после установки я начал получать свои записи в журнале приложений, а не в пользовательском журнале. И в журнале тоже есть следующие ошибки:

Описание для идентификатора события (0) в источнике (AutoCheckout) не может быть найдено. Локальный компьютер может не иметь необходимой информации реестра или файлов DLL сообщений для отображения сообщений с удаленного компьютера. Вы можете использовать флаг / AUXSOURCE =, чтобы получить это описание; см. Помощь и Поддержка для деталей.

По какой-то причине он либо неправильно удаляет источник во время удаления, либо не создает его во время установки.

Любая помощь с лучшими практиками здесь приветствуется.

Спасибо!

Кроме того, вот пример того, как я пишу исключения в журнал: 

// Write to Log
EventLog.WriteEntry(Facade.GetEventLogSource(), errorDetails, EventLogEntryType.Error, 99);

Относительно ответа stephbu: Рекомендуемый путь - это скрипт установщика и installutil или подпрограмма установки Windows.

Я использую проект установки, который выполняет установку службы и настраивает журнал. Использую ли я installutil.exe или проект установки Windows, я считаю, что они оба вызывают один и тот же класс ProjectInstaller, который я показал выше.

Я вижу, как состояние моего тестового компьютера могло вызывать ошибку, если журнал действительно не был удален до перезагрузки. Я буду экспериментировать больше, чтобы увидеть, решит ли это проблему.

Edit: Меня интересует надежный способ регистрации источника и имени журнала при установке сервиса. Поэтому, если служба была ранее установлена, она удалила бы источник или использовала бы его повторно при последующих установках.

У меня еще не было возможности изучить WiX, чтобы попробовать этот маршрут.

Ответы [ 12 ]

0 голосов
/ 11 августа 2009

Проблема возникает из-за installutil, который по умолчанию регистрирует источник событий с именем ваших служб в EventLog «Приложение». Я все еще ищу способ остановить это, делая это дерьмо. Было бы здорово, если бы кто-то мог повлиять на поведение installutil: (

0 голосов
/ 08 октября 2008

Я столкнулся с некоторым странным поведением, потому что я пытался зарегистрировать источник события с тем же именем, что и служба, которую я запускал.

Я заметил, что для DisplayName также установлено то же имя, что и для вашего источника события.

При запуске службы мы обнаружили, что Windows зарегистрировала запись «Служба успешно запущена» в журнале приложений с источником в качестве DisplayName. Похоже, что это привело к регистрации Имя приложения в журнале приложений.

В моем классе журнала событий я позже попытался зарегистрировать Имя приложения как источник с другим журналом событий, но когда дело дошло до добавления новых записей журнала событий, они всегда добавлялись в журнал приложений.

Я также несколько раз получал сообщение «Описание для идентификатора события (0) в источнике».

В качестве обходного пути я просто зарегистрировал источник сообщения с немного другим именем для DisplayName, и с тех пор он работает. Стоит попробовать это, если вы еще этого не сделали.

Страница:
...