У меня есть существующая (на основе C#) служба Windows, которая получена из Installer class, и я в настоящее время использую предоставленную MS командную строку InstallUtil для ее установки и удаления. Это прекрасно работает, и в рамках моей системы я подключил обработчики событий к событиям AfterUninstallEventHandler и CommittedEventHandler. В моем случае я просто использую их для регистрации сообщений в журнале специальных событий - показывая даты и время установки и удаления, а также версии программ.Служба установки WiX и пользовательские события установки
На данный момент я экспериментирую с Wix v3.5 Beta 1, чтобы упаковать кучу моих вещей, включая эту услугу, и я использую Wix ServiceInstall и ServiceControl, чтобы заменить то, что я сделал вручную с помощью InstallUtil.
Однако, похоже, что для установки служб Wix использует совершенно другой механизм InstallUtil. Это видно из названия и описания службы, которой управляет Wix (в отличие от того, что было встроено в сервисную программу), и что мои события больше не срабатывают (что, если используется другой механизм установки, я сомневаюсь, что они).
Возможно ли, чтобы Wix выполнил установку сервиса так же, как InstallUtil, или я просто собираюсь мириться с различиями?
Редактировать
Кристофер предложил факторинг из определений, связанных услуг от моего кода и переместить их в проект установщика Wix. Это меня беспокоит, так как теперь мне либо нужно найти способ обмена информацией между двумя отдельными системами (которые я понятия не имею, как делиться между кодом и проектами Wix), либо мириться с определением информации в двух разных местах (очень плохо программная практика).
Затем у вас установщик сохранит имя источника события в разделе реестра или app.config и попросит вашу службу прочитать это значение и использовать его для доступа к журналу событий. Я действительно не вижу практики «очень плохого программного обеспечения». Это всего лишь контракт между вашим сервисом и установщиком, где установщик создает источник событий «x», а служба записывает в «x». В конце концов, это просто записи в реестре, которые MSI хорошо обрабатывает. Плохая практика заключалась бы в том, чтобы MSI делал все, кроме этого, а затем изобретал велосипед без кода процесса. –
Последняя мысль: Давайте притворимся, что это приложение winforms, которое написано в журнале событий. Предположим, что администратор установил MSI, но никогда не запускал программу. Тогда не-администратор запустил программу. Как у него есть разрешения на создание события? Однако, если MSI создаст источник событий, он сможет. –
Хорошо, что отношения между моим установщиком и сервисом в качестве контракта были полезной идеей для меня (и я согласен с этим), но это также помогает мне укрепить мою проблему, которая у меня есть - это то, что это неофициальный контракт, который не может быть принудительно (как вы гарантируете, что ключи реестра совпадают между сторонами контракта?).Метод InstallUtil может быть ужасным взломом, который подвержен ошибкам, но в моем случае он предоставляет более формальный контракт, который может быть применен, хотя по умолчанию информация определяется только в одном месте. Но, кстати, я ценю ваши комментарии, и они помогают! –