Newsgroup: it.comp.lang.visual-basic
Titolo: aggiunta di dll al pacchetto di setup (INNO SETUP)

ciao a tutti,
per il mio prg sto usando ormai da anni il setupcompiler ISTOOL4  che usa il
motore di inno setup 4.
Siccome non sono molto esperto per crearlo la prima volta ho usato una
funzione/programma che partendo dalla cartella "support" che crea vb6
"traduceva" tutti i file di cui aveva bisogno INNO per creare l'exe
completo.
Adesso mi trovo nella condizione di dover aggiungere 3 dll
- shlwapi.dll
- wininet.dll
- VB6STKIT.DLL
al pacchetto iniziale.
Il problema č che non so ne dove (presumo nella cartella "sys") e con quali 
attributi devo includere queste .dll nel pacchetto (promptifolder, 
regserver, sharedfile ecc).
Qualcuno mi puň dare una mano?
Eventualmente qualcuno si ricorda quale programma crea il listato per INNO 
partendo dalla cartella di support?
grazie.
ciao
Samuele 

 Qualcuno mi puň dare una mano?
Ciao, la soluzione piů veloce č ricrearti il pacchetto con l'installer di 
vb, poi dai il file .lst che č stato creato a ISTool che ti costruisce il 
file per la compilazione con InnoSetup.
E' poi sufficiente posizionare il file per innosetup nella stessa posizione 
del file .lst e tutto dovrebbe funzionare.
Ciao
Stefano


Grazie mille Stefano,
già che ci sono ti volevo chiedere:
le 2 dll non hanno la proprietà "regserver" vuol dire che non devono essere 
registrate?
E' possibile che queste due dll siano già presenti in windows di default? 
perche ho provato l'exe (senza effettuare l'installazione) e tutto è 
funzionato senza problemi ma vorrei sapere se è così sempre, o solo "ho 
avuto fortuna" che quel pc aveva già le dll per motivi a me sconosciuti.
grazie
samuele 

 - VB6STKIT.DLL
La prima domanda da porsi è un'altra.
*Perchè* sei nella condizione di 'dover aggiungere' queste dll?
Hai una vaga idea di quello che fanno e del perchè vadano distribuite?
Io, che so cosa fanno (e ritengo che sia fondamentale conoscere le dll 
che si utilizzano), ho dei seri dubbi che tu sia 'obbligato' a 
distribuirle.
Ciao
Alberto
-- 
Ma noi no

Apri la finestra di dialogo "Riferimenti" e vedi a cosa è linkato il tuo
progetto, poi magari vai in "Componenti" e vedi quali activex usi.
Infine se usi delle API su dll che non fanno parte del core del sistema
operativo devi includere pure quelle nel setup.
L'utilità di creazione pacchetti di vb fa un po' cacare... include file
inutili.

 inutili.
Per mia cultura, potresti farmi UN esempio di file inutile inserito dal 
PDW di vb?


 si utilizzano), ho dei seri dubbi che tu sia 'obbligato' a distribuirle.
Grazie per l'interessamento.
Ti spiego la mia situazione.
Ho distribuito il mio prg ai miei collaboratori.
Ogni tanto devo aggiornarlo quindi vorrei evitare di fargli rifare tutta la 
procedura di installazione e vado quindi a sovrascrivere il vecchio exe e il 
vecchio mdb (travasando i dati).
chiaramente tutto funziona se non aggiungo nuovi componenti che richiedono 
una registrazione.
queste due dll (che, hai perfettamente ragione, non conosco) sono state 
aggiunte dal pacchetto di installazione dopo che ho implementato nel nuovo 
exe la possibilità di scaricare aggiornamenti (nuovo exe nuovo db ecc) da 
internet.
prima infatti non li avevo.
Grande scoramento ha fatto breccia in me :-) quando ho scoperto che il nuovo 
exe necessitava di queste due ulteriori dll e sto cercando di capire come 
posso fare per aggiornare l'exe senza dover rifare la procedura di 
installazione comprendente le due nuove dll.
Per questo ho chiesto se sono già comprese di default in win. In caso 
affermativo tutto dovrebbe funzionare (ci si tocca). Altrimenti vorrei 
capire come devo trattare le dll in modo tale da far funzionare tutto a 
dovere.
Spero tu abbia capito e che possa aiutarmi.
grazie.
Samuele 

 internet.
Parziale bugia.
Le dll non sono 'apparse' quando tu hai aggiunto una funzionalità, ma 
quando hai aggiunto i riferimenti a qualcosa, ocx o dll che sia.
Quando si aggiunge un riferimento, *prima* si deve verificare  quale 
sia la distribuibilità di questo, e le relative problematiche.
Inserire la roba 'sperando' che poi vada, è roba che va bene per i 
ragazzini al liceo che fanno il software per compilare la schedina, non 
di chi con il software ci lavora, e deve quindi garantire un livello 
minimo di decenza al prodotto e, non neghiamocelo, alla categoria degli 
sviluppatori, che inevitabilmente vengono sempre accomunati con il più 
coglione e mai col più bravo.
Ti posso solo dire che:
shlwapi fa parte di librerie di scripting che vengono installate con un 
upgrade di Internet Explorer, per cui basta che tu ponga come 
prerequisito che IE sia aggiornato.
VB6STKIT serve per il funzionamento del setup stesso di vb, quindi, è 
ovvio che venga inserita nel setup, ma non è concretamente distribuita.
Wininet è come shlwapi.
Ti faccio anche osservare che tutte le librerie di scripting, sono a 
rischio antivirus, nel senso che un antivirus 'silente' potrebbe 
inchiodartele senza avviso.


 inchiodartele senza avviso.
Il tuo messaggio mi ha illuminato. Nel senso che mi ha fatto capire che di 
VB6 non ne so una cippa di minchia.
Io non sono un programmatore. Ho solamente, qualche anno fa, incominciato a 
sviluppare un programma per la mia azienda che, anno dopo anno, è diventato 
sempre più grosso e importante fino a diventare parte vitale dell'azienda 
stessa.
Naturalmente nel corso degli anni ho continuato a svilupparlo ma ciò non 
vuol dire che sia diventato un programmatore, visto che il mio lavoro è 
tutt'altro. E' per questo che mi affido, nei momenti di ignoranza come 
questo, a persone moooooolto più esperte di me che sono così gentili da 
darmi una mano.
Mi piacerebbe molto programmare conoscendo perfettamente *tutto* quello che 
faccio ma vorrebbe dire cambiare lavoro e non posso certo permettermelo.
In effetti, come dici tu, le dll sono apparse quando ho inserito codice che 
"downloada" da internet trovato su un sito per programmatori.
Tagliato e ritagliato ora fa quello che voglio io ma non so se lo fa in 
*ogni* condizione.
Quindi, se ho capito bene, se l'utente ha IE aggiornato non ho bisogno di 
includere nel setup le dll incriminate (Wininet e shlwapi)
Dico bene?
grazie comunque per l'aiuto.
Samuele 

 PDW di vb?
MSVCRT40.DLL
OLEPRO32.DLL
e altri. Anche quando hai come riferimento ado, msado25[ o 27 o 36 o quel
cacchio che è].tlb non serve a una mazza.

 samuele
Ciao,
Albe V° ti ha già dato una esauriente risposta.
Vorrei sono integrare una cosa, quando distribuisci il tuo SW fai un setup, 
ma è piuttosto seccante rifare un setup completo quando devi solo aggiornare 
l'eseguibile ed eventualmente qualche componente.
InnoSetup da questo punto di vista è molto flessibile, si tratta solo di 
studiarci un po' su, praticamente quando installi per la prima volta il SW 
scrivi sul registro di sistema il path di installazione.
Quando devi aggiornare l'eseguibile (patch)  e/o qualche componente fai 
un'installazione con "dentro" solo i file che ti servono e destinazione (ad 
esempio per l'eseguibile o il db) il percorso indicato dal registro di 
sistema (ad esempio fai installare l'aggiornamento dell'eseguibile se e solo 
se è gia presente - magari una versione precedente - e così via)
Così la dimensione della pacth si riduce (tra i vantaggi tangibili), non 
devi far disinstallare la versione precedente e nel caso non lo faccia non 
c'è pericolo che venga installata in una directory differente etc.
Ciao
Stefano

 c'è pericolo che venga installata in una directory differente etc.
Effettivamente non avevo mai visto IS come possibilità per installare anche 
le patch.
Però il problema sarebbe:
come faccio a trasbordare i dati salvati nel vecchio db al nuovo db dato che 
non devono essere persi?
Adesso lo faccio con un piccolo exe che se ne occupa ma con IS?
grazie.
ciao
Samuele 

 cacchio che è].tlb non serve a una mazza.
Assolutamente no.
Il tlb è fondamentale, perchè garantisce che il tuo applicativo 
utilizzi una determinata interfaccia Ado, anche se sulla macchina 
target ne è installata una superiore (e quindi il setup non potrebbe 
aggiornarla).
Qui, piuttosto, c'è un bug del pdw per cui fallisce la registrazione, 
quindi viene consigliato, a scanso di problemi e per aiutare chi si 
intoppa con la distribuzione, di togliere tale riferimento. Ma 
occorrerebbe comunque essere consapevoli di quello che si sta facendo, 
perchè uno potrebbe aver bisogno proprio di quella determinata 
interfaccia Ado, per cui anzichè rimuovere il tlb basta modificare la 
sua modalità di registrazione.
In sostanza, prima di dire che un prodotto 'fa cacare', bisognerebbe 
verificare di sapere di cosa si sta parlando.
Spesso, quello che fa cacare è la preparazione dell'utilizzatore.
Come ho detto oramai fino alla nausea, c'è un grosso problema fra gli 
sviluppatori. Tutti si mettono a fare i programmini. Poi, ad un certo 
punto, arriva il terribile momento il cui il programmino deve girare su 
un altro computer. E si scopre che quel componente non è distribuibile, 
che quello non è compatibile con quell'altro, che quel sistema 
operativo non lo supporta, ecc...
Nascono le figure di merda, e alla fine si cerca di convincere il 
cliente, o chi per lui, delle cose più assurde, pur di pararsi il culo. 
Vedi i thread aperti da un certo Gabriele, a cui la 'softuer aus' ha 
raccontato della roba da far ridere i polli, tirando in ballo bug di 
windows o problemi di rete, per nascondere le magagne del proprio 
applicativo e relativo setup.


 applicativo e relativo setup.
Un buon programmatore è anche un buon sistemista, ricorda...


Forse mi sono perso qualche passaggio. Immagino che se trasbordi i dati dal 
vecchio db al nuovo, sul nuovo ci siano già dei dati inseriti e che vadano 
integrati con il pregresso.
Se così non fosse allora basta semplicemente non copiare il db, se cambia 
solo la struttura puoi -nell'eseguibile, al suo avvio- controllare la 
struttura ed eventualmente implementare i nuovi campi/indici/viste etc.
Spero di avere capito correttamente il problema.
Ciao
Stefano 

 Un buon programmatore è anche un buon sistemista, ricorda...
Assolutamente, è quello che dicevo.
E solo chi capisce molto poco di distribuzione e sistemi operativi può 
affermare che il pdw mette 'file inutili' nel setup, ricorda...



Ehm! Penso che questo fosse rivolto a me.
<CODA DI PAGLIA>
Io l'ho solo consigliato perchè è la via più breve per chi non sa usare 
InnoSetup.
</CODA DI PAGLIA>
Personalmente preferisco IS all'installer di VB ma è solo un gusto 
personale, ho usato pdw per anni ma quando ho provato inno l'ho subito 
trovato più flessibile, più semplice e più professionale, ma ripeto è IMHO!!
Ciao
Stefano 

 </CODA DI PAGLIA>
Niente coda di paglia. A me è sembrato un saggio consiglio.
Ciao


Metto un esempio pratico perché forse mi esprimo male:
Questo è lo script generato dal wizard di vb (fatto apposta per
l'occasione):
--------------------------------------------------------------------------
10 [Bootstrap]
20 SetupTitle=Installa
30 SetupText=Copia dei file in corso. Attendere.
40 CabFile=Progetto1.CAB
50 Spawn=Setup1.exe
60 Uninstal=st6unst.exe
70 TmpDir=msftqws.pdw
80 Cabs=1
90 [Bootstrap Files]
100 File1=@VB6STKIT.DLL,$(WinSysPathSysFile),,,7/15/00 1.00.00
AM,101888,6.0.84.50
110 File2=@VB6IT.DLL,$(WinSysPath),,$(Shared),8/5/98 1.00.00
AM,122128,5.0.81.69
120 File3=@COMCAT.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,6/1/98
1.00.00 AM,22288,4.71.1460.1
130 File4=@stdole2.tlb,$(WinSysPathSysFile),$(TLBRegister),,8/31/01 2.00.00
PM,17920,3.50.5014.0
140 File5=@asycfilt.dll,$(WinSysPathSysFile),,,8/19/04 4.39.04
PM,65024,5.1.2600.2180
150 File6=@olepro32.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,8/19/04
4.39.22 PM,83456,5.1.2600.2180
160 File7=@oleaut32.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,8/19/04
4.39.22 PM,553472,5.1.2600.2180
170 File8=@msvbvm60.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,8/19/04
4.39.20 PM,1392671,6.0.96.90
180 [Setup1 Files]
190 File1=@msado27.tlb,$(WinSysPath),,$(Shared),8/3/04 11.21.46
PM,81920,2.81.1117.0
200 File2=@Progetto1.exe,$(AppPath),,,9/5/05 5.24.07 PM,16384,1.0.0.0
---------------------------------------------------------------------------
Forse nei primi post mi sono soffermato a guardare i file di bootstrap,
comunque...
Riga 190: a parte che il wiz non mette $(TLBRegister), chemmenefaccio della
sola type library? ADO non è solo il file tlb, ma sono + file
(msado15.dll,msadomd.dll,msador15.dll,msadox.dll).
I file veramente da distribuire sono nei riferimenti del progetto:
- msvbvm60.dll
- stdole2.tlb
Come per ado non escludo che
comcat.dll,olepro32.dll,oleaut32.dll,asycfilt.dll non siano dei file
"conseguenti" a stdole2.tlb, ma per esperienza ho visto questi file
installati sul 100% delle macchine su cui ho installato applicativi scritti
in vb (anche perché le OLE automation sono partite con win95).
Tra le tante cose, non è mai capitato a nessuno, su alcune installazioni
WIN2k (soprattutto con macchine in dominio - ma credo la cosa sia
irrilevante) che il programma di installazione continuasse a chiedere il
riavvio della macchina senza poi fare niente dopo il reboot?
E dopo il wizard di vb non fa cacare...

Scusate se interrompo :-), ma secondo voi le devo includere quelle dll nel 
pacchetto:
- shlwapi.dll
- wininet.dll
grazie.
Samuele 

Samuele wrote:

Se le hai nei riferimenti...

 E dopo il wizard di vb non fa cacare...
Prova a mettere un componente di explorer in un setup di IS e a farlo 
girare su una macchina con una versione precedente di tale componente, 
e avrai lo stesso comportamento.
Oppure non metterlo, e il tuo app non andrà su macchine vecchie.
E' una scelta.
Chi sa cosa sta facendo, compie la scelta consapevolmente, adegua i 
prerequisiti esplicitati, e non ha problemi.
Chi fa avantiavantiavanti, avrà problemi tanto col pdw che con IS.
Chi invece assume atteggiamenti supponenti a priori, avrà il problema e 
poi accuserà lo strumento anzichè l'utilizzo che di tale strumento ha 
fatto.
Ciao


 regserver, sharedfile ecc).
la dll shlwapi viene installata da IE 4, non includerla nel setup ma
controlla solo che l'utente abbia installato la versione di IE corretta.
Da questo link puoi vedere la versione della DLL e chi la installa.
http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=shlwapi.dll&S=1&x=9&y=14
la wininet.dll direi dalla versione 5 di IE
http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=wininet.dll&S=1&x=6&y=14
invece la VB6STKIT.DLL serve solo al PDW, quindi se usi Inno Setup la puoi
anche non distribuire.
Se vuoi controllare la versione di IE puoi usare questo codice in
innosetup.
http://www.vincenzo.net/isxkb/modules.php?name=News&file=article&sid=2
ciao
-- 
Inno Setup Extension Knowledege Base
http://www.vincenzo.net/isxkb
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


mi prostro.
sei stato veramente gentile oltre che preciso.
grazie 1000
Samuele 

 Ciao
Ciao. 

 e continuerò a lurkare come ho sempre fatto da tre anni a questa parte.
Tu non hai postato alcun argomento supportato, ma solo contestazione su 
contestazione, senza un filo logico e senza alcun costrutto.
Fornendo oltretutto informazioni sbagliate all'OP. Questo non è bene.


Mah...

 Mah...
Concordo.


 Concordo.
:-)