Inoffizielles deutsches Xbase-Forum

Hallo,

bei meinem Kunden gibt es stapelweise Projekt-Verzeichnisse. Zusätzliche dll und lib (eine eigene, dazu ot4xb, usw.) habe ich daher früher immer in das Alaska-lib-Verzeichnis (Xbase++ war auf dem Server installiert, mit Zugriff von allen Entwicklern) gelegt, dann hatten alle Entwickler was davon.

Mit der 2.0 geht das natürlich nicht mehr, da das zwingend lokal installiert werden muß. Da gibt es also auf den ersten Blick zwei Alternativen:

• Jeder Entwickler kopiert diese Dateien in sein lokales lib-Verzeichnis. Das kann man knicken, ich kenn die Jungs, das geht garantiert nicht gut.
• Die entsprechenden dll werden in das jeweilige Projekt-Verzeichnis gelegt. Überhaupt nicht gut. Bei Versionswechseln darf ich dann durch 25 Verzeichnisse oder so gehen und alles manuell aktualisieren

Also Alternative 3: Ich habe ein neues Verzeichnis auf dem Server angelegt, parallel zu den ganzen Projekten. Hierein habe ich alle zusätzlichen dll und lib gelegt. Und einmalig auf allen betroffenen Rechnern schnell den Pfad auf dieses Verzeichnis in die Umgebnungsvariablen hinzugefügt (endlich hat MS da mal was getan - unter Windows 10 ist das jetzt mal übersichtlich!).

So weit, so gut.

Jetzt habe ich aber folgendes Problem: Die eigene dll und die ot4xb werden sofort beim kompilieren gefunden und eingebunden. Die beiden dll und lib zur PDF-Erstellung aber nicht! Kopiere ich nur diese beiden in das Projekt-Verzeichnis, wird alles sauber kompiliert. Lege ich die nur in das eigene Runtime-Verzeichnis, kommt ein "[Fataler Fehler]: ALK 4001: cannot open file "xpppdf51.lib"".

Ich habe vor lauter Verzweiflung den Runtime-Pfad auch an das lib-Verzeichnis angehängt. Keine Änderung.

Warum klappt das mit zwei dll, mit zwei anderen aber nicht?

Jan

Jan hat geschrieben:

• Das kann man knicken

Jan hat geschrieben:

• Jeder Entwickler kopiert diese Dateien in sein lokales lib-Verzeichnis.

Musst es sonst doch so lösen. Legst alle benötigten DInge in einen Read-only-Ordner und wenn einer "rungeknickt" hat, kann er von dort alles wieder herkopieren.

Ich hab erstmal die Lösung gefunden. Alaska ist da wirklich lustig. Beim Kompilieren gehen die NICHT auf die Pfade in den Umgebungsvariablen von Windows. Sondern nehmen nur die, die in der Workbench explizit hinterlegt sind. Und weil da aus irgend eniem Grund sowohl der Pfad zur 2.0 (logisch) als auch der Pfad zur vorher installierten 1.9 (warum das?) drin standen, hat der beim Kompilieren teilweise alte libs gefunden, andere neue dagegen nicht.

Da muß man erstmal drauf kommen ...

Jan

Dass sie diese Pfade nehmen ist logisch, sonst könnte man ja keine Installation nebeneinander haben, aber was die 1.90 da zu suchen hat
Da schau ich mal bei mir rein ...

Bei mir sind auch alle möglichen Verzeichnisse unter EXE und die alten in den anderen enthalten. Garantiert nicht durch mich.