[VB6] Exe --> dll --> mswinsck.ocx

[conger.conger]

Ciao a tutti, scrivo per chiedervi aiuto relativamente allo sviluppo di una DLL in VB6.
Si tratta di una progetto per il quale avevo già postato una richiesta nel forum, Oregon mi aveva dato una dritta grazie alla quale avevo completamente risolto (link).
Adesso sono passato alla fase di deployment/distribuzione e sono spuntati fuori nuovi problemi.

Ho scritto una DLL (che per comodità possiamo chiamare INTERMEDIA.DLL) che ha un reference a MSWINSCK.OCX (Winsock è linkata come reference non aggiunta come component).

La DLL ha un solo metodo che sfrutta alcune funzioni di Winsock per chiamare una pagina html, eseguire il parsing del testo ricevuto e restituire una sottostringa opportunamente elaborata.

Dal momento che tale DLL deve essere utilizzata da altri sviluppatori in altri ambienti, ho realizzato uno standard exe per fare i test (per comodità possiamo chiamarlo CLIENT.EXE). L'exe è stato realizzato in modo isolato rispetto alla DLL; intendo dire che è contenuto in un progetto separato e distinto e che ha tra i reference INTERMEDIA.DLL.

Grazie all'aiuto di Oregon (), tutto funziona perfettamente nell'ambiente di sviluppo, sia se eseguo il codice dentro Visual Studio sia se compilo CLIENT.EXE e INTERMEDIA.DLL e li eseguo con Visual Studio chiuso (naturalmente in questo secondo caso devo registrare INTERMEDIA.DLL prima di eseguire CLIENT.EXE).

Il problema nasce quando provo ad eseguire i test in una macchina diversa da quella di sviluppo (si tratta di un pc con win xp e null'altro installato).
Naturalmente gli step per il deployment sono identici a quelli eseguiti nella workstation di sviluppo:
- copia dei due file compilati (CLIENT.EXE e INTERMEDIA.DLL)
- copia di MSWINSCK.OCX nella cartella C:\WINDOWS\system32\ (il pc di deployment non ha la libreria)
- registrazione di MSWINSCK.OCX con regsvr32
- registrazione di INTERMEDIA.DLL con regsvr32
- esecuzione di CLIENT.EXE

Tutti gli step tranne l'ultimo vengono eseguiti senza ricevere alcun errore, l'esecuzione di CLIENT.EXE produce il seguente errore:
"Run-time error '429': Activex component can't create object"

Di seguito alcune prove che ho fatto per provare a capire dove potrebbe essere l'errore:

Ho scritto uno Standard EXE che chiama direttamente i metodi di Winsock e ha come reference solo MSWINSCK.OCX. Compilato, copiato ed eseguito nel pc di deploy. Funziona tutto senza errori.

Ho scritto uno Standard Exe e una DLL di prova che espone un solo metodo che esegue la somma di due interi. L'eseguibile ha come reference la dll, istanzia l'oggetto, chiama il metodo per la somma e visualizza il risultato della somma. Compilato, copiato ed eseguito nel pc di deploy. Funziona tutto senza errori.

In Visual Studio ho provato due differenti modi di aggiungere il reference alle librerie:
- registrare le DLL nel sistema, aprire il menù Project->References e scegliere le DLL dalla lista delle DLL disponibili;
- aprire il menù Project->References, fare click sul pulsante "Browse", navigare il file system fino al punto in cui è salvato il file della DLL, selezionare il file della DLL.
Tutti e due i metodi funzionano correttamente nella workstation di sviluppo ma non funzionano nel pc di deploy.

Grazie in anticipo
Ciao

[gibra]

Il tuo metodo 'casalingo' è completamente sbagliato.
L'unica cosa certa è che rischi combinare seri guai nel computer di destinazione, che se è il tuo, passi, ma se è di un cliente...

Il deploy lo si deve fare solo con un apposito SETUP creato con un installer (vedi ad esempio www.innosetup.com).

[conger.conger]

Ciao Gibra, innanzi tutto grazie mille per l'intervento e per i suggerimenti.

Ho già provato ad utilizzare un installer, solo che anzi che innosetup ho utilizzato quello fornito con Visual Studio, si chiama "Package & Deployment Wizard".

Non ho aggiunto i dettagli sui test fatti con PDW per non appesantire troppo il post, li riassumo brevemente ora:
- la procedura di generazione del file di setup va a buon fine nel caso di INTERMEDIA.DLL;
- la procedura di generazione del file di setup fallisce nel caso di CLIENT.EXE.

Devo confessare che mi aspettavo questi risultati, l'uso di un installer può essere comodo, può automatizzare le operazioni di deployment, può diventare necessario nel caso di architetture e procedure di rilascio complesse; purtroppo difficilmente può risolvere un errore che probabilmente è interno all'applicazione.

Non solo, dal momento che INTERMEDIA.DLL deve essere utilizzata da altri sviluppatori, ciò che essi vogliono poter fare è registrare la DLL nel modo più semplice, cioè utilizzando regsvr32.
Lanciare un file di setup per registrare una singola DLL da alcuni sviluppatori è considerato ... "inutile sovrastruttura".

Aggiungo un'altra considerazione, i test eseguiti con uno Standard Exe e una DLL un po' più semplice di INTERMEDIA.DLL hanno successo anche se il metodo di deployment è quello che tu chiami casalingo.

Per finire ti chiedo quali possano essere i guai generati nella macchina di destinazione, alla fine di ogni test ho de-registrato le DLL, cancellato tutti file e fatto una scansione con CCLeaner, il quale non ha rilevato nessuna anomalia nel registro di sistema. Quale altro danno potrei aver causato?

Grazie ancora e ciao

[gibra]

Ti rispondo per pura cortesia, dato che questo è un forum sul linguaggio, non sulle installazioni, l'argomento è logicamente OT.

Come più volte raccomandato 'in giro' per il web, il PDW è assolutamente da NON usare, perchè è obsoleto, inefficiente, limitato e causa di seri problemi.
Non è in linea con le attuali versioni di Windows (Vista, Windows 7 e Windows 8) in cui le regole del gioco sono radicalmente cambiate rispetto alle precedenti versioni.
Non è un caso se ti ho segnalato InnoSetup.

I setup vanno fatti perchè, al contrario di ciò che pensano alcuni sviluppatori, non basta registrare una dlll per usarla.
Vi sono altre considerazioni che è necessario tenere presente quando si distribuisce un'applicazione indipendentemente dal numero di DLL/OCX che necessita.

Gli sviluppatori che ritengono la registrazione un 'inutile sovrastruttura' dimostrano le scarse conoscenze che hanno sulle regole del deployment.

Quando si installa un componente COM utilizzando la corretta procedura (SETUP) il sistema imposta una serie di proprietà/impostazioni tra cui quella che incrementa un contatore che indica quante applicazioni utilizzano quel determinato componente.
Solo i SETUP (creati con installer seri) dispongono di 'permessi particolari' per cui ogni operazione viene fatta in modo trasparente all'utente ed assicura la corretta registrazione dei componenti COM indipendentemente dalla configurazione computer/utente che essi si trovano da affrontare, perchè 'loro' sanno come comportarsi di conseguenza.

Tradurre tutto ciò all'uso di un banale comando eseguito con regsvr32.exe, è a dir poco riduttivo, oltre che sbagliato.

Se non si seguono le regole, si rischia di creare problemi non solo in fase di installazione, ma altrettanto in fase di rimozione!


Come vedi, questa 'inutile sovrastruttura' (come la definisci tu) non è poi così tanto inutile.

Non mi dilungo sui seri problemi causati da una procedura di registrazione 'fatta a mano', non è questo il luogo, e comunque ho già espresso divesre considerazioni su questo e altri forum (fai una ricerca se vuoi approfondire).