C# Delegates in Delphi konsumieren

[Nic2012]

Hallo,
analog zu diesem Beispiel
http://www.drbob42.com/examines/examin36.htm
habe ich in VisualStudio2010 ein Com Object in C# erstellt, dessen Getter und Setter ich problemlos in Delphi7 konsumieren kann.

Wie müsste man aber in C# Delegates so deklarieren, daß ich sie in der D7-Anwendung als Callback ansprechen kann?

Gruß,
Nic

[Bernhard Geyer]

Eine Möglichkeit wäre sie sichtbar für COM zu machen:

http://msdn.microsoft.com/de-de/libr...attribute.aspx

[generic]

Ich glaube nicht, dass das geht.

Über COM kannst du nur Interfaces austauschen und keinen Zeiger auf eine Funktion.
ggf. den Delegaten in ein Interface bzw. Objekt einwickeln.

[Robotiker]

Außerhalb von COM gibt es da Wege, es gibt ja z.B.
http://msdn.microsoft.com/de-de/libr...rdelegate.aspx

Aber eventuell muss man da mit VC++ eine mixed DLL schreiben, mit einer nativen und managed Seite. Die packt man dann zwischen Delphi und C#.

http://stackoverflow.com/questions/2...unmanaged-code

[generic]

VC++ ist nicht erforderlich, denn Delphi kann eben so DLL erzeugen.
Wichtig ist nur der Export der Funktionen.

Allerdings passt dann das Beispiel bei Stackoverflow natürlich nicht mehr.

PInvoke ist dann das Stichwort.

[Robotiker]

Zitat:

Zitat von generic (Beitrag 1204131)

VC++ ist nicht erforderlich, denn Delphi kann eben so DLL erzeugen.

Nur VC++ kann DLLs erzeugen, die gleichzeitig nativ und managed sind. In der Anwort auf Stackoverflow wird das ja benutzt (in einer Exe keiner DLL).

[Edit]
Also Delphi-EXE ruft (C-Seite) der VC++ DLL, diese verweist auf die C# DLL. Ein Delegate Aufruf aus C# landet in der VC++ DLL diese kann z.B. einen Callback aus der Delphi-Exe aufrufen.

[Elvis]

Zitat:

Zitat von Robotiker (Beitrag 1204142)

Nur VC++ kann DLLs erzeugen, die gleichzeitig nativ und managed sind.

*Hust*

[Robotiker]

Zitat:

Zitat von Elvis (Beitrag 1204157)

*Hust*

Gesundheit.

Sieht nach einer Notlösung für einfache Fälle aus. Geht auch nur in die eine Richtung. Einen Custom RCW kriegt man da nur mit einer weiteren nativen Hilfs-DLL und viel Handarbeit hin. (Ja, es gibt auch http://msdn.microsoft.com/en-us/library/x8fbsf00.aspx
bevor du einen chronischen Husten kriegst.)

Auf Dinge wie die Marshalling-Lib und andere Dinge die es nur in VC++ Headern und Libs gibt müsste man dann verzichten.

[Nic2012]

Basierend nach diesem Vorschlag http://www.systemwidgets.com/Blog/ta...M-clients.aspx klappt es:

Der C# Com-Server:

Code:

using System;
using System.Runtime.InteropServices;
using System.Threading;

namespace ComDog
{
    [ComVisible(false)]
    public delegate void DogEventHandler();

    [ComVisible(true)]
    [Guid("2406DD50-A3CE-43A6-9F20-112B621CB784")]
    [InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIDispatch)]
    public interface IDogEvents
    {
        [DispId(1)]
        void Bark();
        [DispId(2)]
        void Howl();
        [DispId(3)]
        void Eat();
    }

    [ComVisible(true)]
    [Guid("8C6DAD17-0612-4166-AD35-3A55DDEAF62E")]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    [ComSourceInterfaces(typeof(IDogEvents))]
    public class Dog : MarshalByRefObject
    {
        [ComVisible(false)]
        private Timer _timer;

        public event DogEventHandler Bark;
        public event DogEventHandler Howl;
        public event DogEventHandler Eat;

        public Dog()
        {
            _timer = new Timer(new TimerCallback(timer_tick));
            _timer.Change(5000, 2000);
        }

        private void timer_tick(object state)
        {
            MakeDogBark();
        }

        public void MakeDogBark()
        {
            if (Bark != null)
            {
                Bark();
            }
        }

        public void MakeDogHowl()
        {
            if (Howl != null)
            {
                Howl();
            }
        }

        public void MakeDogEat()
        {
            if (Eat != null)
            {
                Eat();
            }
        }
    }
}

Und aus einer Delphi7 Client Anwendung:

Code:

...
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ComDog_TLB, StdCtrls;

type
  TForm1 = class(TForm)
    Memo1: TMemo;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
  protected
    procedure Barked(Sender: TObject);
    procedure Howled(Sender: TObject);
    procedure Ate(Sender: TObject);
  public
  end;

var
  Form1: TForm1;
  TestDog: TDog;
  iDog: _Dog;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  iDog := CoDog.Create;

  TestDog := TDog.Create(self);
  TestDog.ConnectTo(iDog);

  TestDog.OnBark := Barked;
  TestDog.OnHowl := Howled;
  TestDog.OnEat := Ate;
end;

procedure TForm1.Barked(Sender: TObject);
begin
  Memo1.Lines.Add('Event from COM: Dog Barked');
end;

procedure TForm1.Howled(Sender: TObject);
begin
  Memo1.Lines.Add('Event from COM: Dog Howled');
end;

procedure TForm1.Ate(Sender: TObject);
begin
  Memo1.Lines.Add('Event from COM: Dog ate something');
end;


procedure TForm1.FormDestroy(Sender: TObject);
begin
  if (TestDog <> nil) then
    TestDog.Free;
end;
...

Erhalte ich 5sec nachdem der COM-Server instanziert wurde alle 2 sec das Event "Bark" angezeigt im Memo.

Sieht gut aus oder ?
Gruß,
Nic

[Robotiker]

Zitat:

Zitat von Nic2012 (Beitrag 1204163)

Sieht gut aus oder ?

In der Tat, ja. Dann bleiben Dir komplizierte Nicht-COM Lösungen erspart.

[Elvis]

Zitat:

Sieht gut aus oder ?

Nein, gar nicht.
Ein Event ist sowas wie eine Property. Man hat keinen Zugriff auf das Delegate, kann nur Handler hinzufügen oder entfernen (wenn man sie auch kennt!)
Der Hack auf der Seite führt macht doch das Deklarieren des Events als EVENT (nicht Property) komplett banane.
Das wirkt auf mich als hätte er solange rumprobiert, bis irgendwas ging...
Ein einfacher Event-Subscription-Mechanismus, der in .Net und anderen Umgebungen (wie Delphi) sehr gut funktioniert, sind Subscription wie man sie aus Java kennt: http://www.delphipraxis.net/173317-%...ml#post1204018
Außerdem musst du IDispatch nehmen, also bekommst du weder Code-Completion, noch Compiler-Meldungen wenn du dich vertippst.

Ich bleibe mal bei deinem Hundebeispiel...
Hier die Interfaces:

Code:

[ComVisible(true),
    InterfaceType(ComInterfaceType.InterfaceIsIUnknown),
    Guid("22396704-484A-43CE-AA8D-0765DB317562")]
public interface INotifyEventHandler
{
    void Invoke([MarshalAs(UnmanagedType.IUnknown)] object sender);
}

[ComVisible(true),
    InterfaceType(ComInterfaceType.InterfaceIsIUnknown),
    Guid("5B127B2D-4433-43DA-87A6-28B8CBF725D7")]
public interface INotifyEvent
{
    void Add(INotifyEventHandler handler);
    void Remove(INotifyEventHandler handler);
}

[ComVisible(true),
    Guid("45A15623-E99C-466E-AE76-BFB4500CC900"),
    InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IDog
{
    INotifyEvent Bark { get; }
    INotifyEvent Howl { get; }
    INotifyEvent Eat { get; }
    void PerformBark(int howOften);
}

Delphi-Quellcode:

INotifyEventHandler = interface(IUnknown)
  ['{22396704-484A-43CE-AA8D-0765DB317562}']
  procedure Invoke(const sender : IUnknown); safecall;
end;

INotifyEvent = interface(IUnknown)
  ['{5B127B2D-4433-43DA-87A6-28B8CBF725D7}']
  procedure Add(const handler: INotifyEventHandler); safecall;
  procedure Remove(const handler: INotifyEventHandler); safecall;
end;

IDog = interface(IUnknown)
['{45A15623-E99C-466E-AE76-BFB4500CC900}']
  function GetOnBark : INotifyEvent; safecall;
  function GetOnHowl : INotifyEvent; safecall;
  function GetOnEat : INotifyEvent; safecall;

  property OnBark : INotifyEvent read GetOnBark;
  property OnHowl : INotifyEvent read GetOnHowl;
  property OnEat : INotifyEvent read GetOnEat;

  procedure Bark(aHowOften : Integer); safecall;
end;

hier die Implmentierung in C#. Achte auf das "DllExport", um das zu kriegen musst du einen Rechtsklick auf dein Projekt machen, "manage Nuget Packages" und in dem Dialog suchst du nach dllexport (siehe screenie).

Code:

public class NotifyEvent : INotifyEvent
{
    private readonly ISet<INotifyEventHandler> _Handlers = new HashSet<INotifyEventHandler>();

    public void Add(INotifyEventHandler handler)
    {
        _Handlers.Add(handler);
    }

    public void Remove(INotifyEventHandler handler)
    {
        _Handlers.Remove(handler);
    }

    public void Invoke(object sender)
    {
        var handlersCopy = _Handlers.ToList();
        handlersCopy.ForEach(h => h.Invoke(sender));
    }
}

public class CSharpDog : IDog
{
    public INotifyEvent Bark
    {
        get { return _Bark; }
    }

    public INotifyEvent Howl
    {
        get { return _Howl; }
    }

    public INotifyEvent Eat
    {
        get { return _Eat; }
    }

    readonly NotifyEvent _Bark = new NotifyEvent();
    readonly NotifyEvent _Howl = new NotifyEvent();
    readonly NotifyEvent _Eat = new NotifyEvent();

    public void PerformBark(int howOften)
    {
        for (int i = 0; i < howOften; i += 1)
        {
            _Bark.Invoke(this);
        }
    }

    [DllExport]
    static void CreateDog([MarshalAs(UnmanagedType.Interface)]out IDog dog)
    {
        dog = new CSharpDog();
    }
}

Auf der Delphi-Seit brauchen wir eine Implementierung für einen Eventhandler:

Delphi-Quellcode:

TNotifyEventHandler = class(TInterfacedObject, INotifyEventHandler)
private
  fCallback : TProc<IUnknown>;
protected
  procedure Invoke(const sender : IUnknown); safecall;
public
  constructor Create(aCallBack: TProc<IUnknown>); overload;
  constructor Create(aCallBack: TProc); overload;
end;

{ TNotifyEventHandler }

constructor TNotifyEventHandler.Create(aCallBack: TProc<IUnknown>);
begin
  fCallback := aCallBack;
end;

constructor TNotifyEventHandler.Create(aCallBack: TProc);
begin
  fCallback := procedure(sender : IUnknown) begin
    aCallBack();
  end;
end;

procedure TNotifyEventHandler.Invoke(const sender: IInterface);
begin
  fCallback(sender);
end;

Und das war's dann fast schon. Im C# Projekt musst du noch die CPU-Plattform passend zu deinem Delphi-Projekt (wohl x86) wählen.

Delphi-Quellcode:

procedure CreateDog(out dog : IDog); stdcall; external 'DeineCSharpClassLibrary';

var
  dog : IDog;
  barkCounter : Integer;
begin
  CoInitialize(nil);
  CreateDog(dog);
  barkCounter := 0;

  dog.OnBark.Add(TNotifyEventHandler.Create(procedure begin
      inc(barkCounter);
  end));

  dog.Bark(6);
  dog.Bark(2);

  Writeln('dog barked ', barkCounter, ' times...');
end.

Zitat:

Zitat von Ouput

dog barked 8 times...

Zitat:

Zitat von Robotiker (Beitrag 1204166)

In der Tat, ja. Dann bleiben Dir komplizierte Nicht-COM Lösungen erspart.

Genau, weil Com-Registrierungen auch immer problemlos funzen und jeder sich so gut mit SxS auskennt, dass auch wirklich jeder alles ohne globale Registrierung lösen kann...

Sicherlich ist COM/Interop ein sehr guter Weg für viele, gerade komplexere, Szenarios. aber COM ist auch saumäßig frickelig und kommt mit seinen eigenen Problemen daher. Zum Glück kann man fast alle COM-Goodies aus .Net ohne COM benutzen. Macht C++/CLI die meiste Zeit über auch nicht anders.

Einfach so zu behaupten, dass man keine RCWs über Reverse P/Invoke kriegt, oder es nur als Notlösung taugt, halte ich für ein Indiz einer sehr dogmatische Sichtweise. Ich kann mir kaum vorstellen, dass du wirklich so engstirnig bist.

[Robotiker]

Zitat:

Zitat von Elvis (Beitrag 1204192)

Sicherlich ist COM/Interop ein sehr guter Weg für viele, gerade komplexere, Szenarios. aber COM ist auch saumäßig frickelig und kommt mit seinen eigenen Problemen daher.

Da wiederspreche ich dir in keinen Punkt. Aber der Fragesteller hatte schon mit COM begonnen und da ist das sicher für ihn ein praktikabler Weg. Insoweit stehe ich da zu meiner Aussage.

Was meine Engstirnigkeit angeht, ich komme von ursprünglich von Borland C++ und benutzte Delphi gelegentlich, weil es die "Haussprache" des C++ Builders ist, mit dem ich noch einige alte Sachen warten muss. Meine Haupt IDE ist Visual Studio, seit .net 1.0, ich habe also schon einige Interop-Geschichten hinter mir.

Meine Erfahrungen daraus ? Ich benutzt PInvoke wo es geht, sonst C++/CLI, kein COM.

Natürlich kann man bei einem Callback in C# schreiben

Code:

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate void MyCallback(IntPtr buffer, uint size)

und dann mit Byte-Array und Marshal.PtrToStructure rumtun. (Ganz toll wird das, wenn man als Parameter ein Array von C-structs kriegt, die selber wieder Pointer auf structs enthalten ...)

Ich nehme halt dann in komplizierten Fällen, oder welchen die sich dahin entwickeln könnten, C++/CLI. Andere auch. Das man das als Delphi Entwickler prinzipiell nicht macht, "weil das der Feind ist", kann ich verstehen, geht mir aber ehrlich gesagt am A... vorbei.

[generic]

Zitat:

Zitat von Robotiker (Beitrag 1204142)

Zitat:

Zitat von generic (Beitrag 1204131)

VC++ ist nicht erforderlich, denn Delphi kann eben so DLL erzeugen.

Nur VC++ kann DLLs erzeugen, die gleichzeitig nativ und managed sind. In der Anwort auf Stackoverflow wird das ja benutzt (in einer Exe keiner DLL).

Ja, richtig - mixed DLLs NUR mit VC. Nun kann nicht jeder Entwickler gleich alle Sprachen Delphi,C# und VC.

Daher meinte ich, dass man mit Delphi DLLs erzeugen, um diese dann via PInvoke einbinden.

[Robotiker]

Zitat:

Zitat von generic (Beitrag 1204262)

Nun kann nicht jeder Entwickler gleich alle Sprachen Delphi,C# und VC.

Das stimmt. Aber ich hab ja ursprünglich nur geschrieben

Zitat:

Zitat von Robotiker (Beitrag 1204123)

Außerhalb von COM gibt es da Wege, es gibt ja z.B.

Mehr, als dass man so eine "Doppelstecker-DLL" bauen kann, wollte ich ja gar nicht sagen.

[Elvis]

Zitat:

Zitat von Robotiker (Beitrag 1204254)

Meine Erfahrungen daraus ? Ich benutzt PInvoke wo es geht, sonst C++/CLI, kein COM.

Schaue dir mal mein Nuget package an. (Mein Beispiel oben erfordert nur eine leere Classlibrary in C# in die man das Nuget Package packt, und eine Console App in Delphi)

Exportierte Funktionen aus C# könnten den C++/CLI-Anteil bei dir auf die Stellen zusammenschrumpfen lassen, bei denen du das autom. Konvertieren von C++ <-> .Net Typen nutzen willst, die sich nur sehr frickelig mit Marshaling-Attributen oder CustomMarshaler ausdrücken lassen.

Zitat:

Natürlich kann man bei einem Callback in C# schreiben

Kann man, aber wie lädst du den aus einer nativen App ohne von München über Berlin nach Augsburg zu fahren?

Zitat:

Ich nehme halt dann in komplizierten Fällen, oder welchen die sich dahin entwickeln könnten, C++/CLI. Andere auch. Das man das als Delphi Entwickler prinzipiell nicht macht, "weil das der Feind ist", kann ich verstehen, geht mir aber ehrlich gesagt am A... vorbei.

So war das nicht gemeint. Ich war nur etwas baff, weil du den Weg über COM (der sau-komplex ist, wenn man all den möglichen Deployment-Ärger mit einbezieht!) als einfach, aber eine C# "DLL" mit einer exportierten Funktion als kompliziert bezeichnet hast.
Den komischen Hack, der auf der Page da gezeigt wird noch nicht einmal eingerechnet. :?

[Nic2012]

Jo richtig der Entw. aus http://www.systemwidgets.com/Blog/ta...M-clients.aspx erwähnte auch, dass ihm dieser Wurf nach vielem Probieren erst gelungen ist. Zu dem Thema ist nun im Web auch wenig zu finden, und das liegt bestimmt nicht daran, dass es "trivial" ist. Den Entwurf von Elvis habe ich aber noch nicht ganz verstanden:

Zitat:

Außerdem musst du IDispatch nehmen

Hatte ich das nicht im Interface der Events getan ? Oder meint er statt ClassInterfaceType.AutoDual der Hauptklasse ?
Also der "schlechte" Entwurf funktioniert und macht das was er soll, aber ich lerne gern noch dazu, nur bitte für diese komplexe Thema vertiefte Angaben:
Wird im Entwurf von Elvis noch ein Com-Object erzeugt oder ist das eine Lib ?
In dem Delphi Client spreche ich das Com-Interface an und die exportierte DLL ?

[Elvis]

Zitat:

Zitat von Nic2012 (Beitrag 1204331)

Jo richtig der Entw. aus http://www.systemwidgets.com/Blog/ta...M-clients.aspx erwähnte auch, dass ihm dieser Wurf nach vielem Probieren erst gelungen ist. Zu dem Thema ist nun im Web auch wenig zu finden, und das liegt bestimmt nicht daran, dass es "trivial" ist.

Trivial ist Interop nie, nicht wenn man es für etwas sinnvolles benutzen will. ;-)
Aber die Lösung da ist wirklich nicht schön.

Zitat:

Zitat von Nic2012 (Beitrag 1204331)

Den Entwurf von Elvis habe ich aber noch nicht ganz verstanden

Hast du versucht es in einer Delphi Console App und mit einer C# classlibrary nachzubauen? Worüber bist du gestolpert? Ich würde erst bei diesem Beispiel bleiben, und erst dann das Gelernte auf dein Projekt anwenden.

Zitat:

Zitat:

Außerdem musst du IDispatch nehmen

Hatte ich das nicht im Interface der Events getan ? Oder meint er statt ClassInterfaceType.AutoDual der Hauptklasse ?

Ja, IDispatch nehmen zu müssen ist einer der Nachteile der Lösung. Nicht nur weil es keine cOmpiler-Prüfungen mehr gibt.
Denn was da passiert ist, dass du da indirekt einen Event als Property misbrauchst, auch wenn er es nicht ist. Das funktioniert hier nur weil es ebenfalls 2 Methoden sind.
Allerdings dürfte dir schon der Getter Ärger machen. Der Setter sollte funktionieren weil die Signatur des set_ einer Property kompatibel zum add_ eines Events ist. Das get_ einer property ehingegen hat kein Gegenstück bei Events. Vllt. hat Microsoft hier einen Workaround eingebaut der das auf irgendeine kranke Art zurechtbiegt. Würde ich aber selbst dann nicht nutzen wollen...

Zitat:

Wird im Entwurf von Elvis noch ein Com-Object erzeugt oder ist das eine Lib ?
In dem Delphi Client spreche ich das Com-Interface an und die exportierte DLL ?

In meinem Entwurf wird ein Post-Build-Task von mir verwendet, der es ermöglicht aus C# heraus Funktionen zu exportieren. (So wie man es mit Delphi-DLLs kann)
Dieser wird autom. für dich eingerichtet, wenn du das Nuget-Package in dein Projekt registrierst.

Ich nutze in dem Beispiel .Nets Fähikeiten um .Net-Typen kompatibel zu native Typen zu machen. Deshalb müssen die Interfaces ComVisible sein, und man braucht auch eine Guid, da darüber Interfaces in Delphi (und andere anderen System) identifiziert werden.
Außerdem muss ich .Net sagen, dass meine Interface einfach nur von IUnknown erben, und dadurch kompatibel zu Delphi sind.

Im Endeffekt nutze ich also all die Vorteile von .Net-COM/Interop aus, ohne dass man eine COM library registrieren muss.

[Nic2012]

Ich kann Dir noch nicht folgen, also eins nach dem anderen, ich fasse zusammen:

1) In VS-2010 wird eine neue Classlibary C#-DLL angelegt, die wird allerdings nicht als COM registriert noch unterstützt sie Com/Interop. also diesen beiden Schalter im Projekt im Gegensatz zum meinem Beispiel ausschalten
2) Dein Codeentwurf so komplett übernehmen
3) Abschließend die DLL exportieren ? Dabei sind mir die Begriffe "Post-Build-Task" und "Nuget-Package" nicht geläufig...
4) Die erzeugte C#-DLL kopiere ich in das Delphi-Projekt ?
5) In Delphi entfällt der Schritt "Typbiliothek importieren..." ???
Wo wird Deine Interface-Deklaration in das Delphi-Projekt übernommen ?
6) Ich übernehme Deine Implementation in die Delphi-Anwendung, warum darf es nicht der Client sein, sondern eine Console ?
Interface und Implementation kommen erstmal in die gleiche Unit ?
Wäre es möglich, dass Du die komplette Delphi Unit als Attachment ranhängst.

[Elvis]

Zitat:

Zitat von Nic2012 (Beitrag 1204357)

Ich kann Dir noch nicht folgen, also eins nach dem anderen, ich fasse zusammen:
1) In VS-2010 wird eine neue Classlibary C#-DLL angelegt, die wird allerdings nicht als COM registriert noch unterstützt sie Com/Interop. also diesen beiden Schalter im Projekt im Gegensatz zum meinem Beispiel ausschalten

Lass die Einstellungen einfach sie sind/waren.

Zitat:

2) Dein Codeentwurf so komplett übernehmen
3) Abschließend die DLL exportieren ? Dabei sind mir die Begriffe "Post-Build-Task" und "Nuget-Package" nicht geläufig...

Ich habe dir in meinem ersten Beitrag gezeigt, wie man das Nuget-Package in das Projekt bekommt. Da Nuget bei VS2010 noch nicht von Anfang an dabei war, kann es sein, dass du es erst mit dem Extension Manager installieren musst.
Allerdings kompiliert das angehängte Projekt auch ohne Nuget (da das nuget in meinem VS bereits alles eingestellt hat)
VS ohne Nuget ist aber grauenvoll, wenn du Nuget nicht kennst, solltest du das unbedingt nachholen. :-)

Zitat:

4) Die erzeugte C#-DLL kopiere ich in das Delphi-Projekt ?

Wo auch immer du sie haben willst.
In dem angehängten Bespiel habe ich einen gemeinsamen Ausgabeordner für Debug/x86 für Delphi und C#. Dadurch sollten sie sich finden.

Zitat:

5) In Delphi entfällt der Schritt "Typbiliothek importieren..." ???

Ja, man schreibt die Interfaces selbst. Sowohl in Delphi als auch in C#.
Wenn du hierfür für dein eigentliches Projekt Hilfe brauchst, einfach fragen. Dieses Wissen um Interop zahlt sich 1000-fach aus.

Zitat:

Wo wird Deine Interface-Deklaration in das Delphi-Projekt übernommen ?
6) Ich übernehme Deine Implementation in die Delphi-Anwendung, warum darf es nicht der Client sein, sondern eine Console ?
Interface und Implementation kommen erstmal in die gleiche Unit ?
Wäre es möglich, dass Du die komplette Delphi Unit als Attachment ranhängst.

Ich habe ein Archiv angehängt in dem du das C#-projekt und eine Delphi-App findest.
Ich habe in Delphi die Typen, die für das reine Eventhandling nötig sind, in eine eigene Unit gepackt. Die könntest du später enfach übernehmen (haben ja nix mit dem Hund zu tun ;-) ).

Ich habe es in und für Delphi 2010 geschrieben. Das einzige, was in älteren Version nicht geht sind die anonymen Methoden.
Wenn du also ein Delphi nutzt, dass älter als D2010 ist, musst du das sagen, dann muss ich es etwas umschreiben.
Ich habe die Solution in VS2012 erzeugt, ich hoffe ich habe alle Stellen gefunden, über die 2010 stoplern würde... :angel2:

[Nic2012]

Danke, ich habe hier nur Delphi7 und gerade jetzt nur VS2008, ansonsten VS2010, da komme ich jetzt nicht ran. Ich bekomme hier auch Probleme mit dem ISet<INotifyEventHandler> in VS2008.

Was macht Nuget nun wirklich ? Wird ohne N. trotzdem die DLL gebaut ? Oder anders gefragt, wenn ich die Classlib. anpasse, oder gar eine neue DLL schreibe, muss ich das zwingend benutzen, um die o.g. Funktionalität zu bekommen ?

Ist es das hier was ich sonst bräuchte: http://visualstudiogallery.msdn.micr...f-c7cf6bc9970c So wie das sehe gibt es das nur für >= VS 201x.

[Elvis]

Zitat:

Zitat von Nic2012 (Beitrag 1204375)

Danke, ich habe hier nur Delphi7 und gerade jetzt nur VS2008, ansonsten VS2010, da komme ich jetzt nicht ran. Ich bekomme hier auch Probleme mit dem ISet<INotifyEventHandler> in VS2008.

Was macht Nuget nun wirklich ? Wird ohne N. trotzdem die DLL gebaut ? Oder anders gefragt, wenn ich die Classlib. anpasse, oder gar eine neue DLL schreibe, muss ich das zwingend benutzen, um die o.g. Funktionalität zu bekommen ?

Nuget ist ein Package Manager. D.h. er sorgt dafür, dass alle Abhängigkeiten eines Packages vorhanden sind, und dass Scripts des Packages ausgeführt werden, die zum Beispiel einen Build Task eintragen oder neue Code files einbinden.

VS2008 macht IMO überhaupt keinen Sinn mehr. Dann nimm lieber VS2012 Express. Selbst VS 2008 mit Resharper wird dir kaum soviel Wert bieten wie es VS2012 Express mit Nuget kann.

Wenn du mit dem alten VS _jetzt_ weitermachen willst, nimm die Lösung mit IDispatch.
Mein DllExport untertützt nur noch Nuget und damit VS2010.

Ein TNotifyEventImplementierung für D7 liefer ich nachher nach.

[Robotiker]

Zitat:

Zitat von Elvis (Beitrag 1204326)

Schaue dir mal mein Nuget package an. (Mein Beispiel oben erfordert nur eine leere Classlibrary in C# in die man das Nuget Package packt, und eine Console App in Delphi)

Ja, werde ich bei Gelegenheit tun.

Aber, wie schon gesagt, arbeite ich normalerweise mit Visual Studio, auf der nativen Seite hab ich C++. Und da ist

Zitat:

Zitat von Elvis (Beitrag 1204326)

Exportierte Funktionen aus C#

genau das Problem. Du exportierst lediglich Funktionen, die Objektorientierung geht verloren. Das ist doch schon das Problem bei PInvoke. In C++/CLI sieht man die Objekte von beiden Welten.

Aber das führt jetzt wirklich vom Thema dieses Threads weg.

[Elvis]

Zitat:

Zitat von Robotiker (Beitrag 1204408)

genau das Problem. Du exportierst lediglich Funktionen, die Objektorientierung geht verloren. Das ist doch schon das Problem bei PInvoke. In C++/CLI sieht man die Objekte von beiden Welten.

Naja, ich exportiere oft nur eine Factory, die ein Interface zurückgibt. Von da an ist alles OO (siehe hier der Hund).

Zitat:

Aber das führt jetzt wirklich vom Thema dieses Threads weg.

Ja, das ist wohl wahr...