Newsgroup: it.comp.lang.visual-basic
Titolo: Compilare applicazione con dipendenze

Ho in manutenzione un'applicazione fatta da colleghi non più in ditta
che tutte le volte in cui ci devo mettere le mani mi viene
l'orticaria. E' un applicazione "modulare" (o almeno è stata
progettata con questo intento) ma per me è un bordello. C'è un
progetto che genera un eseguibile e altri 37 progetti che generano
delle DLL il tutto raggruppato in un Project Group che apro modifico e
compilo. Il problema è che ora non riesco più a compilarlo perchè mi
da problemi di accesso in scrittura su alcune DLL che fanno parte
dell'applicazione e sono referenziate da altre DLL dell'applicazione.
Sto girando attorno a sto problema ma non ne esco. Per questo progetto
è stata fatta anche un applicazione che dovrebbe pulirlo dopo ogni
compilazione, sostituisce nei VBP Path32= con Path32="..\..\..\Bin",
CompatibleMode= con CompatibleMode="1" e CompatibleEXE32= con nulla,
non mi è ben chiaro però a cosa serve questa procedura.
Ogni suggerimento è ben accetto.
Ciao
Fritz

 Fritz
Per mia esperienza, i Project Group portano una certa sfiga...
Vanno benissimo per lavorare in debug, ma quando si tratta di compilare � di 
gran lunga preferibile farlo progetto per progetto.
Infatti non � infrequente che capitino problemi come quelli che hai 
descritto tu (modifiche casuali arbitrarie ai VBP facenti parte del gruppo).
Ti consiglio di farti un "makefile", ossia un bat che richiami (nella 
sequenza giusta, a seconda delle dipendenze) il compilatore VB per ciascun 
progetto del gruppo.
start "" /WAIT "C:\Programmi\Microsoft Visual Studio\VB98\vb6.exe" /m 
Progetto1.vbp
start "" /WAIT "C:\Programmi\Microsoft Visual Studio\VB98\vb6.exe" /m 
Progetto2.vbp
...
HTH
Bye
Raf

 Progetto2.vbp
La struttura delle cartelle è:
\pippo\Dll\dll1
\pippo\Dll\dll2
\pippo\Dll\dll3
\pippo\Dll\dll4
\pippo\Dll\dll5
\pippo\Dll\dll6
\pippo\Prj\PrjExe
posso passare il path assoluto del vbp al compilatore o mi devo
posizionare nella cartella del progetto tutte le volte?
Grazie, ciao
Fritz

 progetto del gruppo.
Ho provato ma è peggio di prima, ora ho 15 progetti che mi danno tutti
errore sulla riga:
Global dbDataBase As Database
che non mi sembra nasconda niente di insidioso
Ciao
Fritz

 Fritz
Ciao
Raf 

 che non mi sembra nasconda niente di insidioso
Sar� saltato il riferimento a DAO nei file di progetto...
Raf 

 Sarà saltato il riferimento a DAO nei file di progetto...
Non penso, il problema ora è l'aggiornamento dei reference, infatti se
apro il gruppo di progetti in VB6 sotto reference ho una sfilza di
MISSING sulle DLL che ho rigenerato, in pratica se ho DLL2 che usa
DLL1 se ricompilo DLL1 il reference in DLL2.vbp non la vede più e
dovrei da visual basic togliere e ricreare il reference (almeno mi par
di aver capito), non esiste che si arrangi da solo ad aggiornarseli?
Ciao
Fritz

 di aver capito), non esiste che si arrangi da solo ad aggiornarseli?
Allora, mi pare di aver capito che ogni ricompilazione di DLL1 genera
un CLSID diverso che a quel punto non è più quello che c'era in
DLL2.vbp e per sistemare il problema bisogna aprire in VB6 DLL2.vbp e
riaggiungere il reference, in .NET c'è l'update reference che fa sto
lavoro possibile che in VB6 debba essere fatto a manina?
Ho trovato informazioni sul web che indicavano di usare la Binary
Compatibility ma non ho capito come dovrei usarla, è da flaggare ma
poi vuole per forza un percorso su cui controllarla e che gli do?
Ciao
Fritz

 poi vuole per forza un percorso su cui controllarla e che gli do?
Eh beh, � il classico "DLL Hell"...
Devi avere una versione di riferimento per ciascuna DLL, ossia una copia 
della stessa, con un'estensione diversa da DLL (es. ".cmp") in modo da non 
sovrascriverla per sbaglio, e impostarla una volta per tutte come file di 
riferimento per la binary compatibility nelle prop. del progetto.
Cos� facendo, non avrai la generazione di GUID diversi ad ogni compilazione.
Se hai le versioni originali delle DLL (quelle con cui il gruppo di progetti 
"funzionava") puoi provare ad usare quelle.
Bisogna poi anche stare attenti, negli sviluppi futuri, a non rompere la 
compatibilit� binaria, ad esempio modificando la "signature" di metodi 
pubblici, altrimenti ti ritrovi daccapo con i GUID cambiati (ma almeno VB6 
quando compili ti avvisa).
Ciao
Raf

 "funzionava") puoi provare ad usare quelle.
Fatto, rimpiazzato la compatibilita binaria in tutti i progetti,
ricompilato con il MakeFile.bat (da VB continua a rompere che non può
sovrascrivere DLL) e ora sembra andare tutto bene. Ho avuto solo
problemi con una variabile pubblica di tipo MDIForm che secondo lui
nelle DLL era definita come Object (probabilmente è un adattamento del
compilatore) comunque ho rimpiazzato anche quelle e tutto funziona.
Grazie, ciao
Fritz