Le perplessità sono più che giustificate. Del resto, quando qualche azienda mi chiede se il VB Migration Partner può essere adatto a migrare la loro specifica applicazione - ovvero quando si passa dal generale al particolare - preferiamo fare un assessment per vedere se conviene maggiormente usare il nostro tool oppure puntare a una riscrittura completa.

Uno dei principali problemi nella migrazione di una applicazione è proprio la presenza massiccia di controlli ActiveX di terze parti. Noi riusciamo a migrarli (anche se occorre lanciare una utility separata che crea il codice vb.net per il wrapping) ma ovviamente possiamo solo riutilizzare il controllo ActiveX originario tramite COM Interop. COM Interop ha alcuni problemi, specie con i controlli complessi come le griglie.

Comunque, anche supponendo di dover buttare il controllo ActiveX originale, sostituirlo con un controllo .NET più o meno equivalente e riscrivere tutto il codice che riguarda il controllo, val la pena di sottolineare che è un lavoro che andrebbe fatto in ogni caso, con o senza tool di migrazione. Noi pero' supportiamo una tecnologia tale che chiunque può scrivere una propria classe wrapper per fare in modo che i metodi/proprietà originale siano mappati sui membri del nuovo controllo. In questo modo già oggi supportiamo tutti i 60+ controlli forniti con VB6, ad eccezione di OLE Container e DataRepeater, un risultato che Upgrade Wizard non ha raggiunto neanche dopo otto anni di gestazione.

I nostri piani a medio termine, tuttavia, sono di offrire man mano le classi di mappin per i principali controlli di terze parti utilizzati in VB6, ad esempio quelli della Sheridan. Non è un task prioritario per noi al momento, ma potrebbe essere il "sotto-prodotto" di conversioni fatte per aziende italiane e straniere. Creare una classe di mapping per un controllo di media complessità richiede 1-3 giorni e potrebbe addirittura crearsi un "marketplace" in cui gli stessi utenti regalano o vendono cio' che hanno realizzato.

Molto probabilmente metteremo a disposizione una versione "community" del prodotto, con alcuni limiti riguardo la dimensione e le feature del programma VB6 da migrare, ma chiunque potrà testare il tool prima di acquistarlo e magari scrivere quelle classi di mapping di cui sopra.

Ci tengo anche a sottolineare che sul sito www.vbmigration.com stiamo riversando tantissima documentazione sulla migrazione che non è strettamente correlata al nostro prodotto. Nella sezione "Resources" è possibile trovare tutte (ma veramente TUTTE!) le scoperte sulle macro e micro-differenze tra i due linguaggi. Non appena rilasceremo la versione 1.0 faremo lo stesso per i controlli VB6 e Windows Forms, i problemi di COM interop, ecc.

Buona parte di quel materiale è assolutamente inedito ed è frutto del nostro lavoro in questi due anni. Stiamo rendendo pubbliche queste informazioni per due motivi: il primo (ovvio) è dimostrare che conosciamo l'argomento meglio di chiunque altro, l'altro è che comunque non ho dimenticato che da oltre 20 anni faccio lo scrittore/divulgatore e trovavo vergognoso che nessuno avesse affrontato prima l'argomento "migrazione" con sistematicità e andando oltre i soliti luoghi comuni.

Capisco anche i tuoi dubbi sul perchè Microsoft non abbia saputo o voluto creare un prodotto simile. La risposta è troppo lunga e inoltre gli accordi di NDA mi impediscono di approfondire troppo l'argomento. Però una cosa è certa: nessuno in Microsoft e tra gli "esperti IT" (incluso il sottoscritto) immaginava che a 6 anni dalla introduzione di .NET ci sarebbero state ancora tante aziende e tante applicazioni ancora da migrare.

PS. Non conosco pero' il tuo real-name...ma mi fa piacere che eri in Infomedia ai bei tempi.