Forzare l'installazione di GAC prima di eseguire l'azione personalizzata .NET?

Question

Sto utilizzando un progetto di installazione e distribuzione di VS 2008 per distribuire un'applicazione mista gestita/non gestita.Ho avuto problemi con la registrazione delle DLL in modalità mista utilizzando la proprietà di registrazione incorporata (valore enumerato "vsdraCOM" della proprietà "Register"). Come soluzione alternativa, ho aggiunto un assembly di installazione personalizzato .NET (con una classe che deriva da System.Configuration.Install.Installer.) Sono certo che quella classe è in esecuzione e che una serie di operazioni vengono installate e disinstallate correttamente tramite il codice in quell'assembly, inclusa l'esecuzione del punto di ingresso Dll(Un)RegisterServer di un numero di assembly .

Tuttavia, una DLL non viene registrata correttamente.È l'unica DLL che dipende da alcuni assembly ridistribuibili di terze parti che desiderano essere installati nel GAC.Ho installato questi assembly nel GAC grazie al supporto integrato nei progetti di installazione e distribuzione di VS 2008 e so che funziona.Ho confermato che ciò che sta accadendo è che l'azione personalizzata viene eseguita prima che il programma di installazione esegua l'installazione GAC.

Wow.Quindi la mia domanda è: esiste un modo per forzare il programma di installazione a eseguire l'installazione GAC prima di eseguire l'azione personalizzata?Esiste un modo per utilizzare la proprietà "Condizione" dell'azione personalizzata per eseguire questa operazione?In caso contrario, qual è la mia migliore alternativa?Catturare le voci del registro dalla DLL e aggiungerle alle impostazioni del registro per il programma di installazione (non ti piace perché qualcuno potrebbe aggiungere nuovi server COM alla classe in futuro)?Utilizzo del codice .NET per installare manualmente l'assembly nel GAC (non sai ancora come farlo)?

Grazie,

Dave

Answer 1

I progetti di installazione che puoi creare in Visual Studio sono molto limitati.Consente solo di programmare azioni personalizzate in 4 punti.Tuttavia, MSI consente di pianificare azioni personalizzate in qualsiasi momento del processo con alcune restrizioni su ciò che possono fare.

La mia prima soluzione è smettere di utilizzare Visual Studio 2008 come strumento di sviluppo della configurazione.Il team di Visual Studio ha cercato di eliminare tutta la complessità della creazione di un'installazione.Tuttavia, nel processo hanno tolto anche tutta la flessibilità dell’MSI.Wix, InstallShield o Wise sono prodotti molto migliori per installazioni tutt'altro che semplici.Ho iniziato a utilizzare Visual Studio per le nostre installazioni e alla fine è stato troppo lavoro.C'era sempre un'altra soluzione da implementare e i suoi effetti collaterali da affrontare.

Se non puoi cambiare tecnologia, dovrai imparare come modificare manualmente il file MSI risultante.Nel tuo caso dovrai modificare la tabella InstallExecuteSequence, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx.Puoi farlo manualmente tramite Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx o tramite l'API MSI http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx.Assicurati di scaricare Orca ed eseguire gli script di convalida per la tua installazione.Gli script evidenziano numerosi problemi la cui risoluzione ti farà risparmiare innumerevoli ore durante la distribuzione sui computer dei clienti.