qual è la differenza tra le dipendenze e aggiungere manualmente una dll / ocx in vs installer 6?

Question

Sto usando vs installer per creare un pacchetto di installazione per la mia app vb6. e il problema è che posso vedere che sotto Esplora progetti c'è un elenco di dipendenze associate al mio file exe.

alt text http://img505.imageshack.us/img505/9696/croppercapture259lr8 .png

e sotto il file system sulla treeview della macchina target, posso effettivamente memorizzare la dll / ocx su una cartella o nella stessa cartella di sistema di Windows [la finestra di sinistra].

alt text http://img101.imageshack.us/img101/9224/croppercapture251qm1 .png

quindi quello che non capisco è ... c'è davvero una differenza? se ho appena impostato le dipendenze e non ho aggiunto dll o ocx alla cartella o non ho vinto la cartella sys, anche la dll viene copiata automaticamente?

Answer 1

Non è garantito che tutte quelle DLL siano presenti sul sistema su cui il software viene installato. Quindi devono essere inclusi nel programma di installazione. Da lì hai due scelte.

Puoi installarli nelle cartelle di sistema di Windows o nella cartella dell'applicazione. La differenza è che se li installi nella cartella dell'applicazione puoi impostare le cose su XP e Vista in modo che la diversa versione del software con una diversa versione dei componenti possa essere avviata ed eseguita fianco a fianco. Installandoli nella cartella di sistema si romperà qualsiasi versione precedente che dipende dalla versione precedente dei componenti.

L'installazione nella cartella dell'applicazione raramente non funziona se un componente dipende da altri componenti che non possono essere aggiornati. In questo caso, di solito è con le librerie Microsoft. Sono migliorati nel corso degli anni su questo tema.

Puoi leggere ulteriori informazioni sui problemi relativi all'esecuzione fianco a fianco qui

Infine, le dipendenze devono trovarsi nel programma di installazione in modo che siano registrate nel registro di Windows. A differenza della maggior parte degli assembly .NET, qualsiasi applicazione ActiveX / COM deve avere il componente registrato per poterlo utilizzare anche se si utilizzano i tipi CreateObject e Variant per accedervi.

Devo ammettere che l'intero processo è idiosincratico ed è una delle fonti per le storie su DLL Hell. Inizia con l'articolo MSDN, usa Wikipedia e, naturalmente, fai ulteriori domande qui.

Answer 2

Di solito non dovresti avere un " dlls " cartella sotto la cartella dell'app per un normale pacchetto di installazione, ma sono coinvolti molti fattori (DLL standard private, COM senza registro, ecc.). Sì, le dipendenze vengono incluse (a meno che non le le escluda ). Ciascuno di essi dovrebbe avere una proprietà che determina la posizione di installazione sui sistemi di destinazione.

Nell'elenco sono inoltre presenti numerosi componenti che non sono ridistribuibili in questo modo perché sono componenti di sistema dipendenti dal sistema operativo, componenti MDAC o non sono autorizzati per la redist (ad esempio fm20.dll).

Purtroppo questo è un esempio del tipo di pacchetto che può portare direttamente a DLL Hell per i sistemi dei tuoi utenti. Risolvere questo problema può significare ricercare ogni componente MS negli articoli di MS KB per determinare cosa può o deve essere ridistribuito e come.

La distribuzione può essere un'attività disordinata per avere ragione.