WiX MajorUpgrade of Windows Service,保留.config,并避免重启

Jas*_*ban 10 installer windows-installer wix major-upgrade

我正在努力让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>
Run Code Online (Sandbox Code Playgroud)

相关但未答复:

WiX版本3.8.1128.0

Ste*_*mul 5

编辑:似乎对同一问题或至少在同一主题上的这种解释可能更容易理解:Msiexec:在安装失败时自动回滚到以前的版本


您正在敲打几个核心MSI使用问题.

  1. 文件版本控制:在安装期间,默认文件覆盖模式(由REINSTALLMODE属性定义)不会替换默认情况下版本相同的文件.这可以通过设置REINSTALLMODE ="emus"来更改.这将替换版本化文件的版本相同的文件.如果修改和创建日期不同,则将保留未版本控制的文件.
  2. 升级行为:像Chris说的那样,由于主要的升级配置,实际上已经卸载并重新安装了似乎恢复为默认的文件.如果在InstallExecuteSequence中放置RemoveExistingProducts,则只能在主要升级中进行文件保存.然后,永远不会卸载发行版之间的共享文件,并且第1点中描述的文件版本控制规则适用于覆盖.
  3. 服务配置保留:避免重新输入服务凭据信息是在InstallExecuteSequence中尽早卸载的主要升级的常见问题.换句话说,卸载产品,然后重新安装,擦除已更改的文件.我不推荐它,但是有些人争论这个解决方案:如何在wix中进行重大升级时停止并且不卸载Windows服务?(Rob Mensching是WIX和Orca的作者 - 我认为他建议将此解决方案作为一种选择,而不一定是推荐.请在链接的帖子中询问是否确定).通过在InstallExecuteSequence后期放置正确的组件引用和卸载,通常可以完全避免此问题,这是一种首选方法(正常组件引用可防止组件完全卸载,保留服务设置和更改配置文件 - 如果且仅当,组件引用是正确的 - 请参阅下面对此概念的描述).但是,如果您使用用户帐户运行服务,我首选的方法仍然是使用单独的MSI进行服务安装和配置- 然后它是一个自包含的部署单元,可以包含在引导程序中并自行更新,最重要的是:它不受任何其他应用程序更改或修补程序的干扰.最后,我想指出,出于安全性和部署原因,使用用户帐户运行的服务不是推荐的方法.

组件引用:指分配给MSI组件的GUID以及它们必须如何匹配一个,并且在所有升级中始终只有一条(绝对)路径.通过以下几个示例来更好地讨论这个问题:在wix中更改我的组件GUID?

我没有提到将安装服务的MSI组件设置为永久性以防止在卸载时将其删除的选项,原因很简单,这根本不是好的做法.然后文件和注册将保留在最终卸载状态,您需要自定义操作进行清理.非常糟糕的做法,并且必然导致许多额外的工作和悬挂组件引用的问题.


归档时间:

查看次数:

1888 次

最近记录:

11 年,2 月 前