E 'ok per programmare RemoveExistingProducts un'azione personalizzata prima InstallValidate?

Question

Problema

Ho un MSI che crea e avvia un servizio di Windows durante l'installazione e si ferma e rimuove il servizio durante la disinstallazione. Questo funziona bene per l'installazione e la disinstallazione di per sé, ma durante l'aggiornamento, la File in uso viene visualizzata la finestra (solo su Vista e versioni successive a causa del nuovo Restart manager ), che indica che il servizio è in uso.

Sfondo

Il File in uso finestra di dialogo viene visualizzata durante la InstallExecute successione con la InstallValidate azione personalizzata, che è prevista immediatamente prima del RemoveExistingProducts azione personalizzata; questo significa che la versione precedente non è stato ancora disinstallato, in modo che il File in uso finestra dovrebbe essere indicato.

La documentazione MSDN indica che le RemoveExistingProducts azione devono essere programmati dopo il InstallValidate l'azione, e ho attualmente RemoveExistingProducts azioni programmate subito dopo InstallValidate azione.

possibile soluzione

Vorrei riprogrammare le RemoveExistingProducts un'azione personalizzata per immediatamente prima del InstallValidate azione personalizzata in modo che l'installazione precedente ha la possibilità di fermarsi e rimuovere il servizio prima della < strong> File in uso finestra di dialogo viene visualizzata. Ho provato a riprogrammare le azioni, e sembra funzionare correttamente, senza effetti collaterali negativi (anche se il registro indica ancora che la InstallValidate azione viene eseguito prima del RemoveExistingProducts azione), ma sono riluttanti a utilizzare questa soluzione in quanto viola la documentazione MSDN, e ci possono essere effetti negativi che io non sono solo ancora vedendo.

Qualcuno ha provato questo? L'unica altra alternativa che posso pensare è quello di avere la nuova installazione arrestare il servizio del vecchio impianto, ma questo è indesiderabile perché richiede l'installazione di avere informazioni su tutti i vecchi impianti che si può aggiornare (fermare questo particolare servizio può coinvolgere più di un semplice chiamata al gestore del servizio per fermarlo).

Answer 1

ho implementato la soluzione potenziale indicato nella domanda, la pianificazione di RemoveExistingProducts immediatamente prima di InstallValidate . Non ho ancora visto alcun problema, ma mi post di nuovo dopo l'installazione si fa più uso.

Aggiorna

Il nostro impianto è stato utilizzato questo per qualche tempo, e non ho notato alcun effetto negativo.

Answer 2

La sua già stato costruito dentro al MSI / Windows Installer ... l'unico problema è che le classi di installazione di .NET non utilizza le caratteristiche MSI "Servizio di installazione". Che cosa realmente sta accadendo è che il MSI sta cercando di installare i file ed eseguire un comando personalizzato utilizzando i file appena copiato (che è tutto Visual Studio sta mettendo nel MSI).

Per risolverlo è possibile modificare il MSI con ORCA e aggiungere la seguente riga alla ServiceControl tabella:

1   ServiceName 170     1   C__489628C5CC1144CB47F43E8BE7F3F31D

L'ID componente si può cercare nella tabella FILES ... ho appena scelto il file EXE principale componente ID. La 170 è una bitmap che dice al Windows Installer per arrestare ed eliminare il servizio durante l'installazione e disinstallazione.

Questo cancellerà la strada per gli installatori .NET per aggiungere il servizio ed è possibile utilizzare il ServiceController per avviare il servizio dopo che è stato installato tramite comando personalizzato.

Answer 3

Un potenziale problema sarebbe che se l'utente annulla durante InstallValidate (ad esempio a causa di non sufficiente spazio su disco o di un file in uso) o durante l'installazione, che cosa è il comportamento di rollback. La situazione ideale è che lo stato applicazione è la stessa come prima (ad esempio è installata l'applicazione precedente). Si potrebbe dare che con la vostra sequenza, anche se rollback possono essere una caratteristica si può vivere senza.

Answer 4

Penso che questo vi aiuterà senza violare la documentazione MSDN e evitare eventuali problemi futuri. Mettere una condizione "installati o PREVIOUSVERSIONSINSTALLED" e sarete sulla buona aggiornamento troppo poiché la proprietà PREVIOUSVERSIONSINSTALLED è impostata prima azione InstallValidate durante FindRelatedProducts. Non so perché, ma la proprietà PREVIOUSVERSIONSINSTALLED non è documentato in MSDN ma esiste e molto utile, per me però.