Im einfachsten Fall kannst du doch durch iterieren und merken der letzten Version die aktuelle ermitteln.
Dafür brauchst du nur eine for Schleife die ab der letzten Version die Folgeversionen ermittelt.
Die neu Version muss dann nur gemerkt werden, damit beim nächsten Durchlauf wieder die Folgeversion gesucht wird.
Sollte jetzt keine Raketenwissenschaft sein
Version kannst du dann in eine Textdatei schreiben.
Zusätzlich zu den Vordefinierten Encodings gibt es auch die Möglichkeit mit GetEncoding eine passende Codierung zu erhalten.
Aber auch dies steht in der Doku.
Auch mit VS hat es nichts zu tun.
Es liegt einfach an json selbst.
Und json für die Configs ist zum einen flxibler und auch kompakter als die alten XML Configs.
Gerade wenn man schon seit .NET 2.0 dabei ist, merkt man was für Welten dazwischen liegen.
Ich muss hier teilweise noch mit mehreren KB großen XML Configs mit Meterlangen AssemblyRedirects arbeiten.
Deshalb fährst du mit json um eingies besser.
Ansonsten muss man halt die Unterschiede einmal kennen lernen, dann ist es zukünftig kein Problem.
Da json auch im .NET Umfeld seit Jahren etabliert ist, sollte sich dies auch für dich nicht als schwer darstellen.
@Gimmick
Wäre auch möglich aber man müsste einiges mehr an Prüfungen durchführen.
Man muss z.B. beachten, dass auf allen Ebenen des Pfad Teile fehlen können.
Also z.B. eine Zoomstufe am Anfang (0), Ende (21) oder mitten (1-20) drin.
Das gleiche gilt für X Ordner und die Y Dateien.
Entsprechend müsstest du dir die aktuelle Zoomstufe merken.
Abhängig davon musst du die unterschiedliche X/Y Mengen beachten, da jede Zoomstufe ihre eigene Menge an X/Y Kombinationen hat.
Zusätzlich könnte man den HashSet Ansatz noch beschleunigen, wenn man die Prüfungen auf mehrere Kerne verteilt.
Hier könnte man z.B. pro Zoomstufe mit Parallel.For die Daten gegenprüfen.
Da X/Y pro Zoomstufe in der gleichen Anzahl vorliegen müssten, könnte man damit noch die Abfragen beschleunigen.
Bei größeren Prüfungen wie z.B. bei gößeren Ländern wie Deutschland etc. kann man noch einige Sekunden einsparen.
Contains bei einer Liste ist halt langsam, weil er alle Elemente durchgehen muss um zu schauen ob es einen Treffer gibt.
Dadurch hast du wieder eine lineare Suchdauer, die abhängig von der Anzahl der Elemente und der Position des gesuchten Elements ist.
Im schlimmsten Fall muss er bei Lücken dann alle Einträge durchlaufen um keinen Treffer zu ermitteln.
HashSet sowie Dictionary lösen dies, da beim HashSet der Eintrag und beim Dictioanry der Key über einen ermittelten HashCode (int) via GetHashCode berechnet werden.
Dieser wird dann als Suchposition intern verwendet, was eine Suche extrem beschleunigt.
Im ersten Schritt solltest du das zusammensetzen des Pfad über Stringgebastel durch Path.Combine ersetzen.
Dadurch sparst du viele unnötige String Objekte, die jetzt im Speicher liegen bzw. aufwändig durch GCs entfernt werden müssen.
Ich würde auch folgenden Ansatz versuchen.
1. HashSet für Koordinaten anlegen (String Aufbau Zoom|X|Y)
2. HashSet mit allen vorhandenen Dateien befüllen
3. Durch die Schleife durchlaufen, Keys bilden und prüfen ob vorhanden
4. Wenn HashSet.Contains = false, dann hast du eine Lücke
Damit dürftest du noch etwas schneller sein und sehr viele unnötige String Objekte sparen
Anbei kannst du beim bilden des Key auch String Interpolation verwenden.
Dadurch hast du nur ein Objekt mehr am Ende.
HashSet<string> existingFiles = new HashSet<string>();
// HashSet mit vorhandnene Dateien befüllen
string[] files = Dicrectory.GetFiles(dir, "*.png", SearchOption.AllDirectories);
foreach(string file in files)
{
// Pfad zerlegen um Zoom, X, Y zu ermitteln
string zoom = bla;
string x = blub;
string y = blablub;
string key = $"{zoom}|{x}|{y}";
existingFiles.Add(key);
}
for (int tx = point1.X - 1; tx < point2.X + 2; tx++)
{
for (int ty = point2.Y - 1; ty < point1.Y + 2; ty++)
{
string key = $"{zoom}|{x}|{y}";
if(existingFiles.Contains(key))
tiles++;
}
}
Nachtrag:
Wenn du die Ermittlung des HashSet in eine eigene Methode packst, kann der GC das string[] auch direkt weg hauen.
Dadurch ist dein Speicher nur auf das HashSet als größtes Objekt limitiert.
Dürfte sich aber in Grenzen halten.
Ah okay.
Dann vermute ich mal, dass du über das Dictionary schon die Dateien vorcachen willst.
Also für X/Y/Level als Key und die Datei als Value im Dictionary.
Würde ich aber nicht machen, arbeite hier lieber mit dem Dateisystem Cache und lade die Bilder wenn diese benötigt werden.
Wenn du die Bilder auf den dichtesten Zoom Level nutzt, werden schon je nach Bereich einige GB anfallen.
Diese kannst du dann kaum cachen bzw. müsstest abhängig vom vorhandenen RAM Maßnahmen ergreifen.
Das Dictionary kann bei Geräten mit zugeringem Speicher schnell zum OutOfMemoryException führen.
Ebenfalls müsstest du dann selbst die Speicherverwaltung übernehmen z.B. beim Wechsel des Zoom Levels alle Eintärge für nicht passende Level wieder entfernen.
Und du musst fehlende Einträge, für die es auch lokal keine Datei gibt, dann mit einem Dummy Platzhalter liefern.
Im einfachsten Fall speicherst du die Bilder lokal wie auf dem Webserver und kannst den Pfad dann direkt bilden und abrufen.
Damit fährst du vermutlich am besten.
Gibt es dafür nicht fertige Lösungen von bzw. für OpenStreetMap?
Ich meine mich darin zu erinnern, dass wir was ähnliches bei uns verwenden, wenn auch nicht offline.
Wir rendern z.B. auch die OpenStreetMap Karte von einem eigenen Mapnik Server bei uns.
Wir lassen diese aber erst rendern, wenn diese benötigt werden und cachen diese dann über den Server.
Da wir die Daten auch ca. einmal im Monat updaten lassen, müssen diese auch neu gerendert werden.
Damit dürftest du auch am besten fahren.
Das gesamte Material Offline zu speichern ist wegen der Masse kaum möglich.
Bei uns liegen ca. 800+ GB gerenderte Bilder rum.
Auch andere Dienste bieten dann nur einen Teilbereich der Daten offline an.
Nachtrag:
Wie kopiert ihr den die Daten auf das NAS?
Nutzt hier hier z.B. robocopy?
Dort könnt ihr auch mit Threads arbeiten, was die Performance u.U. noch mal steigert.
Nutze ich auch bei vielen kleinen Dateien.
Das sind aber zwei Paar Schuhe.
Der Explorer ist leider nicht gerade performant bei vielen Dateien und spielt hier erstmal keine Rolle.
Die .NET Lösung, ist wie Abt schon zu Recht sagt, auch nicht die performanteste Lösung, da hier sehr viele Rechteprüfungen etc. durchlaufen werden müssen.
Auch triviale Dinge wie das durchlaufen von großen Verzeichnis Strukturen können dann langsamer sein als Zugriffe über native System APIs wie die WinAPI.
Dadurch hat man aber wieder native Abhängigkeiten, die man eigentlich vermeiden möchte.
Mich würde aber interessieren ob sich hier zwischen .NET Framework und dem neueren .NET 5/6 schon was getan hat.
Oder ist hier ggf. zukünftig was geplant?
@BerndFfm
Du könntest auch mit EnumerateFiles arbeiten.
Damit musst du nicht alle Dateinamen bzw. Pfade im Speicher halten.
Wenn du auch nur einen Teil der Namen brauchst, kannst du damit die Nummer aus dem Namen auslesen und diese in ein HashSet packen.
Wieviele Einträge hast du den und wie oft musst du nach Einträgen suchen?
Alternativ kannst du, wenn es nur um einzelne Attribute geht, diese auch in unterschiedliche Dictionaries packen.
Z.B. nutze ich auch eine eigene Klasse, die meine Einträge je nach Kriterium in eigene Dictionary packt.
Dadurch kann ich die Treffer direkt ermitteln.
Wenn du Attribute aber kombinieren musst, wird dieser Ansatz vermutlich nicht funktionieren.
Dann müsstest du auch sicherstellen, dass neue Einträe überall eingefügt werden.
Ja, bei List<T> werden alle Einträe geprüft und beim ersten Treffer direkt das Ergebnis geliefert.
Wenn du nur eindeutige Einträge hättest, dann könntest du auch Dictionary<TKey, TValue> nehmen.
Dürfte vermutlich aber nicht dein Anwendungsfall sein.
Dein Problem sollte sich doch direkt über den ResourceManager lösen lassen.
Dort kannst du doch einfach bei GetString die CultureInfo für die Sprache mitgeben.
Dann hast du die richtige Übersetzung für die ausgewählte Sprache.
Du benötigst dann nur in deiner UI einfach die resx Datei für die Form mit der jeweiligen Sprache.
Zusätzlich sollte man auch eine neutrale Sprache als Default mitbringen als Fallback falls Übersetzungen fehlen.
Die Formatierung für die Textbox kannst du dann auch über die ausgewählte Sprache formatieren, was du selbst ja schon machst wenn auch über Umwege mit deiner Lib.
Damit kannst du ohne Probleme mehrere Sprachen anzeigen.
Passend dazu schau dir den Jetbrains Link von Abts zweiten Beitrag und die Doku zum ResourceManager an.
Dann solltest du es hinbekommen ohne deine Lib oder eine extra kompilierte DLL einbinden zu müssen.
Die Resourcen werden dann direkt in die Form DLL einkompiliert.
So ganz klar sind mir die Vorteile leider auch nicht.
Nach dem Überblicken des Projekts scheinen die Übersetzungen bei dir halt auch wieder fix in den Code gepackt zu werden.
Oder gibt es in deiner Lib auch die Möglichkeit, die Übersetzungen aus den bestehenden resx Dateien zu nehmen?
Falls nicht, wäre es wieder ein Schritt zurück da man Übersetzungen nicht direkt in den Code packen will und vorhandene Übersetzungen auch weiterverwenden will.
Gerade dies wäre ein wichtiger Punkt mit dem man sich befassen müsste.
Für Projekte, die den .NET Weg bereits nutzen, sehe ich auch keinen Vorteil.
Die Typsicherheit spielt dabei auch nur eine Untergeordnete Rolle.
Diese kann man auch durch Kapselung der .NET Methoden z.B. durch Extention Methods erreichen.
Dafür brauche ich dann keine Lib.
Mir fehlen halt auch gute Beispiele wo ich nun Vorteile bei der Nutzung deiner Lib gegen den .NET Weg habe.
Vielleicht solltest du hier dein Beispielprojekt erweitern um dies etwas klarer hervorzustechen.
Okay, aber einiges im Code macht keinen Sinn.
Die Prüfungen mit Contains, kannst du bei vorheriger Konvertierung einfach über eine Werte Prüfung lösen.
Ebenfalls scheinst du auch in den Schleifen mehrfach unnötig TryPase aufzurufen.
Je nachdem wieviele Zeilen du hast, verheizt du dadurch unnötig Zeit um die immer gleichen Spalten zu konvertieren.
Es wäre vermutlich auch hilfreicher, wenn du einmalig die Zeile aus den zeilen Array ausliest und zwischen speicherst.
Aktuell musst du immer wieder über zeilen[x1] darauf zugreifen, was du auch mit einer string Variable vereinfachen kannst.
Auch ist mir nicht ganz klar war zeilen2 ist bzw. woher es kommt.
Mit den if Abfragen mit dem break der inneren Schleife hast du auch einie magic numbers.
Mach daraus am besten Konstanten damit später klar ist, warum du darauf prüfst und rausspringen musst.
Die Meldungen mit fehlerhaften Zeilen würde ich einmal sammeln und dann insgesamt ausgeben.
Sonst musst du für jede fehlerhafte Zeile dem Benutzer ein Fenster anzeigen.
Das macht bei vielen fehlerhaften Zeilen keinen Spaß!
Wenn in den Spalten nur Zahlenwerte stehen können, dann kannst du auch einfach den Inhalt per Int32.TryParse versuchen umzuwandeln.
Dabei sollte aber geprüft werden ob der Content nicht leer ist, sonst knallt es bei TryParse.
Dann musst du auch nicht auf 2 oder 3 Stellen prüfen
Anbei wäre es auch besser, denn du deinen Code sauberer aufteilst.
Aktuell scheint die gesamte Verarbeitung in einer Methode zu sein, was das lesen des Code unnötig schwer macht.
Das auslesen, verarbeiten und schreiben sollte in eigene Methoden ausgelagert werden.
Im einfachsten Fall lagerst du diese in eine Klasse aus, die sich dann darum kümmert.
Dann kannst du den Code auch später z.B. mit Tests (Unittests) abdecken.
Geht es den um die Firewall?
Ich gehe eher davon aus, dass es um Ausnahmen von Anwendungen von der Überwachung geht nicht aber um die Firewall Regeln.
Aber ohne Details was der TE will, sind dies nur Annahmen.
Es gibt keine allgemeine API für sowas, dass musst du je nach Antiviren Lösung bei dem jeweiligen Hersteller anfragen.
Dabei geht auch jeder seinen eigenen Weg.
Und i.d.R. bieten diese für normale Endanwenderlösungen keine APIs für sowas, dies ist dann den Business/Enterprise Lösungen vorenthalten.
Kannst du aber mit dem jeweiligen Hersteller klären.
Nachtrag:
Wäre auch übrigens ein gutes Einfallstor für Viren/Trojaner wenn es eine allgemeine Lösung per API gibt.
Was genau willst du den damit machen?
Zusätzlich dazu, kannst du auch Redis einbinden.
Wenn du nur einen Prozess hast, kannst du die Daten einfach lokal vorhalten und in Redis speichern/updaten.
Damit könntest du nahe zu endlose Datenmengen wegspeichern.
Durch Pub/Sub kannst du dann auch bei verteilten Anwendungen die Caches updaten lassen.
@Christoph K.
Welches reale Problem wäre dies den, wenn ich fragen darf.
Sieht dein Code im produktiv System genauso aus, dann kann es nicht funktionieren.
Wäre es hier nicht sinnvoll nur benötigte Daten direkt im Cache abzulegen anstatt Unmengen an Einträgen zu generieren?
Dies wäre für sich gegeben schon ein Dictionary mit eindeutigen Keys.
Einträge sollten nur abgelegt/eingefügt werden, wenn diese benötigt werden sonst läufst du eben auf das Speicherproblem.
Ggf. wäre auch die Einbindung von Redis als Cacheserver sinnvoll um nahezu endlose Daten zu speichern.
Nutzen wir auch um größere verteilte Caches zu nutzen.
Wie genau soll diese Prüfung aussehen?
Wenn du keine Schnittstelle hast um die Firewall abzufragen, dann dürfte es nicht ohne weiteres klappen.
Die Firewall selbst gibt keine Informationen preis welche Einstellungen gesetzt sind.
Wäre fatal, wenn eine Firewall so geschwätzig wäre und solche Daten einfach an jeden Client senden würde.
Das liegt daran, dass du MySetup erst nach dem Aufruf des Konstruktor von WDSettings übergibst.
Da du aber im Konstruktor von WDSettings dann CurSetup, was hier noch null ist, dann in Backup speicherst und dann damit arbeiten willst, knallt es.
Du solltest dich erstmal mit den Grundlagen von OOP beschäftigen.
Gerade mit WPF hast du auch einen technischen Ansatz, den du aktuell nicht richtig umsetzt.
Dort arbeitet man nicht mit Code Behind sondern nach dem MVC/MVVM Muster.
Dadurch sind deine aktuellen Prüfungen auf Änderungen nicht nötig, da das Muster Änderungen an das Model selbst melden würde.
Dazu müsstest du aber erstmal die Grundlagen inne haben, damit du das sauber umsetzen kannst!
Nachtrag:
Im einfachsten Fall kanst du das Problem lösen in dem du MySetup an den Konsturktor mitgibst oder deine Verarbeitung nach dem setzen von CurSetup dann in einer public Methode duchführst.
Meine Frage wäre auch welchen Sinn dieser Code hat.
Du hast hier eine while(true) Schleife was so oder so zu einem endlosen Durchlauf führt und früher oder später zu einem Überlauf oder OutOfMemory Exception.
Etwas mehr Context zu deinem Vorhanden könnte ggf. auch zu einer sinnvolleren Lösung führen.
Auf den ersten Blick, weil du den StreamWriter nicht per Close schließt.
Dadurch werden noch nicht geschriebene Daten nicht aus dem internen Puffer geschrieben.
Close schreibt die Daten raus und schließt dann auch sauber die Datei.
Schau dir dazu am besten die Doku zu StreamWriter nochmal an und zusätzlich auch Dispose.
Die Meldung klingt danach, dass du die StartInfo zwar füllst aber das Programm nicht startest.
Dadurch knallt es auch, da du einen Stream lesen willst, der gar nicht geöffnet werden kann, da das Programm nicht läuft.
Klingt nach einem Münzwurf was die Eindeutigkeit der Dateien angeht, wenn du nur 200 Bytes mitten in der Datei lesen willst.
Du kannst zwar eine gewisse Eindeutigkeit durch Hashing bei Dateien ermitteln, dazu müsstest du aber die ganze Datei einlesen und hashen.
Dateien haben an und für sich auch keine eindeutigen IDs.
Mir ist aber nicht klar, wie du darauf kommst, dass eine mp4 Datei auf Platform A anders sein könnte als auf Platform B.
Auf beiden hast du im Endeffekt die gleichen Bytes.
MP4 und co. sind spezifierte Formate mit einem fixen Aufbau.
Ein für alle Platformen eindeutige ID erzeugen klappt m.W. nur durch Hashing.
Eine original und eine geänderte Datei, z.B. durch Schnitt oder andere Änderungen in Bild/Ton, haben dann aber auch unterschiedliche Hashes/Bytes.
Wenn du solche Dinge vergleichen willst, wird es schon etwas komplexer und dürfte den Rahmen deines Vorhabens ggf. sprengen.
Dann müsstest du nicht nur stumpf die Bytes auswerten sondern müsstest direkt Bild/Ton z.B. mit Tools auswerten.
@Palladin
Hab ich oben bereits angepasst, war in der ersten Version noch drin.
Hab in den Source von .NET 6 und 4.8 geschaut.
In .NET 6 wird tatsächlich die nested Class geliefert.
Dort ist SHA256Managed nur auch als Obsolete markiert.
In .NET 4.8 wird noch etwas interne Magic durchgeführt bzw. über Magic Strings dann eine Instanz von SHA256Managed geliefert.