Suchergebnisse

Also eigentümlich, dass die Lib selbst bestimmt, wo gespeichert wird, aber zB SqlServer bestimmt auch selbst, wo die Datenbanken angelegt werden. Aber ich weiß jetzt nicht, nach was für einer Idee gefragt ist - also wo ist das Problem?

Echt? Das hattest du gemeint, als du frugst:Zitat von Linkai: „Hat einer ne Idee?“o - key jdfs weiss ich nicht - probiers halt aus und sag du's uns. Ich denke aber fast, dass My.Settings ins Anwendungs-Daten-Verzeichnis persistiert, und wenn deine Lib dann in 2 Anwendungen eingebunden ist, wird sie in 2 AppData-Verzeichnisse speichern.

gut - habe ich. Seiner Meinung nach wäre das ein Fehldesign. Also seine Meinung Die Begründung, wie diese seine Meinung zustande kommt, lässt er uns leider nicht wissen.

Zitat von RodFromGermany: „bei multiplen Instanzen disjunkte Einstellungen verwendet werden können.“ja, so wärs am ehesten normal. Aber hier ist ja grad beabsichtigt, bei multiplen Instanzen junkte Einstellungen zu verwenden. Und klar, normal ist das eine Super-Fehlerquelle, aber hier ists das beabsichtigte, und soll der Kommunikation zwischen Anwendungen dienen. Oder anders gesehen: Hier sollen globale Einstellungen geschaffen werden - man kann hier eiglich garnet von Einstellungen des Programm…

weil Appdata einer bestimmten Anwendung gehört. Da würde das eine Prog nicht wissen, was das andere speichert. Und warum unbedingt Xml-Serialisierung? Ist nicht gänzlich egal wie, hauptsache richtig? Warum nicht Binär-Serialisierung, Json-Serialisierung, SqLite, typisiertes Dataset, und/oder warum nicht die My Settings? Übrigens verwenden My Settings glaub auch Xml-Serialisierung, aber wie gesagt, ist dieses Internum irrelevant.

ich warte eiglich die ganze Zeit, dass du mal rückmeldest, ob du in der Lib einfach in die Settings persistieren kannst, und ob das dann in 2 verschiedenen Anwendungen verfügbar ist. ich glaub das hab ich heut morgen gepostet, dass du das doch einfach mal ausprobierst und rückmeldest.