Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

VirtualStore beim Umstieg von 32 auf 64 Bit nicht mehr verfügbar?
fantinger
myCSharp.de - Member



Dabei seit:
Beiträge: 23

Themenstarter:

VirtualStore beim Umstieg von 32 auf 64 Bit nicht mehr verfügbar?

beantworten | zitieren | melden

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:


FileInfo fi = new FileInfo(Assembly.GetEntryAssembly().Location); // Verzeichnis der Anwendung ermitteln
cfgpath = fi.DirectoryName + @"\prg.cfg";             
cfgBak = fi.Directory + @"\prg_bak.cfg";
cfgBasis = fi.Directory + @"\standard.cfg";

Kennt jemand dieses Problem und hat ggf. einen Lösungsansatz?

viele Grüße

Christian
private Nachricht | Beiträge des Benutzers
Stefan.Haegele
myCSharp.de - Member

Avatar #avatar-3068.jpg


Dabei seit:
Beiträge: 430
Herkunft: Untermeitingen

beantworten | zitieren | melden

[FAQ] Pfad zur eigenen Anwendung (EXE) ermitteln
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3061
Herkunft: Thüringen

beantworten | zitieren | melden

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
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15510
Herkunft: BW

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
fantinger
myCSharp.de - Member



Dabei seit:
Beiträge: 23

Themenstarter:

beantworten | zitieren | melden

Hallo,

vielen Dank - Problem gelöst!

Christian
private Nachricht | Beiträge des Benutzers
trashkid2000
myCSharp.de - Member



Dabei seit:
Beiträge: 157

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3061
Herkunft: Thüringen

beantworten | zitieren | melden

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
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
trashkid2000
myCSharp.de - Member



Dabei seit:
Beiträge: 157

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3061
Herkunft: Thüringen

beantworten | zitieren | melden

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.
  • Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von LaTino am .
    "Furlow, is it always about money?"
    "Is there anything else? I mean, how much sex can you have?"
    "Don't know. I haven't maxed out yet."
    (Furlow & Crichton, Farscape)
    private Nachricht | Beiträge des Benutzers