Meine allgemeine Frage ist, wie Sie Fehler beheben können: "Mein BPL wird aufgrund einer Abhängigkeit nicht geladen, die einfach nicht verschwindet, egal wie viel ich aufräume und neu kompiliere". Aktualisieren Sie denken vielleicht, dass Sie ein sauberes neu kompiliertes System haben, aber dank des umgekehrten Wunders, das Windows und dessen Fehlfunktion der Dateisystemvirtualisierung ist, haben Sie nicht.
Wenn ich versuche, mein Designtime-Paket (in diesem Fall mit dem Namen dclFsTee.bpl ) in meine Delphi-IDE zu laden (es handelt sich um das Fast Report 4 techart Wrapper-Komponentenpaket), beschwert es sich:
Das tee7100.bpl wird in keiner DCP- oder DCU-Datei auf meinem System, die ich kenne, referenziert. Aber klar, etwas stimmt nicht, und ich kann das Problem nicht finden.
Alle Delphi-Benutzer sehen sich mit hundert "wird nicht kompilieren oder wird nicht geladen" Probleme mit BPLs. Der allgemeine Refrain, wenn Sie gefragt werden, was zu tun ist, ist, Ihren Computer aufzuräumen.
Allerdings habe ich jetzt Stunden damit verbracht, meinen Computer zu säubern, und während alles die Datei kompiliert, muss irgendwo etwas veraltet sein, weil die BPL-Datei, die ich zu laden versuche, immer noch geladen werden will Version einer TeeChart BPL, die ich vor Tagen aus diesem System entfernt habe, zusammen mit jeder Spur, die ich finden konnte.
Die Spuren von TeeChart in Delphi 2007, die ich entfernt habe, enthalten alles im Ordner $ (BDS) \ Lib und $ (BDS) \ Lib \ debug und alle DCP- und BPL-Ordner auf dem System. Auch jede mit TeeChart-Einheiten benannte DCU-Datei ist weg.
Wenn du am Ende der Straße angekommen bist, was versuchst du als nächstes? (Formatieren Sie die Festplatte, kaufen Sie einen neuen Computer.) Im Ernst. Ich denke, ich bin ein kluger Typ, aber ich habe eine 1 TB Festplatte, einen Bibliothekspfad, der zu mehr als 80 Ordnern führt, und ein Quellcode-Repository, das gut organisiert zu sein scheint, aber eindeutig versteckt sich etwas, wo ich nicht kann finde es.
Ich habe TeeChart Standard 2012, mit vollem Quellcode, und soweit ich weiß, enthält meine Entwicklungsmaschine keine alten TeeChart BPLs oder DCP-Dateien mehr von der "techart tee7100.bpl" Version, die mit delphi. Ich habe den "rekompilieren.exe" -Wizard ausgeführt, der mit teechart geliefert wird, der anscheinend nur MSBuild ausführt und die Pakete erstellt, nachdem er eine {$ DEFINE x} -Deklaration in die tee.inc-Dateien geschrieben hat (es gibt zwei davon in der Quellenverteilung). Irgendwie scheint es stillschweigend so zu sein, als ob einer der impliziten Importe in eines der Pakete eine veraltete Datei zeichnet, die nicht neu erstellt wurde und die daher versucht, das tee7100.bpl zu laden. Der neue bpl-Name lautet tee911.bpl. Anstatt die Frage "ziemlich spezifisch-zu-schnell" zu stellen, erwähne ich sie nur als eine spezifische Instanz einer allgemeinen Welt der Verletzung, der ich bei der Entwicklung in Delphi Dutzende Male gegenübergestanden habe. Ich gebe nur die Details für den schnellen Bericht, so dass Sie sehen können, dass es sich tatsächlich um eine spezifische Instanz eines allgemeinen Problems handelt, mit dem Sie in Delphi manchmal konfrontiert werden, wenn Sie mit einem Komponentenquellcode oder -paket arbeiten mit Abhängigkeiten. Bereinigen Sie Ihren Computer, so dass Ihr Code sogar baut. Hier ist meine Delphi-Paket-zu-Paket-Abhängigkeits-Lösungsfrage: Was ist der effektivste Weg, um implizite-Load-of-einige-nicht-mehr-gewollte BPL-Probleme zu finden, so dass mein Code (der baut und kompiliert gut!) tatsächlich in die geladen werden Delphi IDE. Die BPL-Datei, die aus dem Ausführen von Neukompilieren resultiert, scheint ordnungsgemäß mit den richtigen DCP-Dateien verknüpft zu sein, und keine alten / veralteten DCP- oder DCU-Dateien sind vorhanden. Der neue DCP-Dateiname lautet beispielsweise tee911.dcp. Kannst du irgendwie wissen, welches Paket eigentlich veraltet ist und was gelesen und verlinkt und statisch importiert wird, wenn die .bpl-Links? (Ich denke, vielleicht wie eine spezielle MAP-ähnliche Datei für BPL-Dateien?) Update Nachdem ich viele Stunden damit zu kämpfen hatte und jeden Trick, den ich kenne, nutzte, wurde mir klar, dass ich nicht wurde auf einige ... An manchen Tagen hasse ich einfach Windows-Architektur. Wie auch immer, ich werde das Obige nicht als Antwort verwenden, denn ich würde gerne wissen, ob jemand einen besseren Weg oder einen Tipp oder Vorschlag hat, der beim nächsten Mal helfen könnte.
VirtualStore -bezogene Probleme überprüft, die durch Dateivirtualisierung in Windows 7 verursacht wurden. Das bedeutet, dass Windows 7 für die Programme gilt, die darüber ausgeführt werden. Es gibt Ihnen eine andere Version der Datei, die nicht die gewünschte ist. Dies kann auf mehrere Arten tödlich sein; Ein; Sie kompilieren einen BPL, aber das lädt nicht. Die BPL, die mich getötet hat, befand sich im SysWow64-Ordner, der Teil des VirtualStore war. Beachten Sie, dass der virtuelle Speicher grundsätzlich Phantomdateien anzeigt, die nur vorhanden sind, wenn Sie ein bestimmtes "Low-Priory" -Programm sind, was Delphi 2007 unter Win7 / 64 bit ist. So entfernen Sie BPL-Dateien in Ihrem SysWow64 VIRTUALSTORE-Ordner für Ihr aktuelles Benutzerkonto:
Okay, niemand hat geantwortet, also werde ich das hier als hilfreich für zukünftige Leute verwenden:
- Merken Sie sich Windows VirtualStore beim Bereinigen von defekten Systemen, die alte Versionen von DLLs enthalten, einschließlich TeeChart, FastReport, Indy usw., die dazu neigen, an Fehlern beteiligt zu sein, weil sie beide als "out of box" -Pakete existieren können mit delphi "sowie häufig installiert als Upgrade-Versionen, wenn Sie sie direkt von den Herstellern gekauft und installiert haben, oder drittens haben Sie möglicherweise Ihre eigene kompilierte Kopie im Mega-Component-Pack-Verzeichnis Ihres Unternehmens.
- Bei der Suche nach doppelten oder veralteten BPLs wird eine Dateisuche in Windows nicht in den virtuellen Speicherbereichen durchgeführt. Sie müssen den gesamten virtuellen Speicherbereich für Ihren Prozess oder Benutzer oder Programm suchen und zappen. manuell.
Die zweite Ebene dieses Problems ist dies:
Das Abhängigkeitsdiagramm für FastReports ist komplex:
Es hängt von Indy ab und du hast vielleicht deine eigene Version von Indy, und Delphi selbst hat eine, und andere Dinge auf deiner Festplatte könnten ihre eigene Kopie von Indy haben.
Es unterstützt verschiedene Ausgaben von TeeChart, einschließlich der Binärdateien, die mit Delphi geliefert werden, und vielleicht der Standardversion oder einer anderen gekauften Version von TeeChart, die Sie vielleicht von Steema gekauft haben.
Es wird eine vorkompilierte Header-Include-Datei verwendet, um die Kompilierung durchzuführen, und nicht nur EINE, sondern ZWEI verschiedene Kopien einer gleichnamigen Include-Datei (.inc).
Wenn Sie ein eigenes Compiler-Tool verwenden (kompilieren Sie FastReport), funktioniert es ziemlich zuverlässig, aber es ist nicht das Beste, wenn Sie alles aus einem einzigen Build-Skript in Ihrem Projekt erstellen wollen, also die Quelle meines Problems.
Der Schlüssel ist, alles über die Abhängigkeiten aller Komponenten in Ihrem riesigen Stapel von Paketen zu erfahren und Ihr System sauber zu organisieren, so dass Sie keine alten Sachen haben (wie Indy und TeeChart bpls, dcp oder dcu-Dateien) herumliegen. Das zu bereinigen ist ein ziemlich komplexer Job, wenn Sie nicht wissen, was Sie tun.
Ein Dienstprogramm, um alle Spuren der Version von Indy und TeeChart zu entfernen, die mit Ihrem System geliefert werden, und die "Embarcadero Edition" von FastReports ist der Schlüssel, um diese Situation zu lösen. Ein allgemeiner Tipp lautet: "Wenn eine Version von X mit Delphi ausgeliefert wird und Sie eine neue Version installieren, sollten Sie sich darauf einstellen, dass Sie leiden müssen, bis Ihr System wirklich aufgeräumt ist".
Eine wirklich erstaunliche Technik, um all diesen Mist zu vermeiden, besteht darin, Indy, FastReport oder TeeChart während der ersten Delphi-IDE-Installation nicht zu installieren (sie zu deaktivieren oder zu überspringen) und sie dann einzeln aus Quellen zu installieren . Nur weil eine Version in Delphi vorinstalliert ist, macht das keine gute Sache. (Update: Sie können Indy während der Installation nicht mehr abwählen, es ist seit mindestens Delphi XE8 Teil des Delphi-Basisprodukts. Ein Säuberungswerkzeug zum Entfernen des eingebauten Indy aus Delphis eigenen Lib-Verzeichnissen ist für jeden notwendig, der ein eigenes erstellt .)
Eine weitere wirklich erstaunliche Technik besteht darin, die Installer für kommerzielle Komponenten auf einer virtuellen Maschine auszuführen, dann einfach den Pascal-Quellcode zu sammeln und auf Ihren sauberen Entwicklungscomputer zu übertragen und ihn selbst zu erstellen. Auf diese Weise können Sie die schrecklichen Dinge vermeiden, die passieren, wenn Sie BPLs und andere Dinge in Ihrem System haben und sogar in C:\Windows\System32 (auf 32-Bit-Systemen) und C:\Windows\SysWow64 (der entsprechende Pfad auf 64-Bit-Systemen) installiert sind.
Das andere Problem, das dies verursachen kann, ist nicht der Ordner, in dem Sie Ihre .bpl-Dateien in Ihrem Systempfad gespeichert haben.
Dies geschieht, weil Delphi versucht, die WinAPI-Funktion LoadLibrary mit einem Dateinamen anstelle eines absoluten Pfades aufzurufen. Wenn Windows die Datei nicht finden kann, kann Delphi sie nicht laden.
Weitere Informationen finden Sie in diesem Forenbeitrag .
Dies scheint ein Problem in Windows 7 zu sein, allerdings nicht in Windows 10.
Tags und Links dependencies delphi bpl