CreateInstance klappt in C#, gleiches aber nicht in VB!?

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    CreateInstance klappt in C#, gleiches aber nicht in VB!?

    Meine Anwendung ist schon recht groß und in Visual Basic geschrieben, deshalb kommt ein umschreiben zu C# nicht in Frage.

    Folgender Code funktioniert einwandfrei in einer Test-C# Anwendung:

    C#-Quellcode

    1. Type xType = Type.GetTypeFromProgID("MGCPCBReleaseEnvironmentLib.MGCPCBReleaseEnvServer");
    2. dynamic EnvInst = Activator.CreateInstance(xType);


    Exakt gleiches nur in VB.NET klappt aber nicht!:

    VB.NET-Quellcode

    1. Dim xTyp As Type = System.Type.GetTypeFromProgID("MGCPCBReleaseEnvironmentLib.MGCPCBReleaseEnvServer")
    2. Dim EnvInst As Object = Activator.CreateInstance(xTyp)

    ...in VB.NET bekome ich zur Laufzeit immer nur den Fehler das die Klasse nicht registriert sei! Aber es geht ja in C# auch fehlerfrei!

    Gibt es einen Grund dafür? Warum klappt es in C# und in .NET nicht?

    Hinti schrieb:

    VB.NET-Quellcode

    1. Dim EnvInst As Object = Activator.CreateInstance(xTyp)
    Wenn Du Option Infer On hast, probierma

    VB.NET-Quellcode

    1. Dim EnvInst = Activator.CreateInstance(xTyp)
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @RodFromGermany ...leider keine Änderung!

    Egal ob "Option Strict" generell auf "Off" schalte und/oder "Option Infer" Off/On, egal welche Kombination, ...
    geht trotzdem nicht. Also ich bekomme es derezti immer nur in C# zum Laufen.

    Mal schauen, ich google jetzt noch eine Weile bezüglich Dynamic Typ in .NET. Finde ich was, poste ich die Lösung.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Hinti“ ()

    dynamic ist kein Typ, es ist ein Feature.
    Es erlaubt dir sämtliche design- und compiletime Checks (sowie IntelliSense) zu dieser Variablen zu umgehen. Wofür?
    Für dynamische Typisierung, und um hier und da etwas zu tricksen.
    Hintergrund ist die sog. Dynamic Runtime Library, oder DLR als Abkürzung, und baut auf Reflection auf.

    am nächsten kommst du diesem Feature indem du mit Option Strict Off eine Variable ohne As definierst bzw. die Rückgabe einer Funktion in einer solchen Variable speicherst.
    Hast du die Typen, die in beiden Versionen jeweils von GetTypeFromProgID ermittelt werden, mal verglichen? Sind die wirklich identisch?
    Weltherrschaft erlangen: 1%
    Ist dein Problem erledigt? -> Dann markiere das Thema bitte entsprechend.
    Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
    Danke.
    Du hast ja offensichtlich zum Testen zwei unterschiedliche Projekte - eins in C# und eins in VB.NET. Kann es evtl. sein, dass diese für unterschiedliche Plattformen konfiguriert sind? (Eines AnyCPU, das andere x86 - oder ähnlich unterschiedlich)
    Es gibt gerade bei COM nämlich zwei Registry-Bereiche, in denen die Typen registriert werden - einer für 32 und der andere für 64 bit.
    Weltherrschaft erlangen: 1%
    Ist dein Problem erledigt? -> Dann markiere das Thema bitte entsprechend.
    Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
    Danke.
    man sollte dabei noch anmerken, dass hier Object und dynamic vollkommen fehl am Platz sind, schließlich kennst du ja den Typ.
    Also solltest du eine Referenz zu MGCPCBReleaseEnvironmentLib hinzufügen und nach dem CreateInstance(evtl. kann danach sogar new verwendet werden) zu "MGCPCBReleaseEnvServer" zu casten, evtl. gibt es dafür auch ein Interface zu welchem man casten sollte.
    Wenn du das hast ist das ganze schön typisiert, du kannst IntelliSense nutzen und zusätzlich ist es auch noch performanter...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Das ist mir durchaus bewußt. In diesem Fall mache ich es aber mit purer Absicht. Der Grund ist, weil ich Verweis-Versionsunabhängig bleiben kann. Bedeutet: Da die Funktionen die ich von diesem Objekt nutzen muss, immer gleich sind, und bei derartigen Änderungen der Referenz, der Hersteller es sowieso mitteilen müsste.

    Der Hersteller dieser Software bringt jedenfalls zweimal jährlich ein Update raus. Und in den vergangenen Jahren hatte ich dann immer das Problem, das die eingebundenen Bibliotheks-Dll's neue RevisionsNr. bekamen. Und ständig damit in Konflikt war.

    Auf diese Weise aber habe ich mein Programm ohne eingebundenen Verweis. Und die Klasse, auch als eigene Datei gehalten, ganz alleine mit der Option: Strict Off halte. Die globale Einstellung belasse ich auf Strict On.

    Dies ist für mich (ich betone: Nur in dem speziellen Fall) einfach die beste Methode. Wie gesagt, früher hatte ich diesen Verweis direkt integriert, mit erheblichen Folgenachteilen / Das Programm ist jetzt also Versionsunabhängig und läuft zu jedem Update welches der Hersteller auch rausbringt - solange die Refs gleich bleiben -> was ich aber unter Kontrolle habe ^^

    Hinti schrieb:

    Auf diese Weise aber habe ich mein Programm ohne eingebundenen Verweis.
    Das geht auch, indem Du die Assembly per Plugin lädtst.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!