Warum spielt der Konstruktor ORDER in VB.Net eine Rolle? Ich baue eine .NET-Typ-Bibliothek, die eine zugrunde liegende COM-Bibliothek vollständig umschließen soll, so dass die Konsumenten der API vorgeben können, statt einer COM-Bibliothek eine nette .Net-Bibliothek mit .Net-Sammlungen und dergleichen zu verwenden.
Derzeit sind die meisten meiner Klassen nur 1 zu 1 Wrapper, die mit Reflection und CodeDOM erstellt wurden. Diese Klassen haben einen internen Konstruktor, der den zugrunde liegenden COM-Typ als Parameter verwendet. Das CodeDOM erstellt das als den ersten Konstruktor der Klasse. Die Verwendung dieser Klassen aus C # erweist sich als kein Problem. Alles, was ich brauche, ist ein Verweis auf die .Net-Bibliothek und alles funktioniert gut.
Die Probleme treten auf, wenn ich versuche, diese Klassen aus einem VB.Net-Projekt zu verwenden. Wenn der erste Konstruktor über einen COM-Typ als ein Argument verfügt, benötigt das VB.Net-Projekt die COM-Interop-Assembly als eine Referenz. Wenn der erste Konstruktor keine Argumente oder nur verwaltete Typen hat, funktioniert alles gut. Meine Klassenbibliothek ist in C # geschrieben.
Folgendes funktioniert:
%Vor%Folgendes erfordert einen Verweis auf die COMLib.Interop-Assembly:
%Vor%Jetzt kann ich das lösen, indem ich einen Dummy-Konstruktor für diese Klassen als ersten Konstruktor erstelle, aber ich bin eher neugierig, was das verursacht? Warum ist die Reihenfolge der Konstruktordeklarationen in VB.Net wichtig?
Aktualisieren
Das klang so verrückt, dass ich selbst anfing es zu bezweifeln. Verwaltet, um es mit 3 Projekten zu replizieren.
C # Klassenbibliothek: Wrapped
%Vor%C # Klassenbibliothek: Wrapper
%Vor%VB.Net Konsolen App: Referer
%Vor%Wrapper bezieht sich auf Wrapped Referer bezieht sich auf Wrapper Referer bezieht sich NICHT auf Wrapped
%Vor%Erzeugt einen Fehler
%Vor%Durch den Austausch der Reihenfolge der Konstruktoren wird der Fehler behoben.
Nach mehrmaligem Spielen aktualisieren
%Vor%Wenn richtig (ich kann nicht leicht überprüfen), das ist faszinierend. Die Reihenfolge sollte keine Rolle spielen, AFAIK. Wenn Sie sich sicher sind, melden Sie sich möglicherweise als als Verbindungsproblem (mit Beispielcode) an.
Bestätigt als Fehler. Zu schwer zu beheben, um es wert zu sein Ich denke, wir werden einfach damit leben. Glücklicherweise scheint es erforderlich zu sein, dass sprachübergreifende Projekte mit ungewöhnlichen Klasseneinstellungen auftauchen.
Nein, die Reihenfolge Ihrer Konstruktoren, wie sie im Code (mit C # oder VB.NET) aufgeführt sind, spielt keine Rolle.
Aber in diesem speziellen Fall (ich habe es nicht getestet) haben Sie vielleicht einen Fehler gefunden. Bevor Sie zu der Schlussfolgerung "Es bricht auf meiner Maschine" springen, möchten Sie möglicherweise, dass jemand anderes das Problem auf seinem Computer überprüft, damit Sie wissen, dass es nicht nur Ihr Computer ist. Ich habe das schon einmal erlebt.
Tags und Links .net interop reference constructor vb.net