cfg-Datei oder Registry?
hi leute,
habe in einem .net buch gelesen, dass es kein guter stil mehr sein soll, die registry zu nutzen, um bestimmte anwendungsparameter zu hinterlegen; stattdessen sollte man lieber die cfg-dateien der anwendung verwenden.
könnt ihr das so unterschreiben?
was ist gegen die registry auszusetzen?
und ist es nicht bei der cfg-datei so, dass sie pro rechner nur einmal existiert (nämlich im pfad der anwendung) und ich daher nicht für mehrere benutzer verschiedene angaben speichern kann (was ich in der registry unter local user ja sehr wohl kann) ?
danke für eure meinung
ron
Hallo citizen.ron!
Ich verwende seit .NET nur noch xml-Settings Files, da sie besser lesbar sind, als in der Registry. Genauso lassen sie sich besser Im- und Exportieren. Aber ob das guter Stil ist, weiß ich nicht, und ob das so allgemeinüblich ist, weiß ich ebenso nicht...
Wollte das nur erwähnen.
Ciao
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
hi timo,
bin mit xml noch gar nicht warm geworden, daher vielleicht die unwissende frage:
wie löst du denn mit xml files die verschiedenen einstellungen unterschiedlicher benutzer? über knoten in der gleichen datei?
Hallo nochmal!
Das kommt jetzt darauf an. Entweder bekommt jeder User seine eigene Setting-Datei, dann muss vor dem Laden eine Authentifizierung vorgenommen werden, oder ich löse das in der Tat mit Knoten innerhalb der Datei.
Hier ist zu unterscheiden, wie die Zugriffsrechte auf Dateiebene vergeben sind, und ob ein User die Einstellungen des anderen sehen darf, und ähnliches...
Meistens stehen die Settings in einer Datei, die dann vielleicht so aussieht:
<?xml version="1.0" encoding="utf-8" ?>
<Settings>
<!-- allgemeine Einstellungen //-->
<Debug enabled="True" />
<Basisverzeichnis path="http://localhost/irgendwas/" />
<Database>
<connectionstring connectionstring="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=irgendwas.mdb;"/>
</Database>
<Mwst>
<MWST_Satz1 colName="MWST_Betrag1" value="16,0"/>
<MWST_Satz2 colName="MWST_Betrag2" value="7,0"/>
</Mwst>
<Numberformat>
<format culture="de-DE"/>
</Numberformat>
<!-- spezielle Einstellungen //-->
<Admin>
<Role int="255">
</Admin>
<Customer>
<Role int="5">
</Customer>
</Settings>
Das ist jetzt nur mal so schnell aus den Fingern gesaugt, da ich hier verständlicherweise kein original Setting posten kann 😉
Aber das zeigt wie ich das mache. Hier ist es so, dass ich allgemeine Einstellungen in eine Klasse einlese, und die speziellen dann extra auslese.
Für das Ein- und Auslesen schreibe ich mir dann eine Methode in der entsprechenden Settings-Klasse, die mir die Daten lesen und schreiben kann. Ist immer noch nicht Perfekt, weil auch noch ohne XML-Schema und ohne Vollautomatisches Ein- und Auslesen, aber für Settings halte ich das auch für schwierig.
Ciao
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
habe in einem .net buch gelesen, dass es kein guter stil mehr sein soll, die registry zu nutzen, um bestimmte anwendungsparameter zu hinterlegen; stattdessen sollte man lieber die cfg-dateien der anwendung verwenden.
könnt ihr das so unterschreiben?
Hallo citizen.ron,
ja, ich persönlich kann das so unterschreiben. Soweit ich weiß, verfolgt .NET den Ansatz, Anwendungsdaten nicht mehr in der Registry zu speichern. Ich finde das auch besser, da sie so wesentlich besser lesbar sind und man sie auch mal eben auf einen anderen Rechner kopieren kann.
Gruß,
Fabian
"Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vornherein ausgeschlossen erscheint." (Albert Einstein)
Gefangen im magischen Viereck zwischen studieren, schreiben, lehren und Ideen umsetzen…
Blog: www.fabiandeitelhoff.de
Hallo und guten Tag.
Zu diesem Thema hat mir der folgende Artikel weitergeholfen:
AnwendungseinstellungenInNETFramework.mspx
Gruß
HoGi
2b | !2b = 0xff
Benutzerabhängige Einstellungen lassen sich meiner Meinung nach ganz einfach über die Benutzerordner von Windows handeln. Oder man legt selbst noch Ordner im Anwendungsverzeichnis an. Oder man macht es mit den Knoten innerhalb des Dokuments. Oder ein Prefix für jede User-xml-datei, oder oder oder.
XML ist schön! 😁
Anwendungsverzeichnis ist schlecht, gibt Probleme mit der Sicherheit.
Du könntest auch die Klasse, die die Einstellungen speichert serialisieren. Das geht kinderleicht und du musst dich um fast gar nichts kümmern.
Gruß,
SimonKnight6600
Anwendungsverzeichnis ist schlecht, gibt Probleme mit der Sicherheit.
Versteh ich nicht, das darf normalerweise das einzige Verz. sein auf dem der Benutzer schreiben darf.
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
Hallo Svenson!
Anwendungsverzeichnis ist schlecht, gibt Probleme mit der Sicherheit.
Und wenn ich ein separates Unterverzeichnis anlege, und diesem spezielle Rechte zuweise? So muss ich das auch für WebAnwendungen tun, und ich krieg die Krise, wenn dann irgendwo in "Dokumente und Einstellungen" in einem Unterverzeichnis bei einem "IUSERxxx" dann irgendwelche Konfigs gespeichert werden.
Deshalb enthält bei mir jede Applkikation auch ein Unterverzeichnis "Config", und diesem erlaube ich Schreibrechte für "Jeder".
Wie ist dieser Ansatz?
Ciao
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Gut, bei den Anwenderverzeichnissen über Windows muss ich meine Meinung ändern. Alles was mit der Anwendung zu tun hat, ist im Verzeichnis c:\Programme\MySuperExe. Wenn ich erst wieder in "Dokumente und Einstellungen......" gehen müsste, finde ich auch einen Eintrag in der Registry. Sogesehen ist das Config-Verzeichnis wohl am angenehmsten.
Sicherheitsprobleme hätte ich bei einem Registryeintrag auch. Oder kann man dort Benutzerrechte vergeben?
Ob Registry, Configfile, mit oder ohne xml, da oder dort, eine Superlösung für alle Probleme wird es in dieser Frage wohl nicht geben.
Sicherheitsprobleme hätte ich bei einem Registryeintrag auch. Oder kann man dort Benutzerrechte vergeben?
Es gibt im wesentlichen zwei Schlüssel die relevat sind: HKEY_LOCAL_MACHINE und HKEY_CURRENT_USER.
Benutzer mit eingeschränktem Konto können nur HKEY_CURRENT_USER lesen und schreiben. Der Andere ist nur für Leute mit Adminrechten. Deshalb sollten auch keine Nutzerspezifischen Sachen in HKEY_LOCAL_MACHINE gespeichert werden.
Deshalb enthält bei mir jede Applkikation auch ein Unterverzeichnis "Config", und diesem erlaube ich Schreibrechte für "Jeder".
Könnte man machen, nur leider hast du dann aber keine klare Trennung zwischen verschiedenen Nutzerprofilen.
Das könnte in besonderen Fällen auch zu Sicherheitsproblemen führen. Mal ein paranoides Szenario : 😉
Stell dir vor, in deinen Config-Files kann man bestimmte PlugIns festlegen, die beim Start deiner Anwenung geladen werden sollen. Ein Angreifer bräuchte jetzt nur noch ein Gastkonto um deinen Rechner zu kompromitieren. Er schreibt einfach ein neues PlugIn, welches einen Keylogger, Trojaner oder anderen Backdoor startet und trägt es einfach in deine Config ein (ist ja für jeden les- und schreibbar).
Für die meiste Wald- und Wiesen-Software ist sowas natürlich kaum relevat, aber für Software in einem bestimmten Umfeld ist sowas todlich ...
I am Jack's smirking revenge.
I am Jack's raging bile duct.
I am Jack's cold sweat.
I am Jack's complete lack of surprise.
I am Jack's broken heart.
I am Jack's wasted life.
Hallo maxE!
Ja desses bin ich mir bewusst.
Aber PlugIns werde ich sicherlich nicht einem User per File überlassen 🙂 Da programmiere ich das aus. Normalerweise kann man meine Software im Programm selbst steueren, und wenn ich nur eine simple Eingabemaske mit Häkchen setzen anbiete.
Also bei mir kommt in die Konfig-DATEI wirklich nur das, was direkt beim Start der Software unmittelbar gebraucht wird.
Da ich für meine Software (meist WebApplikationen) auf einem Server bin, der garantiert KEIN Gastkonto hat (um Gottes Willen 😉 lässt sich so etwas realisieren.
Bisher war ich für so etwas zu faul, wirklich auf File-Basis runter die Rechte einzeln zu setzen.
Zu Rechtevergabe innerhalb der Registry:
Man kann zu jedem Schlüssel separat Rechte vergeben. Früher gab es 2 versch. Registry Editoren mit untersch. Leistungsumfang, heute wird nur noch einer gestartet, der aber alles kann.
Ich kann auf einem Win2003-Rechner mittels "Regedit.exe" auf einen belibigen Schlüssel klicken, und dann mit Bearbeiten->Berechtigungen Rechte vergeben, so wie für Dateien.
Siehe hierzu auch
Unterschied Regedit.exe - Regedt32.exe
Ciao
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”