C# dll -> native C++ dll ?
Hi!
Ich habe folges "Problem":
Ich habe eine C# CF2.0 DLL in Rahmen einen Pocket PC Projekts erstellt. Jetzt besteht bei Kunden der Bedarf die Funktionalitäten der DLL auch in anderen Projekten zu nutzen (C++, Java).
Fall Interesse besteht kurz zur groben Funktion der c# dll:
Diese beinhaltet eine Klasse Parser welche nur über eine statische Methode "Parser CreateParser(byte[] data)" instantiiert werden kann. Diese erwartet als Parameter einen Rohdatensatz.
Ist dieser Datensatz "valide" wird eine Instanz von Parser zurückgegeben, ansonsten wird eine ParserException ausgelöst welche spezifiziert welcher Fehler aufgetreten ist.
Wurde erfolgreich eine Instanz erzeugt können beispielsweise über eine Methode "object GetValue(key)" bestimmte Werte aus dem Rohdatensatz extrahiert werden.
Auch wenn es im Prinzip nicht kompliziert aussieht ist das Parsing der Daten intern doch schon sehr aufwändig.
Das Problem ist jetzt natürlich das beispielsweise eine Java-Anwendung keine Funktionen direkt aus einer managed .NET dll verwenden kann.
Soweit ich das sehe müsste ich dazu sowas wie eine native win32 dll zur verfügung stellen richtig ?
Die Frage ist jetzt eigentlich die nach dem sinnvollsten Vorgehen bzw. welche Möglichkeiten überhaupt bestehen.
Ich habe mir natürlich schon einige Möglichkeiten genauer angesehen aber ich bin damit nicht so ganz glücklich geworden und wollte dann doch ganz gerne mal eine Diskussion dazu anregen.
Danke schonmal im vorraus,
Rev
So einfach wie möglich, aber nicht einfacher. [Albert Einstein]
take a look at
* baer-torsten.de
* codinghints
Stichwort für Google ist "Java .NET bridge". Klar muss aber sein: .NET muss installiert sein. Mit reinen DLL-Geschichten kommst du nicht weiter, weil du hier mit Objekten hantierst. Das läßt alle einfachen Lösungen aussscheiden.
Schau dir mal das an:
Damit hättest du auch gleich C++ erschlagen, wenn du aus dem Assembly ein COM-Objekt machst.
Evtl. solltest du deinem Kunden klarmachen das er es mit Java nur eingeschränkt nutzen kann. Das übertragen der C#-dll in Java ist zwar möglich, allerdings erfordert diese weiterhin die clr um ausgeführt zu werden, daher ist die vollkommene Platformunbhängigkeit dahin. Selbst mit einer kompilierten DLL wäre die vollkommene Unabhängigkeit schnell weg.
Gruß David
Ich sehe gerade: Pocket PC. Vergiß es. Alle Lösungen die überhaupt existieren funzen meines Wissens nur für den Desktop. Der COM-Weg ist ebenfalls komplett verbaut, da man unter CE keine managed Components zu COM-Objekten machen kann (nativer Code kann unter CE die Runtime nicht hosten).
Alternative: Biete deine Funktionalität als seperaten Prozess an und kommuniziere mit deinem Fremdcode "anderen" Code über CE-IPC-Bordmitteln (bedeutet P2P-MessageQueue). Leider extrem aufwändig im Vergleich zu einem Funktionsaufruf.
Kurzum: Managed Komponenten in anderen Umgebungen sind unter CE schlicht nicht möglich, es scheitert schlicht am Hosting. Aber vielleicht ändert sich das ja mit CE 6 oder 7.
Die "gute" Nachricht: Man kann auch keine Java-Komponenten/Klassen in C++ oder C# verwenden.
Wenn dann gehts andersrum: Managed Anwendung mit unmanaged Dlls/COM-Objekten.
Danke für den Hinweis. Also das mit COM hatte ich auch bereits im Sinn. Da ich in dem Bereich noch keine Erfahrung habe stelle ich das Gedanklich noch einmal etwas zurück.
Außerdem gibt es, wie ich den obigen links entnehmen konnte, ein paar Einschränkungen wodurch ich das "layout" meiner Bibliothek ändern müsste:
- Die Klasse muß einen öffentlichen (public) Konstruktor haben.
- Nur öffentliche Instanzmethoden können von außen angesprochen werden.
- Statische Methoden oder Eigenschaften sind prinzipiell nicht ansprechbar.
Da kommen mir dann die Punkte 1) und 3) in die quere.
Original von svenson
Stichwort für Google ist "Java .NET bridge".
Diese "Bridges" scheinen auch meist über COM realisiert zu werden oder ? Ich habe absolut kein Java-Know-How, deswegen ist für mich etwas schwierig zu überblicken was dort möglich ist bzw. wieviel Aufwand es bedeuten würde.
Original von svenson
Ich sehe gerade: Pocket PC. Vergiß es.
Hmm, also in dieser DLL gibt es nichts was spezifisch Pocket-PC gebunden ist. ich könnte somit im Zweifelsfall auch dne ganzen code in ein "full framework" Projekt copy/pase übernehmen.
Also unterm Strich wurde hier ja quasi einheitlich die Verwendung von COM vorgeschlagen.
Wie sähe es denn mit dem Ansatz aus das ich meine bestehende Bibliothek in eine native c++ Bibliothek portiere ?
Diese müsste ja dann für Java leicht zugänglich sein oder ? Und c++ hätte ich damit dann ja eh erschlagen.
Ist ein win32 dll Projekt dann das was ich suche ? Darf diese MFC gebunden sein ?
Müsste ich diese dll dann über P/Invoke in C# nutzen oder gibt es dort noch andere Möglichkeiten so das ich auch Instanzen von Objekten dieser Bibliothek erzeugen kann anstatt nur spezifische Funktionen aufzurufen ?
Nachteil davon wäre wohl das ich eine Menge Code quasi neu schreiben müsste und das parsing vermutlich sehr viel aufwändiger wird als in c# da ich dort mal abgesehen von den Mechanismen wie Exceptions etc. auch den comfort von RegEx, Stringbuilder etc verwende.
Sorry für so viele Fragen, aber ich habe was OOP Sprachen angeht wirklich nur Erfahrung mit C# und es ist sehr schwierig das grosse Ganze an Möglichkeiten zu erfassen wenn einem bei jedem Artikel den liest immer neue Dinge unklar sind.
Ich lese mir gerne das erfordelriche Wissen an aber ich brauche einen "Wegweiser" 😉
Danke für die bisherigen Antworten.
Original von Rev
Also unterm Strich wurde hier ja quasi einheitlich die Verwendung von COM vorgeschlagen.
Ja, aber das geht wie gesagt nur auf dem Desktop.
Wie sähe es denn mit dem Ansatz aus das ich meine bestehende Bibliothek in eine native c++ Bibliothek portiere ?
Diese müsste ja dann für Java leicht zugänglich sein oder ? Und c++ hätte ich damit dann ja eh erschlagen.
Ist ein win32 dll Projekt dann das was ich suche ? Darf diese MFC gebunden sein ?
Da ist der einzige Weg. Allerdings darf diese DLL auf keinen Fall objektorientiert sein. Nur reine Funktionsaufruf sind möglich.
Müsste ich diese dll dann über P/Invoke in C# nutzen
So ist es. Unter Java heisst das Pendant JNI.
Also soweit ich jetzt einen Überblick habe:
COM
Pro:
- Objektorientiert
- comfortable .NET Bibliotheken können weiterhin verwendet werden
Contra: - benötigt CLR bzw .NET Framework installation
- seperate Parser-Projekte für PocketPC und Desktop benötigt
- relativ aufwändig umzusetzen und zu verwenden (vermutung für Java)
native dll (win32 dll projekt?)
Pro:
- kann "standalone" fast überall verwendet werden
Contra: - c# code muss vollständig nach c++ portiert werden (wie siehts mit MFC aus? oder welche Bibliotheken würde ich da am besten verwenden?)
- nicht objektorientiert
Wenn jemand diese Überlegungen noch einmal Kommentieren bzw. vervollständigen könnte wäre das sehr hilfreich.
Dankeschön !
Original von Rev
- benötigt CLR bzw .NET Framework installation
Wenn du irgendeine .NET-Komponente laufen lassen willst brauchst du immer .NET, egal ob die .NET-Komponente auch als COM nutzbar ist oder nicht.
- seperate Parser-Projekte für PocketPC und Desktop benötigt
Nein, managed COM geht unter Pocket GAR NICHT.
- relativ aufwändig umzusetzen und zu verwenden (vermutung für Java)
Nein, im Prinzip nicht so furchtbar aufwändig. Die COM->Java-Bridges werden vermutlich auch nicht besonders schwierig zu nutzen sein.
Original von svenson
- seperate Parser-Projekte für PocketPC und Desktop benötigt
Nein, managed COM geht unter Pocket GAR NICHT.
Das war anders gemeint. Ich könnte den Code aus der PocketPC dll in eine Desktop dll copy/pasten, diese Desktop dll dann für COM-Funktionalität erweitern/anpassen und müsste dann bei Änderungen beide Projekte parallel pflegen.
Das ist natürlich nicht so schön, aber ich tendiere fast zu dieser Lösung, da am Code eher nicht so viele Änderungen anfallen werden.
Vorteil ist das sich dann Pocket PC seitig garnichts ändert und ich die parsing routinen nicht neu schreiben und somit auch nicht neu debuggen muss (sehr aufwändig).
Allerdings muss der Kunde noch abklären ob er vollständige Platformunabhängigkeit benötigt. Falls ja, kann ich COM eh knicken und werde dann den mühsamen Weg gehen und die ganze C# dll in eine Funktionsbasierte c++ dll portieren.
In dem ganzen Zusammenhang fand ich diesen Codeproject Artikel noch recht interessant.
Allerdings sehe ich nicht das es Vorteile gegenüber COM bringen würde oder übersehe ich da etwas ?
Danke nochmal für die Diskussion, hat mir geholfen.
Rev
Vielleicht habe ich dich falsch verstanden, aber ich dachte, dass dein .NET-Assembly auch weiterhin auf Pocket PC für C++/Java zur Verfügung stehen soll. Offenbar willst du aber diese Pocket PC-Dll jetzt auf dem Desktop ausführen und DORT für Java und C++ zur Verfügung stellen. In diesem Falle wäre COM das Mittel der Wahl.
Leider erlaubt es VS2005 nicht, ein Projekt gegen verschiedene Frameworks zu compilieren, aber Assemblies, die unter CF laufen, tun das auch OHNE Recompilation im Full-Framework. Ausnahme sind natürlich Assemblies, die z.B. via PInvoke reine Windows-CE-Funktionen nutzen.
Wenn du COM wählst, musst du aber deinen Code modifizieren, so dass er sich nur noch unter Full-Framework compilieren läßt. Das kann man aber mit einer Fassade lösen, so dass der fachliche Code nicht getrennt gepflegt werden muss.
Original von svenson
Offenbar willst du aber diese Pocket PC-Dll jetzt auf dem Desktop ausführen und DORT für Java und C++ zur Verfügung stellen.
Genau so ist es! Sorry, da habe ich mich dann evtl nicht deutlich genug ausgedrückt.
In diesem Falle wäre COM das Mittel der Wahl.
...falls keine Platformunabhängigkeit erforderlich ist.
Wenn du COM wählst, musst du aber deinen Code modifizieren, so dass er sich nur noch unter Full-Framework compilieren läßt. Das kann man aber mit einer Fassade lösen, so dass der fachliche Code nicht getrennt gepflegt werden muss.
Ah, gute Idee. Du meinst also noch eine zusätzliche COM-Klassenschicht erstellen welche dann die bereits bestehende c# dll verwendet anstatt nur die bereits bestehende Struktur anzupassen ?
Original von Rev
Du meinst also noch eine zusätzliche COM-Klassenschicht erstellen welche dann die bereits bestehende c# dll verwendet anstatt nur die bereits bestehende Struktur anzupassen ?
So isses.
COM scheint doch zu gehen: