Hi!
Das mit der DLL ist sehr merkwürdig und sollte eigentlich auf keinen Fall vorkommen. Ich verstehe überhaupt nicht, wieso er die will, dass ist mir zumindest noch nie zu Ohren gekommen. Die DLL liefere ich aber auch nicht aus...
zu 1.) Anderes Programm? Wir reden über opsi-setup-detector von uib selber und meinen opsi PackageBuilder in der letzten (8.2.2 aktuell) Python Version, oder?
zu 2.) Wenn du damit gleichzeitig lokaler Admin bist, ist damit alles ok.
zu 3.) Das, was da auf Z: liegt, ist, gelinde gesagt, Kraut und Rüben! Da kann ich nicht erkennen, welches der Paketordner sein soll, etc. Wenn das wirklich so aussieht, dann wundert mich nicht, wieso der oPB nach dem Aufruf aus dem opsi-setup-detector hängen bleibt.
Eine ordentliche Struktur sieht (mindestens) folgendermaßen aus
Code: Alles auswählen
opsi_workbench (Z:)
|
|------ <ProductID 1>
| |
| |------- CLIENT_DATA
| |------- OPSI
|------ <ProductID 2>
| |
| |------- CLIENT_DATA
| |------- OPSI
|------ <ProductID 3>
| |
| |------- CLIENT_DATA
| |------- OPSI
Dabei befindet sich unter CLIENT_DATA der ganze Installerkram plus Scripte und unter OPSI die Control Datei. Das kann ich bei dir auf dem Screenshot nicht erkennen.
Der Screenshot deutet aber auch eher daraufhin, und korrigiere mich, falls ich mich irre, dass du dich mit den Grundlagen von opsi nicht wirklich vertraut gemacht hast und die beiden Programme
mal eben so nutzt.
Wenn das so sein sollte, rate ich dringend dazu, dich zumindest mit der Getting Started und der ersten manuellen Paketerstellung zu beschäftigen.
Wenn deine Grundvoraussetzungen schon nicht eindeutig sind, wird ein Debuggen deines Problems hier eher schwierig.
Sollte meine Vermutung nicht zustimmen und du eigentlich mit opsi vertraut bist, dann räum Z: auf und mach mal einen Testbuild mit Hilfe des oPB von der Kommandzeile ohne Oberfläche. Da lässt sich dann auch das Debuglogging einschalten und du bekommst ziemlich detailierte Infos, was gerade schief läuft...
Gruß
Holger