[VB6] Compatibilità con Vista ed eventuale conversione

[fbalena]

A scanso equivoci, la mia frase

"... è una affermazione forte che si presta a facile ironia"

si riferiva alla affermazione che faccio nel mio blog sulla potenza del programma. A rileggere la mia risposta potrebbe sembrare che mi stessi riferendo invece alla frase di Oregon che avevo quotato all'inizio del post.

Non intendevo fare ironia su quest'ultima, e infatti non l'ho fatta. Ho solo cercato, con due brevi esempi, di "dimostrare" che la mia affermazione originaria, per quanto forte, aveva qualche solida base.

-- Francesco

[oregon]

Originariamente inviato da fbalena
A scanso equivoci

In effetti, avevo l'equivoco poteva esserci ... chiarito ...

Ho solo cercato, con due brevi esempi, di "dimostrare" che la mia affermazione originaria, per quanto forte, aveva qualche solida base.

Grazie per questo tuo chiarimento, Francesco, ma la mia "età" (ed esperienza con una moltitudine di "wizard di conversione") mi suggerisce di testare a fondo certi prodotti, mettendo da parte, per un attimo, le affermazioni dei produttori ...

Quello che immediatamente viene da chiedermi è, come mai, la MS stessa non abbia migliorato in maniera sostanziale il proprio wizard per portarlo ai livelli di efficienza di cui parli ... forse non ha voluto, forse non ha potuto ... resta comunque la perplessità.

Per quanto riguarda il (grande) problema della migrazione, penso che il maggior numero di questioni si abbia sulla migrazione di codice che prevede controlli di terze parti (oppure controlli obsoleti). In quel caso, la migrazione non puo' avvenire al 99% a meno che, in quella percentuale, NON vengano considerate le operazioni "impossibili" ... ma convertire il 100% del convertibile, tranne quello che non si puo' convertire, farebbe sorridere ...

In ogni caso, buon lavoro, in bocca al lupo e facci sapere quando tutto sarà pronto.

P.S. La mia è una critica costruttiva ... del resto ci conosciamo da tempo (... forse ricordi Ponsacco e il pranzo in cui e' nato il numero 0 di VBJ ... )

[fbalena]

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.

[oregon]

Originariamente inviato da fbalena
... preferiamo fare un assessment per vedere se conviene maggiormente usare il nostro tool oppure puntare a una riscrittura completa.

Sì ... comprendo ...

COM Interop ha alcuni problemi, specie con i controlli complessi come le griglie.

E' a questo problema che mi riferisco in particolare, quando penso ai controlli di terze parti ...

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.

Un attimo ... tra il dire e il fare c'e' di mezzo ... il "costo" di tale operazione ...

La maggior parte delle piccole aziende non pensa assolutamente a cambiare cio' che funziona se questo cambio "costa" ... e le grandi, anche se potrebbero non avere grandi problemi di costi, hanno centinaia di applicazioni da migrare con tempi biblici ...

... 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.

Questo e' un fatto positivo, anche perche' potreste avere un feedback utile per eventuali miglioramenti ...

La risposta è troppo lunga e inoltre gli accordi di NDA mi impediscono di approfondire troppo l'argomento.

Capisco ...

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.

Beh ... contrariamente a quello che dici, conosco tanti (piu' o meno) esperti IT che invece pensavano (e pensano) esattamente che questo sarebbe accaduto ... probabilmente MS ha sottovalutato queste voci ...

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

Ti ho mandato un MP ...

Ciao

[alka]

Ricordo sempre che questo è uno spazio di discussione, non uno spazio pubblicitario.

Va bene suggerire una soluzione possibile ad un problema che sia nel contempo il prodotto dell'utente che lo propone, tuttavia questo non dovrebbe trasformarsi in un reiterato elenco delle caratteristiche, delle potenzialità, dell'utilizzo di un prodotto, tutte informazioni che un interessato può approfondire contattando direttamente il fornitore e che non aggiungono molto alla discussione.