COM Interoperability…some tricks ;)

Dovendo sviluppare in questi giorni un wrapper COM per una mia libreria, ho reinstallato su una mia macchina virtuale il mitico lo storico ambiente di sviluppo Visual Basic 6.0. Che tempi! :)

Beh, ho sempre sentito parlare, anche nei vari esametti che ci sono in giro di questa COM Interop, a dire il vero l’avevo già usata “al contrario” (ovvero usare oggetti COM da .Net), ma non mi era mai successo di dover usare .Net da COM.

E così un bel territorio nuovo, ma non sapevo che avrei trovato due insidie *carine*.

Prima Insidia

Qualcuno di voi, leggendo fin qui magari si è chiesto: “ma scusa, dato che si possono utilizzare oggetti COM in .Net perchè non ha utilizzato direttamente il suo wrapper, una volta costruito, direttamente in VS? Perchè vuole farsi del male installando VB6?”

Ve lo siete chiesti vero? :)

Amo il realismo e quindi volevo provare nell’ambiente “vero”.

No, non è per quello. Ci mancherebbe. La risposta è più semplice: non si può. (!)

Cioè se create una classe .Net, la wrappate COM e tentate di usarla in .Net come COM, non si può fare. Punto.

Seconda Insidia

Beh, insomma nulla di difficile, la cosa più lunga sarà installare VB6 e fare un progettino idiota di prova.

Vero.

Ma solo per la prima prova. (ecco svelati perchè tutti i milioni di esempi che si trovano sulla Rete *comunque* funzionano…la prima volta…)

Leggerete che occorre creare un Interfaccia (possiamo anche farla creare in automatico con l’attributo ClassInterface), poi una bella classe che implementa quell’interfaccia, esposta in COM tramite ProgId e Guid

Nulla di nuovo, sono stati scritti due esempi completi: uno più immediato e l’altro molto utile per approfondire…

Cosa non dicono?

Beh, fatte le vostre prove *probabilmente* vorrete cambiare l’interfaccia aggiungendo, sostituendo metodi, no?

E via, a botte di regasm a far rigenerare il tlb (Type Library)…e a ricaricarla come referenza da VB6.

E li cominciano i primi dubbi amletici: non cambia assolutamente nulla. Anzi cominciano ad uscirvi errori dal 429 al 438 ActiveX che, ve la faccio breve, significano che la vostra classe non implementa i metodi richiesti.

Posto che voi invece li abbiate sviluppati (altrimenti avete un altro problema…:D), come fare in modo che la rigenerazione del tlb corrisponda effettivamente ad un refresh delle referenze?

Semplice, una volta che si sa: occorre incrementare la versione del vostro COM wrapper.

Terza Insidia

Ricordatevi, in fase di generazione/rigenerazione del tlb che, se avete utilizzato delle dipendenze, dovete aggiungere l’opzione /codebase, così include tutte le dipendenze nell’esportazione.

Ora siete pronti per il vostro viaggio nel mondo unmanaged :)

That’s all folks!

Print | posted @ lunedì 13 settembre 2010 20:55

Comments have been closed on this topic.