Meine Anwendung ist nicht verwaltet. Wo fange ich an, verwalteten Code einzuführen?

Question

Meine ganze Anwendung (die ziemlich groß ist, mit einer 20MB ausführbaren Datei) wird in nicht verwaltetem C++ geschrieben. Da ich die Vorteile bei der Verwendung von verwaltetem Code deutlich erkennen kann, möchte ich in meiner Anwendung verwalteten Code einführen, aber wo fange ich an?

Kann ich einfach anfangen, C++/CLI zu verwenden und es mit dem Rest meiner Anwendung zu verbinden? (obwohl die C++/CLI-Syntax eher "exotisch" erscheint).

Oder ist es besser, nach C# zu wechseln, aber was ist der beste Weg, dies mit meinem nicht verwalteten C++ - Code zu verknüpfen?

Ist es sinnvoll, meinen gesamten C++ Code mit der Option/clr zu kompilieren? Ob das funktioniert?

Muss ich mich um das Marshalling kümmern? Führt dies zu einem Overhead oder kann ich ohne Leistungseinbußen zwischen Managed und Unmanaged wechseln (wie ich es vor 20 Jahren beim Mischen von Fortran und C getan habe). Leistung ist in meiner Anwendung wirklich wichtig, da es eine wissenschaftliche Anwendung ist, die manchmal mehrere Gigabyte Speicher verarbeitet.

Oder macht es nur sinnvoll, die Benutzeroberfläche neu zu gestalten und nur in C# zu schreiben und den Rest meiner Anwendung (Berechnungslogik, Geschäftslogik, Datenbankschnittstelle, ...) in nicht verwaltetem C++ zu behalten?

Da meine Anwendung manchmal mehrere Gigabytes Speicher verarbeiten muss, habe ich eine 64-Bit-Variante. Ist es einfach, 64-Bit-verwalteten Code zu haben? Wouldl der Müllsammler noch effizient sein, wenn so viel Speicher verwendet wird?

Einfach angeben: wo fange ich an?

Patrick

Answer 1

Betrachten Sie diese Frage für den Moment geschlossen.

Ich erkannte, dass die Antwort nicht Mischen von C++ und C# ist, sondern die Architektur in erster Linie zu bekommen.

Wenn die Architektur korrekt ist und getrennt ist, wo sie getrennt werden muss, sollte das Ändern von Teilen der Anwendung durch andere Module (extern, andere Sprache, ...) einfacher sein.

In Bezug auf die Leistungsprobleme beim Marshalling müssen wir warten, bis .Net weiter gereift ist.

Answer 2

die App Profil, um zu entscheiden, welche Integrationspunkte Sie die C# Linie der Logik abknicken können und brechen in C++ und umgekehrt. Ordnen Sie diese zu einem Plan an, damit sich ein Fassadenentwurfsmuster durch das System bewegt und C++ durch C# ersetzt. Von zentraler Bedeutung sind die CPU- und Speicherkosten bei der Entscheidung, die Sprache bei jeder Kandidaten-Fassade/Schnittstelle zu wechseln.

Sie möchten in der Lage sein, Bearbeitungen zu integrieren, so dass Sie am besten mit einem Quellcode-Set und Quellcode-Repository für den ursprünglichen C++ - Code und einem anderen Set und Repository für die Fassade plus C# arbeiten können.

Dann, wenn Verbesserungen/Wartungsarbeiten in der Eingangsbox kommen, wenden Sie sie auf beide Codebasen an und Sie versuchen sicherzustellen, dass sich die Fassade durch das System bewegt, beginnend mit dem Code, der sich am wenigsten ändert, um Verbesserungen oder Wartung zu minimieren Verdoppelung der Änderungen funktionieren.

Auch ideal strukturieren Sie Ihre Arbeit, so können Sie die Fassade Rollback zurück zu 100% C++ auf den Bruchteil einer Sekunde, wenn Sie einen Haken treffen.

Um zu testen, ob ein paar besonders unergründliche C++ - Module in ein C++ - Stück und ein C# -Teil getrennt werden können, führen Sie sie in zwei verschiedenen Win32 C++ - Prozessen aus, die über eine Pipe oder einen Socket kommunizieren. Auf diese Weise erhalten Sie eine bessere Vorstellung davon, ob Probleme mit der Speicherverwaltung oder der Leistung vorliegen, die behoben werden müssen, bevor Sie die Aufrufkette an diesem Punkt aufteilen können.

Answer 3

Wir tun genau das, was Sie in einer geschäftskritischen Anwendung beschrieben haben, die von Tausenden von Benutzern verwendet wird. Im Grunde behalten wir die existierende Anwendung unverändert bei, so dass die ausführbare Datei immer noch zu 100% nicht verwaltet ist (nicht C++/CLI). Wir setzen dann unseren gesamten neuen C# -Code in .NET-DLLs, die aus Geschäftsobjekten, Benutzersteuerelementen und GUI-Code usw. bestehen.

Grundsätzlich wird der gesamte neue Code in C# geschrieben. Wir haben 1 dll, das ist C++/CLI, das ist nur Klebstoff. Auf diese Weise können wir problemlos zwischen verwaltetem und nicht verwaltetem Code eingreifen, ohne den vorhandenen C++ - Code clr erstellen zu müssen. Dies begrenzt die Menge an C++/CLI-Code, den wir schreiben müssen. Der native Code spricht mit dem Code für gemischten Modus, der mit dem verwalteten Code kommunizieren kann. Die DLL im gemischten Modus kann Ereignisse in den C# -Klassen haken, so dass der C# -Code das Ereignis nur auslösen kann, um mit der C++/CLI (die mit dem nativen Code sprechen kann) zu kommunizieren.

Wir können auch .NET-Benutzersteuerelemente in einer vorhandenen C++ - Anwendung hosten (WinForms ist sowieso nur ein Wrapper um das WINAPI, also funktioniert es ziemlich gut).

Das funktioniert sehr gut und Sie können Ihren vorhandenen Code beibehalten, ohne die gesamte GUI in C# neu schreiben zu müssen.