我在1.0.0.0版本中安装了我的应用程序。服务已安装在用户帐户上(使用用户名/密码)。
如何进行更新,以便用户不必再次指定登录名和密码?
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<Component Id="MyService" Guid="MyGUID" Win64="yes">
<File Id="FileID" Name="MyService.exe" Source="Path\MyService.exe" KeyPath="yes" />
<ServiceInstall Id="InstallService"
Type="ownProcess"
Name="SERVICENAME"
DisplayName="XXX"
Description="XXX XXX"
Account="NT SERVICE\XXXACCOUNT"
ErrorControl="normal"
Start="auto" />
<ServiceControl Id="Controlervice" Name="SERVICENAME" Start="install" Stop="both" Remove="uninstall" Wait="yes" />
</Component>
我试过了:
<InstallExecuteSequence>
<!-- Without overwriting the service configuration -->
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
</InstallExecuteSequence>
但是没有用。
答案 0 :(得分:0)
如果您在升级设置中使用该条件,则该条件不正确。 UPGRADINGPRODUCTCODE设置在旧的已安装产品中,正在更换和卸载,而不是在新的传入升级中。为此,如果使用MajorUpgrade元素,则需要升级元素WIX_UPGRADE_DETECTED中的属性。然而...
影响旧产品的卸载(当它正在升级时)已经太晚了,因为它的DeleteServices已经在卸载中,准备好了,你无法阻止它从新的升级安装中发生。如果您在较旧的安装中具有DeleteServices条件,那么它将有可能工作,以便在升级卸载时不会删除它。如果有多个服务,人们通常不会这样做,因为它会影响所有服务。
通常,人们通过在某处保存和加密凭据来执行此操作,以便将它们还原为具有帐户名和密码的属性,以便在升级,修补,修复等时恢复它们。如果还没有保存它们现在修复它可能为时已晚。例如,如果您对旧安装的产品进行修复会发生什么?它是否再次要求凭证或是否失败?或者可能还原服务以使用默认帐户运行?
长期而言,将这些凭据存储在某个地方是人们采用的方法,而Win32 CredWrite和CredRead以及托管代码等价物比注册表更安全。
根据发布的信息,我认为没有针对您的解决方案。如果我理解正确,那么旧的卸载将无条件地调用DeleteServices,除非您更新旧产品(例如使用补丁)以防止DeleteServices,否则无法阻止删除。然后在传入升级中,您需要跳过调用InstallServices。并完全确定服务二进制文件将位于完全相同的位置(可能不是可浏览的应用程序目录!),因为您不希望旧安装创建的服务设置引用升级可能安装到的二进制文件不同的位置。