![]() |
Projekt als DLL statt EXE
Hallo,
ich bin mir nicht sicher, ob ich den Sachverhalt nicht falsch in Erinnerung habe - bitte korrigiert mich bei Bedarf. Ich glaube gehört zu haben, dass man in Delphi per Einstellung festlegen kann, dass entweder eine große Exe-Datei erstellt wird, oder aber eine kleine Exe, die den Code aus einer großen DLL aufruft. Wenn ja - wo finde ich diese Einstellung? Ich dachte, dass dies damals zumindest in Visual Basic 6 möglich war. Der Hintergrund der Frage ist folgender: unsere Kunden arbeiten mit IT-Dienstleistern zusammen, die stellenweise den Zugriff auf jede Software stark reglementieren. Dadurch ist das Installieren von unseren Updates für den Kunden kostenpflichtig. Klar könnte man das auch anderst regeln, aber dies unterliegt leider nicht unserem Einfluss. Deswegen dachte ich, dass unsere Software im Programmverzeichnis nur noch aus einer kleinen Start-Exe besteht, die sich nicht mehr ändert. Den relvanten Codeteil würde ich als DLL im Benutzerverzeichnis (zum Beispiel) hinterlegen. Somit wäre ein Update jederzeit durch den Anwender möglich. Wie ist die Meinung hierzu? Grüße |
AW: Projekt als DLL statt EXE
Zitat:
Machen doch mittlerweile einige große Anwendungen (Chrome machte das zeitweise, SourceTree). Kann nur passieren das Sicherheitsregeln der IT genau diese Lösung unterbinden werden. Jedenfalls wenn die IT halbwegs aus Leuten besteht die Ahnung von der Sache haben. |
AW: Projekt als DLL statt EXE
Besteht viel Erfahrung im Umgang mit modulübergreifenden Programmieren in eurer Firma (EXE <-> DLL)?
Oder ist das eher Neuland, wie die Frage vermuten lässt? So einen Schalter gibt es nicht. Ihr müsstet viel von eurer bisherigen BL in eine DLL schieben und nach außen hin sicher verpacken. Dies löst ihr am Besten über Interfaces. Strings sollten als WideString übergeben werden. Alle Aufrufe aus der DLL zum Programm hin müssen gegen Exceptions gesichert werden. Ein weiterer möglicher Weg: Können die Anwender einen externen Prozess mit erhöhten Rechten starten, der selbstständig eure EXE austauscht/updated? Oder ist das auf dem Systemen nicht möglich? |
AW: Projekt als DLL statt EXE
Zitat:
Zitat:
Zitat:
|
AW: Projekt als DLL statt EXE
Zitat:
Wer soll das bezahlen? Dann lieber das persönliche Gespräch mit der jeweiligen IT-Abteilung suchen und eine Ausnahmeregelung treffen. |
AW: Projekt als DLL statt EXE
Zitat:
Zitat:
Ein anderer Grund ist, dass die EDV-Administration einen Überblick darüber haben will, welche Software auf den Rechnern installiert ist. Ich erlebe es bei uns immer wieder, dass Mitarbeiter einfach Software auf dem Rechner installieren obwohl wir es untersagt haben. Ein Beispiel ist der CCleaner. Irgendwann wird der Schritt zu den eingeschränkten Berechtigungen dann gemacht. Wir sind den Schritt vor 1,5 Jahren gegangen. Und es gab bisher noch keine Probleme damit. |
AW: Projekt als DLL statt EXE
Du meinst sicher die Technik mit den bpl's, davon würde ich abraten, da bei den neueren Delphi Version mit 32/64 Bit ist dies nicht mehr so einfach.
Der Admin hat übrigens Recht, wenn er nicht alles in sein System läßt und möglichst keine Ausnahmeregelungen zuläßt. Ist eure Software (Anwendung, Install, Update) signiert, dass könnte ein Kompromiss sein. In Zukunft werden immer mehr Admins nicht signierte Anwendungen nicht mehr ins System lassen. Wenn er ganz scharfe Regeln anwendet, dann läßt er nur Anwendungen zu, die über den Microsoft Store kommen. |
AW: Projekt als DLL statt EXE
Zitat:
Dann lieber die Exe dorthin legen um Umbauarbeiten zu vermeiden |
AW: Projekt als DLL statt EXE
Zitat:
|
AW: Projekt als DLL statt EXE
Ok, wir setzen uns nochmals mit den IT-Dienstleistern in Verbindung, um das Thema zu besprechen.
Danke an alle! |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:56 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz