Suchergebnisse

Das ist einfach eine aktuelle Limitation beim Pattern Matching. Ohne konstante Werte kannst du es nicht verwenden. Wie Rod sagt: Ich würde einfach plain old if statements nehmen.

Zitat von VaporiZed: „Vielleicht bin ich aber auch gedanklich grad zu radikal. Schließlich muss man ja auch in der WPF beim DesignTime-DataContext den ViewModel-DataType angeben. Damit wäre ggf. Problem 1 hinfällig und Problem 2 umgangen.“ Hi, in WinForms bin ich null drin und ohne konkretem Code kann ich auch nur best guesses machen, aber ich denke, dein letzter Satz geht in die richtige Richtung. Die Trennung in MVVM ist typischerweise:- Model: Idealerweise absolut unabhängig von allem anderen…

Hmm, das ist dann echt ein spezielleres Problem. Auf die Schnelle gedacht, würde sowas reichen? Ist eine leicht abgewandelte Version von meinem vorherigen zweiten Fragment, mit dem Unterschied, dass die Factory jetzt Services vom ServiceProvider holen kann. Damit könnte der Aufrufer der AddGraphClient Extension spezifische Services auswählen, die gleichzeitig vom DI Container kommen: C#-Quellcode (31 Zeilen)

Wenn du die Handler via DI registrieren möchtest, könnte es vielleicht so klappen? Ich kenne die Libs nicht, die du nutzt, aber wenn ich den Code richtig lese, sollten die Handler alle von DelegatingHandler erben, oder? C#-Quellcode (18 Zeilen) Hier musst du aufpassen, dass die Handler auch immer als Singleton registriert werden. Die Types beim Registrieren müssen auch passen (also DelegatingHandler muss in den Typeparams sein). Dafür könntest du auch easy ne Extension AddGraphHandler<THandler>(…

Bezüglich dem Debug.WriteLine (und den anderen Debug.XXX Methoden): Man kann diese sowohl im Code lassen, als auch ohne den #if DEBUG / #endif Guards schreiben. Der Compiler entfernt diese Calls automatisch im Release Build, weil die Methoden mit dem Conditional("DEBUG") Attribut geflagged sind. Das ganze kann man ganz gut hier sehen (linke Seite euer Code, rechte Seite der finale, kompilierte Code im Debug/Release Mode): - Debug: sharplab.io/#v2:CYLg1APgsAUAAg…IpvzAUsz6VADcdPgAvrDZQA== - Releas…

Disclaimer: Mit LiteDB direkt habe ich noch nie gearbeitet. Alles Folgende schreibe ich nur anhand der LiteDB Dokumentation. Zitat von nogood: „Es sollte laut Dokumentation nur ein Benutzer zur Zeit mit der Datenbank arbeiten.“ Wichtig ist in dem Kontext, was genau ein Benutzer ist. Aus der Sicht von LiteDB ist ein Benutzer kein User im klassischen Sinne, sondern eine geöffnete Verbindung zur Datenbank (bzw. ein Prozess, der mit der DB arbeitet). Das Verhalten kommt auch darauf ein, welchen Conn…

Ich will mal versuchen, so weit wie möglich nur mit Expression Statements und LINQ Query Syntax zu kommen (keine Seiteneffekte/keinen imperativen Code mit Ausnahme der Ausgabe oder Assertions). Ich hab den Tipp gesehen, den ganzen Code mit einem Unit Test Projekt umzusetzen, damit man pro Tag einfach per VS Test Explorer den aktuellen Tag laufen lassen kann, ohne sich groß um verschiedene Projekte oder main Methoden kümmern zu müssen. Den Tipp fand ich gut - ich hab direkt mal umgestellt. (Verst…

Uuuund nochmal C#. (Versteckter Text)

Heißt das, dass du den Code dann pro Rechner, auf dem das Programm nachher laufen soll, einmal kopierst, anpasst und dann für den jeweiligen Rechner neu kompilierst? Wenn ich das richtig verstehe, müssten ja pro Rechner auch die Flags der Attribute unterschiedlich sein, und somit manuell geändert werden. Als Beispiel "Enabled": Wenn Rechner A eine Methode InitX() ausführen soll, Rechner B aber nicht, dann musst du das Programm ja einmal für Rechner A mit "Enabled = true" und einmal für Rechner B…

Ich bin mir nicht sicher, ob ich die Ausgangssituation richtig verstehe. Ich interpretiere es so, dass du selbst eine Library baust, die intern Code für das Ansteuern verschiedener Maschinen bereitstellt. Je nach Maschine müssen die Init Methoden in der richtigen Reihenfolge ausgeführt werden (aber diese Reihenfolge ist dir pro Maschine bekannt). Ich *vermute* jetzt, dass du pro Maschine ein eigenes Programm hast, dass diese Library benutzen möchte. Wahrscheinlich wird eine Funktion in der Lib a…

Ja, aber Vorsicht, es liegt nicht daran, dass es ein Event Listener ist! Das Problem liegt in JS selbst und kann auch an anderen Stellen auftauchen. Wenn es dich interessiert: MDN hat eine gute Erklärung zu den Details: developer.mozilla.org/en-US/do…/Reference/Operators/this

Ohne es getestet zu haben: Vermutlich verliert sich der this Kontext wenn du die handler als Event Listener weitergibts. Sprich, sobald die Handler aufgerufen werden zeigt das this in den Handlern nicht mehr auf deine Klasse, sondern auf irgendetwas anderes. Versuch mal die Handler explizit an die Klasse zu binden: JavaScript-Quellcode (3 Zeilen) Alternativ könntest du die Handler auch einfach als Arrow Functions definieren (die capturen this immer korrekt wie man es erwarten würde): JavaScript-…

Die einfachste Art, den Fehler zu beheben ist, die Command Property einfach im Konstruktor zu initialisieren. C#-Quellcode (6 Zeilen) Hat auch den Vorteil, dass im Vergleich zur => Syntax (public RelayCommand CmdProtocol => new RelayCommand(...); nur eine einzige RelayCommand Instanz erstellt wird, die bei jedem get recycled wird.

Der „Fehler“ liegt darin, dass du BeginInvoke benutzt. Schau dir mal genau an, was diese Methode tut, wie sie funktioniert und welche Alternativen es gibt. Dann kommst du vielleicht schon selbst darauf, was das Problem ist.

Hey, in diesem Thema kam jetzt ja wirklich schon einiges an Antworten und Content, vieles davon auch schon richtig. Ich will jetzt gar nicht groß daherkommen und bereits gesagtes wiederholen. Was mir, und vielen anderen Anfängern, damals beim Thema MVVM am meisten gefehlt hat, war das generelle Verständnis, warum man das Pattern benutzt und wo genau die Grenzen zwischen den 3 Schichten (M-V-VM) liegen. Meiner Meinung nach ist letzteres das Wichtigste an dem ganzen Thema und gleichzeitig das, was…

Jo, ist von ner REPL kopiert. Du musst die Punkte am Anfang und die Ausgabe unten löschen. Edit: Hab grad noch dein Edit gesehen - dann passt es ja soweit. Dann wirkt mein Kommentar mit Punkte/Ausgabe löschen irgendwie auch fehl am Platz - darauf kommt ja eigentlich jeder..

Ja, das stimmt für die aktuelle Dictionary Implementierung. Nichtsdestotrotz ist das undefined behavior (siehe MSDN Zitat oben) auf das man sich nicht verlassen darf. Das könnte sich mit jeder neuen .NET Version und Runtime ändern. Wird es passieren? Fraglich. Kann es passieren? Absolut. @jan99 Was du mitnehmen solltest ist, dass du bei Dictionaries mit der Reihenfolge aufpassen musst. Microsoft/.NET gibt dir keine Garantie, dass es in irgendeiner Art und Weise eine Reihenfolge gibt. Geh am best…

C#-Quellcode (9 Zeilen) Zitat von jan99: „Die Reihenfolge soll dabei nicht durcheinander gebracht werden!“ Dictionaries sind nicht sortiert und haben dementsprechend keine Reihenfolge. Auch wenn das bisher vielleicht zufällig geklappt haben mag wird es dir früher oder später passieren, dass sich die Einfügereihenfolge in deinem Dictionary ändert. Da musst du aufpassen. Dazu zitiert aus MSDN ( docs.microsoft.com/en-us/dotne…ions.generic.dictionary-2 ) : "For purposes of enumeration, each item in …

Zitat von Translating-IT: „Mit der DB könnte ich dann auch ein paar andere Dinge leichter lösen, die mir bei XML aufgefallen sind, aber in diesem Fall mit 2 oder 3 Schritten mehr (somit auch mehr Zeit bei der Verarbeitung der Datei) zu lösen sind.“ Alleine das spricht dann ja schon dafür, dass du eher eine DB, als eine XML Datei benutzen solltest. Es gibt ja keinen Grund dich mit Dateien rumzuschlagen, wenn eine DB dir dein Leben schon leichter macht. "The right tool for the right job", sozusage…

Muss die Datei denn von Menschen lesbar sein? Wenn nicht kannst du dir überlegen, ob du eine Embedded Database benutzen willst. Das hätte mehrere Vorteile: a) Nimmt dir die ganze harte Arbeit ab: Multithreading, File Locking, Konsistenzbedingungen, ... sind alles Probleme, um die sich die Datenbank kümmert. b) Um einiges performanter als XML/JSON/whatever. c) Du kannst später, weil es eine DB ist, deine ganzen Daten auch per LINQ/Queries (performant) analysieren, wenn nötig. Wenn das generell fü…

Glückwunsch dass es funktioniert hat! Ich kann dir auch bestätigen, dass services.AddScoped<MongoDbCrudNetStdLib.MongoAux>(s => new MongoDbCrudNetStdLib.MongoAux(Secrets.MySecrets.MySecretMongoDbConnectionString, Secrets.MySecrets.MyMongoDbName)); richtig ist. Von daher also alles richtig gemacht!

Okay, das sieht schonmal richtig aus! Wenn du deine Lib so erstellt hast, kannst du sie in beiden UI Projekten nutzen. Jetzt haben wir beide noch parallel gepostet - schau dir am besten noch mein Beispiel an und melde dich dann, wenn du Fragen hast.

Also, wie versprochen ist im Anhang eine reduzierte Beispielsolution. Ich habe hier absichtlich nur ein .NET Standard Projekt (das MongoLibraryWrapper Projekt) eingefügt. In deinem Szenario möchtest du noch eine zweite Library (die SQLLibraryWrapper). Diese musst du analog zum MongoLibraryWrapper hinzufügen. Das ist quasi eine nette Übung. Mach die Solution mal auf und schau dir mal in den folgenden Schritten genau an, was enthalten ist: 1.) Mach einen Rechtsklick auf "MongoLibraryWrapper" und e…

Hi, gib mir mal ein paar Minuten, dann erstelle ich dir eine (leere) Beispielsolution, die du dir anschauen kannst. Deine Projektkonstellation sollte aber ohne Probleme möglich sein. kurze Frage vorher: weißt du denn, was ich genau mit <TargetFramework>netstandard2.0</TargetFramework> gemeint habe? Also wo du das genau findest und was es bedeutet? Wenn nicht, schau das mal bei Gelegenheit nach. Der Vorschlag von RFG hilft dir erstmal nicht wirklich weiter, Bzw. geht nicht in die Richtung, die du…

Hi, nein, du musst (wahrscheinlich) keine 2 Versionen pflegen. Dein Einsatzzweck ist genau der Sinn von .NET Standard. Libraries die .NET Standard <= 2.0 als Target setzen können sowohl von .NET 5, als auch vom legacy .NET Framework > 4.6 genutzt werden. Das ist generell der Grund, warum man heutzutage Libraries prinzipiell erstmal für .NET Standard schreiben sollte -> damit sie mit einer möglichst großen Anzahl an Apps kompatibel sind. Wenn das aus irgendeinem Grund nicht klappen sollte (z.B. w…

Du await-est den Task nicht. Ohne await wird der Task parallel gestartet und läuft auch parallel zum Rest deines Programms weiter. Die Main Methode läuft also direkt weiter ohne auf das beenden des tasks und der Schleife zu warten. Das Programm beendet sich dann auch direkt danach. Mach die Main Methode und Deine Netzwerk Methode async und awaite den Task.

Noch eine kleine Anmerkung zu Array.Copy vs. bytes.Skip(...).Take(...).ToArray(), da du in deinem ersten Post nach Performance gefragt hast: Array.Copy ist schneller als die LINQ Alternative. Wenn du, wie in deinem ersten Problemfall, nur ein einziges Mal den Header auslesen musst macht es im Endeffekt keinen (relevanten) Unterschied, weshalb du problemlos die Skip/Take Funktionen nutzen kannst. Solltest du das Ganze allerdings irgendwann mal oft hintereinander machen müssen (beispielsweise in e…

Zitat von PadreSperanza: „ch weiß, dass eine WPF-Applikation, wenn sie gestartet wird, im Hintergrund einen Thread öffnet, der von einem sogenannten Dispatcher verwaltet wird. Dieser achtet auf den Thread und arbeitet alles ab, was in die Queue des Threads gegeben wird. Er sorgt auch dafür, dass die entsprechenden Tätigkeiten von demjenigen Objekt ausgeführt werden, das dafür notwendig ist. Das Problem ist, ich weiß, dass es den Dispatcher gibt, ich weiß auch, dass man mittels Dispatcher.Invoke(…

Vielleicht hilft dir das hier weiter: C#-Quellcode (5 Zeilen)

Hi, das Beispiel sieht gut aus! Wenn du es weiterhin so benutzt, gibt es keine Einwände. Noch als weiterführenden Kommentar, der aber nichts mit dem eigentlichen Thema zu tun hat (wie gesagt, nutze den HttpClient weiterhin genau so, wie du es im Beispiel demonstriert hast): Solltest du irgendwann einmal nicht mehr Blazor Server, sondern Blazor WASM nutzen sieht die Sache in den .razor Dateien (nicht in Service-Internen Klassen wie z.B. BackgroundServices oder Controllern) nochmal anders aus. Hie…