Newsgroup: it.comp.lang.visual-basic
Titolo: Non distribuire Dll 'classiche'

Sto lavorando ad un progetto in cui il peso del setup è critico.
Siccome:
1) nel progetto non utilizzo alcun riferimento se non i 3 'automatici' (VBA,
VBRT, VBObj&Proc)
2) nel progetto non utilizzo alcun componente aggiuntivo
3) non ho CreateObject quindi nessun late binding
mi chiedevo se tutte le dll che sono nel pacchetto siano effettivamente
necessarie.
Mi sono fatto una passeggiata col Dependency Walker, e nell'albero delle
dipendenze del mio Exe e del Setup.Exe del PDW non ho trovato alcuna traccia
delle seguenti DLL, che vengono invece inserite dal PDW:
COMCAT.Dll
ASYCFILT.Dll
Ho generato un pacchetto eliminandole, e apparentemente gira sulle macchine
di test, ma come potete immaginare, dovendo andare a finire su qualche
centinaio di macchine in giro per l'Europa, i casi che si presentano sono
numerosi.
Morale: avete idea di cosa facciano le due dll citate, e se siano
effettivamente necessarie per un progetto che, a livello di dipendenze, è un
"hello world"?
Ciao
Alberto
-- 
"Tina, ta te tòta tinta un tac!"
"Te cat tac i tac, m'tac't un tac?"
"Me ca tac un tac a tè?
Tac'tel te l tò tac, tò!"

 dipendenze, è un "hello world"?
Credo (ma non m'impegno) che servano al programma che _esegue_ il setup.
Se il setup non è necessario (perchè non vi sono controlli "strani") un
programma gira con la sola MSVBVM60.DLL, anche direttamente dal CD. Sarei
quindi per affermare "Se un EXE fatto con VB non usa nulla in più
dell'ambiente di default", basta il runtime.

 ASYCFILT.Dll
Per la Asycfilt ho trovato questo, quindi non ti serve
DLL File: asycfilt or asycfilt.dll
DLL Name: Microsoft OLE DLL
Description: DLL Used by Microsoft OLE (Object Linking and Embedding)
System DLL: Yes
per l'altra fra poco....wait....
ciaociao

 VB non usa nulla in più dell'ambiente di default", basta il runtime.
Però MSVBVM60.Dll va registrata, o no?
Quindi un setup, anche minimo, ci vuole...


 Quindi un setup, anche minimo, ci vuole...
stante il fatto che il runtime di vb dovrebbe essere presente su quasi tutte
le macchine, eviterei il setup.
in alternativa, mi sembra che se il runtime è nella stessa directory
dell'eseguibile non sia necessaria la registrazione. se così fosse puoi fare
una distribuzione copiaincolla di exe+runtime.
--
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 puoi fare una distribuzione copiaincolla di exe+runtime.
Esatto. Su consiglio di Javalab ho messo il runtime nella radice del CD,
ovvero nella stessa zona che contiene il mio programma di avvio (VB che non
usa controlli particolari e che non fa partire alcun setup se non con un
click esplicito). Il tutto si autoavvia da AUTORUN.INF e non fa una piega
anche su macchine vergini. Ho provato su un Win 2003 Server appena
installato.

 dell'eseguibile non sia necessaria la registrazione.
E' tua supposizione o hai info al riguardo?
Potrebbe anche essere una buona soluzione...
Adesso provo deregistrando su qualche macchina la msvbvm60, e provo a
metterla nella cartella dell'exe.


 metterla nella cartella dell'exe.
La virual machine non mi sembra vada registrata, ma lo verifichi subito: 
fai un regsvr32 della dll: se ti insulta significa che non va registrata.
Ancora una volta poi ripeto che il Depandency Walker e suoi simili non 
riescono a mostrare le dipendenze a DLL ActiveX (quelle di VB per 
intenderci).
Poi la settimana scorsa GbC| mi ha mostrato un programmino che 
utilizzava un ocx, e questo si registrava all'avvio dell'exe.
Non ho guardato come faceva ne gliel'ho più chiesto (a occhio direi che 
si limitava all'avvio a chiamare la DLLRegisterQualcheCosa dell'ocx).
Prova a vedere lui se ti risponde :)
Ciao