ExtensibleClassFactory



  • Hi.

    Folgendes problem:
    Ich habe ein C++/CLI assembly, dass einen Satz an COM Objekten zu verfügung stell. Nun möchte ich noch einige bestehende Klassen mehr hinzunehmen, allerdings sind auf C++ + ATL basierend.
    Was ich will, ist diese nativ objects auch über den managed part zur verfügung zu stellen, so das ich die versionsverwaltugn ect. auch für die habe (wenn sie als 'normales' COM object registrie gibt's das ja nicht, das wir der InprocServer32 key ja einfach überschrieben).

    Was ich brauche ist also eine C++/CLI class factory, welche mit ein C++ & ATL object erzugen kann.
    Bin da auf ExtensibleClassFactory stoßen, das auf den ersten Blick so aussieht als würde es genau das können was ich brauche, nur bekomme ich es nicht um laufen.
    Alles was das sample aus der MSDN bei mir macht ist einer System.InvalidOperationException beim RegisterObjectCreationCallback aufruf zu werfen.

    Hat jemand irgend welche tips für mich wie ich das hin bekommen?
    (nein, ich will den nativ c++ code nicht verändern / managed machen, der soll so bleiben wie erst. Nur das class factory soll managed sein).
    Danke!



  • CMatt schrieb:

    Ich habe ein C++/CLI assembly, dass einen Satz an COM Objekten zu verfügung stellt.

    Du meinst wohl: Du hast eine (native) C++ COM-DLL..

    Oder was für einen Sinn sollte es machen eine C++/CLI Assembly zu haben, welche COM-Objekte zur Verfügung stellt?
    C++/CLI macht nur Sinn, wenn Du managed Klassen zur Verfügung stellst...

    CMatt schrieb:

    Nun möchte ich noch einige bestehende Klassen mehr hinzunehmen, allerdings sind auf C++ + ATL basierend. Was ich will, ist diese nativ objects auch über den managed part zur verfügung zu stellen

    Das einfachste ist immer noch einen simplen Wrapper drum rum zu schreiben... ist eigentlich kein grosser Akt...

    CMatt schrieb:

    , so das ich die versionsverwaltugn ect. auch für die habe (wenn sie als 'normales' COM object registrie gibt's das ja nicht, das wir der InprocServer32 key ja einfach überschrieben).

    Was meinst Du mit Versionsverwaltung: DLL-Hell?
    Oder verschiedene Versionen Deines COM-Objekts?

    CMatt schrieb:

    Was ich brauche ist also eine C++/CLI class factory, welche mit ein C++ & ATL object erzugen kann.

    COM-Objekte kannst Du auch ganz simple mittels

    Type t = Type.GetTypeFromProgID(progID);
    object comObject = Activator.CreateInstance(t);
    

    erzeugen.

    CMatt schrieb:

    (nein, ich will den nativ c++ code nicht verändern / managed machen, der soll so bleiben wie erst.

    Wie gesagt, das einfachste ist ein simplen Wrapper... der die Aufrufe einfach nur durchreicht...



  • Du meinst wohl: Du hast eine (native) C++ COM-DLL..
    Oder was für einen Sinn sollte es machen eine C++/CLI Assembly zu haben, welche COM-Objekte zur Verfügung stellt?

    Nein, ich mein schon ein assembly, ist nur etwas unglück beschrieben, das assebmly wird per COM-Interop aus anderen Applikationen verwendet, also mit [ComVisisble(true)] vor ref class.

    Also ein wrapper ist mir ehrlich gesagt auch zu viel abreitet, da ich dann die ganzen interfaces in interface class verpacken muss (sind ne menge 🙂 ).
    Was ich haben möchste ist eine anstädige version-verwaltung für meine COM Objecs. Möchte das genau so haben wie es .NET macht. ein XML file mit zur exe und das CoCreateInstance nimmt dann die assembly version die angegeben ist, nicht die welche als letztes registriert wurde (standard COM weg).
    Mir ist klar das genau das schon unter dem Namen Side-by-side Assemblies gibt, allerdings nur unter >= XP, möchte das aber ich für 2k habe (ich weiß, ich bin kompliziert.. 😃 )

    Die schnellest/einfachste möglichkeit die mir einfällt ist eine managed class factory.
    Mein nativ code würde zu 100% gleich bleiben, ich brauche keinen proxy, gar nichts. Der einzige unterschied, die class factory wird nicht mehr von der ATL registriert/implementiert sonder per C++/CLI. Das hat den vorteil, dass ich mehrer versionen gleizeitig registrieren kann. Per manifest wählt die exe die gewünschte aus, erzeugt sie und diese wiederum zieht mir meine nativ C++ objects hoch.
    Wenn es so geht wäre das extrem einfach/schnell. Einfach DllRegister/Unregister weg lassen, die CLR die class factories registrieren lassen und ne Liste alegen damit die factory weiß welche nativ object zu welche GUID passt (kann so aufbauen, dass es noach aussen gleich aussieht wie die ATL, dann braucht nicht mal de ne Zeile code zu ändern), fertig. 🤡



  • [quote="CMatt"]

    Du meinst wohl: Du hast eine (native) C++ COM-DLL..
    Oder was für einen Sinn sollte es machen eine C++/CLI Assembly zu haben, welche COM-Objekte zur Verfügung stellt?

    Aber wenn Du schon eine "ref class" hast, was willst Du dann noch mit COM!???
    Oder willst Du eine native-Klasse schreiben, welche Deine C++/CLI-COM Klassen zur Verfügung stellen soll?

    Deinen Weiteren Ausführungen folgend, kann ich nur sagen: Hab sowas noch nie gemacht und bezweifle auch ob das "ComVisible" so flexibel ist wie Du das willst...



  • [quote="Jochen Kalmbach"]

    CMatt schrieb:

    Du meinst wohl: Du hast eine (native) C++ COM-DLL..
    Oder was für einen Sinn sollte es machen eine C++/CLI Assembly zu haben, welche COM-Objekte zur Verfügung stellt?

    Aber wenn Du schon eine "ref class" hast, was willst Du dann noch mit COM!???
    Oder willst Du eine native-Klasse schreiben, welche Deine C++/CLI-COM Klassen zur Verfügung stellen soll?

    Deinen Weiteren Ausführungen folgend, kann ich nur sagen: Hab sowas noch nie gemacht und bezweifle auch ob das "ComVisible" so flexibel ist wie Du das willst...

    Mit einer ref class kann eine MFC appliktion aber wenig anfangen, deshalb das [ComVisible(true)] und ein CoCreateInstance auf MFC seite 😉

    Mit ComVisible(true) hat der 2. teil, die ATL klassen ja nicht zu zun. Das ist ja nur der managed part meines assemblies, der Funktionier ja bestens.

    Naja.. werde noch mal etwas mit ExtensibleClassFactory/RegisterObjectCreationCallback rumbastelen. Wenn das teil funktionieren würde würde es genau das machen was ich will, statt das die CLR meine objekte erzeugt macht es ein von mir implementiertes delegt, dass den einfach ein nativ object hoch zieh und das zurück gibt.


Anmelden zum Antworten