Насильно убить службу windows в wix

У меня есть служба Windows, которая будет установлена ​​как часть установки wix. Проблема в том, что в настоящее время служба находится в эксплуатации и не реагирует на остановку из-за плохо написанного кода в методе службы OnStop.

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

Могу ли я как-нибудь узнать, занимает ли wix слишком много времени на удаление, и могу ли я убить процесс, если получу это уведомление?

Кроме того, есть ли способ убить процесс в зависимости от версии продукта?

Спасибо

0
0
775
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

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

  1. Элемент CloseApplication: Может, я сначала попробую Элемент CloseApplication WiX. Я сомневаюсь, что это сработает для службы, но это наиболее удобный подход, который я могу придумать в своей голове.
  2. Sysinternals PsKill: PsKill Марка Руссиновича стоит попробовать. Я думаю, что его инструменты можно распространять, поэтому вы можете включить их в свою установку, и они всегда хороши. Вы должны вызвать его из настраиваемого действия в отложенном режиме с повышенными привилегиями, что всегда более сложно, чем использование встроенной конструкции WiX.
  3. Тасккилл: Также есть встроенный Тасккилл, который я никогда не использовал. Предлагаемое использование с инструментом sc.

Хочу подчеркнуть, что на самом деле я не тестировал эти инструменты для уничтожения сервисов, и сейчас у меня нет на это времени. Могут возникнуть проблемы с секвенированием, когда StopServices может быть запланирован до того, как будет запланировано выполнение настраиваемого действия CloseApplication из WiX. Пожалуйста, проверьте InstallExecuteSequence с помощью Orca (внизу) после компиляции, чтобы узнать, так ли это.

Спасибо, Штейн. Есть ли способ заглянуть в wix перед непосредственным завершением процесса. Я искал возможности с помощью FailureActionsWhen, чтобы, если служба не останавливается, я мог выполнить процесс в параметре runCommand, чтобы убить процесс службы. Я выгляжу примерно так, если служба не останавливается, а затем убивает процесс. В случае сбоя я получаю, что служба не смогла остановить сообщение с возможностью повторной попытки. Еще раз спасибо за ответ ссылки

Praveen M 12.04.2018 11:46
Я вижу некоторые предупреждения относительно этих новых служебных конструкций MSI в MSDN.. По сути: «... эта функция работает не так, как ожидалось» (в прошлом году). Соответственно, я никогда не тратил время на их тестирование. Настраиваемые действия позволяют делать практически все, но они ужасно подвержены ошибкам. Чем больше вы делаете, тем выше риск проблем с развертыванием, которые трудно исправить. Проблемы с секвенированием, олицетворением и обусловливанием являются сложными. Сделать все это в настраиваемом действии? Возможно: да. Легко: нет.
Stein Åsmul 14.04.2018 03:57
Просто перекрестная ссылка на другой ответ. Может быть, бегло бегло. Инструмент sc.exe, вероятно, можно попробовать.
Stein Åsmul 14.04.2018 04:03
Ответ принят как подходящий

Я нашел решение для этого, покопавшись некоторое время.

Я создаю новый проект настраиваемого действия C#, и я упорядочиваю свои действия перед InstallInitialize.

В моем методе настраиваемых действий C# я читаю существующую установленную версию файла, используя FileVersionInfo.GetVersionInfo (filePath);

Затем я проверяю желаемую версию, которую хочу проверить, и если условие совпадает, я убиваю свой процесс обслуживания, используя

 foreach (Process proc in Process.GetProcessesByName("ProcessName"))
 {
      proc.Kill();
      session.Log("Service Killed");
 }

Для этого необходимо заранее установить Wix toolset v3.11.1.

Пользовательские действия в немедленном режиме выполняются без повышенных прав. У них не будет доступа для уничтожения службы, если MSI запущен в заблокированной управляемой среде, где пользователи имеют стандартные права (не права администратора). Я предполагаю, что вам это удалось, потому что вы запускаете свой MSI из командной строки с повышенными привилегиями или повышаете через приглашение UAC - выбирая да для повышения при установке MSI? Проблема с доступом проявится, если вы попытаетесь выполнить развертывание через AD / групповую политику. Это пакет для вашего собственного использования или для крупномасштабного распространения?

Stein Åsmul 18.04.2018 05:46

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

Praveen M 18.04.2018 07:01

Итак, у всех пользователей будут права администратора или только у устанавливающего пользователя? Что произойдет, если вы активируете модифицировать, ремонт или самостоятельный ремонт из стандартная учетная запись пользователя? Вы должны проверить это как минимум - вероятна ошибка времени выполнения. Вы можете настроить настраиваемое действие так, чтобы оно выполнялось только тогда, когда у пользователя есть повышенные права, проверьте Привилегированная недвижимость. К крупномасштабному распространению я бы отнесся очень скептически, к меньшему распределению для нескольких ПК он мог бы выполнить свою работу.

Stein Åsmul 18.04.2018 18:32

Просто хочу прояснить, что Я рекомендую вам запустить такое действие с повышенными правами. Как насчет проверки в немедленном режиме, убивать ли процесс или нет, а затем установить свойства, чтобы указать, должен ли вызов CloseApplication в отложенном режиме убивать процесс? Все, что вы бы удалили из своего настраиваемого действия в немедленном режиме, - это уничтожение процесса, а то, что вы бы установили, будет чем-то вроде свойства DOKILLPROCESS или аналогичного. И вы должны обусловить свой элемент CloseApplication этим свойством. Это условие следует применять очень осторожно, чтобы применять его только тогда, когда это необходимо.

Stein Åsmul 18.04.2018 18:46

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

Praveen M 19.04.2018 08:05

Другие вопросы по теме