Package Installation schlägt fehl

[skoschke]

Beim Installieren eines eigenen Packages erhalte ich "das angegebene Modul wurde nicht gefunden"...
aber das BPL-File ist vorhanden.

Auf Grund eines Tips habe ich jetzt mal das BPL debuggen lassen und bekomme dabei die Meldung:
"Im Projekt bds.exe ist eine Exception der Klasse EFOpenError mit der Meldung 'Datei C:\Users\Stefan\sanct.log kann nicht geöffnet werden. Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird' aufgetreten."

Könnte das die Ursache sein und wer hat da Zugriff?

Ciao
Stefan

[Uwe Raabe]

Die Meldung kommt immer wenn man die IDE selbst mit einer anderen Instanz im Debugger startet.

[dummzeuch]

Zitat:

Zitat von skoschke (Beitrag 1487099)

Beim Installieren eines eigenen Packages erhalte ich "das angegebene Modul wurde nicht gefunden"...
aber das BPL-File ist vorhanden.

Auf Grund eines Tips habe ich jetzt mal das BPL debuggen lassen und bekomme dabei die Meldung:
"Im Projekt bds.exe ist eine Exception der Klasse EFOpenError mit der Meldung 'Datei C:\Users\Stefan\sanct.log kann nicht geöffnet werden. Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird' aufgetreten."

Könnte das die Ursache sein und wer hat da Zugriff?

Das ist normal. Die debuggende IDE öffnet diese Datei und die zweite Intsanz, die debuggt wird, kann dann nicht mehr darauf zugreifen.

Also: Ignorieren, hat nichts mit Deinem Fehler zu tun.

[skoschke]

danke, aber ich komme immer noch nicht weiter:

Compilieren des Packages ist fehlerfrei, bei Installation dann "Das angegebene Modul wurde nicht gefunden!"

Ich habe hier den Tip mit dem ProcessMonitor gefunden, aber ich komme mit dem überhaupt nicht klar, finde auch keine für diesen Zweck hilfreiche Anleitung...

Ein Filtern nach "Process is bds.exe" zeigt nirgends fehlende Dateien / dll's / etc...

Ciao
Stefan

[joachimd]

Zitat:

Zitat von skoschke (Beitrag 1487107)

Compilieren des Packages ist fehlerfrei, bei Installation dann "Das angegebene Modul wurde nicht gefunden!"

Evtl in den Abhängigkeiten noch Packages mit anderen Namen bzw welche, die nicht installiert sind?

[himitsu]

Modul = EXE/BPL/DLL (die EXE läuft schon, also ist zumindestens die BDS.exe nicht das Problem)

Das kompilieren läuft bei abhängigen Packages gegen die DCP,
aber beim Ausführen wird natürlich die BPL benötigt.

Tja, diese Fehlermeldung heißt nicht "DAS wurde nicht gefunden", sondern "hab DAS versucht zu laden, aber ging nicht, weil IRGENDWAS fehlte"

Aber es gibt Hilfsprogramme, zum Nachgucken.
* Dependency Walker
* SysInternals ProcessMonitor


Und alle Fehlermeldungen bezüglich Sanctuary kannst ignorieren.
Es ist normal, dass der kranke Kopierschutz von Emba intern überall knallt.

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1487118)

* Dependency Walker
* SysInternals ProcessMonitor

Ich empfehle inzwischen https://github.com/lucasg/Dependencies

Der alte Dependecy Walker wird nicht mehr weiterentwickelt und hatte zumindest bei mir die Angewohnheit sehr lange Denkpausen einzulegen, wenn er sich durch die Abhängigkeiten wühlte.

[Rolf Frei]

Wenn du ein Package in einen Ort kompilierst, der nicht im Windows PATH enthalten ist, wird diese BPL beim Laden der IDE nicht gefunden. Man muss also dafür sorgen, dass der Output der BPL beim Kompilieren ein Ort ist, der im PATH steht. Standadmässig legt die installation einen solchen Pfad im PATH ab, den man dann nutzen kann, aber ich würde da lieber einen eigenen Pfad definieren, der nur die korrekt benannten BPL's (Dateiname enthält die Delphi Version) enthält und dieser im Paths angeben. Die Delphi Installation macht leider per Default für jede neue Delphi Version einen neuen eigenen Verzeichnis, was dann irgend wann zu einer zu langen PATH Variable in Windows führt und spätestens ab da ist das was die IDE da macht leider Blödsinn.

Ich rate dir dazu 2 Verzeichnisse zu erstellne, die möglichst kurz sind, z.B.:
C:\BPL
Ausgabeverzeichnis für die BPL Dateien, die im Namen die Delphi version enthalten. Dieses kann im Package sauber und dynamisch hinterlegen. Aktuelle professionelle Packages nutzen diesen Mechanismus der Versionvergabe seit Jahren. Diese Pfad wir in die PATH Windows Umgebunsvariable ergänzt und kann bei korrekter Namensgebung der Packages, für alle Delphiverisosn gleich sein. Ist also nur einemal im PATH enthalten.

C:\DCP\D104
Das ist das Ausgabeverzeichnis der Package DCP Dateien, die für das Kompilieren benötigt werden, wenn man die Anwendung mit Packages kompiliert. Dieser Pfad kommt dann in den globalen Suchpfad in Delphi, damit das dann für alle Projekte gültig ist. Dieser Ausagebpfad muss pro Delphi Version eindeutig sein, da diese in der Regel, wenn man das Package sauber gemacht hat, keine Delphi Version im Namen enthält. Hierdurch wird das Updaten auf neuere Delphis wesentlich einfacher, da man so die Requires beim Upgrade des Packagessource auf eine neue Delphiversion, nicht verändern muss und es dann einfach reicht das Package mit einem neuen Namen, der die Delphi Version enthält, zu speichern.

Diese beiden Verzeichniss können am einfachsten bei der globalen Konfiguration als Vorgabe für die BPL und DCP Ausgabepfade hinterlegt werden. Dadurch gilt das dann für alle Packages die man kompiliert und die nicht einen eigenen Wert für die Ausgabepfade in den Packagesoptionen hinterlegt haben.

Auch zu beachten ist, dass wenn man selber ein Package erstellt, dieses nicht einfach "MeinPackage" heissen darf (oder soll), sondern die Delphveriosn enthalten muss, damit eine reibungslosen Upgrade auf neuere Delphi Versionengemacht werden kann. "MeinPacakge_D103" wäre so ein Name den man nutzen könnte. In Delphi 10.4 wird dann einfach die alte Package Source geladen und gleich wieder als "Mein Package_D104" gespeichert. Wenn man die Grundkonfiguruation in 10.4 sauber mit den obigen Angaben hinterlegt hat, kann man einfach neu kompilieren und bekommt dann eine neue BPL/DCP für Delphi 10.4. In C:\BPL liegt dann eine 2. BPL Datei, die den Namen "MeinePackag_D104.bpl" hat. Hiermit kann man alle Delphi Versionen der Packages an einem Ort haben und muss sich nicht die PATH Variable überfüllen. Die DCP liegt dann in C:\DCP\D104.

[himitsu]

Regisrierte BPLs werden aus dem Pfad geladen, womit sie registriert wurden.
z.B. "Known Packages"

Aber BPL aus Abhängigkeiten, welche Windows (vorher) lädt, werden nur im Suchpfad gesucht ... aber dass später ein Eintrag zum Laden folgt, inkl. Pfad, wird nicht beachtet.


die einzige praktikable Lösung wäre, wenn BPL vorher nach Abhängigkeit sortiert und dann geladen würden. (Probleme würde dann zwar noch dynamisches Laden ergeben, aber da könnte man den Pfad mit angeben)

[Rolf Frei]

Zitat:

Zitat von himitsu (Beitrag 1487128)

Regisrierte BPLs werden aus dem Pfad geladen, womit sie registriert wurden.
z.B. "Known Packages"

Aber BPL aus Abhängigkeiten, welche Windows (vorher) lädt, werden nur im Suchpfad gesucht ... aber dass später ein Eintrag zum Laden folgt, inkl. Pfad, wird nicht beachtet.


die einzige praktikable Lösung wäre, wenn BPL vorher nach Abhängigkeit sortiert und dann geladen würden. (Probleme würde dann zwar noch dynamisches Laden ergeben, aber da könnte man den Pfad mit angeben)

Ja und genau das ist ja das Problem, wenn man Runtime und Designtime Packages hat. Das Runtime Package kann dann nicht geladen werden, weil es im PATH nicht gefunden wird. Mit meiner Anleitung ist das Themem ein für allemal Geschichte, ohne dass die PATH Variable überfüllt wird. So reicht ein einziger kleiner Eintraig im PATH auf C:\BPL und fertig. Diese gilt dann für alle Delphiversionen, nachdem man die Grundkonfiguration jeweils daran angepasst hat. Also einfach jeweils diese Grundeinstellung für BPL/DCP Ausgabeverzeichnis auf c:\BPL und c:\DCP\Delphiversion abändern und fertig.