Hallo,
wo muss man mit den DLLs und den Sprachdateien usw. hin?
Kann man die z.B. auch in den Ordner der exe packen?
Gruß
David Müller
Hey
Ja, die DLL’s können in dem gleichen Verzeichnis sein.
Du musst nur aufpassen, dass Du die listlabelvs2005.dll auch in der GAC
registrierst.
Aber genaues findest Du auch noch im Verzeichnis “C:\Program Files
(x86)\combit\LL14\Dokumentation\Files\redist.txt”
mfg
-----Ursprüngliche Nachricht-----
Von: David Müller [mailto:dm@dm-e…]
Bereitgestellt: Freitag, 04. Dezember 2009 13:16
Bereitgestellt in: combit.public.de.listlabel
Unterhaltung: Auslieferung, wohin mit den DLLs?
Betreff: Auslieferung, wohin mit den DLLs?
Hallo,
wo muss man mit den DLLs und den Sprachdateien usw. hin?
Kann man die z.B. auch in den Ordner der exe packen?
Gruß
David Müller
Hallo Harald,
Du musst nur aufpassen, dass Du die listlabelvs2005.dll auch in der GAC
registrierst.
Eine Registrierung der listLabelVS2005.DLL im GAC ist nicht notwendig.
Es muss nur sichergestellt sein, dass diese DLL im selben Verzeichnis wie
alle anderen DLLs von LL steht.
Und wenn man sie nicht in den Exe-Ordner mit legen möchte,
genügt ein Verweis auf den neuen Zielordner in der Config-Datei der
Application (MyApplication.exe.config):
Dieser Eintrag z.Bsp. “probing privatePath=“ListLabel”” veranlasst das
Programm die LL-DLLs im Unterordner “ListLabel” zu suchen.
Gruß
Carsten
Hallo,
wir möchten die LL DLLs gerne nicht direkt in den EXE-Ordner legen sondern z.B. in den Unterordner “ListLabel”. In unserer config-Datei der Anwendung (MyApplication.exe.config) haben wir dafür einen Verweis auf diesen Ordner angegeben (probing privatePath=“ListLabel”). Allerdings ist es in diesem Fall bei uns so, dass dann das Modul “cmLL27pr.dll” für das Einbinden von PDF-Objekten nicht gefunden wird. Beim Öffnen des Designers von einem Report mit PDF kommt dann die Meldung "Die Programmerweiterung, die zur Darstellung des Objekttyps ‘LLPDF’ nötig ist, konnte nicht gefunden werden. Kopiert man die LL DLLs direkt in den EXE Ordner der Anwendung, funktioniert es ohne Probleme.
Warum wird hier das PDF Modul nicht gefunden? Normal sollte es doch möglich sein, das Ganze wie oben beschrieben auszuliefern.
Hallo,
es handelt sich hierbei ja um eine .NET Anwendung, wenn ich das mit der .config-Datei richtig deute. Die .NET Assembly von List & Label lässt sich vermutlich darüber noch aus dem beliebigen Unter-Verzeichnis laden. Aber die .NET Assembly lädt wiederum zahlreiche native Module nach, die sich dann wiederum intern dem DLL-Lademechanismus von Windows unterworfen sind. Und wenn hier Windows selbst nichts vom Unter-Verzeichnis weiß (bspw. Ergänzung in PATH-Variable) wird das vermutlich die Ursache sein. Ginge es ggf. im Startup-Code der betreffenden Anwendung einmal die Windows-Funktion SetDllDirectory aufzurufen mit dem Pfad auf das gewünschte Unter-Verzeichnis?
Genau, es geht um eine .NET Anwendung. Das Verhalten ist wie von dir beschrieben. Die .NET Assembly von LL wird gefunden, aber diese findet dann wiederum z.B. die DLL für das PDF Modul nicht. Das komische ist, dass es auf diesen Weg mit der LL Version 18 aber noch funktioniert hat. Mit der aktuellen Version 27 haben wir nun festgestellt, dass er auf diesen Weg das PDF Modul nicht mehr findet, alles andere scheint noch zu funktionieren. Zumindest sind uns bisher keine weiteren Probleme aufgefallen.
Wir werden es nun wohl so machen, dass wir die Pfad Variable für den Prozess im Code mittels
Environment.SetEnvironmentVariable(“PATH”, %newPathVariable%)
um den Zielordner erweitern. Damit scheint das Problem dann behoben zu sein.
Vielen Dank für die Hinweise.