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

  • »
  • Portal
  • |
  • Mitglieder
Beiträge von Abt
Thema: Interne vs. externe Architektur bei DataFlows
Am Gestern, im Forum: Rund um die Programmierung

Wenn Du das am einfachsten empfindest, dann ist das ja auch absolut in Ordnung; aber ist halt keine "generelle So-Macht-Man-Das-Immer"-Antwort.
Du darfst dabei nur nicht die Ausgangslage des Lesers / des Themenstarters vergessen; und hier war ja aufgrund von Task.StartNew() schon ersichtlich, dass wir uns nicht unbedingt wirklich direkt in der Enterprise-Multi-Cloud-World-Wide-Ausbaustufe befinden.

Zitat von JimStark
Weiter zu diskutieren hat hier für mich aber keinen Sinn mehr, du hast da deine eigene Meinung
Und zur Diskussion: es geht mir hier nicht um meine Meinung; ich formuliert das neutral basierend auf Fakten und unterlege das entsprechend mit Verweisen.
Ziel ist hier neutral Wissen zu vermitteln, sodass der entsprechende Leser für sich das beste rauspicken kann.

Wenn ich etwas basierend auf meiner Meinung ausdrücke, dann kennzeichne ich das entsprechend.
Zitat von JimStark
Ich weis aber zumindest auch aus der Praxis dass es erfolgreich getrennt aufgebaut werden kann.
Natürlich kann hier jeder sein Wissen vermitteln; aber sehr gerne auch entsprechend untermauern mit mehr als "so ist das" oder "ich finde" - das ist ja das Ziel.
Aber man sollte auch Kritik äußern dürfen oder Nachfragen stellen, die nicht gleich mit "Deine Meinung" abgewickelt wird... so kann man nämlich nicht sachlich diskutieren ;-)

Die Trennung ist auch vollkommen okay; stellt nur nicht die kleinste Aufbaustufe dar, sondern geht ja schon in eine spezielle Richtung, die - basierend auf was Moabyter möchte - eher Oversized ist und ein komplettes Neukonzept erfordern würde -> nicht KISS ;-)

Thema: Interne vs. externe Architektur bei DataFlows
Am Gestern, im Forum: Rund um die Programmierung

Ich hab mich fürs Abspalten entschieden und beantworte das nun mal in ausführlicherer Form als in den Offtopic-Style Beiträgen.

Zitat von MoaByter
den Überblick zu behalten: etwa 2,5MB an selbstgeschrieben .cs-Dateien.
Zitat von JimStark
Bei so einer umfangreichen Anwedung
Die Menge an Quellcode ist kein Maß, um Umfang einer Anwendung zu definieren oder darüber zu entscheiden, ob man Quellcode modularisieren sollte.
Das hat man mal vor 35 Jahren gemacht, als man Komplexität von Quellcode auch in Anzahl Zeilen definiert hat; wobei man heute schlauer ist, dass man genau das nicht tun sollte, weil die Aussage dahinter quasi gleich Null ist.
Das kann man entsprechend in Architektur Büchern führender Köpfe nachlesen oder zB. sich Metriken von sehr schlauen Menschen wie zB. McCabe-Metrik nachlesen.

Daher auch der Spruch
Zitat
The number of lines of program code is wonderful metric: it's so easy to measure and almost impossible to interpret.

Namespace Design - nicht nur in C# bzw. Programmiersprachen, sondern quasi in allen Targets von Namespaces - richtet sich immer nach Anforderungen (an den Quellcode/Umgebung), und nicht nach dem Umfang. Auch dazu gibt es Lektüre, angefangen bei den MS Docs.

Wir haben also außer dem Unfang, was eben kein Indiz ist, kein Grund in den Raum zu werfen, dass eine Implementierung in mehrere Apps "besser" wär.
Und von KISS ist das eben auch ganz weit weg.
Zitat von JimStark
neben der 3-Schicht-Trennung, auch in unterschiedliche Anwendungen zu trennen.
Das ist ein Relikt aus den Anfängen von monolitischen Architekturen, das man so nicht mehr macht bzw nicht mehr machen muss.
Gerade auf Windows haben Multi-Prozess-Anwendungen durchaus ihre Berechtigung (jeder Browser tickt aus Sicherheitsgründen so, da jeder Tab aufgrund der Isolation in einem eigenen Prozess läuft) - ist aber immer der letzte Punkt, den man bei einer Gesamt-Lösung in betracht zieht.

Bei Flow-Anwendungen (wie die Quelle dieses Themas) versucht man Multi-Prozess-Anwendungen prinzipiell zu vermeiden, wenn es die Anforderungen zulassen.
Grund ist, dass IPC-Anwendungen immer einen enormen Aufwand bedeuten, angefangen bei der Infrastruktur, bei der Implementierung oder eben auch bei der Security.

Mit unter wurde daher insgesamt das Thema TPL Pipelines angegangen und konzeptionell geformt, aus dem heute, ca. 6 Jahre später die TPL Dataflows wurden.
Zitat von JimStark
m.M. lohnt sich bei so komplett unterschiedlichen Aufgaben, Präsentation, Datenbeschaffung, Verarbeitung,... , wenn möglich, immer eine Aufteilung.
Ich versuche bei meinen Beiträgen immer entsprechende Referenzen (Docs, Lektüre, Bücher..) anzugeben, auf denen meine Meinung aka Erfahrungsgrundlagen oder meine Aussage basieren.

Für das UI spielt keine Rolle, ob die Informationen aus einem Datenfluss stammen, oder nicht. Daher fokussiere ich im folgenden nun auf die Datenbeschaffung.
Zitat von JimStark
Z.b. Consolen-Anwedung oder Windows-Dienst für Scraping (z.B. mit Interceptor-Pattern)
Der Inteceptor-Pattern ist ein Pattern, der für die Organisator von Code-Aufgaben zuständig ist; zB. die Middleware von ASP.NET Core ist ein solcher.
Der Sinn dieses Pattern ist, dass eine fixe Reihenfolge bei der Prozess-Verarbeitung nicht gegeben ist, sondern entsprechende Zwischenschritte "ausgetauscht" werden können; dies hat die Folge, dass In- und Output bei diesen Komponenten meist identisch ist (HTTP: Request und Response).
Bei einem Datenfluss ist dies meist nicht gegeben, weil sich der Output pro Schritt für den Folgeprozess ändern soll. Daher findet man diesen Pattern in Datenfluss-Konzepten eigentlich eher nicht.

Beispiel:
1. Schritt: URL zur Verarbeitung in eine Liste werfen
2. Schritt: URL aus der Liste nehmen, aufgrufen und Ergebnis (Response) in eine weitere Liste werfen
3. Schritt: Response aus der Liste nehmen und zum Beispiel alle Bilder-URLs ermitteln; Bilder-Url in eine weitere Liste werfen
4. Schritt: Bilder-Url aus der Liste entnehmen, laden und in eine weitere Liste werfen
5. Schritt: Bilder-Content entnehmen und analyisieren; Ergebnis in eine weitere Liste werfen
6. Schritt: Bild-Ergebnis anzeigen / verarbeiten, whatever

Wir sehen an den Schritten: Interceptor passt (auf dieses Datenfluss-Beispiel) nicht, weil wir die Schritte untereinander nicht tauschen können. Mit dem TPL-Dataflow Konzept ist dies problemlos umsetzbar - in den Geburtsstunden von TPL Pipelining ist sogar dieses Beispiel das damalige Konzept-Beispiel gewesen.
Es ist aber passenderweise relativ ähnlich zur Anforderung von MoaByter.

Welchen Vorteil hat das?
Dataflows hat den Vorteil, dass mit sehr wenig Overhead eine in sich skalierende, modulare Lösung umgesetzt werden kann, die keine externe IPC-Ressourcen benötigt, die eben diesen Overhead darstellen.
Overhead deswegen, weil man sehr oft diesen eben nicht will / benötigt.
Der weitere Vorteil ist, dass konzeptionell der gesamte Datenfluss in sich "sicher" ist.

Welchen Nachteil hat das?
Der Nachteil ist, dass die Zwischenspeicher-Schichten beim TPL Datenfluss auf InMemory-Umsetzungen basieren; wenn also der Prozess abstürzt, dann gehen alle nicht-konsistent gespeicherte Informationen verloren.
Das Guten an diesem Nachteil ist, dass nur die Zwischenarbeit verloren geht. Den Ausgangspunkt (hier die URL) hat man meistens in einer Quelle, über die man den Prozess für das einzelne Item neu anstoßen kann.

Alternative
Die alternative zu einer "internen" Architektur aka "internen" Skalierung, wie es in manchen Lektüren beschrieben wird, ist eben eine externe Skalierung: statt Schritte über Tasks umzusetzen, setzt man sie mit einzelnen Anwendungen um.
Die Kommunikation basiert dann auf externen Strukturen wie eben IPC oder mit Speichersystemen wie Redis, RabbitMQ und Co.

Man sieht also sofort: die Alternative zum internen Datenfluss hat sofort externe Abhängigkeiten zur Folge. Und natürlich muss man sich dann auch entsprechend über deren Operation-Verhalten (Verfügbarkeit, Restart, Management und Co...) kümmern.
KISS? Eher nicht ;-)
Zitat von JimStark
Für mich würde die Trennung hier trotzdem Sinn machen. Vorallem dass das Scraping, um was es hier wahrscheinlich zum Teil geht, unabhängig läuft.
Schon allein aus Entwicklungs- und Wiederverwendbarkeitsgründen.
Und hier behaupte ich das krasse Gegenteil, weil eben wegen solch einer Aufgaben die TPL Dataflows "erfunden" wurden, um KISS-nah zu sein und nur wenn wirklich notwendig extern skalieren zu müssen.
Und nen bisschen HTML runterladen und in nem Grid anzeigen: selbst mit 50 MB Quellcode würde ich hier klar auf TPL setzen, wenn wir nicht gerade eine Multi-Server-Core-Anforderung an die Leistung der Anwendung haben, wovon ich hier mal nicht ausgehe.

Und welche Wiederverwendbarkeit habe ich denn? Download und Scapping sind vielleicht 20 Zeilen Code - und wenns 100 wär.
Wegen 100 Zeilen Code sooo einen immensen Aufwand betreiben..? Puh.. bin ja auch Architektur-Fanatiker; aber hier überwiegt der Pragmatismus dann in mir doch sehr ;-)
Zitat von JimStark
Und ja, dass es Anfangs mehr Arbeit ist, ist klar, aber ich denke es würde langfristig die Komplexität trotzdem deutlich verringern.
Ich hoffe durch die Beschreibung der Alternative aufgezeigt zu haben, dass es eben nicht nur am Anfang ist, sondern für den gesamten Zyklus und die gesamten Operations.
Zitat von Palladin007
Und später ist es noch mehr Arbeit, als anfangs, weil dann die ganzen Probleme auffallen, die Du übersehen hast
Belies dich mal zu den ganzen Vor- und vorallem Nachteile der Microservices-Architektur, das klingt für mich ein wenig danach.
Nehmen wir mal die Kurzdefinition von Martin Fowler:
Zitat von https://martinfowler.com/articles/microservices.html
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.
Der wichtigste Satz ist: der Zweck muss im Vordergrund stehen. Ist wirklich jeder einzelen Step eine Business Capability, oder ist der Prozess selbst die Business Capability?
Das resultiert direkt in der Frage: wie klein oder groß muss oder darf ein Microservice sein? Reden wir wirklich noch von einem Microservice, wenn jeder Step eine einzelne Anwendung ist, oder sind wir hier schon im Clusterfu*k der TinyServices?
Zitat
A common question people ask is “How big (or small) should my microservice be?” One common answer is that the size of a microservice can be variable, but it should be coded by no more than a dozen people (the so-called “two pizza rule”).

Wie sieht das "der Markt"? Das Problem der Monolithen ist, dass diese irgendwann nicht mehr wartbar werden. Das Problem der Microservice ist: schneidet man sie zu klein hat man am Ende mehr Overhead zu verwalten, als die eigentliche Business-Aufgabe darstellt. Viele Unternehmen fanden das Konzept der Microservices extrem geil und haben dann gemerkt: scheise, wir haben uns plötzlich um Dinge zu kümmern, die wir gar nicht machen wollen - und sind zurück zu eher als monoliothisch bezeichnenden Basis-Architekturen.

Ein guter Artikel dazu ist Goodbye Microservices: From 100s of problem children to 1 superstar, in dem Alexandra Noonan sehr gut beschrieben hat, dass Microservices und viele kleine Anwendungen nicht wirklich immer soooo eine tolle Idee ist ;-)

Mein Vorgehen
Nun ein wenig Weg von eher Fakten zu meinem persönlichen Vorgehen, das ich sowohl bei meinen Anwendungen, bei myCSharp.de und auch bei meinen Kunden anwende:

Namespaces sind ein extrem mächtiges Werkezug, das viele Entwickler unterschätzen; aber bei Namespaces beginnt die Architektur und nicht bei den Anwendungen.
Je besser das Namespace-Konzept ist, desto mehr Möglichkeiten hat meine Architektur im Sinne der Skalierung, Modularisierung und Weiterentwicklung.

Ich kann problemlos mit einem Single-Task-Konzept beginnen, das sich bei einer Anforderung in ein TPL Datenfluss-Konzept weiter entwickelt. Das Datenfluss-Konzept kann am Anfang mit InMemory-Collections arbeiten und später externe Queues verwenden - und wenn ich wirklich ne richtig erfolgreiche App habe, das Task-basierte Datenfluss-Konzept verwerfen und die externen Queues mit Multi-Prozess-Anwendungen befeuern.
So gehe ich bei diesen Anforderungen immer vor; und auf diesem Prinzip basieren viele Hintergrund-Implementierungen von myCSharp.de, zB. das automatische Löschen von IP-Adressen aus Beiträgen nach X Tagen gemäß DSGVO.

Mein Fazit
Die Vorschläge von JimStark mögen durchaus ihre Berechtigung haben; von einer generellen Empfehlung sind wir aber so weit weg, so weit kann ich gar nicht schauen ;-)
Sie entsprechen im Endeffekt dem Anti-Pattern der Tinyservices, wodurch Moabyter basierend aufn den Infos, die er geliefert hat, sich um sooo viel komplexen Overhead kümmern muss, dass die eigentliche Aufgabe nur noch ein Bruchteil darstellt: das klassiche Not-invented-here-Syndrom.

Auch Microservices im Generellen sehe ich hier nicht, da ich nicht mal die Anforderung danach sehe. Auch wenn sie sehr im Trend sind: auch hier gibt es Overhead, den man erst mal durch die Vorteile wieder rein fahren muss.

Die gesamte Plattform von myCSharp.de ist eine monolitsche Grundarchitektur, obwohl durchaus charakterlichen Eigenschaften für einen Microservice existieren würden - aber der riesige Nachteil: der immense Overhead an eine saubere Umsetzung eines solchen steht in keinerlei Verhältnis.
Wir wären sicherlich 30% nur mit Overhead beschäftigt statt mit Inhalten

Und das sehe ich übligens auch immer wieder bei meinen Kunden: wegen nen paar tausend Requests pro Minute baut man riesige Microservice-Konzepte, die man problemlos mit Plugin-Architekturen umsetzen kann; am Ende mit 30-50% weniger Code, weniger DevOps Aufwand und vor allem weniger Kosten; ohne sich auch nur einen einzigen Vorteil erschaffen zu haben.

(Anhang von den Microsoft Docs aus den Anfängen von Pipelining mit C# Task Pipelines aus 2012)

Thema: Interne vs. externe Architektur bei DataFlows
Am Gestern, im Forum: Rund um die Programmierung

Zitat von JimStark
Ja das ist deine Meinung
Klar, auf der Ebene kann man immer argumentieren; förderlich ist das nicht. Beleuchten wir doch einfach die Fakten ;-)
Zitat von JimStark
Das gibts in der Praxis öfter als man denkt.
Und das ist auch nicht schlimm.
Für die Trennung von Verantwortlichkeiten, wie es hier der Fall ist, gibt es in C# primär mal Klassen und Namespaces, Grundlagen dazu hier: https://docs.microsoft.com/de-de/dotnet/standard/design-guidelines/names-of-namespaces
Eine physikalische Trennung macht man in .NET primär dann, wenn man es muss - zB. aufgrund von Wiederverwendbarkeit, Technologie-Trennung etc. Also Anforderungen der Solution Architektur, die wir hier nicht kennen und an der Stelle mit dem Problem nichts zutun hat.

Mit KISS-Prinzip hat das null, also wirklich null zutun - im Gegenteil: Durch Dein Vorschlag mit Prozess-Trennung wirst Du einen riesen Wulst brauchen, damit die Flows miteinernader sprechen können. Also -> ganz weit weg von KISS.
Genau um solchen, oft unnötigen Overhead (IPC und Co...) zu vermeiden, gibt es Tasks, TPL und DataFlows.

Thema: Interne vs. externe Architektur bei DataFlows
Am Gestern, im Forum: Rund um die Programmierung

Davon abgesehen, dass wir das nur von Außen betrachten können JimStark, stimm ich Dir basierend auf den Infos, die wir hier haben, null zu.
Es macht keinen Sinn für jeweils 10 Zeilen Code unterschiedliche Anwendungen zu schreiben, die dann über IPC/Queues kommunizieren müssen, um Folgeaufgaben leisten zu können.
Am Ende ein riesiger Overhead für Null Vorteil.

Thema: mit Task.Factory.StartNew eine class aufrufen
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Zitat von MoaByter
Auch wenn Abt meint, das sei auch mit Tasks super einfach ... wenn man weiß wie's geht, stimmt das wohl, wenn nicht, muss man sich durchbeißen und lernen.
Also das "super einfach" is nich nur aus Komplexitätssicht so von mir gesagt worden, sondern auch aus Code-Sicht: Du brauchst mit async/await viel viel weniger Quellcode, um das Ziel zu erreichen als mit Threads / anderen Mechanismen.
Dass Tasks und das Async/Await-System erstmal eine Lernhürde darstellen: absolut!

Thema: mit Task.Factory.StartNew eine class aufrufen
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Reactive Extensions und Reactive UI können das von Haus aus.

Thema: mit Task.Factory.StartNew eine class aufrufen
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Danke für den Hinweis; wollte eigentlich den (mittlerweile archivierten) Artikel Async/Await - Best Practices in Asynchronous Programming verlinken.

Thema: mit Task.Factory.StartNew eine class aufrufen
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Zitat von MoaByter
Die Zeile 6, "string.IsNullOrEmpty..." ist doch aber nötig.
Nein, ist es nicht, wenn Du async/await korrekt anwendest.
Hab Dir auch den Link gegeben, in dem steht, dass Du .Result nicht verwenden sollst. Denke nicht mal 1% der .NET Entwickler werden den eigentlichen Sinn von .Result verwenden (müssen); in 99% ist es ein (unwissentlicher, aus Bequemlichkeit) Missbrauch, der die im Link beschriebenen negativen Nebenwirkungen hat, die dann Fehler auslösen können, die dann schwer zu finden / reproduzieren sind.

Statt


Task<string> task = Task.Factory.StartNew(scl.Tuwat);
if(string.IsNullOrEmpty(task.Result) return;
schreibt man eigentlich (bezogen auf diese zwei Zeilen)


string content = await Task.Factory.StartNew(scl.Tuwat)
if(string.IsNullOrEmpty(content) return;
..bzw. in expliziter Form, weil Du Duch im UI Kontext befindest


string content = await Task.Factory.StartNew(scl.Tuwat).ConfigureAwait(true);
if(string.IsNullOrEmpty(content) return;
In einer vollständig durchängigen asynchronen Implementierung wirst Du aber niemals Task.Run oder Task.StartNew brauchen.
Siehe Asynchrone Programmierung in C# und ConfigureAwait FAQ/ für das Zusammenspiel zum Sync Context der UI.
Zitat von MoaByter
An der Stelle ist nix parallel. Ich wollte noch zwei Prozesse zusätzlich parallel laufen lassen, aber wenn ich nicht mal mit einem klarkomme ......schluchz! :-))
Asynchrone Programmierung und parallele Programmierung sind zwei unterschiedliche Dinge, die sich jedoch dank Tasks relativ einfach zusammen umsetzen lassen.
Fertige Konzepte gibt es, siehe TPL Docs.
Zitat von MoaByter
Auslesen aus 'nem DGV geht ohne, einschreiben nur mit.
Das ist in diesem Fall "Glück" aber nicht korrekt.
Zitat von MoaByter
Mit Thread(newThreadStart()) funktionierte es, deswegen war ich überrascht, dass es bei Task nicht läuft.
Das funktioniert auch mit Tasks super einfach; Du musst es nur korrekt anwenden, was aktuell nicht der Fall ist.


Thema: mit Task.Factory.StartNew eine class aufrufen
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Zitat
Habe ich an den Tasks etwas falsch verstanden?
Ja. Tasks rufen Methoden / Aktionen auf, keine Klassen.

Dann wäre da noch die Zeile if(string.IsNullOrEmpty(task.Result) return; die zu einem absoluten NoGo im Umgang mit Tasks gehört.
Potenzielle Fehler bei Daten- und Aufgabenparallelität
Zitat
Unterklasse längere Aktionen ausführen soll: Webabrufe, Umwandlunge u.ä.
Generell kann man das alles roh machen, wie Du das versuchst (StartNew() allein ist hier jedoch suboptimal, hier lieber Task.Run()); aber eigentlich gibts dafür bereits fertige Infrastruktur.

Der Task sollte seine Resultate nicht direkt in die UI pushen, sondern Ergebnisse entweder in einen Zwischenspeicher pushen, oder über ein Event verfügbar machen.
Also ganz einfach, simples [Artikel] Drei-Schichten-Architektur

Die fertige Infrastruktur, mit der Du nachlaufende Prozesse, die in Tasks ausgelagert werden, nennt sich DataFlows.
Datenfluss (Task Parallel Library)

Funktionsweise:

Es gibt eine Pipeline, in die Du etwas wirfst, zB eine Url, die abgerufen werden soll.
Die Pipeline hat nun verschiedene Schritte (Download, Parse, Umwandlung...) etc, wie Du es selbst beschrieben hast.
Und dann wird das Ergebnis über ein Event oder eine Zwischenschicht (zB Reactive Extension ObservableCollections) zur Verfügung gestellt.

Machst Du das sauber, dann brauchst Du nirgends ein Invoke, weil das der SyncContext automatisch gerade zieht.
Ein Invoke darfst Du ohnehin nicht blind ausführen; Du musst prüfen, ob der Invoke überhaupt notwendig ist.
[FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke)

Thema: Benutzt ASP Identity Cookies?
Am im Forum: Web-Technologien

Wieso schaust Du nicht einfach in die Doku oder googelst einfach 2,7 Sekunden?
Google Suche nach "asp identity cookies"

Steht direkt im ersten Absatz: Einführung in Identity ASP.net Core

Thema: Sammelthema Wünsche und Bugreports myCSharp
Am im Forum: Wünsche und Kritik

Jo, steht (mit Erklärung der aktuellen Implementierung) ein paar Beiträge weiter oben ;-)

Thema: close Event bei einem User Control
Am im Forum: GUI: Windows-Forms

Zitat von dannysun
Ich häng über ADS an einer Beckhoff Steuerung und das ganze ist event basierend gemacht.
Kein Hindernis.


Thema: close Event bei einem User Control
Am im Forum: GUI: Windows-Forms

Ist etwas ungünstig, dass Du Kommunikationslogik mit UI-Events steuern willst.

Wie ich sowas gelöst hab:
> SPS Events abonnier ich mit Hilfe von Subscriptions (Reactive Extensions)

Die UI kann nun mit einfach auf die Subscriptions hören.
> Aktivieren über den Konstruktor
> Deaktivieren über Dispose

Willst Du das wirkliche Closing Event der Form, dann muss Du das Event an das User Control weiter reichen (zB ein extra Eventhandler einführen).

Thema: Sammelthema Wünsche und Bugreports myCSharp
Am im Forum: Wünsche und Kritik

Das mit den Unterforen hatten wir schon mehrfach; haben wir bereits aufgenommen und fällt wie gesagt unter den Punkt "Suche allgemein überarbeiten".
Der Wunsch hier ist ohnehin auf eine Suche wie Azure Search zu wechseln.

Thema: Sammelthema Wünsche und Bugreports myCSharp
Am im Forum: Wünsche und Kritik

Th69 damit Du es selbst nachvollziehen / testen kannst:
In Deiner Account-Verwaltung siehst Du Deine Logins; hier sollte sich die "Aktiv bis" Zeit mit jedem Request erhöhen (also immer aktueller Zeitstempel + 7 Tage).
Die Cookies sind ebenfalls mit einem Zeitstempel von 7 Tagen versehen. Durch die aktive Sliding Expiration von ASP.NET Core wird automatisch ein neuer Cookie gesetzt, wenn 50% der Expiration Time (also hier 3,5 Tage) erreicht wurden.
CookieAuthenticationOptions.SlidingExpiration Property (Microsoft.AspNetCore.Authentication.Cookies)

Dadurch kann ein "automatischer Logout" nur noch erfolgen, wenn der Cookie (aktiv) gelöscht wird oder man 7 Tage inaktiv war.
Muss man sich trotzdem neu einloggen, dann würde ich nach aktuellem Stand die Verantwortung dafür beim Client suchen.

Thema: Sammelthema Wünsche und Bugreports myCSharp
Am im Forum: Wünsche und Kritik

Zitat von BhaaL
Die Sache mit dem Cookie war auch auf "Eingeloggt bleiben" bezogen, weil ich mich trotzdem alle paar Wochen neu einloggen darf.
Aus Sicherheitsgründen soll ein Cookie nicht unendlich lange gültig sein; das gleiche gilt für die Loginsession.
Beim Foren .NET Release war das so, dass eine Loginsession immer maximal 7 Tage alt ist. Mittlerweile läuft eine Loginsession nur noch aus, wenn diese 7 Tage lang nicht verwendet wurde.

Davon abgesehen ist das .NET Forum nun 4 Wochen online; daher kann die Aussage "alle paar Wochen" sich nicht auf den .NET Stack beziehen.
Und, dass das in der PHP-Welt bescheiden war: ja. Daher kann ich hier mit Deiner Aussage leider wenig anfangen.

Thema: Sammelthema Wünsche und Bugreports myCSharp
Am im Forum: Wünsche und Kritik

Wie gesagt, das Cookie spielt hier keine Rolle.
Im Cookie wird nur die Identität gespeichert, die für einen Login notwendig ist. Das Cookie hat keine weiteren Infos wie besuchte Threads etc.

Alle Queries basieren auf der User-Id und haben keinerlei Beziehung zum Login.

Thema: SQL Query in Linq Lambda Expression
Am im Forum: Datentechnologien

Das ist korrekt, Du brauchst bei Linq für ein Sum auf die Selektion das GroupBy.
Es sind nicht alle T-SQL Queries 1:1 mit einem ORM darstellbar. Du kannst das aber in eine View auslagern und die View aufrufen.

PS: wenn Du mit EF arbeitest, dann ist die Empfehlung EF.Functions statt SqlFunctions zu verwenden.

Was Du aber probieren kannst (weiß nicht, ob es in diesem Fall funktioniert), sind eingebettete Referenzen in Linq.


var query = this.Db.Order
    .Where(w => (w.Key.AllocatedDate != null && w.Key.OrderClosedDate != null && w.Key.OrderClosed == 1) &&
    (SqlFunctions.DatePart("yyyy", w.Key.AllocatedDate) == 2020 && SqlFunctions.DatePart("yyyy", w.Key.OrderClosedDate) == 2020) &&
    (w.Key.partNumber.StartsWith("341911")));

var data = query.Select( _ => new {
   NumberOfOrders = query.Count(), // hier dein Count auf Id
   Avarage = query.Sum(datedif...) // hier das DateDiff
);

Damit kann man sich viele Queries "hin optimieren", die der Provider sonst oft hinwurstelt. Fast jeder Foren-Query hier basiert auf diesem "Hack".
Hab jetzt hier kein Intellisense, um das zuende zu schreiben. Hoffe die Art und Weise ist jedoch ersichtlich.

Thema: Sammelthema Wünsche und Bugreports myCSharp
Am im Forum: Wünsche und Kritik

Hi,

den CSS Bug haben wir prinzipiell auf dem Schirm; der ist aber leider nicht neu.
Das war auch schon im alten Forum so und ist ein Problem mit dem Pre-Tag bei manchen Browsern zusammen mit dem Table-Layout.

Gesamt lösen können wir das vermutlich erst, wenn wir uns vom Table-Design verabschieden können.
Hier fehlt es aktuell an HTML/CSS Entwicklern in unserem Team :-(

Thema: Grid - Feste Row Height wird ignoriert
Am im Forum: GUI: WPF und XAML

Dir ist aber bewusst, dass WPF nicht mit "normalen" Pixeln arbeitet?
DPI and Device-Independent Pixels - Win32 apps

Thema: Connection Sting änderbar durch Benutzer
Am im Forum: Datentechnologien

Hab ich Dir doch schon im ersten Beitrag beantwortet: die Benutzersettings.
Willst das nicht, dann musst Dir eben selbst nen entsprechenden Speichermechanismus programmieren.
Halte Dich dazu an die Empfehlungen von Windows, siehe Environment.SpecialFolder Enumeration

Thema: Connection Sting änderbar durch Benutzer
Am im Forum: Datentechnologien

Bitte richtig lesen, wenn es schon Off-Topic sein muss:
Es ist ein Unterschied, der sich auf die Häufigkeit der Fehler / Defekte auswirkt, ob man von einer Access-Anwendung in einer Access-Runtime spricht oder von einer Access-Datenbank, die von Extern angesprochen wird, wie es hier der Fall ist.

Defekte / korrupte Datenbank-Dateien von Access haben so eine extreme Häufigkeit, dass sich drum herum ein eigenes Ökosystem an Repair- und Backup-Tools entwickelt hat.
Der bekannteste Fehler ist Google Suche nach "It may not be a database that your application recognizes"

Wenn ihr 18 Jahre lang umfangreiche (was relativ ist) Access-Anwendungen betrieben habt, die nie korrupte Datenbank-Dateien hatten, dann kann ich das basierend auf meiner Erfahrung (was ich in Foren (zB hier), Blogs und bei meinen Kunden sehe) nur als Glück bezeichnen.

Thema: Visual Studio Universelle Windows Entwicklung oder .Net Desktop...
Am im Forum: Rund um die Programmierung

Prinzipiell hättest das einfach in der Doku lesen können, aber hier die Kurzfassung:

Universelle Windows Plattform sind UWP Apps.
Was ist eine App der universellen Windows-Plattform (UWP)? - UWP applications
Also Apps, die man primär über den Windows Store verteilt und in Windows in eine Sandbox ausgeführt werden.

.NET Desktopentwicklung sind "klassische" Win32 Apps.
Erstellen von Desktop-Apps für Windows-PCs - Windows applications
Klassische Runtime, klassischer Installer.

Was Du davon installieren "sollst" kann Dir keiner sagen, da keiner hier Deine Anforderungen kennt.
Musst schon selbst entscheiden ;-)

Thema: Connection Sting änderbar durch Benutzer
Am im Forum: Datentechnologien

Access ist keine Datenbank. Access ist ein RAD Tool, das Du als Datenbank missbrauchst.
Access war jedoch nie für das isolierte Speichern im Sinne einer Datenbank gedacht; daher gibt es auch in 99,9999% aller Applikationen, die Access verwenden, Datenverluste und andere Probleme mit Access.

Wenn Du lokal Daten speichern willst, dann nimm sowas wie Sqlite; nicht Access.
Overview - Microsoft.Data.Sqlite

Zitat
Wie kann ich sowas realisieren?
Über die die Anwendungs- oder Benutzereinstellungen. Einfach mal in den Docs schauen.
Using Application Settings and User Settings - Windows Forms .NET Framework

Thema: Dokument mit C# und HTML
Am im Forum: Web-Technologien

Zitat von DerPeter123
Aber wie bekomme ich z.B. die Liste mit den Werten die ich im HTML Document anzeigen möchte, in das HTML file?
Also wenn Du Templating verwenden willst, dann musst Dir halt auch den jeweiligen Syntax anschauen.
Im Falle von Razor übergibt man den Views entsprechend Modelle, die den Inhalt haben, der in das HTML eingebettet werden soll.
Razor ist extrem gut dokumentiert, zB. als Teil der Razor Pages: Teil 2: Hinzufügen eines Modells
Zitat von DerPeter123
Also es ist etwas einheitlicher in HTML Code und nicht so sehr C# mit HTML vermischt?
Es ist ein Templating-Framework; also das, wonach Du gefragt hast.
Zitat von DerPeter123
aber ich habe noch nicht den Vorteil dazu gefunden, als wenn ich einfach HTML code in einem normalen String speichere.
Das ist kein Templating Framework. Das ist halt String-Replace.

Thema: Wie kann ich eine Datei über die Rest-API senden oder abrufen?
Am im Forum: Grundlagen von C#

Das hat mit REST nichts zutun. REST beschreibt die Art und Weise des Aufbaus einer API. Es ist ein Paradigma.
Inhalte werden dabei über Plain-Text dargestellt; nicht binär.

Viele sagen, dass Du Datei-Inhalte mit REST nicht darstellen kannst; sondern wenn dann die Route.
Andere sagen Du kannst das, wenn Du den Body als base64 encodierst.

Ich gehöre zu denen, die sagen, dass REST keine Regeln für den Umgang mit Dateien beschreibt.

Zitat
Wie kann ich eine Datei (z. B. im PDF-Format), die sich in einem Ordner befindet, lokal über einen API-Aufruf in einem Ordner in einem Dokumentenverwaltungssystem verschieben?
Verstehe die Frage nicht, was das mit REST zutun haben soll.
Das Zielsystem sagt Dir doch, wie Du mit der Schnittstelle sprechen musst, damit Du Dateien hochladen kannst.
Und das musst eben umsetzen.
Fehler
System.IO.FileNotFoundException: "Die Datei" C: /Users/******/Documents/*****/*****/pdf.pdf "wurde nicht gefunden.
Auch das hat wenig mit REST an für sich zutun, sondern mit der Bibliothek, die Du verwendest.
Entweder die Datei ist da wirklich nicht, die Anwendung hat keine Rechte drauf oder Du verwendest die Lib falsch.
Wird sich aber sicherlich in der Doku nachlesen lassen.

Tendentiell ist die Wahrscheinlichkeit aber eher gering, dass es ein Bug der Lib ist.

Thema: Netzwerk Adapter Name ändern
Am im Forum: Netzwerktechnologien

PowerShell ist Open Source und unter der Haube auch nur .NET. Werf nen Blick rein und schau, was die tun.
Wird auch nichts anderes als ne Win32 API sein vermutlich.
Google Suche nach "win32 rename network adapter"

Thema: Dokument mit C# und HTML
Am im Forum: Web-Technologien

Ja, nicht so bequem wie RazorLight; aber wenn Du keine Drittabhängigkeiten willst, dann geht das.

Thema: Best Practice Frage zu Exception Handling ASP.NET
Am im Forum: Grundlagen von C#

Es ist eine Methode, keine Funktion. In C# sind Funktionen etwas anderes.

Wie man generell Exceptions behandelt steht im Docs-Link.
Alle weiteren Umsetzungen sind im Endeffekt anwendungspezifisch bzw. kommt es auf die Exception an.

Gibt Exceptions, die kann man automatisch lösen, versuchen automatisch zu lösen; gibt welche, da muss der User aktiv werden und es gibt welche, die man gar nicht behandeln kann.

Thema: Fehlermeldung bei DB-Zugriff
Am im Forum: Datentechnologien

Musst nicht denken: das ist so. Siehe Database First-EF6
Aber ja, EDMX ist seit sieben Jahren abgekündigt.