Ohne die genaue Architektur der Sofware zu kennen (also womit z.B. die Oberfläche usw. erstellt wurde), war die erste Frage die sich mir da aufdrängte: Warum sollte das überhaupt notwendig sein. Welchen Vorteil bringt die Re-Implementierung einer komplexen Bibliothek mit aufwendigen Algorithmen in C# (sofern das überhaupt möglich wäre)? Meiner Meinung nach nichts, solange sie Betriebssystemneutral gehalten ist, oder? Da C++ in direkten Maschinencode übersetzt wird wäre doch bei einer C# Implementierung, die dann in einer Laufzeitumgebung ausgeführt wird eher mit einem Performanceverlust zu rechnen? Abgesehen davon lässt sich mit C# eher schlecht systemnah (Speicherzugriff usw.) programmieren. Lassen sich damit überhaupt DLLs erstellen? UND: Wozu .Net (plattformunabhängige Laufzeitumgebung) wenn es eine offizielle Laufzeitumgebung von MS momentan eh nur für Windows gibt.

Zweite Frage die mir kam: Man könnte die Bibliothek als C++ Implementierung beibehalten und das Frontend bzw. umgebende Framework portieren. Wie sind hier die Möglichkeiten mit C#/.Net, Bibliotheken (DLLs) einzubinden. Ich meine mal gelesen haben, dass diese sich nur dynamisch laden lassen und nicht statisch linkbar sind. Ist das korrekt?

Dritte Frage die mir kam. Wie siehts eigentlich mit der guten WinApi unter Windows Vista aus. Existiert die noch, oder gibt es ein Nachfolgemodell welches die altbekannte WinApi über einen Wrapper oder ähnliches zur Verfügung stellt?

Vierte Frage: Wird es zukünftig überhaupt notwendig sein Windows Software .Net fähig zu halten um sie auf Windows auszuführen. Auf der WinApi basierende Programme müssen doch aus Kompatibilitätsgründen weiter ausgeführt werden können. Somit kann man doch auch weiterhin klassisch MFC oder WinApi Programme in C++ schreiben ohne was zu befürchten zu haben oder?

Fünfte Frage: Soweit ich gelesen hab, ist C++/CIL momentan die einzige Möglichkeit Mischcode (.Net/Maschinencode) zu erstellen aber wohl sehr unbeliebt wegen der unangenehmen Syntax und schlechten Lesbarkeit. Wäre diese Lösung ein Mittelweg (also Bilbiothek in C++ behalten) und Frontend auf .Net umstellen.

Wäre sehr schön wenn jemand meine wirren Denkanstöße mal mit fachlich, fundiertem Wissen hinterlegenlegen/diskutieren könnte.

Viele Grüße
mc_ginley

Sehr unbeliebt war der erste Versuch C++ an .net zu binden. Dieser hieß "managed C++". Deswegen gibt es seit .net 2.0 C++/CLI. Das sieht wesentlich übersichtlicher aus.

Die Zusammenarbeit zwischen C# und C++ klappt damit ganz gut.

ja danke soweit. muss mich mal schlau machen was es mit C++/CLI auf sich hat.

http://de.wikipedia.org/wiki/C-Plusplus/CLI