La mia domanda non è gestita. Dove posso iniziare a introdurre il codice gestito?

Question

Tutta la mia applicazione (che è piuttosto grande, con un eseguibile da 20 MB) è scritta in C++ non gestito. Perché posso vedere chiaramente i vantaggi nell'utilizzo del codice gestito, voglio iniziare a introdurre il codice gestito nella mia applicazione, ma da dove comincio?

Posso iniziare facilmente a utilizzare C++/CLI e collegarlo al resto della mia applicazione? (anche se la sintassi C++/CLI sembra piuttosto "esotica").

O è meglio passare a C#, ma qual è il modo migliore per "collegarlo" insieme al mio codice C++ non gestito?

Ha senso compilare tutto il mio codice C++ con l'opzione/clr? Funzionerà?

Devo preoccuparmi del marshalling? Ciò comporta un sovraccarico o posso passare da gestionale a non gestito senza penalizzazione delle prestazioni (come ho fatto 20 anni fa quando mischiavo fortran e C). Le prestazioni sono molto importanti nella mia applicazione poiché si tratta di un'applicazione scientifica che a volte elabora diversi gigabyte di memoria.

Oppure ha senso ridisegnare l'interfaccia utente e scriverlo solo in C# e conservare il resto della mia applicazione (logica di calcolo, logica aziendale, interfaccia database, ...) in C++ non gestito?

Poiché la mia applicazione a volte ha bisogno di gestire diversi gigabyte di memoria, ho una variante a 64 bit. È facile avere un codice gestito a 64 bit? Woudl il garbage collector è ancora efficiente se viene usata così tanta memoria?

Basta indicare: da dove iniziare?

Patrick

Answer 1

Per il momento, considera questa domanda chiusa.

Mi sono reso conto che la risposta non è mescolare C++ e C#, ma ottenere l'architettura giusta in primo luogo.

Se l'architettura è corretta e separata dove deve essere separata, è opportuno semplificare la modifica delle parti dell'applicazione da parte di altri moduli (esterni, altre lingue, ...).

Per quanto riguarda i problemi di prestazioni durante il marshalling, dovremo attendere fino a .Net è ulteriormente maturato.

Answer 2

Profilo di app, decidere a quale integrazione punti è possibile scattare al largo della linea C# di logica e rompere in C++ e viceversa. Disporre questi in un piano per far muovere il modello di progettazione di una facciata attraverso il sistema sostituendo gradualmente C++ con C#. Di fondamentale importanza è il costo della CPU e della memoria quando si decide di cambiare lingua in ogni facciata/interfaccia candidato.

Si vorrà essere in grado di incorporare le modifiche in modo da poter essere meglio con un set di codice sorgente e un repository del codice sorgente per il codice C++ originale e un altro set e repository per la facciata più il C#.

Quindi, quando i miglioramenti/interventi di manutenzione arrivano nel vassoio di alimentazione, lo si applica a entrambe le basi di codice e si tenta di assicurarsi che la facciata si muova attraverso il sistema iniziando dal codice meno probabile che cambi in miglioramenti o manutenzione per ridurre al minimo il raddoppiamento delle modifiche funziona.

Ideale anche per strutturare il tuo lavoro in modo da poter ripristinare la facciata per tornare al 100% C++ alla caduta di un cappello se si colpisce un ostacolo.

Per verificare se una coppia di moduli C++ particolarmente inscrutabili può essere separata in un pezzo C++ e in un pezzo C#, eseguirli in due processi Win32 C++ diversi comunicanti utilizzando una pipe o un socket. In questo modo avrai un'idea migliore se ci sono problemi con la gestione della memoria o le prestazioni che devono essere risolti prima di poter dividere la catena di chiamate in quel punto.

Answer 3

Facciamo esattamente ciò che hai descritto in un'applicazione mission-critical che viene utilizzata da migliaia di utenti. Fondamentalmente, abbiamo mantenuto l'applicazione esistente così com'è, quindi l'eseguibile è ancora un eseguibile non gestito al 100% (non C++/CLI). Quindi inseriamo tutto il nostro nuovo codice C# nelle DLL .NET che comprende oggetti business, controlli utente e codice GUI, ecc ....

Fondamentalmente, tutto il nuovo codice è scritto in C#. Abbiamo 1 DLL che è C++/CLI che è solo colla. Questo ci consente di interpolare facilmente tra il codice gestito e non gestito, senza dover creare il codice C++ esistente clr. Questo limita la quantità di codice C++/CLI che dobbiamo scrivere. Il codice nativo parla del codice in modalità mista, che può comunicare con il codice gestito. La dll in modalità mista può agganciare gli eventi sulle classi C# in modo che il codice C# possa semplicemente attivare l'evento per comunicare al C++/CLI (che può parlare con il codice nativo).

Possiamo anche ospitare .NET UserControls in un'applicazione C++ esistente (WinForms è comunque solo un wrapper per WINAPI, quindi funziona piuttosto bene).

Questo funziona molto bene e consente di mantenere il codice esistente senza dover riscrivere l'intera GUI in C#.