VC++ nach C# Migration Richtlinien/Ansätze/Probleme

Question

Wir planen, einige unserer VC++ Legacy-Produkte auf C# mit .NET-Plattform zu verschieben. Ich bin dabei, die relevanten Informationen zu sammeln, bevor ich den Vorschlag optimistisch und effektiv mache Annäherung an Kunden. Bin auf der Suche nach den folgenden Details.

1. Alle allgemeinen Richtlinien in der Migration von VC++ zu C# .NET
2. Was die Probleme sind, dass ein Team stellen können, wenn wir diese Aktivität
3. Sind nehmen es bestehende Ansätze zur Verfügung? Ich glaube, dass viele vielleicht versucht haben, aber vielleicht keine detaillierten Informationen haben, aber das hier zu konsolidieren, würde nicht nur mir helfen, sondern auch jedem, der nach diesen Informationen sucht.
4. Alle guten/gültigen Ressourcen im Internet verfügbar?
5. Irgendwelche Vorschläge von Microsoft-Team, wenn Microsoft-Leute in dieser Gruppe?
6. Architektur, Komponenten Designansätze usw.

Bitte helfen Sie mir diese Informationen in immer, jeden Cent mir helfen würde, gutes Verständnis zu gewinnen ..

Vielen Dank im Voraus für diejenigen, die ihre Weisheit teilen gründlich diese Abfrage.

Answer 1

Ein Problem, wenn Sie eine komplizierte Klassenhierarchie haben, beachten Sie, dass C# keine Mehrfachvererbung unterstützt, so dass Sie die Struktur Ihres Programms möglicherweise überdenken müssen.

Bearbeiten: Eine andere Sache zu beachten ist, dass das. NET-Framework sehr, sehr groß ist. Möglicherweise finden Sie in Ihrem C++ - Code Utility-Klassen, die vollständig durch Standardbibliotheksklassen in C# ersetzt werden können.

Answer 2

Oft ist mein bester Rat: Tun Sie es nicht.

Wenn Sie über funktionierenden, sauberen C++ - Code verfügen, gibt es keinen Grund, ihn neu zu schreiben. Es ist sehr einfach, C++/CLI zu verwenden, um Wrapper um den Legacy-Code zu erstellen, um ihn von C# /. NET aus nutzbar zu machen.

Dies ist oft ein besserer, schnellerer und sicherer Ansatz. Sie können dann Ihre neue Entwicklung in .NET durchführen und eventuell vorhandenen Code langsam migrieren, wenn dies wirklich erforderlich ist.

Das Migrieren von Code von C++ zu C# ist in der Regel sehr vollständig, von Grund auf neu geschrieben (es sei denn, Sie wickeln wie oben erwähnt). Dies ist hauptsächlich auf den großen Unterschied in den Bibliotheken zurückzuführen, nicht auf den Unterschied in den Sprachen.

Das .NET Framework bietet eine umfangreiche Bibliothek mit Tools, die die Architektur Ihres Codes beim Schreiben ändern können und sollten. Wenn Sie C++ direkt in C# portieren, werden Sie feststellen, dass Sie viele Dinge auf nicht-standardmäßige Weise tun werden, und Sie werden mit sehr schwierig zu wartendem C# -Code enden.

Mein Vorschlag, basierend auf meiner Erfahrung, besteht darin, Ihren Code zuerst zu verpacken. Wenn Sie dann entscheiden, dass Sie bestimmte Funktionen erweitern müssen, und das ist wegen der Wrapper einfach, können Sie diesen einen bestimmten Teil Ihres Codes in C# mit völlig neuen Techniken und Bibliotheken umschreiben - und C++ Stück für Stück ersetzen.

Answer 3

Einige Dinge, die sofort kommen:

• unten finden Sie die C nicht verwirren ++ "char" und die C# "char". Sie wissen wahrscheinlich, dass ein "Char" in C# nicht wirklich ein Ein-Byte-Primitiv ist. Wenn Sie also beim Portieren verwirrt werden, sollten Sie darauf achten, dass Sie in C# das C++ "char" in "byte" portieren.

• Wie Brennan Vincent sagte, unterstützt C++ Multi-Vererbung, während C# nicht. Sie müssen die Hierarchie wahrscheinlich neu überdenken, wenn Ihre Klassen "komplex" sind.

• Zeiger sind in C# NICHT wie in C++ nativ. Auch hier kommt es darauf an, wie Sie Ihre C++ App geschrieben haben, aber ich kann wetten, dass Sie dort Zeiger verwenden, also stellen Sie sicher, dass der usafe C# 's entspricht, da er sie vom Programmierer (in den meisten Fällen) transparent behandelt.

Ich könnte ein paar mehr später hinzufügen, nette Frage!

Answer 4

Nehmen Sie zunächst Ihren nativen C++ - Quellcode und kompilieren Sie ihn als C++/CLI. Sie werden schreckliche Ergebnisse bekommen. Zweitens sollten Sie Ihren nativen C++ - Code nicht verwenden und versuchen, ihn in C# zu übersetzen, während Sie gleichzeitig Orte für die Verwendung der Basisklassenbibliotheken, die Änderung der Datenzugriffsmethode und die Anpassung des UI-Paradigmas von MFC an WPF beachten. Sie werden eine Menge Energie ausgeben, um im besten Fall das zu produzieren, was Sie vorher hatten.

Verwenden Sie stattdessen Ihren nativen C++ - Code und refactorisieren Sie ihn so, dass Sie eine oder mehrere "Business Logic" -Bibliotheken haben. Wenn diese bereits vorhanden sind, könnten sie COM-Schnittstellen haben, sie könnten einige "extern C" -Funktionen offenlegen, oder sie könnten einige C++ - Instanzmethoden offenlegen. Keine Bange. Wenn sie nicht bereits existieren, haben Sie zwei Möglichkeiten. Wenn es nur eine Handvoll Methoden gibt, die von der Präsentationsschicht benötigt werden, und sie einfache Dinge wie Zeichenketten verwenden, fügen Sie einige "extern C" -Funktionen als Schnittstelle zur Geschäftslogik hinzu. Jetzt können Sie diese über die verwaltete Benutzerschnittstelle (VB oder C#, Windows Forms oder WPF, was auch immer) mit P/Invoke aufrufen. Wenn es eine Menge gibt und Sie diese organisieren möchten oder wenn sie komplexe Strukturen oder Objekte benötigen, schreiben Sie eine C++/CLI-Klasse oder Klassen, die mit den nativen C++ - Klassen kommunizieren können, während "public ref class" -Klassen offengelegt werden auf die verwaltete Benutzeroberfläche. Das C++/CLI wird die Marshalling- und Lifetime-Probleme vereinfachen.

Für Ihre neue Benutzeroberfläche schreiben Sie sie von Grund auf neu und rufen Sie wo erforderlich in die Geschäftslogik auf. Verwenden Sie die alte Benutzeroberfläche nur als Anleitung für die benötigten Funktionen und für Validierungen. Verwenden Sie das "Look and Feel" Ihrer neuen UI-Technologie (WPF oder was auch immer), um die Benutzeroberfläche selbst zu erstellen, und versuchen Sie nicht, eine mechanische Konvertierung durchzuführen. Sie werden am Ende Pixel jagen und härter arbeiten, als Sie brauchen, wenn Sie zu sehr an der alten Benutzeroberfläche festhalten. Alte App hatte 3 Tasten und eine Checkbox? Großartig, 3 WPF-Tasten und ein WPF-Looking Check-Box kommt auf. Wechseln Sie lieber zu einem Farbband, während Sie die Änderung vornehmen? Fein. Es ist in Ordnung, anders auszusehen, wenn Sie fertig sind.

Dann stellen Sie Ihre nativen Business-Logikbibliotheken bereit, die immer noch als systemeigener Code kompiliert sind, Ihren C++/CLI-Wrapper, falls Sie einen haben, und Ihre verwaltete UI. Dies funktioniert für alles außer dem Telefon.

Ich muss nur noch einmal sagen bitte portieren Sie nicht Ihre Arbeit native C++ Business Logik in C# als Teil der Anfangsphase des Projekts. Wenn es fertig ist und funktioniert, wenn Sie einen guten Geschäftsgrund haben (wie wir kein Geld mehr für C++ - Entwickler ausgeben wollen), dann können Sie darüber nachdenken. Aber zuerst funktioniert es mit Interop. Das hat den Vorteil, dass wenn Ihre Übersetzung die delikate Geschäftslogik von Leuten, die nicht mehr bei Ihnen sind, durchlesen und sich auf C++ Feinheiten verlassen, die Ihr aktuelles Team nicht kennt, können Sie für den Rest Ihrer Tage auf die verpackten Bibliotheken zurückgreifen.

Answer 5

Ich habe umfangreiche Erfahrung in der Vergangenheit der Migration einer großen Anwendung von C++ (MFC) zu C# (WinForms).

Einige wichtige Faktoren können Sie Ihre Strategie beeinflussen:

1. Zunächst einmal, warum müssen Sie migrieren? Kennen Sie Ihre Ziele, um eine richtige Strategie zu wählen. In den meisten Fällen sollten Sie nicht "nur" migrieren, damit Sie eine coole neue Technologie verwenden.

2. Wie groß ist die bestehende Codebasis? Wenn es sich um eine sehr kleine Codebasis handelt, die nur eine Sache von, sagen wir, Wochen ist, um zu überschreiben, nicht mit Überanalyse zu tun und es einfach tun ...

3. Müssen Sie alle vorhandenen Funktionen zu konvertieren C#? Oder können Sie mit C++ leben und nur neue Funktionen in C# hinzufügen? Abhängig davon, wie Ihr vorhandener C++ - Code in der Lage ist, Komponenten zu verwenden, können Sie möglicherweise Technologien wie COM Interop verwenden, um die Wiederverwendung während der Entwicklung in C# fortzusetzen.

4. Können Sie sich die Veröffentlichung einer neuen Version zu verzögern, bis Sie alles neu schreiben? Normalerweise wäre die Antwort nein. (Netscape kommt Ihnen in den Sinn - Sie sollten vielleicht this lesen ...) Vielleicht möchten Sie eine Strategie entwickeln, mit der Sie Komponenten und Frameworks in Ihrer Anwendung schrittweise ersetzen können, so dass Sie Versionsupgrades freigeben können , so dass jede Version etwas mehr C# und etwas weniger C++ enthält.

5. Grundsätzlich war ein Ansatz, der für mich funktionierte, um die grundlegenden Frameworks meiner Anwendung in C# neu zu schreiben und diese Frameworks aus meiner C++ - Anwendung mit COM Interop zu verwenden. Jede Version hatte einige weitere Frameworks und Steuerelemente in C#. Nachdem wir eine kritische Masse des Codes sowie alle Steuerelemente unseres Hauptfensters konvertiert hatten, änderten wir den Eingangspunkt der Anwendung in .NET anstelle von C++.

6. Wie für Ressourcen, für mich, das Buch ".NET and COM: The complete interoperability guide" war ein Schatz.

Das sind die wichtigsten Dinge, die ich im Moment denken kann. Ich bin möglicherweise in der Lage, viele spezifischere Fragen zu beantworten, die Sie möglicherweise haben.

@@