[Delphi/C#] Eigenes PlugIn System übersetzen nach C#

[RWarnecke]

Hallo zusammen,

ich habe für mein Programm Code-Orakel ein PlugIn-System erstellt. Dieses funktioniert auch hervorragend mit Delphi. Nun habe ich aus der Entwickler-Ecke die Anfrage erhalten, ob ich auch ein SDK für C# erstellen kann.

Da ich aber C# nicht so gut kenne wie Delphi ist meine erste Frage, ob ich das jetzige PlugIn-SDK von Delphi einfach übersetzen kann oder ob ich mein PlugIn-System nochmal komplett überarbeiten muss ?

Reicht Visual C# Express für die Übersetzung völlig aus oder brauche ich eine höhere Version ?

[Elvis]

Deine Interfaces nutzen Register als Aufrufskonvention, IOW die wohl mit Abstand schlechteste Wahl, die du hättest nehmen können.
Damit kannst natürlich alle Compiler außer Delphi, BCB und FPC vergessen.

Fix das lieber solange es noch geht.
Außer es gibt schon zu viele nicht mehr aktiv gepflegte Plugins für dein Programm.
Hier konnte ich mir irgendwann mal von einigen sehr weitsichtigen Leuten anhören wie sinnlos es ist das gleich von Anfang an richtig zu machen... :roll:

[RWarnecke]

Hallo Robert,

irgendwie verstehe ich Deinen Post noch nicht. Ich glaube, ich habe da noch Nachholbedarf was Interfaces angeht. Ich habe mir den Thread aus Deinem Link durchgelesen, aber so richtig verstanden habe ich es nicht. Kannst Du es mir vielleicht anhand eines kleinen Beispiels erklären bitte. Mein Verständnis von Interfaces war bis jetzt, dass ich damit eine externe Schnittstelle für ein Programm schaffen kann um zum Beispiel PlugIns zuzulassen.

Zitat:

Zitat von Elvis (Beitrag 1203918)

Fix das lieber solange es noch geht.
Außer es gibt schon zu viele nicht mehr aktiv gepflegte Plugins für dein Programm.
Hier konnte ich mir irgendwann mal von einigen sehr weitsichtigen Leuten anhören wie sinnlos es ist das gleich von Anfang an richtig zu machen... :roll:

Wie viele PlugIns es gibt weiß ich nicht. Aber die jetzige PlugIn-Schnittstelle gibt es erst seit Version 1.2.0. Deshalb weiß ich nicht, ob es noch machbar ist umzubauen. Aber ich interessiere mich trotzdem für beide Varianten.

[jfheins]

Zitat:

Mein Verständnis von Interfaces war bis jetzt, dass ich damit eine externe Schnittstelle für ein Programm schaffen kann um zum Beispiel PlugIns zuzulassen.

Das sit ja auc richtig. Aber nur Funktionen aufrufen reicht nicht, der Computer muss auch wissen wie er die Funktionen aufrufen muss. dazu gehören solche Sachen wie "In welcher reihenfolge werden die Parameter übergeben?" und "Wer räumt nachher auf? Der Aufrufer oder die Funktion?" also grob: "In welchen Zustand wird die CPU zurückgelassen nachdem die Funktion beendet ist?"

Da das Problem natürlich überall aufgetaucht ist, haben sich Konventionen gebildet (ja, Plural) und Pascal hatte eben eine andere als C. Die von pascal heißt register, die von C heißt stdcall.

Pascal kann auch Funktionen erzeugen die sich an die stdcall-Konvention halten, die müssen aber gekennzeichnet werden. Umgekehrt kann C keine Funktionen erzeugen oder aufrufen, die sich an die register-Konvention halten.

Ergo: Die interfaces ermöglichen zwar Plugins. Da du aber keine Konvention explizit geschrieben hast, nimmt der Delphi-Compiler register als Aufrufkonvention. Da er das tut, kannst du diese Funktionen wieder nur aus Pascalcode aufrufen. Die Plugins müssen also zwangsläufig in Pascal geschrieben sein!

[Robotiker]

Zitat:

Zitat von jfheins (Beitrag 1203920)

die von C heißt stdcall.

Als Konvention bei Interfaces, insbesondere COM, ja. Die standard Aufrufkonvention ist aber sowohl beim BCB als auch VC++ cdecl, nicht stdcall. Die Unterschiede liegen im Aufräumen des Stacks
http://msdn.microsoft.com/en-us/libr...vs.100%29.aspx

[Phoenix]

Zitat:

Zitat von RWarnecke (Beitrag 1203916)

ich habe für mein Programm Code-Orakel ein PlugIn-System erstellt. Dieses funktioniert auch hervorragend mit Delphi. Nun habe ich aus der Entwickler-Ecke die Anfrage erhalten, ob ich auch ein SDK für C# erstellen kann.

Hat derjenige Ahnung von .NET?
Sorry, aber ein taugliches Plugin-System kann ich für .NET in 10 Minuten herzaubern und habe das schon mehrfach gemacht. Wieso sollte man dazu ein SDK nutzen? Assembly laden, bestimmte für das Plugin-System definierte Interfaces mit Reflection rausziehen und go. Dazu braucht man nicht mehr als die Hausmittel liefern, und alles andere geht vermutlich stark am eigenen Use-Case vorbei.

[RWarnecke]

Zitat:

Zitat von Phoenix (Beitrag 1203929)

Hat derjenige Ahnung von .NET?
Sorry, aber ein taugliches Plugin-System kann ich für .NET in 10 Minuten herzaubern und habe das schon mehrfach gemacht. Wieso sollte man dazu ein SDK nutzen? Assembly laden, bestimmte für das Plugin-System definierte Interfaces mit Reflection rausziehen und go. Dazu braucht man nicht mehr als die Hausmittel liefern, und alles andere geht vermutlich stark am eigenen Use-Case vorbei.

Das Wort SDK habe ich selber dazu geschrieben. Verstehe ich Deine Aussage richtig, dass ich in C# einfach eine Unit schreibe, womit dann das PlugIn erstellt werden kann, so wie mit dem Beispiel aus meinem Download ?

[Furtbichler]

Ja, Du musst nur eine C#-Klasse erstellen, die dein COM-Interface implementiert.

Hier steht, wie das geht.

[BlackSeven]

Zitat:

Zitat von Phoenix (Beitrag 1203929)

Sorry, aber ein taugliches Plugin-System kann ich für .NET in 10 Minuten herzaubern und habe das schon mehrfach gemacht.

Hast Du dazu ein Beispiel? Würde mich brennend interessieren.

[Furtbichler]

Na, ich glaube er meint: Deklariere dein IPlugin-Interface, erzeuge ein paar DLL mit jeweils einer Klasse, die das IPlugin-Interface implementieren, schmeiss die DLL in ein Verzeichnis und zum dynamischen laden lädst Du die Assemble und fragst mit Reflection, ob die exportierte Klasse in der DLL das IPlugin-Interface implementiert.

Code:

...
  Assembly assembly = Assembly.LoadFile(fullFilename);
  foreach (Type type in assembly.GetTypes())
    if (type.IsClass && type.IsPublic)
       if (type.GetInterfaces().Contains(typeof(IPlugin)))
          // type ist eine Plugin-Klasse und kann jetzt verwendet werden.
...