Wenn wir die Kompatibilität in einer vb6-DLL unterbrechen, muss ich Folgendes tun:
Natürlich ist das ein bisschen vereinfacht, aber jeder, der es schon einmal gemacht hat, sollte wissen, wovon ich rede.
Meine Frage ist: Haben Sie einen besseren Weg gefunden, dies zu tun, oder haben Sie irgendwelche (nicht zu teure) Werkzeuge gefunden, um diesen Prozess zu erleichtern? Oder noch besser, haben Sie eine erstellt, die Sie mit mir teilen können:)
Beachten Sie, dass ich frage, wie Sie diesen Prozess vereinfachen und nicht vermeiden können. Also gib bitte keine Antworten darauf, wie schlecht es ist, die Kompatibilität zu brechen und dass wir das nicht tun sollten. Ich lebe in der realen Welt, wo es Dinge gibt, die außerhalb meiner Kontrolle liegen und ich versuche nur, mit dem fertig zu werden, was ich habe.
In einem früheren Job hatte ich eine riesige VB6-Anwendung, die Dutzende VB6-DLLs enthielt, die wir in den Projekten unserer Projektgruppe referenziert hatten. Wir haben die Kompatibilität oft getrennt und die Aktualisierung der Referenzen, wie Sie sie beschreiben, war keine Option.
Wir haben ursprünglich ein Tool entwickelt, das Referenzen in allen .vbp-Dateien in einem Ordner nach dem Brechen und Neukompilieren aktualisiert, aber ich habe schließlich Visual Build von Kinook Software (www.kinook.com) gefunden, das automatisch damit umgehen könnte.
Ich habe ihre Lösung seit vielen Jahren erfolgreich eingesetzt. Was ist gut an ihrer Aktion "Make VB6" (http://www.kinook.com/VisBuildPro/Manual/makevb6.htm) ist, dass es eine Abhängigkeitsstruktur erstellen und alle Ihre Projekte in Ihrer Projektgruppe in der richtigen Reihenfolge neu erstellen kann, während die Referenzen entsprechend aktualisiert werden.
Für Ihr Szenario müssten Sie die Option "Versionskompatibilität vor dem Erstellen festlegen" auf "Keine Kompatibilität" setzen und dann das Kontrollkästchen "Binärkompatibilität festlegen" aktivieren, damit die Projekte nach dem Erstellen wieder auf Binärkompatibilität zurückgesetzt werden.
Wenn Sie Projekte haben, für die Sie Binärkompatibilität beibehalten müssen, lassen Sie sie einfach außerhalb der .vbg-Datei und sie wird nicht neu erstellt.
Zusätzliches Visual Basic 5.0 & amp; 6.0 Beispiele bietet ein Binärkompatibilitäts-Add-In , das nützlich sein könnte. Siehe die Dateien ReadMe.txt und Revised Binary Compatibility.doc nach dem "Installieren" (nach dem Ausführen des Downloads müssen Schritte ausgeführt werden).
Dieser Download enthält das Dokument "Revised Binary Compatibility" sowie das Add-In SyncCompt.dll. Die in Visual Basic 5.0 und Visual Basic 6.0 implementierte Binärkompatibilität stellt sicher, dass neue Versionen von Versandprodukten vollständig mit älteren Versionen kompatibel sind. Das Dokument erläutert Probleme im Zusammenhang mit der Binärkompatibilität und der GUID-Revision und führt die DLL ein. Das DLL-Add-In erstellt eine neue Kompatibilitätsdatei, um Ihr Produkt zu stabilisieren (außer Standard-EXEs, die keine Binärkompatibilität haben). Dieses Tool funktioniert nur in einer Microsoft Windows NT®-Umgebung.
Dies kann Ihr Problem beheben oder auch nicht.
Sie sollten die Kompatibilitätseinstellung nicht ändern müssen. Sie müssen jedoch sicherstellen, dass die Dll (oder Exe), auf die Sie in Ihrer Kompatibilitätseinstellung verweisen, nicht ist der Ort, an dem Sie gerade kompilieren wollen.
Wir machen etwas ähnliches, daher haben wir folgende Struktur:
C:\ProductName\Bin - enthält alle aktiven Baugruppen
C:\ProductName\Bin\Compatibility - enthält alle Assemblies so wie sie im letzten Build waren
Nachdem wir einen Build erstellt haben (was wir automatisch tun, indem wir VB6.exe scannen), verschieben wir alles in \Bin nach \Bin\Compatibility
Ich habe die Versionskompatibilität in ActiveX-Komponenten MSDN-Serie ist sehr aufschlussreich zum Thema Kompatibilität und wann / wie man es bricht. Ich poste das hauptsächlich für zukünftige Referenz.