Forum: PC-Programmierung ProgramData, wie macht man es richtig?


von Thomas W. (Firma: ipc-systems) (werner_tom)


Lesenswert?

Hallo,

Ich habe eine .Net Software, die ihre Konfiguration in den Programdata 
Ordner speichert. den richtigen Zielpfad erhalte ich mit 
"Windows.Forms.Application.CommonAppDataPath", also 
c:\programdata\Hersteller\Progammname\Version.

Allerdings habe ich Probleme mit den Zugriffsrechten bei mehreren 
Benutzern.

Wenn Benutzer1 die Software das erstemal startet, dann wird das 
Verzeichnis angelegt und die Konfig gespeichert. Der Benutzer1 kann die 
Software ganz normal nutzen, also Konfig laden, ändern und speichern.

Melde ich mich jetzt als Benutzer2 an und starte die Software, dann kann 
zwar das Programm die Konfig öffnen aber nicht wieder speichern. 
(Zugriff verweigert).
Der Benutzer2 kann aber im Verzeichnis 
"c:\programdata\Hersteller\Progammname\Version" neue Dateien erstellen 
und auch speichern, aber die vom Benutzer1 erstellte Konfig nicht 
ändern.

Ich suche nach einer Möglichkeit, die Konfig abzulegen, die von jedem 
Benutzer auch geändert werden kann.
Das ganze sollte Windowskonform sein.
Ich möchte nicht einen "neutralen" Ordner anlegen (z.B. c:\MeineKonfig).
Auch möchte ich nicht nachträglich händisch die Rechte der Datei ändern 
müssen.
Es muss doch eine offizelle Lösung geben, wo man zentral Dateien ablegen 
kann, auf die alle Benutzer Vollzugriff haben

Kann mir vieleicht einer weiterhelfen?

Gruß
Tom

von Robert L. (lrlr)


Lesenswert?

FOLDERID_ProgramData / 
System.Environment.SpecialFolder.CommonApplicationData
The user would never want to browse here in Explorer, and settings 
changed here should affect every user on the machine. The default 
location is %systemdrive%\ProgramData, which is a hidden folder, on an 
installation of Windows Vista. You'll want to create your directory and 
set the ACLs you need at install time.


der letzte Satz ist wichtig..

ansonsten vielleicht nach %public% ...

von Vlad T. (vlad_tepesch)


Lesenswert?

Thomas Werner schrieb:
> Ich habe eine .Net Software, die ihre Konfiguration in den Programdata
> Ordner speichert.

das wird das Hauptproblem sein.
Der normale Benutzer hat keine Schreibrechte im Programmverzeichnis und 
damit auch von ihm gestartete Anwendungen nicht.
Konfigurationen müssen im Benutzerprofilverzeichnis gespeichert werden.

von Thomas W. (Firma: ipc-systems) (werner_tom)


Lesenswert?

Ich rede hier vom ProgramData und nicht von "Programme", "Program files" 
oder ...(x86)

im ProgramData hat jeder Benutzer Schreibrechte, allerdings nur aus 
seine eigenen Dateien.
Ich habe gerade meine Software so umgestellt:

falls die Datei nicht vorhanden ist wird sie erstellt.
Der aktuell angemeldete Benutzer darf ja die Datei erstellen.
Da er automatisch auch der Besitzer ist, kann ich im nächsten Schritt 
auch die Rechte auf "Jeder" "Vollzugriff" setzen.
Greift dann Benutzer2 schreibend auf diese Datei zu, dann darf er das 
jetzt auch.

Bin grad am testen, ob das in allen Situationen funktioniert.

tom

von Markus V. (valvestino)


Lesenswert?

Hallo Tom,

mir fallen da spontan drei Lösungen ein:

1. Setze über ein Setup-Programm die Zugriffsrechte des betreffenden 
Directory-Baums so, dass alle User Änderungen machen können.

2. Beschaffe Dir im Programm die erforderlichen Zugriffsrechte. Das 
erfordert aber sicherlich einen Admin-Account zur Laufzeit.

3. Lege in ProgramData eine Default-Konfiguration ab, die für alle 
ReadOnly ist. Wenn ein Anwender Änderungen macht, speichere die Änderung 
in einem Ordner des Users ab (siehe 
System.Environment.GetFolderPath(System.Environment.SpecialFolder)). 
Beim Lesezugriff dann den umgekehrten Weg gehen: Zuerst beim User, dann 
in der zentralen Config nachschauen. Das hat den Vorteil, dass sich die 
User nichts gegenseitig "kaputt konfigurieren".

Gruß
Markus

von Thomas W. (Firma: ipc-systems) (werner_tom)


Lesenswert?

Hi Markus
In meinem Fall geht es darum, das benutzer1 die Software installiert 
oder einfach via copy/paste auf den rechner bringt und konfiguriert.
Beim Benutzer2 läuft die Anwendung als shell. da wird nichts gegenseitig 
"kaputt konfiguriert".
Ich werde jetzt die entsprechenden Rechte durch die Anwendung setzten.
Ich bin mir allerdings nicht sicher, ob das der offizielle 
windowskonforme Weg ist.
Ich glaube, auch wenn es mir schwerfällt, daß sich Microsoft schon was 
dabei gedacht hat, wenn die anderen Benutzer keine Schreibrechte auf 
dieser Datei haben.

Gruß
Tom

von Robert L. (lrlr)


Lesenswert?

>ob das der offizielle
>windowskonforme Weg ist.

c&p "Installation" ist mal auf jeden Fall nicht "windows konform"

IMHO ist der richtige weg, wie ich oben schon gepostet habe

beim INSTALLIEREN (da ist man ja Admin) die dateien (oder einfacher ein 
Unterverzeichnis)  anlegen und Rechte (mit Vererbung) setzten..

von Markus V. (valvestino)


Lesenswert?

Robert L. schrieb:
> beim INSTALLIEREN (da ist man ja Admin) die dateien (oder einfacher ein
> Unterverzeichnis)  anlegen und Rechte (mit Vererbung) setzten..

Das sehe ich auch so. Siehe Punkt 1 in meinem Post. Der Vorteil ist, das 
es sich um eine einmalige Aktion bei der "Installation" handelt und 
danach zur Laufzeit nur Standard-Rechte benötigt werden.

Gruß
Markus

von Oliver R. (superberti)


Lesenswert?

Hi,

falls die Lösung etwas größer ausfallen darf, dann könnte ein 
entsprechender Dienst auch die Lösung sein. Mit WCF ist sowas relativ 
leicht erstellt und kann auch noch bei anderen Dingen (z.B. Logging) 
ganz nützlich sein.
Manchmal hat man halt die Situation, dass alle User genau EINE 
Konfiguration ändern können sollen, die dann für alle gilt.

Gruß,

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.