Ich bin dabei, ein ziemlich großes in VB6 geschriebenes Projekt in C # zu konvertieren. Angesichts der Größe des Projekts, das verschoben wird, wird es in Phasen innerhalb von 18 Monaten durchgeführt. Ich stoße auf ein Problem beim Hinzufügen einer Referenz einer VB6 ActiveX-DLL zu einem .Net-Projekt.
Wenn Sie genau diese Schritte ausführen, sollten auch Sie in der Lage sein, das Problem neu zu erstellen.
Ich habe eine Schnittstelle in .Net geschrieben, die COM sichtbar ist:
%Vor%Wenn Sie auf der Registerkarte Kompilieren der Projekteigenschaften "Für COM-Interop registrieren" auswählen, erhalten Sie eine TLB-Datei.
Ich habe ein VB6-Projekt erstellt, das auf diesen TLB und eine Klasse verweist, die die Schnittstelle implementiert.
%Vor%Wenn ich die Registerkarte "Component" der Projekteigenschaften in VB6 auf "Remote Server Files" setze, wird beim Kompilieren automatisch ein TLB erstellt. Ich kann diesen TLB in OleView anzeigen und Folgendes anzeigen (zusätzlich zu den Details der konkreten Implementierung, die in VB6 der im .Net-Projekt definierten Schnittstelle ausgeführt wird):
%Vor%Jetzt erstelle ich ein komplett neues .Net-Projekt. Wenn ich einen Verweis auf die VB6-DLL hinzufüge, erhalte ich den folgenden Fehler:
COM-Referenz konnte nicht aufgelöst werden " ef005573-bfc7-436d-a382-f906ca09f94a " Version 3.0. Der Typbibliothekimporteur hat bei der Typverifizierung einen Fehler festgestellt. Versuchen Sie, ohne Klassenmitglieder zu importieren.
Wenn ich jedoch eine Visual Studio-Eingabeaufforderung starte, führe Folgendes aus:
%Vor%Dann kann ich diese DLL als Referenz in meiner .Net-Lösung hinzufügen und es funktioniert einwandfrei.
Meine Frage. Was macht tlbimp in der Befehlszeile, die nicht ausgeführt wird, wenn ich die Referenz direkt hinzufüge? Wenn die Nachricht in Visual Studio "Importieren ohne Klassenmitglieder" sagt, wie genau mache ich das in Visual Studio? Ich weiß, wie man das in Tlbimp macht.
Ich entschuldige mich für die Textwand, aber ich wollte die Situation so gut beschreiben, wie ich die Informationen, die ich für relevant hielt, behalten konnte.
Die Visual Studio-IDE verwendet bei der Registrierung von DLLs für COM Interop einen anderen Pfad als bei der Ausführung der Befehlszeilentools über eine Eingabeaufforderung.
Ich bezweifle, dass Microsoft das irgendwo dokumentiert hat. Meine jahrelange Erfahrung hat dies jedoch bewiesen. Ich habe einmal in eine Situation geraten, in der ein "regsvcs" Befehl von .NET 2.0 Framework tatsächlich eine Endlosschleife verursachen würde. Wenn Sie es googlen, werden Sie wahrscheinlich andere finden, die dieses Problem hatten. Ich konnte einen Schritt weiter gehen, indem ich mit der VS IDE die COM-Registrierung einer .NET Serviced Component durchführte. Es endete jedoch zwangsläufig mit einem Fehler. Der Fehler war ein Schritt vorwärts über die Endlosschleife. Wie auch immer, es hat sich für mich herausgestellt, dass die VS IDE einen anderen Codepfad / eine andere Geschäftslogik verwendet, wenn es um COM-Interop- und Registrierungseinträge geht.
Tags und Links c# visual-studio-2010 vb.net vb6 tlbimp