Laden...

Zum Speichern von Einstellungn lieber Ini oder Xml?

Erstellt von doubleII vor 7 Jahren Letzter Beitrag vor 7 Jahren 5.693 Views
D
doubleII Themenstarter:in
33 Beiträge seit 2016
vor 7 Jahren
Zum Speichern von Einstellungn lieber Ini oder Xml?

Hallo,

was wäre einfacher, wenn man Einstellungen einer Benutzeroberfläche speichern, aufrufen, ändern (also Speicherverwaltung) möchte. Ini File oder XML? Was würdet ihr mir empfehlen?

Schöne Grüße
doubleII

2.207 Beiträge seit 2011
vor 7 Jahren

Hallo doubleII,

wieso kein JSON?

Siehe aber auch [Tutorial] Konfigurationsmodell im .NET Framework

Gruss

Coffeebean

C
2.121 Beiträge seit 2010
vor 7 Jahren

Jedenfalls keine ini Files 😃

T
2.219 Beiträge seit 2008
vor 7 Jahren

C# bietet hier entsprechende Möglichkeiten solche Configs abzuhändeln.
Natürlich würde ich hier XML oder alternativ auch JSON nehmen.
Was du davon nimmst, ist dann reine Geschmacks sache.
Ini Dateien sollte man definitiv nicht mehr nutzen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

D
doubleII Themenstarter:in
33 Beiträge seit 2016
vor 7 Jahren

Vielen Dank,

ich habe ein paar JSON Tutorial angeschaut, ich glaube, nehme ich JSON. XTM ist mir etwas schwer, glaube ich.
Warum auf kein Fall ini File. Was meint ihr damit?

Schöne Grüße
doubleII

2.207 Beiträge seit 2011
vor 7 Jahren

Hallo doubleII,

ich behaupte einfach mal, dass das heutzutage gerade bei Neuentwicklungen kein Mensch mehr macht. (Gleich geht's los 😉 )

Gruss

Coffeebean

16.806 Beiträge seit 2008
vor 7 Jahren

ini Dateien sind ein Relikt und haben schon lange ihre Nachfolger - eben wegen den vielen Nachteilen! - gefunden: in XML und Json.

  • ini Dateien sind nur schwer bzw. umständlich pragrammatisch zu lesen
  • sie können nicht validiert werden
  • haben keinerlei Hierarchiemöglichkeit

Es ist Absicht, dass .NET von Haus aus keine INI-Unterstützung hat.
Sonst wäre dieses Konstrukt heute noch im Einsatz - ist es aber Gott sei dank in aktueller Software kaum noch.
Alles ist besser als eine ini Datei.

D
doubleII Themenstarter:in
33 Beiträge seit 2016
vor 7 Jahren

Alles klar. Danke.

Ich habe eine Frage jetzt. Ich habe von NuGet Newtonsoft.json installiert. Muss ich dann eine .json oder .js erstellen?> Fehlermeldung:

unexpected character encountered while parsing value . path '' line 0 position 0

Danke!

16.806 Beiträge seit 2008
vor 7 Jahren

"Json als Klasse" zeigt anhand des Namens, das man eine Json-Inhalt in der Zwischenablage haben muss. Das sagt der Fehler ja auch eindeutig aus.

Darauf formt das Visual Studio dann - ähnlich wie xml2cs - eine CSharp Klasse.
Nichts anderes wird das Tutorial hier vermutlich zeigen (und auch so heißen?).

Json-Dateien für Inhalte haben üblicherweise *.json Endung.

D
doubleII Themenstarter:in
33 Beiträge seit 2016
vor 7 Jahren

Okay mir ist es das alles nicht so eindeutig aber Danke. 😃

Ich habe die .json Datei oben in der linken Ecke habe ich Schema: http.//json.schemastore. (Auswahl)
Für was sind die Schema? Was heißt das genau? Sind Verschiedene auto Schemas oder etwas anderes?

   string JSONstring = File.ReadAllText("generalConfig.json");

Warum habe ich einen Fehlermeldung > Fehlermeldung:

Die Datei wurde nicht gefunden.

Nochmal Vielen Dank!

1.029 Beiträge seit 2010
vor 7 Jahren

Hi,

.js nimmt man normalerweise für JavaScript, .json für JSON.

Naja - die Fehlermeldung ist eindeutig. Die Datei ist nicht da, wo dein Programm sie erwartet - respektive: deine kompilierte *.exe-Datei findet die JSON-Datei nicht.

Wenn du unter VisualStudio arbeitest und die JSON-Datei der Projektmappe hinzugefügt hast, kannst du z.B. unter Eigenschaften der Datei einstellen, dass diese ins Ausgabeverzeichnis kopiert wird...

LG

74 Beiträge seit 2014
vor 7 Jahren

JSON ist kein gutes Format für Konfigurationen. Einfach aus dem Grunde, dass es keine Kommentare kennt. Wenn diese Konfigurationsdateien von Menschen bearbeitet werden sollen, ist das ein großer Nachteil für mich.

Wenn ich die Wahl zwischen INI und JSON hätte, würde ich lieber INI nehmen.

Grüße

463 Beiträge seit 2009
vor 7 Jahren

Wenn ich die Wahl zwischen INI und JSON hätte, würde ich lieber INI nehmen.
Grüße

Sehe ich genauso - man muss auch nicht immer mit aller Gewalt alte Techniken verdammen und schlecht reden. Für kleinere Projekte ist eine INI Datei (mit bis zu ca. 25 Werten) auch heute noch in meinen Augen absolut in Ordnung.

Stefan

3.003 Beiträge seit 2006
vor 7 Jahren

JSON ist kein gutes Format für Konfigurationen. Einfach aus dem Grunde, dass es keine Kommentare kennt.

Interessant, denn genau das ist der Grund, wieso wir auf json umstellen. Die über Jahre (>25) gewachsenen ini-Dateien sind zu 95% Kommentar, und niemand, am wenigsten der Kunde selbst, weiss noch, WIESO diese oder jene Option im Jahre 2003 mal auskommentiert wurde. Man traut sich auch nicht, sie zu entfernen - dabei könnte ja Wissen verloren gehen - oder gar wieder einzubauen. Und so wächst die ini, und wächst, und wächst...vom Overhead für's Parsing und (programmatische) bearbeiten wollen wir gar nicht reden.

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)

709 Beiträge seit 2008
vor 7 Jahren

Ich werfe mal den Exoten YAML in die Diskussion.
Es ist ähnlich simpel wie eine INI-Datei aufgebaut, kann aber weitaus mehr (und Kommentare gehen auch).

463 Beiträge seit 2009
vor 7 Jahren

Interessant, denn genau das ist der Grund, wieso wir auf json umstellen. Die über Jahre (>25) gewachsenen ini-Dateien sind zu 95% Kommentar, und niemand, am wenigsten der Kunde selbst, weiss noch, WIESO diese oder jene Option im Jahre 2003 mal auskommentiert wurde.
LaTino

Genau das selbe wird in 15 Jahren über JSON hier stehen und JSON als total veraltert dargestellt werden...

D
doubleII Themenstarter:in
33 Beiträge seit 2016
vor 7 Jahren

Ich danke allen, die geschrieben haben.

Ich habe mich immer noch nicht entschieden welche Dateityp soll ich nehmen. Ich versuche es zu konkretisieren .

Es geht um Kameraeinstellungen, die beim Laden der Benutzeroberfläche gelesen werden müssen, also von einer Seite es geht um Standard Kameraeinstellungen, von anderer Seite, wenn man die Einstellungen ändert, sie können gespeichert werden, wenn der User will.

  1. Lesen der Datei
  2. Ändern der Datei (Schreiben auf die Datei).

Ich habe ein Objekt (Allgemeine Einstellungen) und in diesem Objekt andere Objekte, wenn man JSON nimmt (so weit ich die Sprache verstanden habe)
In diesem äußeren Objekt (Allgemeine Einstellungen) existieren Toolboxen (die andere Objekte). Sie haben eigene Einstellungen. Das ist alles.
Es ist nicht viel. Was würdet ihr für solche Einstellungen empfehlen.

Abt hat folgendes geschrieben:

ini Dateien sind ein Relikt und haben schon lange ihre Nachfolger - eben wegen den vielen Nachteilen! - gefunden: in XML und Json.

  • ini Dateien sind nur schwer bzw. umständlich pragrammatisch zu lesen
  • sie können nicht validiert werden
  • haben keinerlei Hierarchiemöglichkeit

Es ist Absicht, dass .NET von Haus aus keine INI-Unterstützung hat.
Sonst wäre dieses Konstrukt heute noch im Einsatz - ist es aber Gott sei dank in aktueller Software kaum noch.
Alles ist besser als eine ini Datei.

Okay dann bleiben die beide .xml, .json. Ich habe irgendwo gelesen, dass die XML-Doku bei Microsoft nicht großartig erklärt wird.
Pinki hat noch YAML als Möglichkeit gegeben.
Ich möchte was einfaches nehmen.

Vielen Dank!

2.207 Beiträge seit 2011
vor 7 Jahren

Hallo doubleII,

Ich möchte was einfaches nehmen.

naja, dann schau dir doch mal die Syntax des jeweiligen Formats an. Und was dir gefällt, das nimmst du. JSON ist einfach in der Syntax, lässt sich einfach (De)Serialisieren...mehr brauchst ja eigentlich nicht. Zumal du es, richtig abstrahiert, sowieso austauschen können solltest.

Gruss

Coffeebean

16.806 Beiträge seit 2008
vor 7 Jahren

Es gibt eine entsprechende Doku. (Zweiter Treffer bei "Microsoft XML"): MSDN: XML
Davon abgesehen gibt es mehr Quellen über allgemeine Technologien als nur Microsoft.

YAML ist eine option (nutze ich selber).
Wer aber mit XML so seine Schwierigkeiten hat, der sollte meiner Meinung nach von Exoten wie YAML erstmal Abstand nehmen.
Das Lesen von YAML kann das .NET Framework auch nicht von Haus aus.

Stefan.Haegele, das glaube ich nicht bzw. schwer vorzustellen.
Json hat nahezu kein Overhead und deckt viel mehr Szenarien ab.

Json ist zudem prinzipiell mal zur Datenübertragung gedacht gewesen - XML für schema-behaftete Dinge.
Json Schema ist nicht wirklich weit verbreitet und das Tooling ebenfalls nicht.

Anfänger sollten nicht überfordert werden; wieso ihn also mit so vielen verschiedenen Dingen bewerfen?
Völlig unnütz in meinen Augen.

XML ist am weitesten verbreitet, darauf ist das .NET Framework ausgerichtet und wird sich auch noch "ein paar Jahre" halten.
Er wirds so oder so brauchen.

3.003 Beiträge seit 2006
vor 7 Jahren

Genau das selbe wird in 15 Jahren über JSON hier stehen und JSON als total veraltert dargestellt werden...

Wenn man in 15 Jahren eine Möglichkeit gefunden hat, in eine serialisierte Darstellung eines Objekts Kommentare einzufügen, ja. 🤔

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)

D
doubleII Themenstarter:in
33 Beiträge seit 2016
vor 7 Jahren

Also besser geeignet wäre XML aber ich kann auch JSON nehmen. Hm vielleicht nehme ich doch XML.

Hier ein link an allen, die noch nicht wissen, wie man ein Text/XML/JSON Datei in Visual Studio einbinden kann. 😃
https://www.youtube.com/watch?v=874NuVyFg7I

Danke!

Schone Grüße
doubleII

R
228 Beiträge seit 2013
vor 7 Jahren

Es ist im JSON Format zwar nicht vorgesehen, aber JSON.Net unterstützt doch zum Beispiel Kommentare.

16.806 Beiträge seit 2008
vor 7 Jahren

Ist dann aber kein standardgetreues Json mehr, sondern mit JavaScript comment flavour.

3.003 Beiträge seit 2006
vor 7 Jahren

Es ist im JSON Format zwar nicht vorgesehen, aber JSON.Net unterstützt doch zum Beispiel Kommentare.

Zum einen, was Abt sagt, zum anderen ist JSON ein Datenaustauschformat. Einmal deserialisieren und wieder serialisieren, und du kannst den Kommentaren Lebwohl sagen 😉.

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)

199 Beiträge seit 2006
vor 7 Jahren

Also warum json in .NET Entwicklung empfohlen wird, versteh ich ehrlich gesagt nicht. Allein schon vom Namen her (Java Script Object Notation) ist eigentlich schon klar, wo json hingehört.
Json finde ich als Konfigurations-Format absolut untauglich, da es meiner Meinung nach (und auch nach der Meinung meiner meisten Kunden) schlecht lesbar ist und daher auch schwierig zu bearbeiten ist.

XML ist in .NET viel leichter zu verarbeiten. Es gibt nativ alle Methoden dafür, die man benötigt und man braucht keine zusätzliche Komponente. Klar ist XML ziemlich aufgebläht, aber wir reden hier nur von einer Konfigurations-Datei. Da spielen meiner Meinung nach ein paar Byte mehr oder weniger keine Rolle.
Aber auch bei XML hatte ich schon Probleme mit Kunden, weil sie damit nicht umgehen können.

Für den absoluten DAU ist meistens wirklich eine INI-datei mit entsprechenden Kommentaren am leichtesten zu verstehen und kann vom Kunden auch am ehesten bearbeitet werden. Ein kleiner Parser dafür ist auch mit einfachen Mitteln (Regex und Co) schnell erstellt und gegebenfalls gibt es dafür auch einige gute Komponenten, die das Leben damit gewaltig vereinfachen.

Wenn jetzt jemand behauptet, dass eine Config-Datei ja auch nicht für den Kunden lesbar sein muss, weil man dafür in der Regel eine Konfigurations-Oberfläche bereitstellt, dem geb ich natürlich recht. Aber dann brauch ich auch kein Textformat um die Konfiguration zu speichern, sondern dann speicher ich die Konfiguration binär als Object-Dump und gut ist.

Im Grunde kommt es immer auch die Anforderung an, die der Kunde stellt.

Meine persönliche Empfehlung ist XML. Ich habe eine Objekt (static oder singleton), in dem alle bekannten Properties enthalten sind und im Konstruktor dieses Objekts wird die Konfigurations-Datei gelesen und per Linq2Xml verarbeitet und die einzelnen Properties gefüllt. Fertig ist die Wurst. Wenn man noch die Möglichkeit zur Änderung der Konfiguration einbaut, gibt es dann eben noch eine SaveToXml Methode, die die Properties dann eben wieder in ein Xml packt und das Ganze wegschreibt.
Alternativ kann man auch noch per Serialisierung das Ganze ein bisschen vereinfachen.

3.003 Beiträge seit 2006
vor 7 Jahren

Also warum json in .NET Entwicklung empfohlen wird, versteh ich ehrlich gesagt nicht.

Kürzeste Antwort: .net core.

(zB hierfür)

Deine Kritikpunkte daran sind zwar valide [1], das ändert aber nichts am Paradigmenwechsel weg von XML. Man nutzt halt das, was die Umgebung vorgibt, weil die Umgebung damit am besten klar kommt. "Früher" war das XML, jetzt ist es halt json.

LaTino
[1] okay, bis auf den Bezug auf den Namen (javascript object notation, hat nichts mit Java zu tun. Und json selbst ist halt inzwischen DAS universelle serialisierte Datenaustauschformat)

"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)

199 Beiträge seit 2006
vor 7 Jahren

Kürzeste Antwort: .net core.

(zB
>
)

Aber da steht auch drin, dass man von project.json auf msbuild wechseln will.

The .NET Core tooling is going to move from project.json to MSBuild-based projects in a future release. The recommendation is to still use project.json files for new .NET Core projects since there will be a path to convert your project to MSBuild when the tooling is released.

okay, bis auf den Bezug auf den Namen (javascript object notation, hat nichts mit Java zu tun. Und json selbst ist halt inzwischen DAS universelle serialisierte Datenaustauschformat)

Ich wollte damit auch nicht sagen, dass es was mit java zu tun (Ok, ich hab ein Leerzeichen zuviel drin). Aber json kommt definitiv von Javascript.
Für den Datenaustausch ist es auch vollkommen in Ordnung. Da bringt json natürlich viele Vorteile mit sich, weil man relativ problemlos zwischen verschiedenen Architekturen austauschen kann.
Aber eine Konfigurationsdatei hat meiner Meinung nach nicht viel mit Datenaustausch zu tun.

3.003 Beiträge seit 2006
vor 7 Jahren

Wie gesagt kann man da prima diskutieren, und die goldene Lösung gibt es eben nicht. (Man kann sich aber darüber einig sein, dass .ini nicht die goldene Lösung ist 😉 ). Ich tendiere dazu, das zu benutzen, worauf das tooling zugeschnitten ist. In .net core ist das an allen Ecken und Enden JSON (der Beispiellink war blöde gewählt...Konfigurationen in net core wäre ein besserer Link gewesen, um zu verdeutlichen, dass hier die Prioritäten bei den Tools eben auf JSON liegen).

Und für das multiplattform-Framework net core ergibt JSON auch Sinn - gerade weil es ein Datenaustauschformat ist. Soll nicht heissen, dass es nicht auch für XML auf allen möglichen Systemen Tools zum bearbeiten und anschauen gäbe. Wie gesagt, es ist aus meiner Sicht kein entweder-oder, sondern ein wenn-dann.

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)

16.806 Beiträge seit 2008
vor 7 Jahren

project.json ist schon wieder tot und wird durch eine aktualisierte csproj-Fassung ersetzt.

T
708 Beiträge seit 2008
vor 7 Jahren

Dann mische ich mich doch auch mal mit ein 😃

Für alle meine Projekte verwende ich ein und die selbe Serializer-Klasse.
Diese stellt mir eine Funktion zum Laden und eine zum Speichern zur Verfügung. Per optionalen Parametern, kann ich den Pfad und die Art mitgeben.
Art umfasst aktuell: Xml, Json & Binary.

Wenn ich nun einen Dienst ohne GUI verwende, setze ich i.d.R. auf XML, da auch ein nicht-Entwickler-Kollege oder Kunde damit klar kommt.

Biete ich eine Einrichtung in der GUI oder es handelt sich um Daten, die nur von meiner Anwendung verwendet und angezeigt werden, setze ich auf Json.

Möchte ich nicht, dass jemand "mal eben" an der Konfig rumfummelt, verwende ich Binary. Hat aber den Nachteil, dass ich selbst auch nicht "mal eben" etwas ändern kann.

Verändert sich eine der o.g. Anforderungen, kann ich mit einem Parameter auf das nächstbeste Format wechseln.
Wenn aber möglich, verwende ich Json, da ich immer den Anspruch habe, eine kompakte Lösung bereitzustellen.

Ini verwende/unterstütze ich nicht, da es keinen sauberen, standardisierten Serializer gibt.