La mia applicazione non è gestito. Da dove comincio l'introduzione di codice gestito?

Question

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

Posso facilmente iniziare ad utilizzare C ++ / CLI e creare un collegamento con il resto della mia applicazione? (Anche se la sintassi C ++ / CLI sembra piuttosto 'esotica').

O è meglio per passare a C #, ma qual è il modo migliore per 'link' questo insieme con il mio codice non gestito C ++?

Ha senso per compilare tutto il codice C ++ con l'opzione / CLR? Sarà questo lavoro?

Devo preoccupare di smistamento? Questo dà un sovraccarico o posso passare tra gestito e non gestito, senza una riduzione delle prestazioni (proprio come ho fatto 20 anni fa, quando la miscelazione FORTRAN e C). Le prestazioni sono veramente importante nella mia applicazione in quanto si tratta di un'applicazione scientifica che a volte elabora diversi gigabyte di memoria.

Oppure è senso solo a ridisegnare l'interfaccia utente, e solo scrivere questo in C #, e mantenere il resto della mia domanda (logica di calcolo, logica di business, l'interfaccia del database, ...) in non gestito C ++?

Dal momento che la mia domanda a volte ha bisogno di gestire diversi gigabyte di memoria, ho una variante a 64 bit. E 'facile avere codice gestito a 64 bit? Merion il garbage collector ancora essere efficiente se viene utilizzato più di tanto la memoria?

Semplicemente Stato:? Da dove si comincia

Patrick

Answer 1

Per il momento, si consideri la questione chiusa.

mi sono reso conto che la risposta non è la miscelazione C ++ e C #, ma ottenere la giusta architettura, in primo luogo.

Se l'architettura è corretto, e separati dove deve essere separati, che cambiare parti della domanda da altri moduli (esterno, altre lingue, ...) dovrebbe essere più facile.

Per quanto riguarda i problemi di prestazioni durante smistamento, dovremo aspettare fino a .Net è ulteriormente maturato.

Answer 2

Profilo app, decidere a quale integrazione punti è possibile scattare al largo della linea C # di logica e rompere in C ++ e viceversa. Organizzare questi in un piano per avere un modello di progettazione mossa Facciata attraverso il sistema sostituendo gradualmente C ++ con C #. Di fondamentale preoccupazione è il costo della CPU e della memoria quando si decide di passare da una lingua ad ogni candidato Facciata / interfaccia.

Si vuole essere in grado di incorporare le modifiche cui si potrebbe essere migliore con il codice impostato e codice sorgente repository di una sorgente per il codice originale C ++ e un altro set e repository per la facciata più il C #.

Poi, come il lavoro miglioramenti / manutenzione viene nel nel cassetto lo si applica ad entrambe le basi di codice, e si tenta di assicurarsi che le facciate si muove attraverso il sistema iniziano con il codice meno probabilità di cambiare in miglioramenti o manutenzione per ridurre al minimo il raddoppio dei cambiamenti di lavoro.

idealmente strutturare anche il vostro lavoro in modo da poter far ritirare la facciata di tornare al 100% C ++ alla goccia di un cappello, se si colpisce un intoppo.

Per verificare se una coppia di moduli particolarmente imperscrutabili C ++ può essere separato in una ++ piece C e # piece C, farli funzionare in due differenti processi Win32 C ++ comunicanti con un tubo o una presa. In questo modo si otterrà una migliore idea di se ci sono problemi con la gestione della memoria o le prestazioni che hanno bisogno di fissaggio prima di poter dividere la catena di chiamate in quel punto.

Answer 3

Lo facciamo esattamente quello che hai descritto in un'applicazione mission critical che viene utilizzato da migliaia di utenti. Fondamentalmente, abbiamo mantenuto l'applicazione esistente come è, quindi l'eseguibile è ancora un eseguibile gestito 100% (non C ++ / CLI). Abbiamo poi messo tutto il nostro nuovo codice C # .NET in DLL che si compone di oggetti di business, controlli utente e codice della GUI, ecc ....

In sostanza, tutto il nuovo codice è scritto in C #. Abbiamo 1 dll che è C ++ / CLI che è appena colla. Questo ci permette facilmente di interoperabilità tra il codice gestito e non gestito, senza dover fare il codice C ++ CLR esistente. Questo limita la quantità di codice C ++ / CLI dobbiamo scrivere. Il codice nativo parla al codice modalità mista, che può parlare con il codice gestito. La modalità mista dll può collegare gli eventi sulle classi C # in modo che il codice C # può solo generare l'evento di comunicare al C ++ / CLI (che può parlare con il codice nativo).

Si può anche ospitare controlli utente .NET in un'applicazione esistente C ++ (WinForms è solo un wrapper per il WINAPI in ogni caso, in modo che funziona abbastanza bene).

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