Oder einfach Publish to Folder
Die UI dafür ist einfach und "Self Contained Deployment" ist da nur eine Checkbox.

Die ganz Faulen, die einfach nur für sich ein Tool basteln wollen, können dort auch einfach direkt den richtigen Ziel-Ordner einstellen, wo dann z.B. ein Startmenü-Link hin zeigt.

Ich verstehe aber nicht wieso ich dieses Problem mit VB in .Net nie gehabt habe.

Vielleicht ein anderes Framework?
.NET Core/5/6 sind etwas ganz anderes, als .NET 4 (meist wird es ".NET Framework" ausgeschrieben) oder älter, auch wenn es gleich klingt.
Mit .NET Core/5/6 hat sich einiges zum alten System geändert.

Wieso ist das eine schlechte Idee und Pfusch? Das ist doch eine einfache Variante sich die Tools direkt irgendwo hin zu kopieren...

Wenn Du nur für privat arbeitet, reicht der Pfusch meistens auch völlig aus, sind halt ein paar Klicks mehr.
Produktiv kann sich der Publish-Prozess aber schon mal vom simplen F5 unterscheiden, das müsstest Du immer manuell machen und da versteckt sich der Pfusch.
Außerdem sollten fertig auslieferbare Versionen immer ein Release-Build sein.

Ich werde mir das "ILmerge" mal ansehen, guter Tipp.

Ist kein guter Tipp, sondern nur ein "So hat man's früher gemacht".
Heute solltest Du Self Contained Deployments nutzen, ist sowieso viel einfacher.

Macht das Eig. einen Unterschied dabei ob ich.Net oder .Net Core nehme [FAQ] Das .NET Ökosystem - .NET, .NET Core, .NET Standard, NuGet und Co
Lesen und verstehen, da führt heutzutage kein Weg dran vorbei, außer Du magst Felsen im Weg 😉

Ein Teil des Projektes ist ein ASP.net MVC 3.0 Projekt. Ist eine einfache Migration hier überhaupt machbar?

Nein - zumindest nicht einfach.

Ich hab's mal geschafft, das alte ASP.NET unter .NET Core 3 ans Laufen zu bringen, aber einfach ist das nicht und langfristig klug ganz sicher auch nicht ^^
Auch eine Neuentwicklung unter ASP.NET Core ist nicht "mal eben so" machbar, mit genügend KnowHow zu beiden Frameworks, dem Projekt und einer halbwegs vernünftige Architektur ist das aber überschaubar.

Der Artikel zur Migration zu ASP.NET Core geht (beim rüber scrollen) hauptsächlich nur auf die Unterschiede auf die Frameworks ein. Das ist sicher nützlich, ich würde das Projekt aber vorher vorbereiten, die ASP.NET Core Umstellung ist dann nur der letzte Schritt.

Schau dir an, wie ASP.NET Core arbeitet und wie man die Geschäftslogik aus den Controllern raus hält, sodass die dann eigentlich nur noch Endpunkte sind.
Abt hat zu der Architektur von diesem Forum einiges geschrieben: [Artikel] Die myCSharp.de Software Architektur
Ob das bei Euch auch angebracht oder Overkill ist, weiß ich nicht, aber aber ich will darauf hinaus, dass Controller und Logik nichts miteinander zu tun haben. Der Controller sollte seine Abhängigkeiten per DependencyInjection bekommen und die Abhängigkeit sollte nichts von ASP.NET benötigen.

Das gemacht kannst Du den ausgelagerten Code auf .NET Standard 2.0 umstellen, das wird in .NET 4.7 und .NET 6 unterstützt.
Ich habe das bisher manuell gemacht, aber dafür gibt's meines Wissens nach auch ein Tool von Microsoft.
Eventuell habt Ihr Abhängigkeiten die es nicht für .NET Standard 2.0 gibt, da müsst Ihr dann natürlich Alternativen suchen.

Als nächstes schau dir die "Microsoft.Extensions.***"-Frameworks an, die werden in ASP.NET Core genutzt und sind (wenn ich mich nicht irre) alle .NET Standard 2.0.
Außerdem können diese Frameworks (Logging, DependencyInjection, Configuration) als Abstraktion dienen und viele altbekannte Frameworks aus der Community unterstützen das.
Das Hosting-Framework lässt Du aus, das ist eine Start-Infrastruktur, die wirst Du so ohne Weiteres nicht umstellen können - nicht solange ASP.NET noch an Board ist.
Wenn alles darauf aufbaut, kann ASP.NET Core direkt damit umgehen.

Es bleibt noch das ASP.NET-Projekt (es sollte an dem Punkt nur noch ein Projekt sein) und das müsst Ihr neu entwickeln, doch mit den Vorbereitungen sollte das überschaubar sein.
Und von .NET Standard 2.0 zu .NET 6 ist es dann nur noch ein Katzensprung, ggf. einige Packages aktualisieren.

Danach könnt Ihr dann Stück für Stück ältere, wenn auch noch unterstützte, Frameworks ersetzen, ich denke da z.B. an Newtonsoft.Json vs. System.Text.Json.

Das hatte damals den wundervollen Namen "WebView2" - such einfach mal danach.

Aber die Runtime muss installiert sein, oder man legt einen eigenen Pfad fest, wo man sie dann aber auch selber hin bringen muss.
Ob die Runtime wirklich immer beim Windows dabei ist, weiß ich nicht, müsste aber in der Doku dazu stehen. Eventuell häng das auch von den Einstellungen bei der Installation ab und Desktop vs. Server.

Eventuell sieht das mittlerweile auch anders aus.
Wäre cool, wenn man die Runtime als normales Package (noch mehr Dateien) mit liefert kann bzw. die Option dazu hat.

Ganz einfach 😉

<Window.DataContext>
    <local:MainViewModel />
</Window.DataContext>
    
<DockPanel LastChildFill="True">
    <Button DockPanel.Dock="Top" Content="Fill data" Command="{Binding FillDataCommand}" HorizontalAlignment="Left" />
    <DataGrid ItemsSource="{Binding Data.DefaultView}" AutoGenerateColumns="True" />
</DockPanel>

public class MainViewModel : INotifyPropertyChanged
{
    private DataTable? _data;

    public event PropertyChangedEventHandler? PropertyChanged;

    public DataTable? Data
    {
        get => _data;
        private set
        {
            _data = value;
            NotifyPropertyChanged();
        }
    }

    public ICommand FillDataCommand { get; }

    public MainViewModel()
    {
        FillDataCommand = new FillDataCommandImpl(this);
    }

    private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }

    private class FillDataCommandImpl : ICommand
    {
        private readonly MainViewModel _owner;

        public event EventHandler? CanExecuteChanged;

        public FillDataCommandImpl(MainViewModel owner)
        {
            _owner = owner;
        }

        public bool CanExecute(object? parameter)
            => _owner.Data is null;

        public void Execute(object? parameter)
        {
            _owner.Data = CreateDataTable();

            CanExecuteChanged?.Invoke(this, EventArgs.Empty);
        }

        private static DataTable CreateDataTable()
        {
            var dataTable = new DataTable();

            for (int c = 0; c < 10; c++)
                dataTable.Columns.Add($"Column {c:00}");

            for (int r = 0; r < 1000; r++)
            {
                var row = dataTable.NewRow();

                for (int c = 0; c < 10; c++)
                    row[c] = $"Value {c:00}-{r:0000}";

                dataTable.Rows.Add(row);
            }

            return dataTable;
        }
    }
}

Aber das ist definitiv kein guter Code, nur das, was ich in 10 Minuten so hin gezimmert habe 😁

Wieso?
Viele Dateien sind nicht schlecht.
Seit .NET Core/5 ist es sogar mehr geworden, weil jetzt alles auf Packages setzt.

Aber die pdb-Dateien sind nicht notwendig, die helfen beim Debuggen.
Wenn Du die nicht willst, kannst Du die in den Eigenschaften unter "Debug symbols" abschalten.

Einige (nicht alle) der XMLs sind vermutlich Code-Dokumentationen.
Die kann man mit der MSBuild-Property "GenerateDocumentationFile" aktivieren, wie man sie bei bestehenden Packages abschalten kann, weiß ich nicht.
WENN es Code-Dokumentationen sind, kannst Du die auch einfach löschen.

Aber Du solltest es einfach lassen, wie es ist.
Die Dateien tun nicht weh und interessieren in 99% der Fälle keinen Anwender, solange es einen Link im Startmenü oder auf dem Desktop gibt.
Ein aktuelles Projekt von mir (unfertig und Debug-Build) besteht aus stolzen 313 Dateien.
Für ein Release kannst Du aber auch alles zusammen führen lassen, dafür gibt's beim Publish-Prozess ein paar Option oder Du liest dich ein, wie Du es manuell einstellst.

By the way:
Es gibt auch eine Edge-Engine, die wiederum auch Chromium basiert.
Die kann im Windows schon vorhanden sein, extra nachinstalliert werden oder man bringt seine Eigene mit und legt sie ab, wo man will.
Meine Arbeit damit war noch in der PreRelease-Zeit und da habe ich etwas gebraucht, bis ich die Kinderkrankheiten im Griff hatte (und mit dem nächsten Update ging's von vorne los), aber da es jetzt schon über ein Jahr alt ist, gehe ich stark davon aus, dass es gut funktioniert.
Und da Edge bei Windows mit kommt und ein sehr gutes Browser ist, würde ich persönlich darauf setzen.

Ach stimmt, die Methode gibt's ja auch 😁

Aber der Hinweis von Th69 gilt weiterhin.

Warum weist Du die DataTable direkt zu? Dafür gibt's DataBinding und WPF ohne MVVM macht keinen Spaß.
Bei Tasks solltest Du NIEMALS (außer Du weißt, was Du tust und hast einen guten Grund) direkt mit dem Result arbeiten.
Console.WriteLine? In WPF-Anwendungen gibt es keine Konsole. Wenn's da einen Fehler gibt, fällt dir der also nicht auf.
Die DataTable habe ich noch nie mit dem DataGrid zusammen genutzt, ich würde aber die DefaultView benutzen - ob eine Eigene ein Problem ist, weiß ich aber nicht.

Und ich würde auch keine DataTable nutzen, die unterstützt (meines Wissens nach) keine Live-Aktualisierung beim Binding und angepasste Columns stelle ich mir auch schwierig vor.

Der ISourceGenerator ist ein Auslaufmodell, weil er Performance so extrem schwer macht.
Aber ja, ist komplexer, doch sobald man begriffen hat, was das Konzept ist, geht's eigentlich ganz gut.

Mit dem CompilerVisibleProperty-Item kann man auch weitere Properties sichtbar machen.
Mit dem CompilerVisibleItemMetadata-Item geht das gleiche mit Items, allerdings ist das (noch?) auf "AdditionalFiles" begrenzt. Allerdings sind die Metadaten frei wählbar, man kann also alle beliebigen Items in die AdditionalFiles schreiben und anschließend mit passend definierten Metadaten unterscheiden. Mehr dazu hier, der Artikel ist nicht mehr aktuell, aber das Konzept ist ähnlich.

Guter Gedanke, zumindest erlaubt der zweite Parameter das Verstecken.
Müsste man aber mal testen, ob bereits sichtbare Fenster auf diese Weise versteckt werden können, hab ich bisher nie versucht.

Den Binding-Pfad "DataContext.UnitsModel.Instance" gibt es nicht.
"Instanz" ist static und kann nicht in Bindings genutzt werden.
An statische Quellen bindet man so:

{Binding MyProperty, Source={x:Status UnitsModel.Instance}}

Sauber oder klug ist das aber nicht, so verlierst Du früher oder später nur den Überblick, was wie worauf zugreift.
Am einfachsten ist, wenn ein Control an das Nächste den DataContext vererbt (passiert automatisch) oder ein untergeordnetes Objekt (klassisches Binding) setzt.

Es kommt vor, dass man (was Du eingangs gefragt hast) nicht mit dem aktuellen DataContext arbeiten kann.
Das ist kommt z.B. beim ItemsControl immer wieder vor, weil im ItemTemplate das Item als DataContext steht und nicht das ursprüngliche ViewModel, was alle Items hat.
Wenn Du nun z.B. an etwas vom ursprünglichen ViewModel binden willst, geht das mit einer RelativeSource, die das ItemsControl sucht.

Und warum setzt Du am Button erst den DataContext, wenn Du die andere Instanz nur an einer Stelle (Command) brauchst und an zwei anderen Stellen nicht?
Pass das Command-Binding so an, dass es das richtige ViewModel sucht und lass den DataContext, wie er ist.
Im Trigger hast Du dann den DataContext, den der Button hat und der hat den DataContext, den dein StackPanel hat und so weiter.

Du kannst ein Window-Handle suchen und dann mit der WinApi schließen.
Die Process-Klasse teilt dir meine ich den MainWindow-Handle mit. Alternativ bietet die WinApi natürlich auch passende Funktionen an.
Und zum Schließen gibt's in der WinApi die CloseWindow-Funktion.

Für einen Anfänger ist das aber vermutlich etwas to much 😉

... wobei ich beim letzten Punkt keine Liste, sondern wieder ein Dictionary nehmen würde, mit dem Enum als Key.
Bei der Umsetzung mit der Liste sind Reihenfolge (und damit Werte) im Enum direkt von der Reihenfolge der Listeneinträge ab - also eine Sollbruchstelle, wenn man mal nicht aufpasst.

Hier sollte ein Umstieg auf eine Version ≥ 4.6.2 gemacht werden, falls diese noch zum Einsatz kommen.
Vermutlich wäre der direkte Sprung nach 4.8 am sinnvollsten.

Das sowieso ^^
Aber wenn es hier um XP geht, hat der TE wohl keine Wahl.

Wenn der TE aber auf Windows XP Support setzt, dann dürfte alles > 4.0 nicht mal supportet werden.

In dem Fall fliegt dann .NET Standard wohl ganz raus, Version 1.0 braucht min. .NET 4.5
Die Tabelle dazu: .NET-Standard

Dann bleiben nur noch Shared Projects und bedingte Kompilierung.
Vieles der beiden Frameworks sind - auf die Namen und den Code bezogen - ja gleich, wie gut/einfach das funktioniert, hängt dann davon ab, wie viele spezifische Funktionen genutzt werden.

Ich weiß nicht, wie die .NET 4.6.1-Unterstützung auf XP aussieht, aber 4.6.1 unterstützt .NET Standard 2.0
Dann kannst Du die Legacy-Lösung mit .NET Framework >4.6.1 anbieten und für den Rest .NET 6, alle Gemeinsamkeiten sind mit .NET Standard 2.0 umgesetzt.
Für aufwändigeren Code, der nicht so einfach in .NET Standard 2.0 geht, kannst Du mit bedingter Kompilierung arbeiten - das ist umständlich aber möglich.
Einige Frameworks machen das auch so (oder haben es so gemacht): Eine Code-Basis (z.B. als Shared Project) und dann diverse Bedingungen, welcher Code kompiliert werden soll und welcher nicht. Für .NET 4.6.1 und 6 gibt's dann zwei verschiedene Projekte, die das einbinden und die Bedingungen einstellen.

Das wäre wohl der aufwändigste Weg, aber so kannst Du in beiden Welten tanzen.

Es gibt Programme, die WPF-Anwendungen von "außen" untersuchen und live bearbeiten können.
Früher habe ich dafür den WPF Inspector genutzt, aber den gibt's leider nicht mehr.
Vor kurzem habe ich stattdessen SnoopWpf verwendet und das hat sehr gut funktioniert.

Schau dir mal den Source an, da kannst Du dir sicher einige Tricks abschauen.
Aber ich vermute mal, dass das eine ziemlich komplizierte Angelegenheit werden kann.
Oder das Tool bietet eine API, das habe ich mir nicht angeschaut.

Ich denke, ich habe gefunden, was Du suchst.

Nutz den IIncrementalGenerator und nicht den ISourceGenerator.
Den Hauptgrund für dessen Existenz und eine grobe Einführung kannst Du hier nachlesen.
Die Nutzung ist deutlich anders, im Vergleich zur ersten Variante, aber da findest Du dich schon rein 🙂
Ob es das Gleiche auch in der ersten Variante gibt, weiß ich nicht, aber aus den im Artikel beschriebenen Gründen sollte man den sowieso nicht mehr benutzen.

Mir geht's um den AnalyzerConfigOptionsProvider bzw. die GlobalOptions, denn die liefern mir unter Anderem auch folgenden Eintrag:

build_property.rootnamespace = ConsoleApp1

Damit solltest Du haben, was Du suchst 🙂

Du kannst jeden DataContext setzen, den Du setzen willst, aber irgendwie musst Du den ja auch finden.
Der einfachste Weg ist, dass ein MainViewModel Referenzen zu den einzelnen Dialogen/Bestandteilen hat und die haben Referenzen zu den Details, die sie benötigen.

Im Style arbeitest Du jedenfalls immer gegen den DataContext, den auch das Ziel-Objekt (der Button) hat.
Wenn Du da einen anderen DataContext brauchst, dann setze am Button selber einen anderen oder keinen DataContext.
Oder Du setzt ein Binding, in dem Du mit Hilfe einer RelativeSource ein anderes Control (im VisualTree hoch suchen, z.B. das StackPanel) suchst und dann direkt an den DataContext davon bindest.

{Binding DataContext.MyProperty, RelativeSource={RelativeSource AncestorType=StackPanel}}

Normalerweise ist das nicht notwendig, das macht man nur, wenn man aus irgendeinem Grund einen anderen DataContext hat, das aber nicht ändern kann.

Ich sehe so auf Anhieb keinen groben Fehler, außer dass ich so gar kein Fan vom (Service) Locator Pattern bin ^^

Sind die gezeigten Properties im MainVM, oder woanders?

Und schau mal in VisualStudio (ich nutze 2022), das hat ein "XAML Binding Failures"-Fenster. Alternativ sollten Binding-Fehler im Output landen.
Wenn das Binding scheitert, dann sollte das dort auftauchen.

Ach dafür ist das ThemeInfoAttribute da 😁
Das wird bei dem Template, das Du meinst, mit generiert:

using System.Windows;

[assembly: ThemeInfo(
    ResourceDictionaryLocation.None, //where theme specific resource dictionaries are located
                                     //(used if a resource is not found in the page,
                                     // or application resource dictionaries)
    ResourceDictionaryLocation.SourceAssembly //where the generic resource dictionary is located
                                              //(used if a resource is not found in the page,
                                              // app, or any theme specific resource dictionaries)
)]

Wieder was gelernt.

Ich persönlich habe noch nie eine "Generic.xaml" genutzt 😁
Also wenn es für diesen speziellen Namen irgendwelche Sonderregelungen gibt, weiß ich nichts davon.

Jedenfalls muss das ResourceDictionary bekannt sein, das geht entweder in der App.xaml für alles oder in der konkreten xaml, wo Du das Control nutzen willst.
Vermutlich fehlt dir einfach der passende Eintrag in der App.xaml, dass deine Generic.xaml auch gefunden wird.

Dazu muss dann natürlich auch der Key bekannt sein, das ist normalerweise für einen Default-Style einfach der Typ ({x:Type}) des Controls und im Control überschreibst Du dann den Wert der DefaultStyleKeyProperty.

Bei mir gibt's je Control ein eigenes ResourceDictionary, einfach um die Suche und Übersicht zu erleichtern.
Und damit die App.xaml nicht zu riesig wird, hat jede Assembly mit solchen Controls eine weitere xaml, wo alle ResourceDictionarys zusammengefasst werden - die wird dann in der App.xaml eingebunden.

Klingt irgendwie unsinnig, die Daten, die übertragen werden, bekommt doch sowieso nur der Client zu Gesicht
Oder gehen die Daten an einen anderen Client? Dann ergäbe das mehr Sinn.

Ja ist alles im C# ASP.NET Core Universum. Du meinst einen eigenen Serializer bauen? Der basierend auf einem Dictionary das korrekte Property raussucht und dann dem JObject hinzufügt?

Kein eigener Serializer, die können das doch alle ^^ Aber ja, zumindest so ungefähr, dein Beispiel sind ja ziemlich leicht analysierbar aus.
Der System.Text.Json.JsonSerializer kann auch zum JsonNode serialisieren, daraus kannst Du dann entfernen, was Du willst und vom Ergebnis den String erzeugen lassen.

Wie Du das in ASP.NET Core integrierst, musst Du dann schauen. Das einfachste wäre, Du gibst das JSON direkt als Content zurück.

Aber kann der Client nicht selber definieren, welche Daten er zurück bekommt?
Dann kann es auch ein potentieller Angreifer machen und die Daten abgreifen.
Aber wenn das wirklich ein Thema ist, sollte die Lösung erst abgesegnet werden.

Und wie Du die Rückgabedaten aufgebaut werden, hängt davon ab, wie ihr Aufbau festgelegt werden soll.
Suchen und zusammensammeln genauso wie sonst auch und beim Zurückgeben lässt Du das JSON nicht automatisch erzeugen, sondern machst es per Reflection selber, aber mit deinen Regeln. Bei Newtonsoft.Json ist das einfach, wie es bei System.Text.Json geht, weiß ich aber nicht.

Vorausgesetzt Du verwendest ein System, was sowas erlaubt, mit ASP.NET Core ist das jedenfalls kein Problem.

JSON - bau das JSON selbst zusammen, dann hast Du maximale Freiheiten

Aber warum eigentlich? Warum muss das Ergebnis so genau spezifiziert werden?
Überleg dir, welche Daten üblicherweise zusammen gehören und liefere die immer als Ganzes zurück, die Client kann sich ja das raus picken, was er braucht. Z.B. zum Hersteller bekommt der Client immer alle Hersteller-Daten und was er nicht braucht, ignoriert er.
Und wenn es zu groß oder komplex wird, pack IDs mit rein, worüber man die restlichen Daten abrufen kann, z.B. eine Hersteller-ID und ein GET-Endpunkt zum Abrufen der Hersteller-Daten.

Und auch die Client-UI sollte 0,nichts mit der Web-API zu tun haben, die liefert die Daten, die vom Server verwaltet oder berechnet werden und mehr nicht.
Wenn zu den Daten eine Größe gespeichert oder anhand der Daten berechnet wurde, ok, aber wenn sie z.B. nur durchgeschleift werden soll (z.B. UI-Eingabe, Client schickt sie mit und bekommt sie zurück), ist das vermutlich Murks.

Ist gewollt, dass der Forenbereich immer unter dem Titel steht?
Ich bilde mir irgendwie ein, dass es bis gestern noch anders war.

Außerdem ist das irgendwie überflüssig, immerhin steht's über der Liste auch nochmal.

Configure launch.json for C/C++ debugging in Visual Studio Code

Oder nutz VisualStudio, damit ist's wahrscheinlich etwas einfacher, läuft aber nur auf Windows und ist leistungshungriger.

Bist Du nicht.
Du bist dabei, eine Benutzeroberfläche mit komplexen Eingaben und Datenbank zu programmieren.
Das ist weit von den Grundlagen entfernt - klar, dass Du Schwierigkeiten hast.

gerade wenn man blutiger Neuling ist, dann sollte man Ratschläge auch annehmen und nicht einfach ignorieren.

Und das kannst du direkt aus DateTimePicker.Value übernehmen.
Schau dir mal die Doku an.
>

Der DateTimePicker kann von Haus aus leider kein DateTimeOffset (nur die von Drittherstellern).
Man muss daher manuell konvertieren

  
DateTimeOffset dateTimeOffset = new DateTimeOffset(dateTime);  
  

Alles aus diesem eher kleinen Thema hier
Soviel zum "kannst mir glaube ich suche mir die Finger Wund."

Vielleicht ist Faulheit nicht das richtige Wort, aber es geht zumindest in die Richtung, die ich meine.
Ich meine nicht, dass Du faul (im klassischen Sinne) bist, sondern dass es eben Arbeit braucht, sich diese Fähigkeit (von Theorie auf Praxis schließen) anzueignen, für Manche mehr als für Andere. Das braucht viel Zeit (Monate, vielleicht Jahre) <- Diese Arbeit meine ich, da steigen Viele vorschnell aus, mit der Begründung, sie können es nicht.
Denn auch wenn Du es nicht glauben magst: Jedes Gehirn (auch deins 😛) kann das lernen.

Also ja: Natürlich haben auch Andere Schwierigkeiten damit, das ist normal - Du bist also nicht alleine.
Aber in einem Forum wie Diesem, wo die antwortenden Menschen oft schon ein paar Jahre in diesem Bereich hinter sich haben, entsteht vielleicht der Eindruck, als wärst Du alleine.

Damit meine ich aber nicht, dass Du nur noch Doku lesen sollst.
Ich meine, dass Du professionell geschriebene Erklärungen verwenden sollst, z.B. Microsoft bietet neben der Doku auch eigene Tutorials an. Für die Grundlagen gibt's das auch in Videoform von CSharpFritz (von Microsoft), aber das ist nur ein kleiner Teil und Du solltest nicht darauf vertrauen, dass Du immer gute Videos findest - dem ist nicht so.
Und wenn Du mehr Praxis brauchst - schaffe dir deine eigene Praxis, probiere aus, was Du liest. Das braucht natürlich die Transferleistung von Theorie zur Praxis, aber irgendwo musst Du anfangen und das wird einfacher.
Und versuche nicht gleich ein ganzes Projekt aufzusetzen, sondern nur den Teil, der dich interessiert. Wenn Du wissen willst, wie ein Uhrwerk funktioniert, baust Du ja auch nicht ständig ganze Uhren, sondern nur das Uhrwerk. Genauso auch hier: Wenn Du DependencyInjection verstehen willst, dann brauchst Du keine Oberfläche mit Datenbank und Business-Logik. Persistente Daten brauchst Du nicht, für die Oberfläche reicht eine billige Test-Ausgabe und die Logik besteht z.B. daraus, dass Du per DependencyInjection einen hardcoded Text holst und ausgibst. Bei mir, wenn ich irgendetwas teste, sind's meist nur eine Sammlung von quasi leeren Klassen (+ Interfaces) und im Debugger will ich dann an der geplanten Stelle die richtige Instanz sehen.

ein klassischer Fall von "wollen", aber nicht" können"?

Sorry für die harten Worte, aber für mich klingt das eher nach "nicht eingestehen wollen, dass es die eigene Faulheit ist".

Du unterschätzt die Thematik gewaltig und das trotz deiner frustrierten Frage hier.
Professionelle Softwareentwicklung ist riesig und es gibt unfassbar viel, was man dazu wissen kann. Niemand kann alles wissen, aber es kommt immer mal vor, dass man aus diversen Gründen (Kunde will es) in eine andere Richtung schauen muss und dann stehst Du dumm da. Z.B. für das ASP.NET Identity findest Du ein QuickStart und die Doku (und ein bisschen Kleinkram) - die Doku ist dabei die mit Abstand wichtigste Quelle, die Du hast. Achso und natürlich die MSDN-Artikel.

Natürlich kannst Du auch alles an aktiven Projekten ausprobieren.
Das geht, allerdings wirst Du dann die gleichen Fragen stellen und Fehler machen, die in der Doku besprochen wurden und Du wirst viel, viel länger brauchen.
Also ja, es geht, aber Du wirst abgehängt werden - auch nicht gerade toll, oder?

Dieser Beruf lebt davon, dass die Leute ihre Erfahrungen austauschen, aber das findet eben hauptsächlich schriftlich statt.
Blogs von so Namen wie "Stephen Toub" (hat mir damals sehr geholfen, async/await zu begreifen) sind dabei wertvolle KnowHow-Quellen.
Oder fremde Projekte wie unser schönes Forum hier, wo ich sehnsüchtig darauf warte, im Quellcode blättern zu dürfen 🙁
Oder Abt oder gfoidl (und alle Anderen hier), die hier immer wieder an ihrer Erfahrung teilhaben lassen.
Aber ich bezweifle, dass einer davon Lust hat, jemand Fremdes etwas in Videoform (so ein Video ist eine Heidenarbeit) vorzukauen, was es schon längst in Schriftform gibt. Und selbst wenn Du jemanden findest, der das macht, hast Du wieder das Zeit-Problem: Die Produktion von solchen Videos dauert zu lange und Du wirst wieder abgehängt.

Wenn Du also wirklich ohne Doku auskommen willst, brauchst Du einen Trainer, da findest Du garantiert jemanden, der das gegen entsprechendes "Kleingeld" macht.
Dürfte auf Dauer aber ziemlich teuer werden und ich bezweifle, dass das eine Firma lange mit macht 😉

Für Datum und Zeit nutzt man im allgemeinen DateTimeOffset.

Oder seit .NET 6 auch DateOnly (Api-Docs) oder TimeOnly (Api-Docs) - je nachdem, was man braucht.

ASP.NET Core ist halt nicht nur "ein" Framework, hier arbeiten viele Frameworks zusammen, die alle Teil von ASP.NET Core sind und für die man sich Zeit nehmen sollte.
Z.B. ist DependencyInjection eines dieser Frameworks, das man nicht "einfach so" versteht, das braucht Zeit, Arbeit und eine gute Erklärung.
Dann noch die Konfiguration, auch ein eigenes Framework mit einem besonderen "Schicht-Ansatz".
Und EFCore ist gleich noch ein riesiger Brocken, den man nicht mal eben so abhandeln kann, das ist aber kein Teil von ASP.NET Core.
Und noch mehr.

Ganz ehrlich:
Dieses "praxisorientiert" wird gerne mit "Grundlagen überspringen" gleichgesetzt - das funktioniert aber nicht.
Schau dir die Prinzipien an, mit denen ASP.NET Core arbeitet und schau dir die Dokus zu den einzelnen Frameworks an. Die ASP.NET Core Doku verlinkt auf viele Andere, dazu dann noch EFCore, aber fang lieber erst mal klein an.
Und Bootstrap ist etwas komplett eigenständiges und wurde nur in den MVC-Templates verwendet.

Und sowas wie Frameworks-Versionen kann man im PackageManager oder in der Projektdatei nachlesen.

Und lass solche Tutorials weg.
Das erste Video, das ich gesehen habe (vielleicht sind die anderen ja besser) besteht größtenteils aus "Das kannst Du da machen und das geht dort" und nicht aus Erklärungen - und dann springt er auch noch von einem Framework zum Nächsten. Wundert mich nicht, dass Du da nur Fragezeichen siehst.
Abgesehen davon fand ich die eine oder andere Formulierung etwas ... ungünstig, z.B. ist .NET Core kein "ein bisschen reduziertes" .NET
By the way: Man kann auch einfach F5 drücken - anstatt STRG+F5 - warum auch immer er das vorschlägt. O.o

Klar, C# brauchst Du auf jeden Fall.
Aber Symfony und Laravel sind ein PHP-Frameworks 😉

Der Client liest also Daten und schaufelt sie in eine DB.
Die DB liegt hinter einer Web-API, mit der der Client reden muss.
Die Web-Anwendung mit der Web-API hostet gleichzeitig auch die Website.

Den Client würde ich mit WPF entwickeln, WinForms tut's aber auch - oder Du setzt auf das fast (nicht ganz) fertige MAUI oder irgendein anderes Drittanbieter-Framework.
Der Server wäre bei mir in jedem Fall ASP.NET Core, wie Du die Website umsetzt, kannst Du dir aussuchen - z.B. Balzor.
Die API kannst Du z.B. mit REST oder gRPC umsetzen, für die Kommunikation vom Client mit einer REST-API hilft das Framework Refit.

Die verwendeten Frameworks sind beim Faktor "Professionalität" aber nicht der entscheidenden Faktor.
Ich verbinde damit (neben den Softskills fürs Teamwork) in erster Linie die Fähigkeit, den Quellcode und die Architektur klug zu schneiden und dafür zu sorgen, dass das ganze System langfristig testbar und wartbar bleibt und auch alle anderen Anforderungen wie erwartet funktionieren. Richtig aufgebaut ist dann auch eine Fehlentscheidung bei einem der Frameworks kein Todesurteil für die Software, sondern man kann es mit überschaubarem Aufwand umstellen.
Die Themen dahinter sind aber nicht so einfach, dass man nur ein paar Artikel auflisten könnte, aber ich denke, die S.O.L.I.D.-Prinzipien sind die beste und wichtigste Grundlage, auf der alles Andere aufbaut. Ich finde die Erklärung im "Clean Architecture"-Buch von Robert C. Martin sehr gut (bzw. Vollständiger als Andere), die ist aber nicht ganz leicht zu verstehen.

Parallel IO to Disk ist auch ein Angriffsszenario (DOS), da nicht jede Festplatte mit parallelen Schreibarbeiten zurecht kommt.

Ich glaube nicht, dass er paralleles schreiben meint, sondern eher genau das, was CopyTo macht: Einen Block lesen, schreiben, lesen, schreiben, ...

Wenn Du einen bestehenden Stream auf die Platte schreiben willst, dann mach einfach den FileStream auf und nutze hier das CopyTo, das gibt's für 4.6.2 "schon".
Das beachtet dann auch das blockweise kopieren, kannst Du dort nachlesen: https://referencesource.microsoft.com/#mscorlib/system/io/stream.cs,295ec16c77d4fafb
Die Methode interessiert sich auch nicht für den Quell- und Ziel-Stream, es geht mit jedem Stream.

Oder - wenn das Ziel ein byte-Array ist: MemoryStream

Nimm einen MemoryStream (und gib beim Konstruktor ggf. die Länge mit), kopiere alles vom Quell-Stream in den MemoryStream (CopyTo) und hole dir anschließend dein Array (ToArray).
Dein Vorhaben ist also schon fertig, Du musst es nur noch nutzen ^^

Aber ja, auch da wird abgeschnitten, das ist halt so.
So viel willst Du aber auch nicht im RAM haben, damit hast Du ganz schnell Performance-Probleme.
Besser wäre, Du verarbeitest die Daten als Stream, also Stück für Stück und hast dann nur das im RAM, was Du gerade brauchst.

By the way:
Eine Methode mit 10 Parametern, von denen auch noch 3 null sind, deutet auf ein Problem hin 😉
Eine Methode, die so viele Parameter braucht, von denen auch noch einige optional sind, macht meist mehr, als sie sollte.

Das ist jetzt ein eigenes ORM, jetzt würde ich aber Dapper oder EF benutzen.

Wobei Dapper aber das SQL schreiben nicht ab nimmt - zumindest nach meinem letzten Stand.
Es mappt nur die Ergebnisse passend zu den eigenen Klassen.
Das übernehmen nur die "großen ORMs" wie EF oder nHibernate, sind dadurch aber auch deutlich komplexer.

Warum nicht als embedded resource?

Oder ein Repository, dessen Implementierung größtenteils aus SQL besteht.
Das Ausführen und Mappen übernimmt z.B. Dapper.

Oder direkt ein vollwertiges ORM wie EFCore, dann spart man sich die ganzen SQL Queries.

Gibt leider in Azure selbst keinen eingebauten Mechanismus für Update-Seiten.

Darauf hatte ich gehofft, aber wenn's das nicht gibt, ist das halt so.
Schade eigentlich, das Problem müsste doch jede Website früher oder später mal haben.

Im Anhang ein Bild von der Meldung, die gerade eben ein paar Minuten angezeigt wurde.

War das ein Fehler oder ein geplantes Update?
Wenn es ein geplantes Update war, fände ich gut, wenn dann eine Update-Seite im Stil des Forums gezeigt wird.
Also irgendetwas, was nicht so sehr nach Fehler aussieht ^^

Geht auf jeden Fall, es sagt ja niemand, dass alles nur eine SPA sein muss.
Doch ich würde es nicht pauschal so machen, sondern nur auf Anforderung (z.B. ein Button "Abdocken").
Oder ganz allgemein gesprochen: "Ist so etwas [...] realisierbar?" kann man so gut wie immer mit "Ja" beantworten ^^
Das teilen der Zustandsdaten zwischen den "Dialogen" stelle ich mir aber etwas komplizierter vor, als beim Desktop.

Aber muss es denn eine Web-Anwendung sein oder ist das eher ein "das macht gerade jeder"?
Der große Vorteil vom Web ist ja die Flexibilität auf allen möglichen Geräten, aber hier scheint ja nur der Desktop realistisch zu sein?

Das, was Du im ViewModel machen musst, hat nichts mit WPF zu tun - außer das OnPropertyChanged, aber das hast Du ja schon.

Wenn Du noch Anfänger bist, ist WPF nicht der richtige Einstieg für dich.
Fang vorne an und lerne lieber erst mal die C#-Grundlagen und was OOP ist und was man damit macht.

Code-Snippets ohne Verständnis aus dem Internet zusammen zu kopieren hat sich noch nie bewehrt.

Warum machst Du das denn nicht im ViewModel?
Einfach die Liste mit den Rechten auf CanAddFPFoer filtern und einer zweiten Property zuweisen - oder direkt die erste Liste gefiltert anbieten.
Und wenn es immer nur ein Recht geben kann, suchst Du halt das eine Recht raus.
Dann brauchst Du den ganzen Kram nicht.

Fehlermeldung:
Quelle nicht gefunden: RelativeResource FindAncestor, AncestorType="ViewModel", AncestorLevel="1"

AncestorType meint Controls - die RelativeSource sucht den LogicalTree ab. Das ViewModel hat damit nichts zu tun, das befindet sich im DataContext, der vom Binding als Default-Quelle verwendet wird.
Im ItemsControl bzw. dem ItemTemplate davon wird allerdings das tatsächliche Item als DataContext gesetzt, wenn Du an das ursprüngliche ViewModel kommen willst, suchst Du am besten mit der RelativeSource ein Control weiter oben (z.B. ListBox) und bindest darüber dann an DataContext.FoerderEintragen

Und ein paar andere Kommentare:

• Binding-Mode musst Du quasi nie setzen, meist passt der Default
• UpdateSourceTrigger brauchst Du nur, wenn die ViewModel-Property auch aktualisiert werden soll, z.B. SelectedFont - ich bezweifle, dass die ListBox die Source aktualisiert
• Im ItemTemplate ist genau ein Item drin, das StackPanel brauchst Du nicht

Das ist eine Property im ViewModel, die kannst Du zuweisen, wie jede andere Property auch.
Wenn Du sie aus der View heraus zuweisen willst, musst Du sie binden, viele Listen-Controls haben dafür eine SelectedItem-Property.

Wie gesagt: Der musst Du natürlich auch ein Recht geben.
Wenn Du nichts zuweist, wird sie auch immer null zurück geben.

Nur gibt er mir keinen Wert aus?

Ist die Property null?
Der musst Du natürlich auch ein Recht geben.

Allerdings wandelt er es nicht um bzw. ich vermute, dass ich meinen Wert nicht bekomme. Kann ich irgendwie überprüfen, ob true oder false ankommt?

Du kannst einen Breakpoint im Converter setzen.

Du meinst "Array" oder "Liste" oder was auch immer Du da hast und nicht "Klasse", das ist was anderes.
Und ja, das geht, in einem WPF-Binding kann man auch auf ein einzelnes Item einer Auflistung zugreifen:
binding-in-wpf-to-element-of-array-specified-by-property
Ob das so gut ist, sei mal dahingestellt, ich habe in meiner ganzen Laufbahn noch keinen Fall gehabt, wo ich das gebraucht habe.

Wenn Du die Rechte nur als Liste hast, musst Du im ViewModel für eine Property mit einem Recht sorgen.
Danach schreibst Du als Binding einfach "{Binding MyRecht.WhatEver}".

Irgendwas in deiner Aufruf-Kette kann null zurück geben. Ich glaube, das war die Version-Property.
Behandle das und der Analyser ist glücklich.

Und der Unterschied zu Application.ProductVersion ist:
https://source.dot.net/#System.Windows.Forms/System/Windows/Forms/Application.cs,ddd6e2b5fca971e7
Die faken einfach die Versionsnummer.

Was mich wundert, ist dass mein programm bei getResponse einfach hängen bleibt

Für mich klingt das danach, dass die API nicht antwortet. Wenn Du einen Timeout einstellst, würdest Du vermutlich eine TimeoutException bekommen.
Woran das nun genau liegt, kann dir der Entwickler der API am besten sagen - oder Du vergleichst mit Fiddler.

Du könntest auch Mal den curl-Befehl testen, den kann Postman meines auch anbieten. Oder direkt die HTTP-Daten - findest Du alles rechts im "Code snippet"-Bereich.
Und teste es doch mal mit Refit, vielleicht macht RestSharp hier irgendetwas unter der Haube, "verkauft" es als Default-Verhalten und tritt dir damit ans Bein.