Установщик службы WiX и пользовательские события установки - PullRequest
4 голосов
/ 14 июля 2010

У меня есть существующая (на C #) служба Windows, которая является производной от класса установщика , и в настоящее время я использую предоставленную MS командную строку InstallUtil для ее установки и удаления. Это работает нормально, и как часть моей системы я подключил обработчики событий к событиям AfterUninstallEventHandler и CommittedEventHandler. В моем случае я просто использую их для записи сообщений в специальный журнал событий с указанием даты и времени установки и удаления, а также версий программы.

В настоящее время я экспериментирую с Wix v3.5 Beta 1 , чтобы упаковать кучу своих вещей, включая эту службу, и я использую Wix ServiceInstall и ServiceControl, чтобы заменить то, что я сделал вручную с InstallUtil .

Однако, похоже, что Wix использует совершенно иной механизм InstallUtil для установки служб. Это видно из названия и описания службы, управляемой Wix (в отличие от того, что было встроено в программу службы), и что мои события больше не запускаются (что, если используется другой механизм установки, я сомневаюсь, что они будут ).

Так может ли Wix выполнить установку службы так же, как InstallUtil, или я просто собираюсь мириться с различиями?

Редактировать

Кристофер предложил выделить из моего кода определения, относящиеся к сервисам, и перенести их в проект установщика Wix. Это делает меня неловким, так как теперь мне нужно либо найти способ обмена информацией между двумя отдельными системами (что я не знаю, как делиться между кодом и проектами Wix), либо смириться с определением информации в двух разных местах (очень плохо практика программирования).

1 Ответ

2 голосов
/ 14 июля 2010

С точки зрения установщика Windows, InstallUtil - злой антипаттерн, потому что он внедряет хрупкий код из процесса в декларативную модель программирования. Установщик Windows уже давно имеет таблицы ServiceInstall и ServiceControl, и это работает очень хорошо. То же самое относится к Regasm и Regserver. Мы предпочитаем извлекать данные COM и записывать их в установщик, а MSI позаботится о применении значения реестра, а не о загрузке сборок и вызове точек входа в надежде, что они будут работать. Когда происходит сбой, вы не знаете, почему, и вы не можете откатить состояние машины назад.

Какие вещи вы делаете на своих мероприятиях? Я бы исключил и / или реорганизовал каждого из них в то, что MSI может сделать для вас. Если этого все еще недостаточно, напишите настраиваемое действие DTF и запланируйте его между InstallServices и StartServices.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...