WiX MajorUpgrade службы Windows, сохранение .config и предотвращение перезагрузки

Я изо всех сил стараюсь, чтобы файлы MajorUpgrade, ServiceControl,.config работали вместе. После моего другого вопроса, теперь я снова вижу противоположную проблему.

Раньше файлы не перезаписывались, потому что AssemblyFileVersions были статичными, поэтому я исправил это. 1) Теперь даже с Schedule="afterInstallExecute" мой KeyPath='yes'.config файл все еще перезаписывается, даже если дата изменения существующего файла отличается от даты создания файла, и это установлен как KeyPath. В настоящее время мне приходится перезаписывать файл .config и перезагружать службу после установки.

2) И даже если я исправлю это, у меня все еще есть проблема избежания перезагрузки. Если я скажу Schedule="afterInstallInitialize", то я верю, что файл .config, безусловно, будет удален вместе со службой слишком рано. Если я скажу Schedule="afterInstallExecute", то служба не будет остановлена и после установки потребуется перезагрузка. (Правильно ли это?) Остановить службу вручную до установки, позвольте мне избежать перезагрузки. Добавление пользовательского действия net stop могло бы сработать, чтобы заменить ServiceControl, я думаю, но получение всех условий правильно кажется сложным.

3) В качестве бонуса я бы хотел НЕ удалить службу вообще во время обновления. Могу ли я просто остановить службу, заменить двоичный файл и снова запустить службу? Это означает избежать повторного ввода учетных данных учетной записи службы для обновления. Но, конечно, его еще нужно установить при первой установке и удалении при удалении функции.

Здесь мясо его (которое также поставляется позже, в случае, если это имеет какое-то значение):

<MajorUpgrade DowngradeErrorMessage="A newer version is already installed." 
              Schedule="afterInstallExecute" />

<ComponentGroup Id="ServiceCG">
    <Component Id="Service" Guid='*' Win64='yes' Directory='INSTALLDIR'>
        <File Id='ServiceEXE' Source='$(var.root)Service.exe' />
        <ServiceInstall Id="ServiceInstall"
                          Name="MyService"
                          DisplayName="My Server"
                          Type="ownProcess"
                          Start="auto"
                          ErrorControl="normal"
                          Description="My Server Service"
                          Interactive="no"
                          Account="[...]"
                          Password="[...]" />
        <ServiceControl Id="StopService" Name="MyService" Start="install" 
                        Stop="uninstall" Wait="yes" Remove="both" />
        <util:User Id="UpdateServiceAccountLogonAsService" UpdateIfExists="yes"
                   CreateUser="no" Name="[SERVICEACCOUNTFULL]" 
                   LogonAsService="yes"/>
    </Component>
    <Component Id="ServiceConfig" Guid='*' Win64='yes' Directory='INSTALLDIR'>
        <File Id='FileServiceConfig' KeyPath='yes' 
              Source='$(var.root)Service.exe.config' />
    </Component>
</ComponentGroup>

Связано, но не отвечает:

Предотвращение удаления/установки службы во время обновления WiX - сервис не останавливается

Версия WiX 3.8.1128.0

Ответ 1

EDIT: похоже, это объяснение одной и той же проблемы или по той же теме, по крайней мере, может быть проще понять: Msiexec: автоматический откат к предыдущей версии при сбое установки

Вы столкнулись с несколькими проблемами использования MSI здесь.

Версии файлов: во время установки режим перезаписи по умолчанию (определенный свойство REINSTALLMODE) не будет замените файлы, которые по умолчанию равны. Это можно изменить, установив REINSTALLMODE = "emus". Это заменит файлы с одинаковой версией для версий файлов. Неверсифицированные файлы будут сохранены, если изменения и создание дат будут разными.
Модифицировать поведение: как говорит Крис, файлы, которые, как представляется, возвращаются к умолчанию, фактически удаляются и переустанавливаются из-за большой конфигурации обновления. Сохранение файлов возможно только при крупных обновлениях, если RemoveExistingProducts помещается в конце InstallExecuteSequence. Затем разделяемые файлы между релизами никогда не удаляются, а правила перезаписи файлов, описанные в пункте 1, применяются для перезаписи.
Сохранение конфигурации службы: исключение повторной записи информации учетных данных службы является распространенной проблемой для основных обновлений, которые удаляются на ранней стадии InstallExecuteSequence. Другими словами, продукт удаляется, а затем переустанавливается, удаляя измененные файлы. Я не рекомендую это, но некоторые люди спорят об этом решении: Как остановить и не удалять службы Windows при основном обновлении в wix? ( Rob Mensching - автор WIX и Orca - я думаю, что он предлагает это решение в качестве опции, а не обязательно рекомендацию. Пожалуйста, задайте в связанном сообщении, чтобы быть уверенным). При правильной установке и удалении компонентов, размещенных в конце InstallExecuteSequence, эту проблему обычно вообще избегают, и это предпочтительный подход (нормальный компонент, ссылающийся на предотвращение удаления компонента, полностью оставляя параметры службы и измененные файлы конфигурации неповрежденными - если и только если, ссылка на верна - см. описание этой концепции ниже). Однако мой предпочтительный подход по-прежнему должен использовать отдельный MSI для установки и настройки службы, если вы используете учетную запись пользователя для запуска службы - тогда это автономный блок развертывания и может быть включен в bootstrapper и обновляется самостоятельно, и лучше всего: он невозможен никакими другими изменениями приложения или исправлениями. Наконец, я хотел бы указать, что служба, работающая с учетной записью пользователя, не рекомендуется для начала - для целей безопасности и развертывания.

Ссылка на компоненты: относится к идентификаторам GUID, назначенным компонентам MSI, и о том, как они должны соответствовать одному и только одному (абсолютному) пути на всех этапах обновления. См. Лучшее обсуждение этого с помощью нескольких примеров здесь: Измените мой GUID-компонент в wix?

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

Ответ 1

Ответ 2