Und ich dachte ich hatte auch mal etwas gelesen, das man diese Eigenheit beim SMS einstellen kann.
Das ist keine Eigenheit, sondern das korrekte Vorgehen; alleinaus Domänensicht. Die Eigenheit ist euer Thema da - ich würd sogar als konzeptionellen Fehler betiteln; eben weil ich solche Systeme schon aufwändig reparieren musste.
Kein Mensch kann erkennen, dass sich die Bedeutung von Werten nur anhand der Groß- und Kleinschreibung unterscheidet - auch Nicht-Imformatiker :-)
Wer soll das denn in 5 Jahren noch wissen? Folgefehler sind da vorprogrammiert.
Am Ende läuft das unter Normalisierung (Datenbank).
Das heisst, Du musst einen generischen Datenbank-Aufbau machen - und dann Schnittstellen schaffen, die die Eindeutigkeit von Werten herstellen kann.
Bei Maschinen macht man das leider oft pro Maschine / Version; selten pro Hersteller.
Das heisst: Du musst wissen das Wert A von Maschine 6 "XYZ" bedeutet. Bei Hersteller O bedeutet Wert F aber XYZ.
Im Endeffekt funktioniert technisch jeder Datenbank-Provider von großen Frameworks so:
Aus .NET Developersicht erstellst Du einfach eine "Datenbank"-Verbindung, und je nachdem welche DB Typ das ist..
IDbConnection connection = new MySqlConnection("...");
IDbConnection connection = new MssqqlConnection("...");
IDbConnection connection = new Oracle("...");
Bei Dir dann halt:
- "Durchmesser-A" von Maschine 1 bedeutet zB "Durchmesser Gesamt"
- "Durchmesser-a" von Maschine R bedeutet jedoch "Durchmesser Bohrkopf"
Wie mache ich denn so einen Bearer-Token-Verifizierung auf meinen Code bezogen?
Sorry, das so deutlich zu sagen, aber den Code kannst wegwerfen :-)
Nimm ein REST Package (zB Refit), schau in dessen Doku: die haben alle Bearer-Token Support.
Personio ist ein personen-bezogener Service - Du unterliegst damit sehr strengen DSGVO Regeln.
Eine Lücke in Deinem Code kann euch (finanziell) extrem weh tun.
Also les besser 1-2 Dokumentationen, bevor Du irgendwas hin klatschst. Dir wird das nicht zugeflogen kommen.
Machs ordentlich. :-)
Konzeptionell behandelst Du hier ein Symptom, löst aber nicht die Ursache des Problems.
Lass die Maschinen nicht blind in die Datenbank pumpen, weil sonst passiert schnell das, was Du jetzt hast: Inkompatibilitäten.
Das jemals wieder zu fixen: viel Spaß.
Gib den Maschinen eine Schnittstelle; wenn schon nicht auf API Basis (REST, gRPC..), dann wenigstens als Stored Proc.
Dann kannst Du auch ein Name Mapping (zB durch einen Provider Pattern aufbauen).
Hab den gleichen Käse mal bei nem namhaften Maschinenbauer fixen "dürfen" - den Ärger und die Kosten kann man sich sparen :-)
Ich mag mich gerade arg täuschen, aber meines Wissens reicht es nicht die Collation einer DB zu ändern.
Server Identifiers müssten IIRC über die Instanz-Collation Settings (also den DB Server) beim Setup mitgegeben werden.
Aber wie gesagt: hiermit wird nicht das eigentliche Probleme hier gelöst, sondern ein Symptom.
Naja, aber wieso schaust Du Dir nur die aus dem Jahr 2015 markierte Lösung an, und nicht die weiteren Beiträge?
Wie man schon in der 2. Klasse bei Tests lernt: Seiten immer erst mal durchlesen, bevor man anfängt.
Ganz am Ende ist ne Lösung, die nur wenige Tage alt ist und den async/await Pattern hinein implementiert hat - wie man auch empfiehtl mit Semaphore.
Hättest Dir also das eigene Zeug sparen können ;-)
Hab aber keiner der Snippets validiert (weil ich das halt eh nich so lösen würde).
Hast ja trotz Nachfrage leider auch gar nichts zur Anforderung gesagt, daher..
Musst halt der JavaScript Funktion den ModelState mitteilen.
Da gibts dutzende Wege; das kannst entweder direkt in JS einbetten, oder als zusätzliches data-Attribut in Dein Form (HTML) und im JS Code darauf reagieren... etc etc.
Ich arbeite i.d.R. über die Attribute-Variante und reagiere dann mit JavScript Events/Bindings bzw. CSS Styles drauf.
Async != Parallel.
Das sind zwei unterschiedliche Dinge. Async hat primär nichts mit Performance zutun, sondern ist ein Mechanismus um blockierenden Code zu vermeiden und System-Resourcen besser zu verwenden.
Aber ja, im Falle von ASP.NET bzw. Webanwendungen im Allgemeinen spielt beides eine Rolle.
Ich rate einfach mal, weil Du es nicht genau sagst, dass Du ein stink-normales Dateisystem verwendest und über NTFS-Dateipfade zugreifst.
Diese Art und Weise ist nicht optimal für Webanwendungen, weil - wie Du schon gemerkt hast - solche Dateisysteme nicht wirklich für Webanwendungen gedacht sind.
Für Webanwendungen, insbesondere produktive Anwendungen in größer Umgebung, sollte man entsprechend ausgelegte Dienste für sowas verwenden.
In der Cloud sind das sowas wie CloudFlare R2, Azure Blob Storage, AWS S3. Äquivalente Services zum selbst hosten im eigenen Rechenzentrum sind zB. Cloudian, Dell Elastic Storage, NetApp Storage Grid, min.io.. Diese Systeme nehmen einem so etwas an, da sie i.d.R transaktionssicher sind.
Damit wäre beantwortet, was man generell so für Webanwendungen verwenden sollte ;-)
Willst Du sowas selbst bauen, so ist es in .NET mit Bordmitteln möglich solch einen Pipelining Mechanismus zu bauen: Datenfluss (Task Parallel Library)
Damit lassen sich viele Anfragen auf eine einzelne, transaktionssichere Pipeline bündeln und umsetzen.
Leider scheint der AsyncReaderWriterLock vom "Microsoft.VisualStudio.Threading" Package zu einem Deadlock zu führen!?
Das Paket Microsoft.VisualStudio.Threading kann für alle Arten von .NET verwendet werden und ist durchaus für den allgemeinen gebraucht gedacht.
Woher ich das weiß? Steht in der Info des Pakets ;-)
Ich glaube des weiteren nicht, dass der Deadlock von diesem Paket kommt. Die Wahrscheinlichkeit dürfte bei 99,9999% bei Deinem Code liegen.
Üblicherweise sollte man die Logik und nicht den Schreibvorgang selbst locken, weshalb Du ein Lock mit async i.d.R. mit SemaphoreSlim.WaitAsync umsetzen solltest.
Zielführender wäre aber, wenn Du einfach erklären würdest, was denn überhaupt Deine Anforderung ist. ;-)
Dann könnte man Dir auch erklären, ob Du überhaupt die richtige Richtung verfolgst, oder wir hier an einem Problem helfen, das es ein Folgefehler ist.
Und wenn man von Code mit Deadlock spricht dann hilft es auch immer, wenn man Quellcode zeigt.
Das is aber ne Detailfrage und hängt davon ab, ob es am Ende wirklich nen Enum wird.
Den Sinn - hier OOP anzuwenden, wie es in solchen Sprachen wie C# halt gedacht ist - wird ja vermittelt :-)
In Perl programmiert man auch anders als in C# (+ ähnliche Sprachen).
Versuch nich blind Paradigmen zu übernehmen. Da wirst nicht der erste sein, der an einem solchen Versuch scheitert wird - aber leider auch nicht der letzte..
Windows XP besitzt seit 2014(!) keinerlei offiziellen Support mehr. Selbst der Extended Support ($$$$) hat 2016(?) geendet.
Neue Programmiersprachen und Runtimes, die seitdem entstanden sind, unterstützen XP schon ewig nicht mehr oder haben XP nie offiziell unterstützt.
Man muss auch in der .NET Welt lernen, alte Zöpfe abzuschneiden.
Wenn Du Windows XP immer noch unterstützen musst (ich kenn sowas aus der Maschinenbau-Welt, leider - ich komm ja auch da her)... dann musst Du für immer und ewig bei .NET Framework bleiben und darfst halt nichts mehr Neues nutzen und Dich damit abfinden.
Aber die Erwartung zu haben, dass neue Technologien und Runtimes auf Steinzeit-OS laufen: no way.
Man kann (können schon, aber die Zeit !) ja nicht alle Projekte umschreiben, auf .Net5/6 usw.
Sorry, aber "Zeit" ist eine faule Ausrede. Es geht hier schließlich um Dich, Deine Projekte, Deine Kunden und deren Zukunft.
- 2015, also vor SIEBEN JAHREN, war bekannt, dass .NET Core kommen wird.
- Seit 5 Jahren ist bekannt, dass NET FX ein Auslaufmodell ist.
- Seit 2016 gibt es .NET Standard 2.0, das eine breite API zwischen NETFX und NET Core hat.
- Seit 4 Jahren predigt Microsoft und die gesamte .NET Community: mach Dich bereit, dass Du migrieren MUSST.
Das *MUSS* jeder .NET Entwickler wissen. Es gibt keine Chance an diesen Infos vorbei zu gehen.
Spätestens wenn man mit Visual Studio täglich arbeitet, selbst mit alten Versionen.
Wer das ignoriert: selbst schuld.
Zitat von oehrle
Welche Möglichkeiten hat man?
Migrieren! Es wird Zeit! .NET Framework und .NET Standard haben keine Zukunft mehr!
Du musst alles auf .NET 5/6 heben - oder Du kommst aus der Welt nicht raus.
Da gibts absolut keinen anderen Weg.
Zitat von oehrle
Gibt es da keine Brücke, das neue im vorhadnenen (alten) zu verwenden?
Nochmal: Die Brücke heisst .NET Standard. .NET Basics seit 7 Jahren!
Diese Brücke war aber nur temporär, von .NET FX auf .NET Core 3 (bzw. ausgereiz auf 5).
Aber auch .NET Standard war allen bewusst, dass es nur für die Transition in die neue Welt gedacht ist.
Diese Brücke braucht man schon lang nicht mehr, wenn man sich entsprechend vorbereitet hat.
Daher wurde diese Brücke mit dem Ende von .NET Standard 2.1 auch eingerissen bzw. nicht mehr weiter entwickelt, kann aber noch genutzt werden.
Siehe Probleme und Zukunft von .NET Standard
Es sind zwei unterschiedliche Technologien, als ob Du Lego und Duplo zusammen stecken willst.
Der einzig offizielle Support zwischen den beiden Welten ist .NET Standard, dafür war es gedacht und hat auch seinen Zweck erfüllt.
Dein Video zeigt auch was anderes als Deine Frage.
Zitat
Kann ich aber rückwirkend eine NetCore-DLL mit neuer Anwendungsfunktionalität auch in ein .Net-Projekt einbinden (DLL) um dann die Methoden anzusprechen?
In dem Video wird Multi Targeting gezeigt, kein Backward-Referencing.
Also erstens: poste keine Credentials in Foren.
Ich habe die Credentials aus Deinem Beitrag gelöscht, Du solltest sie trotzdem zurück setzen.
Zitat
Mein Problem ist, dass ich mit dieser Materie noch gar nichts am Hut habe...
Das ist völlig normal, aber es bietet sich immer an, dass man erstmal etwas dazu liest, statt blind loszulegen. Das Wissen kommt Dir nicht zugeflogen, das musst Dir schon selbst holen. :-)
Gerade bei REST APIs gibts fertige Bibliotheken, wie zB. Refit, die einem sehr viel Arbeit und auch die Authentifizierung sowie vor allem die Fehlerbehandlung und Kommunikation abnehmen.
Ansonsten hat Dein Code auch auf den wenigen Code schon viel konzeptionelle Fehler, zB Dein Wait bei einem Task (das kann in der Form Deadlocks und damit in Folge zum Absturz führen), oder das using um den HttpClient.
Google blockt automatisierte Logins von Integrationstest, was auch gut so ist.
Schließlich wäre das eine Sicherheitsproblem, wenn das nicht so wäre - es sind technisch schließlich automatisierte Bot-Logins; inkl. allen Nebenwirkungen.
Früher war der Workaround ein Chrome User Directory zu verwenden, in dem ein User bereits eingeloggt ist.
Dafür gibts das --user-data-dir Flag.
Äh, nein. So funktioniert WebAssembly im Client leider nicht.
Aber evtl. nimmt Deine JS Lib einen eine data:-Uri an, dann kannst Du das Bild als base64 übergeben.
Das wird so von Haus aus nich möglich sein, was aber nichts mit Blazor zutun hat. Die Dateien selbst sind im Local Storage, d.h. gar nich über ne URI erreichnbar.
Eine URI erzeugt jedoch auch einen neuen Request und damit einen neuen Kontext im Browser; d.h. same context behavior is hier auch nicht.
Ich würde jetz pauschal aufgrund vom Ausschlussverfahren sagen, dass Deine externe Kompotente hier inkompatibel mit WebAssembly ist.
Aber is jetz nichts so ungewöhnliches; viele JS Bibliotheken sind (noch) inkompatibel mit WebAssembly.
, dass jedes Vorgehen seine Nachteile hat - auch die Vesionierung über Url Segmente.
Nur um das nich ganz so stehen zu lassen: Ja, bei URL gibts einen einzigen Nachteil: eine Ressource kann mehrere URLs haben, was so nur Query/Header-Versioning erfüllt.
Dieser "größere" Nachteil hat aber nur ganz spezifische Anwendungsfälle, sodass es in 99,999% der APIs nicht relevant ist.
Die Nachteile der Header-Lösungen sind aber für 99,999% der Anwendungen so groß oder gar ein No-Go, dass es dafür absolut null Pros gibt, die das rechtfertigen würden.
Daher muss man die Pros/Cons gerade bei APIs gewichten. Man spricht daher auch i.d.R. davon, dass Header-Versionierungen nur theoretische Vorteile haben, aber keine praktischen. Dazu gibts auch einen Vortrag von Google, mit dem ich pers. auch jeden Kunden bisher überzeugen konnte, dass das keine gute Idee ist. Finde ihn aber gerade nicht. Aber das habt ihr sicher gut auf euren Anwendungsfall evaluiert.
Daher lass ichs nun auch dabei, wollte das mit der Gewichtung aber nicht unerwähnt lassen.
Zitat von fluxy
Was meinst Du mit impliziter Versionierung?
Deine Attribute.
ApiVersion und MapToApiVersion sind verschiedene Versionierungsattribute mit entsprechenden Auswirkungen in ASP.NET Core.
Ich habe nie eine Versionsverwaltung *in der Applikation*, wenn ich nicht dazu gezwungen werden.
Zitat von Abt
Bist Du Dir da sicher?
Ja, und ich kenne auch den/die beiden Issues (Header/Query), wenn dann halt nur mit den nicht offiziell enthaltenen Workarounds.
Ich kenn auch Kunden-Bastellösungen, die das über nen eigenen Middleware-Resolver gemacht haben - alles bisher (von mir) gesehen aber war murks.
Kein Scherz: ich hab das für die Kunden dann so gelöst, dass es nur eine Methode gibt und die API Version als ENum über nen ModelBinder ein MethodenParameter ist, wenn es nur die Resource Versionierung betrifft.
Alles andere immer über mehrere Namespaces, ansonsten ist ein Evolutionsrisiko auch viel zu groß (meiner Meinung nach).
dass die Versionierung über den HTTP Header eine bewusste Entscheidung war
Dann müsst ihr auch mit Workarounds leben, wie hier :-)
Ich verwende Dein Vorgehen generell nirgends, weil es viele Probleme im Alltag macht. Die Grundidee ist ja, dass Versionen unabhängig voneinander betrieben und weiterentwickelt werden, zB. durch Legacy etc. Alles in eine Applikation zu packen, macht nur in ganz ganz ganz wenigen Mini-Szenarien sinn.
Und selbst in diesen würde man eher pro Version einen eigenen Namespace haben, statt alles über Mappings zu lösen. Ich hab das in freier Wildbahn, ausserhalb von Demos, noch nie gesehen.
Zum Problem: Implizite Versionierung ist im Framework nur dann möglich, wenn Du keinerlei andere Versionsinformationen setzt. Daher knallts.
In Deinem Fall dürfte es aber eh knallen, weil NSwag keine Versionierung über Header oder Query unterstützt. Nur URL Versionierung wird unterstützt.
D.h. Dein Header-Vorgehen mit NSwag so geht eh nicht.
Konzeptionell erstellt man in den aller meisten Fällen eigentlich erst das Swagger/OpenAPI Dokument, und implementiert dann die Anwendung (Contract First Architecture). Auch nen breites Team-Vorgehen geht nicht ohne Contract First.
Es gibt meines Wissens derzeit keinen OpenAPI Runtime Generator für ASP.NET, der Header unterstützt - nutzt halt auch fast niemand, wegen den enorm vielen Cons.
Die einzige Lib, die das meines Wissens zumindest teilweise kann, ist https://github.com/dotnet/aspnet-api-versioning
Zitat
über den HTTP Header eine bewusste Entscheidung war
Tipp für die Zukunft: halte Dir den "Ich habs Dir gleich gesagt"-Satz schon mal parat :-)
PS: auch in Deinem Startup sind paar Fehler, zB hast Du UseAuthorization ohne Authentication, sowie passen die Reihenfolgen nicht.
Siehe ASP.NET Core-Middleware
Swagger etc gilt als "Custom Middleware".
Hättest du vielleicht ein Beispiel von dem MemoryStream?
Wieso schaust nicht einfach in die Suchtreffer aus meinem ersten Beitrag? Da steht alles mit Erklärung und Co.
Oder einfach in die Dokumentation schauen.
@Caveman das sieht nach .NET 3.5 Code oder früher aus.
Seit .NET 4 kann man einfach CopyTo verwenden
fileStream.CopyTo(memoryStream);
Den Magic String im Property Event braucht man mittlerweile auch nicht mehr; so ist die potentielle Fehlerquelle auch eliminiert.
In der Regel macht man das mit Hilfe von Subscriptions bzw. allgemein Messaging Pattern aka Event Sourcing, zB mit Reactive Extensions.
Du gibst also dem Messaging System bekannt, welche Person selektiert wird. Im anderen Window hörst Du auf das Messaging und zeigst dann zB die Person an oder machst irgendwas anderes damit.
Mit solch einem Pattern vermeidest Du auch so Zeugs wie globale Klassen.
Sobald Du das Gefühl hast, dass Du sowas brauchst, ist das in 99% nen Zeichen, dass was suboptimal ist ;-)
Gerade als Anfänger muss man eben viel lesen, haben wir alle hier durch gemacht, um Software schreiben zu können.
Du suchst ja hilfe, dann les halt auch das durch, was die Helfer Dir geben. Wenn Du nur die Lösung suchst, ohne das verstehen zu wollen, dann musst jemanden dafür beauftragen - ist ja auch legitim.
Beispiele sind in den Artikeln, musst sie nur lesen; bezweifle in Anbetracht der Zeit zwischen Post von FZelle und Deine, dass Du das getan hast.
Ansonsten beachte bitte [Hinweis] Wie poste ich richtig?, dass das Forum natürlich Dir kein fertigen Code liefert.
Umsetzen musst es schon selbst.