Was könnte dazu führen, Vb6 Laufzeitfehler 430

Question

Ich habe eine COM-DLL in vb6 geschrieben. Wenn ich versuche, ein neues Objekt eines Klassenmoduls aus dieser DLL zu erstellen, erhalte ich einen Laufzeitfehler 430: Die Klasse unterstützt keine Automatisierung oder unterstützt keine erwartete Schnittstelle. Das Interessante ist, dass dies nur von außerhalb der IDE geschieht, wenn ich in der IDE debugge, wird kein Fehler ausgelöst und das neue Objekt der Klasse wird erfolgreich erstellt. Was kann die Ursache sein?

Im Allgemeinen bekomme ich gelegentlich diese Art von Fehlern in COM dlls. Was ist der beste Weg, COM-Probleme zu debuggen? Wie kann ich den Pfad der DLL kennen, die verwendet wird, wenn ein Programm ausgeführt wird?

Answer 1

Wenn dieses Projekt vollständig in VB6 ist. Die wahrscheinliche Ursache davon ist, dass die EXE eine Kopie der DLL-Binärdatei in ihrem Verzeichnis hat. Wenn Sie feuern, verwendet es diese Kopie anstelle der kompilierten Kopie. Wenn Sie Methoden oder Klassen hinzufügen, wird EXE mit der alten DLL inkompatibel. Wenn Sie einen Bugfix oder nur mit dem Inside-Code gearbeitet haben, wird EXE ausgeführt, aber es hat die alte DLL verwendet.

Setzen Sie Ihre DLL auf binäre Kompatibilität. Stellen Sie sicher, dass Sie ein kompatibles Verzeichnis haben. Setzen Sie die DLL der letzten Version dort ein. Zeigen Sie die Binärkompatibilität auf diese DLL. Stellen Sie sicher, dass Ihre EXE in ihr Projektverzeichnis kompiliert. Führen Sie das EXE aus dem Projektverzeichnis des Projekts aus. Auf diese Weise wird die von Ihnen kompilierte DLL verwendet. Sie müssen ein Dienstprogramm schreiben, damit Sie jedes Projekt separat kompilieren können. Testen Sie Ihr Setup mit Virtual PC oder einem anderen Computer.

All diese Schritte helfen, DLL Hell zu vermeiden. Mein eigenes Projekt hat zwei Dutzend ActiveX-Projekte in 6 Schichten. Als ich das oben genannte übernommen habe, sind meine DLL-Hell-Probleme auf fast nichts gesunken.

Answer 2

Dies ist mit ziemlicher Sicherheit ein Versionierungsproblem, manchmal auch als "DLL-Hölle" bekannt.

Der Hintergrund ist, dass die .NET-Welt explizit entworfen wurde, um Schnittstellen unter Beibehaltung des gleichen Namens entwickeln zu lassen. In der COM-Welt gelten Schnittstellen jedoch als unveränderlich.

Wenn Sie in der IDE arbeiten, erstellt Visual Studio bei jeder Ausführung Ihrer Lösung einen neuen COM Interop-Wrapper für die COM-DLL. Aber wenn Sie nicht jedes Mal die gesamte Lösung freigeben und ersetzen, einschließlich eines brandneuen COM Interop-Wrappers, stoßen Sie auf ein Versionierungsproblem, bei dem der .NET-Code eine COM-Schnittstelle erwartet, aber eine andere.

BEARBEITEN: Aus irgendeinem Grund nahm ich an, dass Sie versuchen, die COM-Komponente aus einer .NET-Komponente zu verwenden. Wenn die gesamte Lösung tatsächlich VB6 ist, dann ist die Lösung von Herrn Conley der empfohlene Ansatz. Here's a good link, die das Problem behandelt.

Answer 3

Lesen Sie auf binär vs Projekt kompatibel.

Wenn Sie eine gemeinsame DLL haben, müssen Sie vorsichtig sein und binär kompatibel verwenden. Auf diese Weise behält VB6 dieselbe COM-Signatur/Schnittstelle zwischen den Builds. Sie müssen eine Kopie der freigegebenen DLL für VB6 zum Vergleich haben - ich habe normalerweise einen separaten Ordner für freigegebene Binärdateien. Die Einschränkung bei der Binärkompatibilität besteht darin, dass Sie öffentliche Eigenschaften oder Methoden nicht löschen können und dass Sie ihre Signaturen nicht ändern können. Sie können neue Eigenschaften und Methoden hinzufügen.

Verwenden Sie die Projektkompatibilität, wenn Sie Änderungen vornehmen müssen (z. B. Löschen alter öffentlicher Methoden). Wenn Sie dies jedoch tun, müssen Sie alle anderen Anwendungen neu kompilieren, die die freigegebene DLL verwenden.