Beh ... anche su questo ho dei dubbi ... ovviamente dipende dall'essere umano ... altrimenti, paradossalmente, si potrebbe dire che il suo tool lavora meglio di come farebbe lui ...

... e facendo anche il caffè a richiesta ...

Mi dispiace, ma diffido da questo tipo di prodotti ...
E' evidente che una affermazione del genere è un po' "forte" e si presta a facili ironie. Ma chi è davvero interessato alle potenzialità di VB Migration Partner, sul sito www.vbmigration.com può trovare la documentazione completa, articoli di KB, video, ecc. e giudicare da solo. Abbiamo anche numerosi sample VB6 e la corrispondente versione VB.NET migrata, e garantiamo che neanche una riga di quest'ultima è stata "aggiustata" dopo la migrazione.

Da quel che mi risulta, siamo gli unici produttori di un tool di conversione (non solo da/a VB) ad aver adottato una simile "trasparenza". Forse siamo più incoscienti dei nostri concorrenti, oppure siamo fiduciosi nel fatto che possiamo supportare le nostre affermazioni con esempi concreti.

D'altra parte, mi rendo conto che non è possibile chiedere a chi è solo vagamente interessato al tema della migrazione di leggere centinaia di pagine. Per questo motivo mi limiterò a un paio di esempi concreti per cercare di dare un po' di forza alle mie affermazioni.

1) BYREF PARAMETERS
Com'è noto, per default i parametri dei metodi sono passati con ByRef. Passare dei parametri by-reference in VB.NET è fortemente sconsigliato perchè può portare ad errori di compilazione e di esecuzione. Ad esempio, passare un oggetto ADODB.Field a un parametro ByRef spesso causa un errore al ritorno dalla procedura, ma potrei fare numerosi altri esempi.

Un developer coscienzioso dovrebbe quindi cercare di trasformare in ByVal tutti i parametri che in VB6 sono passati by-reference senza un motivo reale, ma per farlo deve prima controllare che il parametro non sia mai modificato nel metodo, o non sia passato ad altri metodi che lo modificano. Un controllo del genere richiede da pochi secondi ad alcuni minuti per ciascun parametro definito nel programma, che in una applicazione da 100mila righe significa spendere giorni e giorni su questo dettaglio. Nel mondo reale nessun developer lo farà mai, mentre VB Migration Partner può farlo in pochi secondi grazie al suo code analysis engine, evitando decine e decine di potenziali malfunzionamenti.

2) SEGNALAZIONE DI BUG "OSCURI"
Nei due anni di lavoro su questo tool abbiamo migrato qualche milione di righe di codice VB6 e ci siamo resi conto di numerosi bug (o comportamenti anomali, se si preferisce) ignoti alla stragrande maggioranza di developer anche esperti, incluso noi stessi prima di queste scoperte. Ecco un esempio semplice semplice:

Dim buffer As String
buffer = Space(256)
' La API GetSystemDirectory restituisce il numero di caratteri del risultato
buffer = Left(buffer, GetSystemDirectory(buffer, 256))

Il codice precedente funziona in VB6 ma non in VB.NET. VB Migration Partner correttamente segnala questo problema (che si verifica con un centinaio di Declare), ma quanti developer .NET anche esperti lo conoscono?

Potrei fare molti altri esempi, ma spero queste due note siano sufficienti a insinuare qualche dubbio e magari a sospendere il giudizio fino a quando sarà disponibile una versione pubblica. (PS: no, il caffè non lo fa...)

Francesco Balena
Code Architects Srl