Установщик службы WiX и пользовательские события установки

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

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

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

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

Изменить

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


person Peter M    schedule 13.07.2010    source источник
comment
Затем пусть ваш установщик сохранит имя источника событий в разделе реестра или app.config, а ваша служба прочитает это значение и использует его для доступа к журналу событий. Я действительно не вижу очень плохой практики программного обеспечения. Это просто контракт между вашей службой и установщиком, в котором установщик создает источник события x, а служба записывает в x. В конце концов, это просто записи реестра, с которыми MSI хорошо справляется. Плохая практика заключалась бы в том, чтобы MSI делал все, кроме этого, а затем изобретал колесо с кодом вне процесса.   -  person Christopher Painter    schedule 14.07.2010
comment
Последняя мысль: давайте представим, что это приложение winforms, которое записывает в журнал событий. Допустим, администратор установил MSI, но никогда не запускал программу. Затем программу запустил не администратор. Какие у него будут разрешения на создание источника события? Однако, если бы MSI создал источник событий, он мог бы это сделать.   -  person Christopher Painter    schedule 14.07.2010
comment
Хорошо ... указание на отношения между моим установщиком и службой в виде контракта было для меня полезной идеей (и я согласен с этим), но это также помогает мне укрепить мою проблему, которая заключается в том, что это неофициальный контракт, который может не подлежат принудительному исполнению (как обеспечить соответствие ключей реестра между сторонами контракта?). Метод InstallUtil может быть ужасным взломом, подверженным сбоям, но в моем случае он предоставляет более формальный контракт, который может быть принудительно исполнен, хотя по умолчанию информация определяется только в одном месте. Но, кстати, я ценю ваши комментарии, и они помогают!   -  person Peter M    schedule 14.07.2010
comment
Крис - точка зрения на сценарий приложения winforms. Очевидно, мне нужно уделять больше времени более философскому размышлению о том, что на самом деле означает установка.   -  person Peter M    schedule 14.07.2010
comment
Когда мы начинаем говорить об интеграции программного обеспечения, мы обычно говорим о контрактах между компонентами программного обеспечения от разных групп, а иногда и от разных поставщиков. Обычно я участвовал в группах по интеграции программного обеспечения с заинтересованными сторонами из разных областей. Лидеры Framwork, лидеры по продуктам, инженеры программного обеспечения работают вместе, чтобы определить эти отношения, а затем формализовать их в проектной документации, чтобы убедиться, что все находятся на одной странице. Я согласен с теорией пуленепробиваемой установки. Он просто никогда не должен подводить. Любые дополнительные соображения должны быть второстепенными.   -  person Christopher Painter    schedule 14.07.2010


Ответы (1)


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

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

person Christopher Painter    schedule 13.07.2010
comment
Я понимаю, о чем вы говорите, но у меня нет опыта, чтобы таким образом критиковать InstallUtil. Однако то, что я не осознал, так это эффект от предложенного вами решения. Если я создам собственный метод, теперь Wix и моя служба должны знать имя моего выделенного журнала событий - и я не могу представить, как экспортировать имя из моего серверного кода в выражение Wix, поэтому Мне нужно было бы определить имя в двух местах .. плохой код .. плохой код! Это общая проблема, с которой я сталкиваюсь с проектами Wix (и, я полагаю, msi). В краткосрочной перспективе я мог бы записать в стандартный журнал событий имя, например, приложение. - person Peter M; 14.07.2010
comment
Я занимаюсь установками 14 лет, 7 из которых были на MSI. Погуглите мое имя, и вы увидите мои работы - я эксперт и InstallUtil - отстой. Поверьте мне, MSI - это огромный шаг вперед по сравнению с установщиками на основе сценариев, и шаблон MSI существовал до того, как DevDiv ушел и заново изобрел колесо. MSI также должна поддерживать неуправляемые сервисы, которые существовали задолго до CLR. Если единственное, что вы делаете в своем коде, - это создание журналов событий, это легко сделать в WiX. stackoverflow.com/questions/58538/ - person Christopher Painter; 14.07.2010
comment
Если вы создадите свой установщик и посмотрите MSI в ORCA, вы увидите, что это всего лишь синтаксический сахар ключей / значений реестра, используемых для определения журнала событий и источника. Кстати, я не вижу, чтобы WiX и ваша служба знали имя журнала событий как проблему SoC. Задача установщиков - установить ваше приложение, и задача ваших приложений - запускать, а не устанавливать ваше приложение. - person Christopher Painter; 14.07.2010
comment
Говорим ли мы о реестре xeys, именах odbc, переменных среды, какая бы интеграция ни работала, долгое время означала объединение двух доменов. Если что-то, что связано с установкой вашего приложения, журнал событий является проблемой SoC, поскольку становится трудно определить, какой субъект вызывает проблему с установкой. - person Christopher Painter; 14.07.2010