Newsgroup: it.comp.lang.visual-basic
Titolo: Problemi di compatibilità

Ciao.
Scusate se torno su un argomento che sarà stato trattato migliaia di volte
ma come al solito, quando credo di aver capito tutto... ecco che qualcosa
rovina le mie certezze!
Diciamo che ho fatto una DLL per la gestione dell'accesso ai dati. Select,
Update, Insert, Delete... le solite cose insomma.
Questa DLL l'ho usata in parecchi OCX che poi ho messo nella mia
applicazione e ovviamente anche nell'applicazione stessa.
Sabato ho fatto una piccolissima modifica alla DLL. Niente di stravolgente.
E mi sono detto... Adesso compilo con compatibilità e tutto funzionerà senza
problemi... Palle!
Diciamo che ho una struttura di cartelle fatta cosi:
X:\NomeDLL\VersionePrincipale\SottoVersione
Quindi se la mia dll si chiama Bsn.DLL mi trovo:
- X:\Bsn\01.00 che contiene l'ultima versione della DLL (quella che registro
per usare nelle applicazioni).
e anche
- X:\Bsn\01.00\01.00.001 che contiene la versione 1.0.1 della mia DLL.
Quando ho compilato la nuova versione 1.0.2 ho impostato la compatibilità su
X:\Bsn\01.00\01.00.001\Bsn.dll e ho creato la nuova versione direttamente in
X:\Bsn\01.00 in modo da sovrascrivere la vecchia e da non dover registrare
nulla di nuovo.
Poi ovviamente ho fatto una copia della nuova DLL anche in
X:\Bsn\01.00\01.00.002
A questo punto ho riaperto il progetto principale e... Errore! La classe non
supporta l'automazione o l'interfaccia prevista!!!
Sia quando creo l'oggetto nel progetto principale, sia quando imposto la
proprietà Connection dei miei OCX dove praticamente viene creata un'istanza
della DLL.
La cosa interessante è che se aggiungo il progetto del mio OCX (creando un
gruppo di progetti) tutto funziona correttamente.
Ho provato a deregistrare e riregistrare la DLL, ma nulla cambia.
Sicuramente se ricompilo tutti gli OCX dopo aver compilato la DLL tutto
riprenderà a funzionare, ma vorrei solo capire perche' succede questa cosa,
nonostante io abbia mantenuto la compatibilità della DLL.
Grazie a tutti.
Ciao
-- 
Skysurfer

e tutto funzionerà senza problemi... Palle!
Se e' compatibilita' di progetto *NON* puo' funzionare, devi usare
la compatibilita' binaria.
-- 
ciao, hal

 la compatibilita' binaria.
Non ho mai capito a cosa serva la compatibilità di progetto.
In quali casi è utile?
Ciao

In quali casi è utile?
Me lo sono chiesto spesso anch'io, mi piacerebbe tanto saperlo.
-- 
ciao, hal


Quando stai facendo debug di una libreria non piu' compatibile, e hai aperto
i sorgenti sia di questa che di una applicazione client di prova; imposti
compatibilita' progetto e togli il percorso della vecchia DLL incompatibile.
Il vantaggio e' che quando imposti sul progetto client il riferimento al VBP
della libreria, anche se continui a stoppare e riavviare il debug di
quest'ultima i vari CLSID temporanei vengono mantenuti sempre uguali, e
quindi non hai la fastidiosa necessita' di reimpostare tutte le volte il
riferimento di cui sopra.
Questo vale in particolare quando i due progetti sono aperti in due istanze
separate di VB (la modalita' di debug che preferisco) ma penso valga anche
per una istanza di VB con il gruppo di progetti
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

Quando stai facendo debug di una libreria non piu' compatibile,
Uhm, perche' dovrei mettere in circolazione una libreria non piu'
compatibile, con il rischio di creare casino fra gli utenti?
Se proprio dovessi rompere la compatibilita', cambierei il nome del
file e farei i test sempre in compatibilita' binaria.
Mi pare di capire inoltre che la compatibilita' di progetto possa
essere impiegata solo nel debug dall' IDE.
Insomma, penso che se non l'avessero messa sarebbe stato meglio.
-- 
ciao, a


Allora... ho fatto piccole modifiche al codice interno dei metodi e ho
aggiunti due metodi nuovi (proprio per non modificare l'interfaccia dei due
metodi già esistenti).
In pratica avrei voluto aggiungere un parametro ai due metodi esistenti, ma
per evitare (almeno così pensavo) casini con la compatibilità ho preferito
lasciare inalterati i due metodi esistenti, aggiungerne due nuovi con il
parametro in più e richiamare i due metodi esistenti impostando una
variabile a livello di modulo.
Alla fine ho compilato con compatibilità binaria (anche io non uso mai
quella di progetto) e comunque la compatibilità credo che me l'abbia
mantentua, altrimenti me l'avrebbe segnalato.
Grazie, ciao!
-- 
Skysurfer

 file e farei i test sempre in compatibilita' binaria.
Il cambiare nome e' una scelta *di distribuzione* che posso anche
condividere, ma non ti facilita in alcun modo la fase di debug.
Fai conto di dover modificare una DLL che sai non essere piu' compatibile, e
sulla quale devi intervenire in piu' punti (e per la qual cosa magari
impiegherai alcuni giorni)
Se togli la compatibilita' del tutto, hai i fastidi che tutti sappiamo, se
cambi nome e lavori in compatibilita' binaria, per contro, ti crei un
disagio da solo, perche' in tutta la sessione di modifica potresti rompere
ulteriormente la compatibilita' e costringerti a ricompilare varie volte
solo per avere un binario di riferimento
Potresti obiettare che con un lavoro ordinato faresti tutte le modifiche di
interfaccia in un colpo solo e poi passeresti al resto (per stabilizzare
subito una versione di riferimento) ma il fatto e' che, una volta rotta la
compatibilita', non ha piu' importanza se le classi cambiano poco o tanto o
del tutto; succede quindi, perlomeno a noi, di approfittare dell'occasione
per toglierci tutti i "sassolini nelle scarpe" e sistemare strada facendo
quelle piccole cose che fino a quel punto si erano aggirate diversamente
proprio per non rompere la compatibilita'
Ecco quindi che il modo piu' pratico e' proprio la compatibilita' di
progetto (anche cambiando nome), in modo da lavorare a tutti gli effetti
senza compatibilita' ma senza i fastidi di dover continuamente ripristinare
i riferimenti nelle applicazioni di test, e passare alla binaria solo prima
di distribuire


 vecchia e da non dover registrare nulla di nuovo.
[SNIP]
Una cosa che non sono sicuro di aver capito e' se, al momento della
compilazione, la DLL in 01.00.001 e quella in 01.00 erano esattamente la
stessa versione oppure la prima (quella che hai usato come riferimento) era
una versione compatibile e successiva alla seconda
In questo caso, se invece gli OCX erano stati compilati contro la seconda,
potrebbe succedere qualche impiccio, sebbene le tre versioni siano tra loro
compatibili...




Grazie per la "lucidazione" ;-)
-- 
ciao, hal

 Ciao
ciaociao

mantentua, altrimenti me l'avrebbe segnalato.
Salta pure al post di Luca delle 11.41 che potrebbe essere la risposta
che cerchi.
-- 
ciao, hal

 Ciao
La versione era identica. Io di solito compilo in 01.00 e poi copio la DLL
appena compilata in 01.00.001 (o .002 ecc a seconda del numero di
revisione).
Qui comunque continua a non funzionare, anche se aprendo il progetto dal pc
di un mio collega non dà nessun problema.
Boh... proverò a ricompilare tutto, ma mi viene un po' da piangere.
Grazie.
Ciao
-- 
Skysurfer