Hallo,

ich habe hier ein Programm, das schon eine längere Geschichte hinter sich hat. Dieses Programm arbeitet mit Konfigurationsdateien. Soweit ich mich erinnere wurden diese unter XP einfach noch im Programmordner abgelegt. Seit Windows 7 (oder Vista) landen diese im VirtualStore (genauer: Program Files (x86) ). Die Anwendung war bislang eine 32-Bit-Anwendung. Um Zugriff auf mehr Speicher zu erhalten habe ich die Anwendung nun auf 64-Bit konvertiert, was auch an sich keine weiteren Probleme macht - bis auf den Zugriff auf die Konfigurationsdateien. Hier erfolgt nämlich kein Speichern/Laden aus den VirtualStore und die Anwendung startet nicht. Ich kann die Anwendung dann nur starten, wenn ich diese mit Admin-Rechten ausstatte. Die Konfigurationsdateien landen dann aber natürlich wieder direkt im Programmordner, was ich unterbinden möchte.

Der Zugriffspfad auf diese Dateien wird übrigens so ermittelt:
Kennt jemand dieses Problem und hat ggf. einen Lösungsansatz?

viele Grüße

Christian

[FAQ] Pfad zur eigenen Anwendung (EXE) ermitteln

Ich wüsste auch nicht, was Konfigurationsdateien im Installationsverzeichnis zu suchen hätten.
https://blogs.msdn.microsoft.com/patricka/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions/

LaTino

Wer unter Windows XP oder Vista Konfigurationsdateien in das Anwendungsverzeichnis und damit in einen für den User geschützten Ordner abgelegt hat, hat es damals schon falsch gemacht.
Das zeigt der Link von LaTino extrem gut.

Hallo,

vielen Dank - Problem gelöst!

Christian

Hi,

von welcher Art von Konfiguration reden wir hier?
Die typische app.config?
In denen nur Application-Settings stehen?

Zitat von Abt

Wer unter Windows XP oder Vista Konfigurationsdateien in das Anwendungsverzeichnis und damit in einen für den User geschützten Ordner abgelegt hat, hat es damals schon falsch gemacht.

Ach ja?
Ich bin sehr wohl der Meinung, dass eine app.config mit ApplicationSettings dort gespeichert sein sollte, wo das Programm liegt.. also meist unter C:\Programme, oder C:\Programme(x86),
(und auch nicht jeder DAU-User schreiben und etwas ändern kann)

Wo hat VS seine devenv.exe.config abgelegt??

Ein anderer Part sind User-Settings
Die gehören ganz sicher an einen Plaz, wo der User auch Schreibberechtigung hat

Ich würde dir zustimmen, aber dann würden wir beide falsch liegen.

Es gibt keine Begründung, wieso ein Programm, das unter eingeschränkten Berechtigungen laufen können muss, Schreibrechte auf sein Installationsverzeichnis haben sollte. Wenn solche Rechte notwendig sind, handelt es sich um eine potenzielle Sicherheitslücke, die zB das nachträgliche Installieren von Programmen in C:\Programme gestatten würde.

Es ist gefährlicher Unsinn, ApplicationSettings im Installationspfad zu hinterlegen.

LaTino

Zitat von LaTino

Es gibt keine Begründung, wieso ein Programm, das unter eingeschränkten Berechtigungen laufen können muss, Schreibrechte auf sein Installationsverzeichnis haben sollte.

Ich habe ja auch nicht gesagt, dass dort ein schreibender Zugriff möglich sein soll Ja, bitte, never!!
Aber die Anwendung, die aus dem Pfad gestartet wird, sollte sehr wohl seine Application Settings laden dürfen.
Wer und wie diese geändert werden können, steht auf einem anderen Blatt.

User Settings landen natürlich im Benutzerprofil.

Zitat von LaTino

Es ist gefährlicher Unsinn, ApplicationSettings im Installationspfad zu hinterlegen. LaTino

warum?

Weil es sich um ein Konzept handelt, das nicht ausreichend offensichtlich ist und deshalb gern und oft falsch implementiert wird, oder umgangen wird. Bestes Beispiel ist das Ursprungsposting hier.

Das Problem ist hier: MSDN: Using Settings in C# sogar schön festgehalten:

Zitat von MSDN

To Change the Value of a Setting Between Application Sessions Using Microsoft Notepad or some other text or XML editor, open the <AssemblyName>.exe.config file associated with your application. Locate the entry for the setting you want to change. It should look similar to the following example: <setting name="Setting" serializeAs="String"> <value>This is the setting value</value> </setting> Type a new value for your setting and save the file.

Ich weiß nicht, in welchem Drogenrausch es jemals für eine gute Idee gehalten wurde, das für ein geeignetes Vorgehen zum Pflegen von Application Settings zu halten.

Ja, wenn man es so macht, kriegt man kein Problem.

Nein, in der Praxis macht das kaum einer (löbliche Ausnahmen gibt's, siehe VS). Was ich schon gesehen habe:
- user privilege elevation (lies: "loggen Sie sich als Administrator ein, um diese Einstellung in dieser UI pflegen zu können")
- Zugriffsrechte auf das Programmverzeichnis während der Installation für alle User gestatten
- Konfigurationsmodell komplett umgehen
- Installation eines WCF-Service in einem Windows-Dienst, der Schreibrechte im Installationsverzeichnis der Anwendung hat und die .config manipulieren kann, sowie die Anwendung nach Bedarf neu startet, eine net.tcp-Bindung hat von der Anwendung bedient wird

Gibt sicher noch mehr Varianten, und allesamt sind sie Müll. Keine davon ist sicher, alle davon resultieren aus dem Wunsch, Application Settings bequemer ändern zu können. Und die sind nur unbequem zu ändern, wenn sie im Installationsverzeichnis liegen.

Und deshalb halte ich das für eine beknacktes Design.

LaTino

Nein, das denke ich mir nicht aus.