[VB6] Runtime error 48 aggiornando una libreria DLL

[sbirropg]

Ciao a tutti,
la mia applicazione, scritta in VB6, utilizza una DLL scritta in C, sviluppata in ambiente Dev-C++.
La DLL viene posta nella cartella di sistema appropriata in base al tipo di sistema operativo dal programma di setup.
La funzione di update del programma rinomina la DLL da aggiornare secondo lo schema [nome DLL]-[versione].OLD e pone nello stesso percorso la nuova DLL.

Al di la' della bonta' di questo sistema di aggiornamento, sul quale accetto suggerimenti, il problema che ho riscontrato (un paio di volte su una base di alcune centinaia di utenti) e' il seguente: su sistemi Windows 7 (sia a 32 che 64 bit) l'applicazione fallisce al momento di richiamare una funzione contenuta nella DLL con errore di runtime 48 ("File non trovato: mylib.dll"), mentre la DLL e' in realta' tranquillamente dove deve essere.
In realta' questo errore, piu' che alla mancanza della DLL, dovrebbe essere legato a un errore nel suo caricamento.
Il problema infatti persiste anche copiando la DLL direttamente nella cartella in cui si trova l'eseguibile o eliminando manualmente la DLL corrente ed eventuali vecchie versioni e ripristinandola.
Il problema si risolve disinstallando l'applicazione, riavviando il PC e reistallando l'applicazione, soluzione tentata come "ultima spiaggia" e che sfugge dalla mia comprensione, visto che la DLL non e' ActiveX e quindi non e' interessata da registrazioni e simili.

In rete ho trovato alcuni suggerimenti che non si applicano al mio caso o che comunque ho applicato senza successo:
- compilare la DLL in versione release anziche' debug quando si utilizza VC++ 2008
- utilizzare lo stesso name casing per i nomi delle funzioni sia nella DLL che nelle istruzioni "Declare" nel codice VB
L'unico aspetto che ho tralasciato, ma che dovrebbe essere ininfluente, e' che nella clausola "Lib" della istruzioni "Declare" ho indicato solo il nome della libreria ("mylib") senza includere l'estensione ("mylib.dll").

Il problema sembra limitato e facilmente aggirabile, ma vorrei sapere se e' stato riscontrato anche da altri e quale e' secondo voi il suo reale motivo, in modo da poterlo risolvere con cognizione di causa.

Grazie,
Riccardo

[gibra]

Ti rispondo, ma sappi che questo argomento è assolutamente OT su questo forum perchè non riguarda il linguaggio di programmazione, ma la configurazione, installazione ed aggiornamento dei programmi.

Se per 'update' intendi semplicemente da programma 'copiare' la DLL rinominando quella vecchia allora ecco spiegato il motivo.

Prima di tutto, da Windows 7 la musica è completamente cambiata.
Affinché un setup o un aggiornamento abbia successo e funzioni è non è sufficiente avere i permessi di amministratore.
Il discorso è complicato e contorto, ed ha a che fare con l'owner (il proprietario) che spesso non è l'utente che ha installato il programma.
Ti consiglio di documentarti in merito.

Il solo modo per aggiornare con successo un programma è prevedere un setup, realizzato con un'installer, esattamente come si fa il setup per l'installazione.

Il codice usato, non c'entra niente.

[sbirropg]

Mi permetto di dissentire sull'OT del post.

Da regolamento:

Sono discussioni valide quelle che riguardano errori o comportamenti anomali del codice sorgente scritto, o problemi generali con ambienti di sviluppo, compilatori, SDK e altri strumenti affini.

Il mio problema riguarda esattamente un errore di runtime di codice sorgente scritto in VB6 che viene sollevato ad una specifica istruzione e incidentalmente sembra riguardare una questione di distribuzione, ma potrebbe anche esserne del tutto scorrelato. La descrizione del meccanismo di installazione e pseudo-aggiornamento è stata inserita per rendere chiaro il contesto in cui si verifica il problema.

In ogni caso ringrazio per il suggerimento, controllerò la questione quando il problema si riverificherà ed anzi, se hai a disposizione dei link sull'argomento, se già hai incontrato difficoltà del genere, li leggerei volentieri (anche in inglese); la tematica è relativamente nuova e vasta e saperne di più è utile a prescindere dalla situazione specifica.

Saluti,
Riccardo

[sbirropg]

Scrivo solo per risollevare la mia richiesta di informazioni riguardo all'errore in tema; se qualcuno lo ha incontrato in qualsiasi contesto, non necessariamente legato all'aggiornamento manuale (o comunque non tramite installer) di una DLL, mi farebbe piacere sapere se e come lo ha risolto.

A titolo di curiosita', il termine "libreria DLL" che è stato aggiunto al titolo del post è un classico esempio di acronimo ridondante.

[sbirropg]

Risollevo il post dopo molto tempo perche' solo da pochi giorni ho trovato la soluzione al problema e vorrei condividerla in quanto e' stato molto difficile trovare documentazione al riguardo.

L'errore menzionato non dipendeva in nessun modo dal meccanismo di distribuzione e aggiornamento. Era invece causato dal fatto che la DLL, sviluppata in ambiente Dev-C++, e' compilata come DLL utilizzando l'utility dllwrap. Le DLL generate con questa utility hanno seri problemi se il sistema operativo le alloca nello spazio di memoria del processo che le carica a un "base address" diverso da quello predefinito. Questo e' probabilmente uno dei motivi per cui dllwrap e' deprecata, ma anche la nuova versione del Dev-C++ (Orwell Dev-C++) continua ad utilizzarla.

Qui e qui la documentazione del problema e un possibile workaround.
Per eseguire il debug di questo problema, ma in genere di ogni errore in fase di caricamento di una DLL, mi e' stato molto utile utilizzare l'opzione di profiling del software Dependency Walker, che indica in modo preciso la causa del mancato caricamento.

Come nota a margine, sconsiglio a chiunque l'uso del Dev-C++ per sviluppare DLL da utilizzare in applicazioni VB; l'alternativa, di livello nettamente superiore, e' il Visual Studio Express 2012, che dovrebbe essere gratuito anche per usi commerciali.

Chiedo a chi di dovere di marcare in modo appropriato il thread come risolto, se necessario.

Riccardo