Laden...
Avatar #avatar-4119.png
Abt myCSharp.de - Team
Principal Software Engineer Dabei seit 20.07.2008 16.807 Beiträge
Benutzerbeschreibung
Als Principal Software Engineer berate und unterstütze in Form von Entwicklungsleistung aktiv Projekte und Unternehmen in Sachen technischer Zukunft mit dem Fokus auf auf .NET und hoch-moderne Web-Anwendungen/-Landschaften in der Cloud. Ich präsentiere die Technologien von Morgen und helfe bei der Analyse der korrekten Strategie und Methodiken für die Umsetzung. Neben meinem Tech-Blog SCHWABENCODE.com bin ich seit 2011 in exekutiver Funktion dieses Forums tätig, schreibe Artikel und halte ab und zu Vorträge in kleineren Runden zum Thema Cloud, Web-Development und IoT. Seit 2015 wurde ich jedes Jahr zum Microsoft MVP für (.NET / Azure) ernannt.

Forenbeiträge von Abt Ingesamt 16.807 Beiträge

11.06.2023 - 13:14 Uhr

Ich könnte bei Zeit ja noch den Hinweis "Lokalzeit" ausgeben.

Welche Zeit sollte denn angezeigt werden, um den CODE-FEHLER zu beseitigen ?

Du kannst auch einfach die Zeit korrekt einlesen, nach UTC. Ein kleiner Edit behebt den Fehler.
Deswegen hab ich Dir den Link gegeben.

DateTime dt = new(1970, 1, 1); // TimeZone Unknown
DateTime dt = new(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc); // 1970 nach UTC
DateTimeOffset o = new(1970, 1, 1, 0, 0, 0, 0, 0, TimeSpan.Zero); // 1970 nach UTC

Die ZEIT und die ZEITZONE ist m.E. mehr ein philosophisches als ein technisch-mathematisches Problem.

Nein. Das ist ein messbarer Fakt. UTC ist standardisiert und ist weltweit gleich.
Für Deine Information spielt der Ort auch keine Rolle.

Da ja nicht angespeichert ist, wo (an welchem Ort der  Erde) die  Installation stattfand, kann man die Zeit auch nicht korrekt zuordnen.

Das wiederum ist Theorie. Das Argument eine Zeit passend zu seinem Ort zu speichern ist ein nett verwendetes Argument, zB auch vom EF Core Team (das anders argumentiert als das MSSQL Server Team), das in der Realität jedoch kaum eine Rolle spielt und eine Genauigkeit auch nicht erreicht werden kann.
When “UTC everywhere” isn’t enough - storing time zones in PostgreSQL and SQL Server
Das ist eine nette Theorie, die die gleiche Schwäche hat, wie das Argument selbst. Es würde nur funktionieren, wenn die Geokoordinaten zu einem Zeitstempel gespeichert werden und dementsprechend Zeitzonen zur Verfügung stehen würden - dem ist aber nicht so.
Eine Zeitzone zu einem Zeitstempel zu speichern hat keinen Vorteil im Bezug zum Ort, denn der Ort könnte dieser Theorie die Zeitzone ebenfalls wechseln - und die Genauigkeit ist wieder verloren. Das ist aber eine Theorie, die 1-2 mal pro 100 Jahre eintritt (siehe Süd/Nordkorea).
Hingegen die (Konvertierungs-)Fehler von DateTime gegenüber DateTimeOffset bleiben die gleichen.

Nach UTC bzw. nach ISO8601 zu speichern sind jedoch technische Standards - daher auch keine Philosophie.
Wenn Du also eine Zeit erhälst, die diesem Standard zugrunde liegt, dann machts schon sinn das auch so zu behandeln; aber zu argumentieren "dann isses halt ne Stunde falsch" ist halt schon... "ein schwieriger Umgang".

11.06.2023 - 12:58 Uhr

Warum machst Du das überhaupt so? Warum denkst Du, dass es eine praktische Idee ist, DLLs von Hand zu kopieren?
Es gibt unzählige Wege das korrekt zu managen, zum Beispiel über ein NuGet Paket, das Du auch privat ohne NuGet.org zur Verfügung stellen kannst - inklusive Symbol-Dateien.
Da haben sich Leute schon was dabei gedacht... → Creating symbol packages (.snupkg)

Die Breakpoints werden aber nicht angefahren.

Breakpoints werden nur angefahren, wenn die korrekten Symboldateien zur Verfügung stehen.
Darüber hinaus wird in der DLL/EXE der vollständige Pfad der Symboldateien eingebettet und dort gesucht. Kopierst Du das weg, funktionierts natürlich nicht mehr.
Basics: Specify symbol (.pdb) and source files in the Visual Studio debugger

Die Fremdanwendung.exe ist hier installiert: C:\Fremdprogramme\Fremdanwendung

Auch nicht die schlaueste Idee. Es gibt unter Windows gewisse Ordner, die für Installationen vorgesehen sind und genutzt werden sollten. Alle anderen Ordner gelten unter Windows erstmal als "geschützt", was Nebenwirkungen haben kann - zB Berechtigungen und Co.

10.06.2023 - 18:34 Uhr

Das ist ein sehr interessanter Umgang mit Feedback zu Code-Fehler.

09.06.2023 - 23:10 Uhr

Mh. Mein Vorschlag, den man technisch durchaus als Standard bezeichnen kann, ist simpel, weit verbreitet und unterstützt auch komplexe Szenarien.
Deine Idee ist customized, vergleichsweise komplex und unterstützt nur simple Szenarien.

Klar, eigene Ideen sind toll - aber zu welchem Preis, und so weit weg vom Standard. Wozu?
Nicht falsch verstehen: mir ist im Prinzip egal was Du umsetzt oder nicht; es sind nur Tipps.

Ich nutze bereits Repositories, die auf extra dafür implementierten Schnittstellen basieren.

Das hat damit nix zutun. Was Du machst sind Roundtrips bzw. komplette Replacements mit allen Effizienznachteilen. Repository hin oder her.
EF Core kann Partial Updates, zB mit ExecuteUpdate, wo man nur die Properties angibt - auch dynamisch - die man ändern will.

Man kann also dieses gesamte Thema sehr effizient und standardisiert lösen, wenn man einfach die Mittel nutzt, die existieren.

09.06.2023 - 21:34 Uhr

Gibt es eine Möglichkeit, festzustellen, welche Formularfelder manuell geändert wurden?

Nein. Dafür gibts keinen Automatismus. Musst selbst implementieren.
HTTP kennt nur: Wert übertragen, oder nicht.

Die Update-Methode (hier _InProduktionRepository.Update(inprodukktion)) hat keine Ahnung vom aktuellen Kontext. Diese sollte autark feststellen können, welche Felder geändert wurden.

Das kann die Methode ohne hellseherische Kräfte nicht leisten.

Oder geht man schließlich ganz anders vor?

Ja. Man geht grundlegend anders vor. Angefangen damit, dass man keine Datenbank-Entitäten in der Oberfläche verwendet. Das gehört zu den absoluten Grundlagen.
[Artikel] Drei-Schichten-Architektur
Man verwendet - wie bei jeder anderen Technologie - abstrahierte Modelle, im Web-Kontext meist Request- und Submit-Models genannt. Was Du da mit Deinen Models und Entitäten tust fällt leider eher in die Bezeichnung "Gefrickel". Gelinde gesagt machst Du das, was man allein aus Logik/Sicherheitsgründen niemals tun sollte: blind Modelle aus einem Request annehmen und in eine DB stecken.

Der korrekte Weg wäre extra Update-Modelle zu verwenden, die dann mit einer Patch-Operation mitgeteilt werden.
Property im Patch = null → keine Änderung

Willst Du alles über einen Post-Request lösen, dann brauchst trotzdem eigene Modelle, aber auch eine eigene Logik zur Verarbeitung von Eigenschaften eines DB Modells.

09.06.2023 - 19:35 Uhr

In Deiner Zeiterstellung ist aber mindestens ein Fehler drin, nämlich die Zeitzonenbehandlung. Du erzeugst alles mit der lokalen Zeitzone (zB Deutschland), Windows speichert jedoch alle Werte getreu dem ISO-Standard nach UTC.

[FAQ] DateTime vs. DateTimeOffset und der Umgang mit Zeiten in .NET

09.06.2023 - 12:46 Uhr

Suchst Du vielleicht die Methode Show von Form?

Du kannst im Endeffekt das Schließen ein Form durch Events abonnieren; und Du musst Dir alle Forms, die existieren, merken.
Zum Beispiel durch das Form.Closing-Event. Du bekommst hier aber nichts von Windows oder vom Framework geschenkt. Verwaltest Du Forms, dann bist Du in der Verantwortlichkeit eben das zu tun: verwalten.

Schließen einer Form allein räumt keine Abhängigkeiten, die Du selbst verwaltest, auf.
Wie gesagt: Du bist in der vollen Verantwortlichkeit für das Lifecycle jeder Form respektive jeder Instanz.

07.06.2023 - 11:49 Uhr

Bei Deiner Maschine scheinen generell Dinge zu fehlen, wenn Du schon nicht dotnet new aufrufen kannst.
dotnet new ist Teil der .NET CLI und existiert seit mindestens Version 2 - also mindestens 2018.

02.06.2023 - 13:29 Uhr

Wie der Name WindowsIdentity.GetCurrent() schon in gewisser Weise aussagt, repräsentiert das die Identität des aktuellen Users des Prozesses. Das kann so natürlich bei IIS nicht funktionieren, weil hier kein Prozess des Benutzers involviert ist, sondern nur der Prozess der Server-Applikation.

Was Du suchst ist im Endeffekt unter Understanding identities in IIS beschrieben; was man eigentlich per Google Suche gut findet. Vielleicht hast das übersehen.

Du willst die Windows Authentication nutzen; aber achtung: diese funktioniert nur in sich geschlossenen Unternehmensnetzwerke, nicht über das Internet! Auch ist diese per default nicht aktiv sondern muss aktiviert, bzw. manchmal auch nachträglich installiert werden (auf dem Windows Server über das Paket-Management).

In Deiner ASP.NET Core Anwendung bekommst Du die Identität des Benutzers dann über das Request.User-Objekt. Willst Du mit der Identität des Applikationsnutzers weiter arbeiten (zB gegen ein Laufwerk, gegen eine Share, gegen eine andere interne Anwendung), dann brauchst Du Windows-Impersonation. Die Anwendung läuft nämlich prinzipiell anonym und muss dann sich selbst als User weiter identifizieren; pro Request und nicht global.

Bezüglich Auswahl des richtigen Identity Providers (Windows Identity ist nicht unbedingt für alles empfohlen, eher dann Microsoft Identity Platform, wie die neue Umgebung heisst) hilft Microsoft identity platform best practices and recommendations

30.05.2023 - 22:40 Uhr

Woher hast Du denn das Beispiel, dass Du ObservableProperty auf ein ItemCollection setzt?ItemCollection dürfte doch ein UI Control sein, oder?

In MVVM kennt das ViewModel keine UI Controls. Das funktioniert also so konzeptionell nicht im Ansatz.
Üblicherweise hast Du in Deinem "MailViewModel" eine Bindung weitere Sub-ViewModels. zB

[ObservableProperty]
private ObservableCollection<MyItemViewModel>;

Wobei MyItemViewModeldann die Abstrahierung mit in Deinem Fall wohl Name und Bild ist.

Les Dir durch was die Idee von MVVM ist und wie es funktioniert.

30.05.2023 - 21:41 Uhr

Ich würde MVVM gerne etwas später benutzen.

Es gibt Technologien, die darauf ausgelegt, dass gewisse Pattern verwendet werden.
Avalonia, WPF und noch weitere sind auf MVVM ausgelegt. Du wirst ohne Stolpern und Workarounds bei solchen Technologien nichts anderes verwenden können - weil es Teil des Konzepts ist.

Der konzeptionell etwas einfacher zu verstehende MVU-Pattern, der deswegen auch beliebter ist, ist offiziell noch nicht unterstützt, aber über ein Community-Projekt nachrüstbar.
https://github.com/fsprojects/Avalonia.FuncUI

Reines Code-Behind, was Du hier machst, mag Avalonia aber nicht.

26.05.2023 - 15:40 Uhr

Okay, dann gern nochmal ganz von vorn:

  • Alle Format-Angaben sollten mit Parameter verwendet werden; wird kein Parameter angeben, dann wird die Thread Culture verwendet
  • Die Thread-Culture kannst Du aktiv setzen; setzt Du sie aktiv nicht, dann wird die Betriebssystem-Culture verwendet. Wird Deine app.config Setting nicht übernommen, dann hast was falsch gemacht.
  • Die Betriebssystem-Culture unter Windows ist die Regionseinstellung - nicht die Sprache
  • Die Regionseinstellung hat angaben für Formate, Währungen und Co

Change the Windows regional settings to modify the appearance of some data types

Die Trennung von Sprache und Region gilt für jede Art von Lokalisierung und für jede Runtime. Ansonsten wären Standards wie "en-us" oder "de-de" bzw "de-at" nicht möglich.

26.05.2023 - 15:04 Uhr

Ist mir schon klar - aber DateTimeOffset hilft Dir a) beim sicheren Anpassen der Zeitzone und b) bei der Formatierung durch die entsprechenden Parameter.

Default-Format ergibt sich immer aus der Thread.Culture, wenn nichts angegeben wird.
Daher hab ichs Dir geschickt.

26.05.2023 - 14:47 Uhr

Server sollten immer nach UTC eingestellt sein und die Anwendung ist verantwortlich das in die Zeitzone des Besuchers anzupassen.
Dafür gibts DateTimeOffset mit den entsprechenden Cultures.

[FAQ] DateTime vs. DateTimeOffset und der Umgang mit Zeiten in .NET
Manuell anzupassen - aber nicht zu empfehlen - in allen .NET Runtimes über die Thread.Culture - inkl. potentiellen Nebenwirkungen.
Der einzig korrekte Weg ist die Angabe der Parameter, weil nur das auch mit externen Libs etc skaliert.

25.05.2023 - 10:15 Uhr

Sowas geht, auch wenns nicht wirklich empfohlen ist - vor allem nicht auf externe Verzeichnisse, über assemblyBinding und probing

Siehe Verweis auf DLL im kompilierte Projekt in ein Unterverzeichnis bringen

Gibt aber ein paar seltene Szenarien, wo das derzeit nicht unterstützt wird.
probing privatePath="..." doesn't work in .Net 5.0

Edit: interessant, ich dachte hier würden mittlerweile auch vollständige Pfade funktionieren.

24.05.2023 - 22:29 Uhr

Fixed. Danke.

24.05.2023 - 20:13 Uhr

Siehe ! (null-forgiving) operator (C# reference)

Hilft Dir qualitativ besseren und stabileren Code mit einer OOP-Sprache zu schreiben, in dem Du Code so schreibst, dass Du es nicht brauchst 😃

24.05.2023 - 17:32 Uhr

Mein Fehler - das kann so gar nicht klappen. Hab auch gesehen, dass mein Publish nicht korrekt war.
Daher gings bei mir.

Kurz nachgelesen: Du musst Deine Serialisierung als Source Code Generator wählen, ansonsten funktioniert NativeAoT nicht, weil sonst Reflection.
Siehe Docs dazu: Specify source generation mode 
Siehe GitHub dazu: [Native-AOT] Using Json Serialize and Deserialize with Native AOT

24.05.2023 - 17:22 Uhr

Ne, hab ich nicht. Ist drin.
Wüsste jetzt nicht, was ich sonst für ein Setting vergessen hätte.

Auch die Exe als Release-Exe ohne Debugging/VS funktioniert einwandfrei.

24.05.2023 - 17:06 Uhr

Funktioniert einwandfrei.

    public class WeatherForecast
    {
        public WeatherForecast() { }
        public WeatherForecast(DateTimeOffset date, int temperatureCelsius, string? summary)
        {
            Date = date;
            TemperatureCelsius = temperatureCelsius;
            Summary = summary;
        }

        public DateTimeOffset Date { get; set; }
        public int TemperatureCelsius { get; set; }
        public string? Summary { get; set; }
    }

    internal class Program
    {
        static void Main(string[] args)
        {
            WeatherForecast weatherForecast = new(DateTime.Parse("2019-08-01"), 25, "Hot");

            string jsonString = JsonSerializer.Serialize(weatherForecast);
            Console.WriteLine("Object as Json: " + jsonString);

            byte[] byteArray = Encoding.UTF8.GetBytes(jsonString);
            
            string restoredJsonString = Encoding.UTF8.GetString(byteArray);
            Console.WriteLine("Restored Json: " + restoredJsonString);

            WeatherForecast restoredWeatherForecast = JsonSerializer.Deserialize<WeatherForecast>(restoredJsonString);
            Console.WriteLine("From Deserialized " + restoredWeatherForecast.Summary);
        }
    }

Console Output:

Object as Json: {"Date":"2019-08-01T00:00:00+02:00","TemperatureCelsius":25,"Summary":"Hot"}
Restored Json: {"Date":"2019-08-01T00:00:00+02:00","TemperatureCelsius":25,"Summary":"Hot"}
From Deserialized Hot

C:\source\temp\ConsoleApp13\ConsoleApp13\bin\Debug\net8.0\ConsoleApp13.exe (process 126296) exited with code 0.
24.05.2023 - 15:50 Uhr

Und Fehlermeldungen vielleicht lesen. Da steht das Problem - und die Lösung - ja drin.

System.NotSupportedException: Deserialization of types without a parameterless constructor, a singular parameterized constructor, or a parameterized constructor
24.05.2023 - 11:02 Uhr

Ändert an der Situation ja nichts.

Davon abgesehen wird dem Windows Team herzlich egal sein wie das .NET Team die Version als Objekt implementiert hat.

22.05.2023 - 22:23 Uhr

Die BuildId ist das einzig Konstante in der Windows Versionierung.

  • Windows 11 >20000
  • Windows 10 >10000
  • Windows 8.1 >9000
  • Windows XP >3000

Major und Minor sind bei Windows schon immer (wie bei der meisten Software) Marketing-Versionen.
Windows hält sich hier inhaltlich nicht an SemVer. BuildId wird aber mit jedem CI-Build unique erzeugt.

Glaskugelraten: sehr wahrscheinlich wird Windows 12 nicht mit 30xxx anfangen, da an Windows viel mehr und schneller gearbeitet wird.
Wird also vermutlich ein anderer Range werden; wer weiß, vielleicht bei 100xxx oder sowas.

Version 10.0.x kann übrigens sowohl Windows 10 sein wie auch Windows Server 2016 bzw. 2019.

22.05.2023 - 14:56 Uhr

Noch besser

int buildNo = Environment.OSVersion.Version.Build
22.05.2023 - 13:39 Uhr

Dazu gibst tausende von verschiedener Möglichkeiten.

Siehe Google Suche nach .NET detect windows Version

Und ja, die Buildnummern muss man immer beachten.

20.05.2023 - 16:23 Uhr

Bedenke, dass Rechnungen als PDF/A exportiert werden müssen - das kann nicht jede PDF-Bibliothek.
IronPDF unterstützt PDF/A daher auch erst in den neueren Versionen, in denen sie auf die Chrom Render Engine gewechselt sind.

19.05.2023 - 19:35 Uhr

Ganz grobe Hilfe: Aliase werden nicht bei allen Projekten unterstützt. Zum Beispiel gibts irgendein Grund, wieso das bei Projekten, die XAML-Dateien haben, nicht funktioniert.
Aber welche Projekte das genau war, weiß ich nicht mehr.

17.05.2023 - 16:16 Uhr

Irgendwas ist wohl mit Deinen Dev Certs passiert.

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-dev-certs

dotnet dev-certs https --trust erstellt sie neu.

17.05.2023 - 16:14 Uhr

Weil Du vermutlich nur die Mappe (Solution) erzeugt hast, und nicht das Projekt.

16.05.2023 - 12:36 Uhr

Jaja, das leiden mit dem ASP.NET Core Identity, sobald man die Standard-Implementierung nicht mehr verwenden will 😃
Das Forum hier leidet auch darunter - und bin froh, wenn Identity rausgeschmissen ist.

Aber Dein Vorgehen ist korrekt: Du musst alles überschreiben und selbst implementieren.
Wenn Du es ganz korrekt machen willst bedeutet es jegliches Customizing automatisch, dass Du alle "*Manager"-Klassen selbst implementieren musst - leider.

16.05.2023 - 10:25 Uhr

Also ich find die Idee gut und auch der Aufbau vom Projekt gefällt mir im Großen und Ganzen.

Was mir nicht ganz gefällt ist, dass die Prüfung im Build erfolgt.
Das "verschlechtert" meine Developer Experience, weil es länger braucht.

Ich/wir verwenden so eine Prüfung zB mit Hilfe von WhiteSource - erfolgt also auf dem CI/CD System; nicht lokal.

Idee: mach das Ding als .NET Tool, das man als CLI einbinden kann. Das ist ein weit verbreitetes Vorgehen, zB bei OpenAPI, Swagger, NBGV...
Das .NET Tool kann dann als MSBuild Task eingehängt werden; hier Beispiel für Swashbuckle CLI.

<Target Name="OpenAPI" AfterTargets="Build" Condition="$(Configuration)=='Debug'">
    <Exec Command="dotnet swagger tofile --output ./wwwroot/openapi/v1/openapi.yaml --yaml $(OutputPath)$(AssemblyName).dll v1" 
          WorkingDirectory="$(ProjectDir)" />
    <Exec Command="dotnet swagger tofile --output ./wwwroot/openapi/v1/openapi.json $(OutputPath)$(AssemblyName).dll v1"
          WorkingDirectory="$(ProjectDir)" />
</Target>

Das würde dann sowohl im CI (CLI halt als Task ausführen) aber auch lokal/während des Builds.

12.05.2023 - 16:37 Uhr

Dann scheinen trotzdem Deine Exception Settings (oder was anderes) komisch zu sein, weil - obwohl die Blazor Developer Experience mit Exceptions nicht wirklich gut ist - NullRefenceExceptions, was dann hier wohl der Fall ist, trotzdem geworfen und in VS gefangen werden.

Weiterhin:

Entitäten haben in der API nichts zu suchen. Man exposed niemals die Struktur seiner Datenbank 1:1 in Form von Modellen nach Außen.
Damit verbaust Du Dir jede Möglichkeit der Anpassbarkeit ⇒ https://mycsharp.de/forum/threads/111860/artikel-drei-schichten-architektur

List macht hier kein Sinn; bei Entity Framework verwendet man zum initialiseren das HashSet.
Eine Relation kann schließlich nicht als Referenz doppelt existieren. Siehe dazu EF Core Basic Docs.

12.05.2023 - 11:06 Uhr

Das Modul ist optimiert, und die Debugoption "Nur eigenen Code" ist aktiviert.

Mach mal die Exceptions an für den gesamten Code.
Hilft uns vielleicht mehr, die echte Exception zu können - so sehen wir halt nur den unterdrückten Fehler; nicht die Exception.

09.05.2023 - 10:44 Uhr

Ich persönlich würde so ein Feature auf Platz 1 meiner meist gewünschten Features schreiben 😃

Es ist tatsächlich "nur" auf Platz 3 - weil es auch Bausteine hinter den Kulissen gibt, die vielleicht nicht bekannt sind 😃 Betriebsrelevante Themen gehen einfach vor.
Problem ist auch, dass es für den ckeditor 5 keine fertige Client-seitige Lösung dafür gibt.

Wenn sich das also jemand anschauen will, wie das mit ckeditor 5 funktioniert - zB über den Browser Local Storage: sehr gern.

06.05.2023 - 13:36 Uhr

Nur so als Relation, als Feedback: die Größe eines Projektes ist eine relative Ansicht. Was Du als "riesen Groß" bewertest, können andere als einfaches Wochenendtool empfinden.
Das Forum hier wird nebenher entwickelt, hat trotzdem mittlerweile weit über 1000h Entwicklungszeit - würde ich aber trotzdem anhand der Code-Base nicht als "riesig" oder gar "groß" empfinden 😉
Und wo wir schon dabei sind: auch Zeit ist relativ, je nachdem welchen Wissenstand die Leute bei der Entwicklung von Code hatten.

Daher kann man Dir nur rein sachlich antworten: Ja, MVVM macht immer sinn. Ja das lohnt sich immer.
Technische Schulden bremsen ausnahmslos immer ein Projekt aus, sodass es allein rein rechnerisch immer einen Punkt gibt, ab wann der sich lohnt. Das kann man aber nicht pauschal sagen, sondern hängt vom Code und von den beteiligten Personen ab.

02.05.2023 - 21:51 Uhr

Hmm, ich finde leider bei den Links nichts, was mir helfen kann.

Model Binding in ASP.NET Core - haste das nicht gefunden, hast nicht gesucht. Steht direkt in den Docs von ASP.NET Core.

Es gibt unterschiedliche Binding-Arten in ASP.NET Core und das API Binding basiert zu 100% auf Modellen und Attributs-basiert. Im Falle von ApiControllern war das IIRC schon immer so. Wenn man natürlich Formdata-Controller für die API missbraucht hat: jo, das tut jetzt weh.

Es gibt hier auch kein Setting, das das ändert, weil das Binding so funktionieren muss, um gewisse Szenarien unterstützen zu können.
Steht alles in den Binding Docs. Und die Docs sind super wichtig, weil wenn man die nicht liest, wird man unendlich viel Zeit verbrennen, weil man das Binding und die Reihenfolgen des Bindings nie verstehen wird.

02.05.2023 - 15:32 Uhr

Auch wenns vielleicht funktionieren mag, aber damit untergräbst die Idee von Middlewares in ASP.NET Core.
Dadurch hast Seiteneffekte und zB das Testen wird komplexer.

ASP.NET Core hat zb eine DSGVO-konformes Cookie-Behavior direkt integriert, wozu was eigenes machen, das evtl. nicht konform ist.
Integrierte Services von ASP.NET Core verwenden auch das integrierte Cookie Behavior.

Für das ganze Zeug, Canonical etc... würde man einfach die Templating-Funktion von Razor verwenden.
Das heisst, dass das in den Views definiert wird, nicht in den Actions.

Beispiel des Forencodes:

// Layout.cshtml
    @if (ViewData.TryGetCanonicalUrl(out var canonicalUrl))
    {
        <link rel="canonical" href="@(canonicalUrl)" />
    }
    
// MyView.cshtml
var currentUrl = Router.ToForumThreadView(thread.Id, thread.Topic, currentPage);
ViewData.AddCanonicalUrl(currentUrl, Context);

Und damit brauchst den ganzen Overhead-Krams nicht.
Kann so einfach sein, wenn man die eingebauten Funktionen von ASP einfach verwendet.

30.04.2023 - 15:12 Uhr

Zitat von Christoph K.

Dies geht ja nun nicht mehr, und mann muss alle Parameter in einer Klasse kapseln und dann in Form eines Parameters + dem Attribute [FromBody] in die Parameterliste schreiben.

Nö, muss man nicht.

Der einzige Breaking Change existiert, wenn man versucht den ApiControllerfür Forms zu verwenden oder den Controllerfür Json-basierte Requests. Das wurde aber schon vor über 7 Jahren announced.

Blick in die Doku hilft übrigens sehr:
Upgrade from ASP.NET Framework to ASP.NET Core

28.04.2023 - 10:13 Uhr

Es gibt in den neuen Templates keine Controller für Identity mehr, weil alles (leider) über Razor Pages funktioniert.
Siehe Docs: Scaffold Identity in ASP.NET Core projects
Willst nen Controller, musst das alles selbst machen, was weiterhin geht. Aber die Templates nutzen halt kein MVC mehr. 
Templates sind aber halt auch immer nur Beispiele - niemand zwingt Dich das zu nutzen, wenn es für Dich nicht passt. Schreib die Controller einfach selbst.

Solltest unbedingt mal die ASP.NET Core Docs überfliegen, bevor Du migrierst. Ansonsten werden sehr viele Stellen schwierig für Dich nachzuvollziehen.

26.04.2023 - 20:40 Uhr

Um ne zweite Antwort zu haben.

Zitat von Palladin007

Was haltet ihr von dieser Lösung?

Nicht viel 😉

Dem, sowie dem Rest, stimm ich zu.

26.04.2023 - 13:43 Uhr

Das hat mit Markdown nichts zutun; es ist quasi die gleiche RichText Experience, wie Du sie in Office Tools wie Word, Outlook hast:

  • Link einfügen
  • Leerzeichen oder Enter damit automatisch ein Link draus wird
  • Irgendwo in den Link klicken oder markieren
  • Text einfügen, woraus der Titel wird

Das Link-Bearbeiten / Entfernen beim Draufklicken ist dazu da, dass Du den Link selbst unabhängig vom Titel ändern kannst; quasi wie eben in Word.

Es gibt kein extra Textfeld für den Titel.

26.04.2023 - 10:36 Uhr

Ist mir schon klar. Ich geh jedoch weiter davon aus, dass Deine Batch so in der Wix ungültig ist.
zB weil %msiopts% oder %cd% oder was anderes zwar in Deiner Shell lokal existiert, aber nicht über Wix. Dadurch verschiebt sich der Parameterscope und der Befehl wird als ungültig erkannt → das Prompt kommt.

26.04.2023 - 10:28 Uhr

Zitat von Th69

Dazu ist mir auch aufgefallen. daß bei dem Link-Button (bzw. Ctrl+K) nur der Link abgefragt wird, aber kein Titel (und daher benutze ich bevorzugt den Markdown-Modus, da man dort explizit [Titel](Link)angeben kann).

Das ist "Absicht". Idee ist: Hürde so klein machen wie möglich, weil wir keine Lust mehr haben Posts editieren zu müssen.
Daher kann man Adressen einfach einfügen und sie werden automatisch zu Links. Du kannst den Link dann einfach markieren und einen eigenen Titel vergeben.

Dass aus dem Link automatisch der Titel gesetzt wird, das ist noch auf der Todo.

26.04.2023 - 10:13 Uhr

Habt Ihr Ideen/Vorschläge die diesen Sachverhalten erklären

Deine Parameter werden nicht erkennt oder sind ungültig. Wenn Du sagst, dass das manuell funktioniert, dann scheint es offenbar so zu sein, dass Deine Parameter anders angegeben werden müssen.

Google ich kurz https://www.google.com/search?q=wix+execute+msi+with+parameters sieht man dutzende Samples, die das MSI direkt in der XML-Datei hinterlegen und dabei MsiProperty-Elemente verwenden.

https://stackoverflow.com/questions/14762617/wix-bootstrapper-how-do-i-set-burn-variables-from-the-command-line

25.04.2023 - 15:57 Uhr

Deine Blazor-Anwendung läuft lokal, auf dem die Excel Datei offen ist?
Dann ist das evtl. ein Seiteneffekt, dass die Datei "lokal" verarbeitet wird.

25.04.2023 - 15:48 Uhr

Grundregel für jede Art von File Upload: niemals im Speicher verarbeiten, sondern im Stream.
Verwendest Du den MemoryStream und damit den RAM, ist das ein potentieller Angriffspunkt für DOS - es skaliert einfach nicht.

Zum Problem: ist die Datei größer als der IIS unterstützt bzw. Deine aktuelle Web.Config (aktiv oder passiv) erlaubt?

Dein HResult ist ein allgemeiner Fehler, kein Fehlercode.
Daher für die Einschränkung ungeeignet. Im Endeffekt heisst das sowas wie ein "Any Error Occured".

24.04.2023 - 07:59 Uhr

Das ist mit den Themen ist so bewusst.
Das war früher begrenzt auf einen Zeitraum; ist in den neuen Ansichten quasi nur eine andere Sortierung. Ist das schlimm?

Das mit dem Layout: das ist halt leider immer so ne Sache.
Die einen bevorzugen das, die anderen das - und dann gibts da immer auch noch Google und Co, die einen punishen, wenn man X verwendet.
Das zentrierte Layout ist die "übliche Empfehlung" heutzutage, weswegen das auch viele andere Seiten verwendet; als Beispiel hier auch Stackoverflow.

Wir müssen einfach ausprobieren, was besser ist.
Über die Gestaltung einzelner Elemente lässt sich sicher streiten und lässt sich sicher auch noch verbessern.
Aber bin auch leider kein UI Designer und bin auf Framework-Bausteine und Feedback angewiesen 😃

13.04.2023 - 13:42 Uhr

Der Fehler ist ein Sammelfehler. Die wichtigsten Punkte sind:

Sig[0].Name=Problemsignatur 01
Sig[0].Value=Service99.exe
Sig[1].Name=Problemsignatur 02
Sig[1].Value=1.0.0.7
Sig[2].Name=Problemsignatur 03
Sig[2].Value=642c0df6
Sig[3].Name=Problemsignatur 04
Sig[3].Value=System.Core
Sig[4].Name=Problemsignatur 05
Sig[4].Value=4.8.4515.0
Sig[5].Name=Problemsignatur 06
Sig[5].Value=624cf626
Sig[6].Name=Problemsignatur 07
Sig[6].Value=451
Sig[7].Name=Problemsignatur 08
Sig[7].Value=245
Sig[8].Name=Problemsignatur 09
Sig[8].Value=System.IO.IOException

Problemsignatur 01 = Die App, die den Fehler auslöst.
Problemsignatur 09 = Die Exception

Leider hast Du es versäumt die letzten - gefühlt 50 - Jahre die App zu aktualisieren; denn in neueren Runtime-Versionen gibts mehr Infos.
In diesem Fall müsstest Du jetzt mit dem ILViewer durchgehen und schauen, was Methoden am Offset 245 und 415 sind und kannst dann schauen, was fehlt.

Aus Erfahrung ist das entweder ein Folgefehler weil in der Registry (GAC) was kaputt ist, oder es fehlt eine Abhängigkeit, oder eine Abhängigkeit von der Abhängigkeit.... etc

Einfacher kann man das herausfinden, wenn man in der Anwendung AppDomain.UnhandledException abonniert und schaut, was los ist.
Soviel mal zur Erklärung des Eintrags.

Diese Informationen laufen unaufhörlich weiter auf, auch bei beendetem Dienst und sogar nachdem ich den Dienst deinstalliert habe. Das verstehe ich überhaupt nicht.

Macht kein Sinn, daher kann das auch nicht sein. Der EventLog erfindet nichts.
Dann wirst irgendwas übersehen haben.

13.04.2023 - 10:37 Uhr

@Th69 wir haben leider noch kein Weg gefunden, das stabil in den neuen CKEditor5 zu integrieren.

Vorschau ist ja im Richtext-Editor integriert. Einfach wieder umschalten.