Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Delphi Projekt als DLL statt EXE (https://www.delphipraxis.net/194480-projekt-als-dll-statt-exe.html)

ernschd 28. Nov 2017 08:14

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

Bernhard Geyer 28. Nov 2017 08:21

AW: Projekt als DLL statt EXE
 
Zitat:

Zitat von ernschd (Beitrag 1387313)
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?

Und wieso legst du nicht gleich die große Exe ins Benutzerverzeichnis?
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.

TiGü 28. Nov 2017 08:28

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?

ernschd 28. Nov 2017 08:57

AW: Projekt als DLL statt EXE
 
Zitat:

Zitat von Bernhard Geyer (Beitrag 1387314)
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.

Und das wollte ich vermeiden.

Zitat:

Zitat von TiGü (Beitrag 1387315)
Oder ist das eher Neuland, wie die Frage vermuten lässt?

Genau, es wäre das erste Projekt in dieser Art. Deiner Antwort nach ist wäre es mit nicht unwesentlichem Aufwand verbunden.

Zitat:

Zitat von TiGü (Beitrag 1387315)
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?

Bei einigen Kunden ist dies so eingestellt, hier haben wir auch keine Probleme. Es gibt jedoch zwei oder drei Admins, die dies nicht zulassen, aus welchen Gründen auch immer.

TiGü 28. Nov 2017 09:00

AW: Projekt als DLL statt EXE
 
Zitat:

Zitat von ernschd (Beitrag 1387317)
Bei einigen Kunden ist dies so eingestellt, hier haben wir auch keine Probleme. Es gibt jedoch zwei oder drei Admins, die dies nicht zulassen, aus welchen Gründen auch immer.

Für zwei oder drei Kunden würde ich nicht die gesamte Applikation umbauen, ohne ausreichende Kenntnisse.
Wer soll das bezahlen?
Dann lieber das persönliche Gespräch mit der jeweiligen IT-Abteilung suchen und eine Ausnahmeregelung treffen.

Aviator 28. Nov 2017 09:04

AW: Projekt als DLL statt EXE
 
Zitat:

Zitat von ernschd (Beitrag 1387317)
Genau, es wäre das erste Projekt in dieser Art. Deiner Antwort nach ist wäre es mit nicht unwesentlichem Aufwand verbunden.

Eine DLL und ein Interface ordentlich zu programmieren und auch immer schön alle Instanzen wieder freizugeben kann sehr viel Aufwand bedeuten. Wenn es nur ein kleines Programm ist, dann ist das schnell auch mit statischer Bindung der DLL-Funktionen gemacht. Aber ein Interface ist IMO sauberer und einfacher zu erweitern.

Zitat:

Zitat von ernschd (Beitrag 1387317)
Zitat:

Zitat von TiGü (Beitrag 1387315)
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?

Bei einigen Kunden ist dies so eingestellt, hier haben wir auch keine Probleme. Es gibt jedoch zwei oder drei Admins, die dies nicht zulassen, aus welchen Gründen auch immer.

Ein Beispiel warum man solche Einstellungen macht wäre bspw. das Thema Sicherheit in Bezug auf Viren. Keine Adminrechte bedeutet, dass ein Virus auch nur mit den Berechtigungen eines Benutzers laufen kann und somit auch keine Systembereiche befallen kann.

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.

Pfaffe 28. Nov 2017 09:22

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.

Bernhard Geyer 28. Nov 2017 10:09

AW: Projekt als DLL statt EXE
 
Zitat:

Zitat von ernschd (Beitrag 1387317)
Zitat:

Zitat von Bernhard Geyer (Beitrag 1387314)
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.

Und das wollte ich vermeiden.

Ob nun eine Exe oder eine DLL im Benutzerprofil liegt dürfte die gleichen Einschränkungen unterliegen.
Dann lieber die Exe dorthin legen um Umbauarbeiten zu vermeiden

jaenicke 28. Nov 2017 12:01

AW: Projekt als DLL statt EXE
 
Zitat:

Zitat von ernschd (Beitrag 1387317)
Bei einigen Kunden ist dies so eingestellt, hier haben wir auch keine Probleme. Es gibt jedoch zwei oder drei Admins, die dies nicht zulassen, aus welchen Gründen auch immer.

Dann müssen sie Updates über ihr eigenes Deployment machen. Wer nicht möchte, dass Aktualisierungen per Dienst (die meiner Meinung nach sauberste Lösung) oder ähnlichem automatisch stattfinden, der muss nun einmal manuell bzw. über ein eigenes System aktualisieren. Da führt kein (sauberer) Weg dran vorbei.

ernschd 28. Nov 2017 13:50

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 05:23 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz