Linee guida/approcci/approcci alla migrazione da VC++ a C#

Question

Stiamo pianificando di spostare alcuni dei nostri prodotti VC++ legacy in C# con la piattaforma .NET. Sono in procinto di raccogliere le informazioni relavent prima di rendere la proposta ottimistica ed efficace approccio ai clienti. Sto cercando i seguenti dettagli.

1. Eventuali linee guida generali in migrazione di VC++ a C# .NET
2. Quali sono i problemi che una squadra può affrontare quando prendiamo questa attività
3. Ci sono approcci esistenti disponibili? Credo che molti potrebbero aver provato ma potrebbero non avere informazioni dettagliate, ma il consolidamento di questo sotto non solo aiuterebbe me, ma chiunque cerchi queste informazioni.
4. Qualsiasi risorsa valida/valida disponibile su Internet?
5. Qualche suggerimento da parte del team Microsoft in caso di persone Microsoft in questo gruppo?
6. Architettura, componenti approcci progettuali, ecc

Ti prego, aiutami a ottenere queste informazioni, ogni centesimo mi avrebbe aiutato a guadagnare buona comprensione ..

Grazie in anticipo a coloro che condivideranno la loro saggezza approfondita questa domanda.

Answer 1

Un trucco, se si dispone di una gerarchia di classi complicata, si noti che C# non supporta l'ereditarietà multipla, quindi potrebbe essere necessario ripensare la struttura del programma.

Modifica: Un'altra cosa da tenere a mente è che il framework .net è molto, molto grande. È possibile trovare classi di utilità nel codice C++ che possono essere completamente sostituite dalle classi di libreria standard in C#.

Answer 2

Spesso, il mio miglior consiglio è: Non farlo.

Se si dispone di un codice C++ funzionante e pulito, non c'è motivo di riscriverlo. È molto facile usare C++/CLI per creare wrapper attorno al codice legacy per renderlo utilizzabile da C# /. NET.

Questo è spesso un approccio migliore, più rapido e più sicuro. È quindi possibile eseguire il nuovo sviluppo in .NET e migrare lentamente qualsiasi codice esistente richiesto se c'è una reale necessità di farlo.

Detto questo, la migrazione del codice da C++ a C# è in genere una riscrittura completa, da zero (a meno che non venga eseguito il wrap come sopra indicato). Ciò è principalmente dovuto all'enorme differenza nelle librerie, non alla differenza nelle lingue.

.NET Framework offre un'enorme libreria di strumenti che possono e devono cambiare l'architettura del codice quando vengono scritti. Se porti semplicemente il C++ in C#, scoprirai che farai un sacco di cose in modi non standard, e finirai con un codice C# molto difficile da gestire.

Il mio suggerimento, basato sulla mia esperienza, è quello di avvolgere il codice prima. Quindi, se decidi di dover estendere determinate funzionalità, ed è poco soddisfacente a causa dei wrapper, puoi riscrivere quella porzione specifica del tuo codice in C# usando tecniche e librerie completamente nuove e sostituire il C++ pezzo dopo pezzo.

Answer 3

Alcune cose che vengono istantaneamente:

• essere sicuri di non confondere il "char" e il "char" C# C++. Probabilmente sai che un "carattere" in C# non è in realtà una primitiva a un byte. Quindi, nel processo di porting potresti essere confuso, fai attenzione che in C# porti il ​​C++ "char" a "byte".

• Come ha detto Brennan Vincent, il C++ supporta l'ereditarietà multipla mentre C# no. Probabilmente dovrai ripensare alla gerarchia, se le tue classi sono "complesse".

• I puntatori NON sono nativi in ​​C# come in C++. Di nuovo, dipende da come hai scritto la tua app C++, ma posso scommettere che stai usando i puntatori lì, quindi assicurati che l'usafe corrisponda ai C# perché li gestisce in modo diverso, in modo trasparente dal programmatore (nella maggior parte dei casi).

Potrei aggiungere qualche altra più avanti, bella domanda!

Answer 4

Prima di tutto, non prendere il tuo codice C++ nativo e compilarlo come C++/CLI. Otterrai risultati orribili. In secondo luogo, non prendere il tuo codice C++ nativo funzionante e provare a tradurlo in C#, notando contemporaneamente i posti in cui utilizzare le librerie di classi di base, modificando la tecnica di accesso ai dati e modificando il paradigma dell'interfaccia utente da MFC a WPF. Spenderai molta energia per produrre, nel migliore dei casi, ciò che avevi prima.

Invece, prendi il tuo codice C++ nativo funzionante e rifattalo in modo da avere una o più librerie di "business logic". Se questi esistono già, potrebbero avere interfacce COM, potrebbero esporre alcune funzioni di tipo "extern C" o potrebbero esporre alcuni metodi di istanza C++. Nessun problema. Se non esistono già, hai due scelte. Se ci sono solo una manciata di metodi necessari al livello di presentazione, e prendono cose semplici come le stringhe, mettono alcune funzioni "extern C" nel posto come gateway per la logica di business. Ora puoi chiamare quelli dall'interfaccia utente gestita (VB o C#, Windows Form o WPF, qualunque cosa) usando P/Invoke. Se ci sono molte cose e vuoi organizzarle, o se hanno bisogno di prendere strutture o oggetti complessi, allora scrivi una classe o classi C++/CLI che possano parlare alle classi native C++ as-is mentre esponi le classi "public ref class" all'interfaccia utente gestita. Il C++/CLI renderà più semplici i problemi di marshalling e lifetime.

Per la nuova interfaccia utente, scriverla da zero, richiamando la logica aziendale dove necessario. Utilizza la vecchia interfaccia utente solo come guida per le funzionalità necessarie e per le convalide. Usa il "look and feel" della tua nuova tecnologia UI (WPF o altro) per costruire l'interfaccia utente stessa e non provare una conversione meccanica. Finirai per inseguire i pixel e lavorare di più del necessario se ti affidi troppo al vecchio ui. La vecchia app aveva 3 pulsanti e una casella di controllo? Grandi, 3 pulsanti con aspetto WPF e una checkbox dall'aspetto WPF in arrivo. Piuttosto passare ad un nastro mentre stai facendo il cambiamento? Belle. È ok per sembrare diverso quando hai finito.

Quindi si distribuiscono le librerie logiche aziendali native, ancora compilate come codice nativo, il wrapper C++/CLI se ne possiede uno e l'interfaccia utente gestita. Funzionerà per qualsiasi cosa eccetto il telefono.

Ho solo bisogno di dire ancora una volta NON PORTA la tua logica di lavoro C++ nativa in C# come parte della fase iniziale del progetto. Una volta terminato e funzionante, se hai una buona ragione di lavoro (come non vogliamo più spendere soldi per gli sviluppatori C++), puoi prenderlo in considerazione. Ma prima fallo funzionare usando interop. Questo ha il vantaggio che se la tua traduzione incasina la delicata logica aziendale scritta da persone che non sono più con te, facendo affidamento su sottigliezze C++ che il tuo team attuale non conosce, puoi ricorrere alle librerie avvolte per il resto dei tuoi giorni.

Answer 5

Ho avuto una vasta esperienza nel passato della migrazione di una grande applicazione da C++ (MFC) a C# (WinForms).

Alcuni fattori chiave in grado di influenzare la strategia:

1. Prima di tutto, perché devi migrare? Conosci i tuoi obiettivi per scegliere una strategia adeguata. Nella maggior parte dei casi, non è necessario migrare "solo" in modo da utilizzare una nuova tecnologia innovativa.

2. Quanto è grande il codice esistente? Se si tratta di una base di codice molto piccola che è solo questione di, per esempio, settimane da riscrivere, non preoccuparti di sovra-analizzare e basta farlo ...

3. Devi convertire tutte le funzionalità esistenti in C#? O puoi vivere mantenendo il C++ e aggiungendo solo nuove funzionalità in C#? A seconda di come il tuo codice C++ esistente è strutturato, potresti essere in grado di utilizzare tecnologie come COM Interop per continuare a riutilizzarlo mentre si sviluppa in C#.

4. Puoi permetterti di ritardare il rilascio di qualsiasi nuova versione fino a quando non riscrivi tutto? Di solito la risposta sarebbe no. (Mi viene in mente Netscape - potresti leggere this ...) Potresti voler elaborare una strategia in cui puoi gradualmente sostituire componenti e framework nella tua applicazione, in modo da lasciarti libero di rilasciare gli aggiornamenti della versione , così ogni versione ha un po 'più C# e un po' meno C++.

5. Fondamentalmente, un approccio che ha funzionato per me era di riscrivere i framework di base della mia applicazione in C# e consumare tali framework dalla mia applicazione C++, usando COM Interop. Ogni versione aveva altri framework e controlli in C#. Una volta convertiti una massa critica del codice, oltre a tutti i controlli della nostra finestra principale, abbiamo modificato il punto di ingresso dell'applicazione in .NET anziché in C++.

6. Per quanto riguarda le risorse, per me il libro ".NET and COM: The complete interoperability guide" era un tesoro.

Queste sono le cose principali a cui riesco a pensare in questo momento. Potrei essere in grado di rispondere a molte altre domande specifiche che potresti avere.