我有什麼是我想象的一種常見的情況，但無法讓事情完全工作。在WiX主要升級期間阻止服務移除/安裝 - 服務不停止
該場景非常簡單，我想在不更改服務設置的情況下執行產品的主要升級，也不需要重新啓動。
我主要通過在DeleteServices上使用NOT UPGRADINGPRODUCTCODE條件工作。但是，升級過程中該服務並未停止，因此需要重新啓動。
升級時是否有某種方式停止服務，安裝新文件並重新啓動服務而不刪除/安裝服務？
您是否啓用了等待標誌用於Windows安裝程序等待服務正常停止？ http://msdn.microsoft.com/en-us/library/aa371634(v=vs.85).aspx。即使啓用了此標誌，您的服務也必須在30秒內停止或主要升級進行。有些方法可以實現你自己的延遲，讓它有更多的時間，但如果沒有必要，不要這樣做。從本質上講，這可能只是一個自定義操作，其中一些代碼實現了屬性表中定製屬性中指定的延遲。
注意，不要在DeleteServices UPGRADINGPRODUCTCODE可能表現爲沒有副作用，但會發生什麼是一個重大的升級不會刪除定於卸載作爲升級的一部分的服務。換句話說，你已經刪除了一個服務，或許增加了一個新服務，而舊服務不會正確卸載。與這樣的標準Windows安裝程序操作混淆並不是最佳實踐，並且幾乎肯定會有意想不到的副作用。在與Windows Installer對戰時，您可以將自己繪製在角落以便以後進行更新。
如果我是你，我寧願將服務安裝拆分爲單獨的MSI，以防處於不應受主安裝影響的狀態。然後，將MSI文件與引導程序一起鏈接起來。如果您將來需要添加新服務或刪除舊服務，這非常靈活。它完全是香草，並不與Windows Installer設計相抗衡。這是從公司的角度思考的問題，即當每個服務可能具有非常不同的發佈時間表時，能夠可靠地控制每個服務。如果您將安裝程序作爲第三方產品提供給某人，則可能不是您所希望的。
該服務在30秒內停止，其設計明確表現爲與服務控制命令正確對應。問題是StopServices沒有在我最初描述的場景中被調用。它在卸載時停止運行，所以這不是問題。 – snae
這應該只是起作用（暫時擱置Delete），但不知道您的升級的RemoveExistingProducts操作的位置，不清楚發生了什麼事情，特別是如果您添加條件並且StopService不起作用一些原因。但是，DeleteServices有什麼問題？如果服務沒有運行，對系統的瞬間影響很小。您是否試圖保留後來添加的服務，如帳戶？如果這就是你正在做的事情，那就是一個問題，因爲修復可能會失敗。
無論如何，如果你的REP是在年底，那麼事件的簡化序列，因爲它適用於你的服務是一樣的東西：
傳入安裝停止舊服務，刪除服務，安裝所有更新的文件，重新安裝服務並啓動新服務。
REP後來停止服務，不刪除它，因爲它被ref計數，然後啓動它。 但是有一個瞬間刪除，所以問題是爲什麼停止不起作用，問題是刪除有什麼不好？
有幾個人問過同樣的問題。我猜這些問題主要是您丟失的證書，以及像您指出的那樣糟糕的重新計數和REP。我絕對不會混淆空調的標準動作。 –
DeleteServices的問題在於Glytzhkof通過升級保留服務設置。如果服務帳戶已更改，那麼這應該不會因升級而受到影響。 REP正在InstallValidate之後完成。在升級情況下，這可能爲時過早嗎？ 請注意，如果我不關心保留服務設置，那麼安裝程序可以「完美地工作」 - 但那在我的場景中很重要。 – snae
嘗試我建議的內容：修改服務憑證後修復產品。此修復可能會失敗，因爲Windows無法重新安裝該服務，如果成功，您可能會發現它已經丟失了用戶提供的憑據。換句話說，整個區域都是混亂的，最可靠的選擇可能只是告訴用戶在升級到新產品後重新輸入證書。這不是每天都發生，對嗎？ – PhilDW
第一次檢查將查看停止服務需要多長時間。如果不能及時停止，您需要先看看。 –
服務及時停止不是問題 - 當我在DeleteServices上使用指定的條件時，在升級繼續之前不會嘗試停止服務。 – snae
Hi @snae，您在此期間找到了解決方案嗎？ –