La migliore strategia per passare da VB6 a .NET

Question

La mia azienda ha tonnellate di legacy applicazioni scritte in VB6.

Siamo in transizione da trasferire applicazioni VB6 a .NET (3.5 in particolare).

Quale sarebbe la migliore strategia per lo spostamento del modulo da VB6 a .NET?

NOTA: Sotto aggiornamento dovrebbe andare a "Project Management" e non ha nulla a che fare con la questione principale.

[UPDATE]: Grazie per il tuo feedback finora
Ora ci sono domanda più che pop-up sono

1. come è possibile assegnare agli sviluppatori di sviluppare nuove applicazioni?
2. Dovrebbe esserci una divisione speciale di aggiornamento una tantum che convertirà le app legacy in nuove? O dovrebbe ogni sviluppatore partecipare al processo di conversione ?
3. Solo gli sviluppatori senior possono partecipare alla conversione? Junior sviluppatori? o misto?

Sembra che, più ci penso questo problema, più domande solo mostrare up.

Answer 1

Chiaramente questa è un'impresa importante che richiederà molto lavoro.
Quindi il mio consiglio sarebbe di trattarlo come un progetto a lunghissimo termine.

Avere un obiettivo chiaro in mente, che affronta problemi importanti come sicurezza, resilienza, manutenibilità e il futuro delle vostre applicazioni.

Una volta che questo è stato concordato dai portatori di interesse, sviluppare un sistema prototipo per testare le proprie ipotesi con, dove è possibile provare C# vrs VB.net o MVC vrs Webforms. Assegnerei i tuoi migliori sviluppatori per questo.

Quindi iniziare con uno dei sistemi legacy più piccoli e creare i componenti principali che verranno riutilizzati in altre aree.
In questa fase, inizia con i tuoi sviluppatori più esperti, ma tutti devono essere coinvolti e conoscere il nuovo framework.
Ciò garantirà che tutti siano addestrati nello stesso momento e nessuno è lasciato indietro.
A seconda di quante applicazioni avresti ruotare gli sviluppatori, quindi tutti i sistemi possono trarne vantaggio.

anche tutti i nuovi lavoro deve essere fatto nel vostro non linguaggio .NET in VB6.

Converti gradualmente ciascuna delle applicazioni legacy. (Vorrei convertirli solo se stanno cambiando o se c'è un chiaro vantaggio nell'aggiornarli.)

Questo dovrebbe darti una solida struttura da utilizzare in futuro, assicurando comunque che la funzionalità degli utenti non sia ostacolata dal tuo migrazione.

Ad esempio:
Ho lavorato in un'azienda con circa 40 applicazioni VB.
Nel corso del tempo abbiamo migrato tutti questi elementi in C# e ora (5 anni dopo), abbiamo circa 150 applicazioni in C# (tutte in .net 2.).

Questi condividono un quadro comune, che li rende facili da mantenere ed estendere, ove necessario.

Answer 2

Vorrei iniziare con gli strumenti di Microsoft:

http://msdn.microsoft.com/en-us/library/aa480541.aspx

Answer 3

vedere questo:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

Naturalmente, C# vs VB.Net è solo una parte di esso.

Ad esempio, un'altra cosa da considerare è se si desidera utilizzare questa opportunità per spostare queste app su una rete intranet, se non lo si è già fatto. O quanto vuoi approfondire lo stack di microsoft. Ad esempio, Winform è abbastanza o vuoi usare WPF.

Answer 4

si potrebbe trovare il seguente articolo utile: http://www.vsj.co.uk/articles/display.asp?id=756

Answer 5

provare a sostituire le funzionalità di base con COM abilitato .NET librerie. "Svuota" le tue app VB6 esistenti spostando funzionalità su .NET bit per bit.

Attenzione alle riscritture complete. Anche se sono allettanti "perché è un taglio netto" - di solito la pazzia procede! Leggi "Lavorare efficacemente con il codice legacy" di Michael Feathers come preparazione. Sebbene il libro non vada specificamente nello "spostamento da una lingua all'altra", mostra molte insidie ​​del mondo reale che incontrerai.

Penso che tutti gli sviluppatori debbano avere intervalli di tempo definiti in cui eseguono la migrazione sulle app legacy che hanno sviluppato in precedenza. Dal momento che hanno già conoscenze di dominio e conoscono lo spazio del problema dovrebbero essere i più produttivi.

Answer 6

Qui è un adattamento del mio answer a una domanda simile.

Conversione di programmi di grandi dimensioni automaticamente è una scelta migliore rispetto alla riscrittura. È un comune errore iniziare a riscrivere ottimisticamente un grande software, fare progressi precoci risolvendo alcuni dei ben noti difetti della vecchia architettura, e poi impantanarsi nella funzionalità che si è appena dato per scontato per anni. A questo punto la tua gestione inizia a diventare nervosa e tutto può diventare molto scomodo.

... ed ecco un post sul blog da un Microsofty che agrees with me:

Molte aziende con cui ho lavorato nei primi giorni di .NET guardò prima riscrittura guidato in parte da un forte desiderio di migliorare la architettura e strutture di codice sottostanti contemporaneamente al loro spostamento su .NET. Sfortunatamente molti di questi progetti sono stati messi in difficoltà e molti non sono mai stati completati.Il problema che stavano cercando di risolvere era troppo grande

Questo eccellente Microsoft page consiglia due strumenti di migrazione di terze parti come migliore del sottodimensionato wizard integrato in VB.NET aggiornamento - Artinsoft e CodeArchitects VBMigration. Artinsoft ha scritto la procedura guidata di aggiornamento VB.NET, questa è la versione migliorata. E CodeArchitects è stata fondata da Francesco Balena, che ha scritto alcuni degli classic books su VB6 e VB.NET.

La stessa pagina Microsoft dice anche:

Esecuzione di una riscrittura completa di .NET è molto più costosa e difficile da fare bene [di conversione] ... avremmo solo raccomandare questo approccio per un piccolo numero di di situazioni.

---

EDIT: Sung dice nei commenti: "Io non sono un grande fan di generazione automatica di codice, perché è più difficile da mettere a punto inizialmente e potrebbe prendere solo il tempo che ci vuole per riscrivere tutto" . Devo essere in disaccordo con forza. In generale, anch'io non sono un fan della generazione di codice, ma in questo caso il codice risultante sarà strutturato in modo identico al VB6 originale e dovrebbe essere quasi totalmente funzionante. In realtà non ho ancora provato questi strumenti, ma dal loro customertestimonials questa promessa è soddisfatta.

E ripeto il consiglio di Microsoft appena sopra, in base alla loro esperienza di assistere molte migrazioni - "una completa riscrittura è di gran lunga più costoso e difficile di conversione [corsivo mio]" - una contraddizione della supposizione che essa potrebbe richiedere lo stesso tempo Se si desidera migliorare la struttura del VB6, è probabile che il refactoring graduale sia molto più economico di una riscrittura.