Windows服务的WiX MajorUpgrade,保留.config并避免重新启动 [英] WiX MajorUpgrade of Windows Service, preserving .config, and avoiding a reboot

查看:67
本文介绍了Windows服务的WiX MajorUpgrade,保留.config并避免重新启动的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在努力使MajorUpgrade,ServiceControl和.config文件很好地协同工作. 在我提出其他问题之后,我现在有点再次遇到相反的问题.

I am struggling to get MajorUpgrade, ServiceControl, .config files to work nicely together. After my other question, I'm now kinda having the opposite problem again.

之前,文件没有被覆盖,因为AssemblyFileVersions是静态的,因此我将其修复. 1)现在,即使现有文件的修改日期不同,即使使用Schedule="afterInstallExecute",我的KeyPath='yes' .config 文件仍被覆盖而不是文件创建日期,并将其设置为KeyPath.我目前必须覆盖 .config 文件,并在安装后重新启动服务.

Before, the files weren't being overwritten because the AssemblyFileVersions were static so I fixed that. 1) Now, even with Schedule="afterInstallExecute" my KeyPath='yes' .config file is still being overwritten even though the existing file modified date is different than the file creation date and it is set as a KeyPath. I'm currently having to overwrite the .config file and restart the service after the install.

2),即使我修复了该问题,我仍然遇到避免重新启动的问题.如果我说Schedule="afterInstallInitialize",那么我相信.config文件肯定会与服务一起过早删除.如果我说Schedule="afterInstallExecute",则该服务不会停止,并且在安装后需要重新启动. (是对,对吗?)在安装之前手动停止服务,让我避免重新启动.我猜想添加net stop自定义操作可以代替ServiceControl,但是正确处理所有条件似乎很复杂.

2) And even if I fix that, I still have a problem of avoiding a reboot. If I say Schedule="afterInstallInitialize" then I believe the .config file will certainly be removed along with the service too early. If I say Schedule="afterInstallExecute" then the service isn't stopped and after the install a reboot is necessary. (That's right, right?) Stopping the service manually prior to the install let's me avoid the reboot. Adding a net stop custom action could work to replace the ServiceControl I guess, but getting all the conditions right seems complex.

3)作为奖励,我想在升级过程中根本不删除服务.我可以停止服务,替换二进制文件,然后重新启动服务吗?这将避免重新输入服务帐户凭据进行升级.但是,当然,它仍然需要在首次安装时进行安装,并在功能删除时进行卸载.

3) As a bonus, I'd like to NOT remove the service at all during an upgrade. Can I just stop the service, replace the binary, and start the service again? That will avoid re-entering the service account credentials for an upgrade. But of course it still needs to install on a first install and uninstall on a feature removal.

这是它的实质(以后也会捆绑在一起,以防万一):

Here's the meat of it (which is also bundled later, in case that somehow matters):

<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版本3.8.1128.0

WiX version 3.8.1128.0

推荐答案

EDIT :看来,对同一问题或至少在同一主题上的解释可能更容易理解: Msiexec:在以下版本上自动回滚到以前的版本安装失败

EDIT: it seems this explanation of the same issue, or on the same topic at least, might be easier to understand: Msiexec: automatic rollback to previous version on installation failure

您在这里遇到一些MSI核心使用问题.

You are banging your head against several core MSI usage problems here.

  1. 文件版本控制:安装期间的默认文件覆盖模式(由
  2. 升级行为:就像克里斯说的那样,由于主要的升级配置,实际上已卸载并重新安装了看起来已恢复为默认值的文件.如果将RemoveExistingProducts放在InstallExecuteSequence中的较晚位置,则仅在大型升级中才可以保留文件.这样就不会卸载版本之间的共享文件,并且第1点中描述的文件版本控制规则适用于覆盖.
  3. 服务配置保留:对于早期在InstallExecuteSequence中卸载的主要升级,避免重新输入服务凭证信息是一个常见问题.换句话说,先卸载产品,然后再重新安装,以清除更改的文件.我不推荐这样做,但是有人为这种解决方案辩护:
  1. File versioning: during installation the default file overwrite mode (defined by the REINSTALLMODE property) won't replace files that are equal version by default. This can be changed by setting REINSTALLMODE = "emus". This will replace files with equal version for versioned files. Unversioned files will be preserved if modify and create dates are different.
  2. Upgrade behavior: like Chris says, files that appear to be reverted to default are actually uninstalled and reinstalled due to major upgrade configuration. File preservation is only possible in major upgrades if RemoveExistingProducts is placed late in the InstallExecuteSequence. Then shared files between releases are never uninstalled and the file versioning rules described in point 1 apply for overwriting.
  3. Service configuration preservation: avoiding re-entry of service credential information is a common problem for major upgrades that uninstall early in the InstallExecuteSequence. In other words the product is uninstalled and then reinstalled wiping out changed files. I don't recommend it, but some people argue for this solution: How to only stop and not uninstall windows services when major upgrade in wix? (Rob Mensching is the WIX and Orca author - I think he is suggesting this solution as an option, and not necessarily a recommendation. Please ask in the linked post to be sure). With correct component referencing and uninstall placed late in the InstallExecuteSequence this problem is normally avoided altogether, and this is then a preferred approach (normal component referencing prevent the component from uninstalling altogether leaving service settings and changed config files intact - if, and only if, component referencing is correct - see description of this concept below). However, my preferred approach is still to use a separate MSI for the service install and configuration if you are using a user account to run the service - then it is a self contained deployment unit and can be included in a bootstrapper and updated on its own, and best of all: it is undisturbed by any other application changes or hotfixes. Finally I would like to point out that a service running with a user account isn't a recommended approach to begin with - for security and deployment reasons alike.

组件引用:是指分配给MSI组件的GUID,以及它们如何与所有升级始终始终只有一条(绝对)路径相匹配.此处有一些示例,可以对此进行更好的讨论:在wix中更改组件GUID吗?

Component referencing: refers to the GUIDs assigned to MSI components and how they must match one, and only one (absolute) path at all times through all upgrades. See a better discussion of this with a couple of examples here: Change my component GUID in wix?

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

I didn't mention the option of setting the MSI components installing services to permanent to prevent their removal on uninstall for the simple reason that this isn't good practice at all. Then files and registration will remain on final uninstall, and you need a custom action to clean up. Very bad practice and bound to cause lots of extra work and problems with dangling component references.

这篇关于Windows服务的WiX MajorUpgrade,保留.config并避免重新启动的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆