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

  • »
  • Community
  • |
  • Diskussionsforum
Zum Speichern von Einstellungn lieber Ini oder Xml?
doubleII
myCSharp.de - Member



Dabei seit:
Beiträge: 33

Themenstarter:

Zum Speichern von Einstellungn lieber Ini oder Xml?

beantworten | zitieren | melden

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

Avatar #avatar-3295.gif


Dabei seit:
Beiträge: 2461
Herkunft: Deutschland/Schweiz

beantworten | zitieren | melden

Hallo doubleII,

wieso kein JSON?

Siehe aber auch [Tutorial] Konfigurationsmodell im .NET Framework

Gruss

Coffeebean
private Nachricht | Beiträge des Benutzers
chilic
myCSharp.de - Experte



Dabei seit:
Beiträge: 2143

beantworten | zitieren | melden

Jedenfalls keine ini Files :-)
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1920
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 33

Themenstarter:

beantworten | zitieren | melden

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

Avatar #avatar-3295.gif


Dabei seit:
Beiträge: 2461
Herkunft: Deutschland/Schweiz

beantworten | zitieren | melden

Hallo doubleII,

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

Gruss

Coffeebean
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16234

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
doubleII
myCSharp.de - Member



Dabei seit:
Beiträge: 33

Themenstarter:

beantworten | zitieren | melden

Alles klar. Danke.

Ich habe eine Frage jetzt. Ich habe von NuGet Newtonsoft.json installiert. Muss ich dann eine .json oder .js erstellen?
Fehler
unexpected character encountered while parsing value . path '' line 0 position 0

Danke!
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von doubleII am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16234

beantworten | zitieren | melden

"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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
doubleII
myCSharp.de - Member



Dabei seit:
Beiträge: 33

Themenstarter:

beantworten | zitieren | melden

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
Fehler
Die Datei wurde nicht gefunden.

Nochmal Vielen Dank!
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von doubleII am .
private Nachricht | Beiträge des Benutzers
Taipi88
myCSharp.de - Member

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1044
Herkunft: Mainz

beantworten | zitieren | melden

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

Avatar #avatar-3452.jpg


Dabei seit:
Beiträge: 74

beantworten | zitieren | melden

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

Avatar #avatar-3068.jpg


Dabei seit:
Beiträge: 463
Herkunft: Untermeitingen

beantworten | zitieren | melden

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

Avatar #avatar-4122.png


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

beantworten | zitieren | melden

Zitat von Lando
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)
private Nachricht | Beiträge des Benutzers
pinki
myCSharp.de - Member

Avatar #avatar-4072.jpg


Dabei seit:
Beiträge: 706
Herkunft: OWL

beantworten | zitieren | melden

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).
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von pinki am .
private Nachricht | Beiträge des Benutzers
Stefan.Haegele
myCSharp.de - Member

Avatar #avatar-3068.jpg


Dabei seit:
Beiträge: 463
Herkunft: Untermeitingen

beantworten | zitieren | melden

Zitat von LaTino
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...
private Nachricht | Beiträge des Benutzers
doubleII
myCSharp.de - Member



Dabei seit:
Beiträge: 33

Themenstarter:

beantworten | zitieren | melden

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:
Zitat
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!
private Nachricht | Beiträge des Benutzers
Coffeebean
myCSharp.de - Team

Avatar #avatar-3295.gif


Dabei seit:
Beiträge: 2461
Herkunft: Deutschland/Schweiz

beantworten | zitieren | melden

Hallo doubleII,
Zitat von 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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16234

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


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

beantworten | zitieren | melden

Zitat von Stefan.Haegele
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)
private Nachricht | Beiträge des Benutzers
doubleII
myCSharp.de - Member



Dabei seit:
Beiträge: 33

Themenstarter:

beantworten | zitieren | melden

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



Dabei seit:
Beiträge: 228

beantworten | zitieren | melden

Es ist im JSON Format zwar nicht vorgesehen, aber JSON.Net unterstützt doch zum Beispiel Kommentare.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16234

beantworten | zitieren | melden

Ist dann aber kein standardgetreues Json mehr, sondern mit JavaScript comment flavour.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


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

beantworten | zitieren | melden

Zitat von Rioma
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)
private Nachricht | Beiträge des Benutzers
Mossi
myCSharp.de - Member

Avatar #avatar-2646.jpg


Dabei seit:
Beiträge: 200
Herkunft: Regensburg

beantworten | zitieren | melden

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

Avatar #avatar-4122.png


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

beantworten | zitieren | melden

Zitat von Mossi
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)
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
Mossi
myCSharp.de - Member

Avatar #avatar-2646.jpg


Dabei seit:
Beiträge: 200
Herkunft: Regensburg

beantworten | zitieren | melden

Zitat von LaTino
Kürzeste Antwort: .net core.

(zB hierfür)
Aber da steht auch drin, dass man von project.json auf msbuild wechseln will.
Zitat
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.
Zitat von LaTino
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.
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


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

beantworten | zitieren | melden

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)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16234

beantworten | zitieren | melden

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

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
trib
myCSharp.de - Member



Dabei seit:
Beiträge: 693

beantworten | zitieren | melden

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