[...]dann musst du deinen eigenen link richtig lesen[...]
Ich hab das schon richtig gelesen, du auch? 😉
Auf der von mir verlinkten Seite steht folgendes
.NET Framework 4.8 is the latest version of .NET Framework and will continue to be distributed with future releases of Windows. As long as it is installed on a supported version of Windows, .NET Framework 4.8 will continue to also be supported.
Also es wird weder eine spezifische Version noch sonst genauere Details genannt, ab wann .NET nicht mehr unterstützt wird. Und da auch verschiedene Komponenten von Windows selber auf .NET basieren, geh ich (Stand jetzt) davon aus, dass es kein zeitnahes Supportende geben wird!
Solltest du andersweitig Informationen haben, so freu ich mich auf entsprechende Quellen. Alles andere kann ich dann nur unter Gerüchte und Co verbuchen.
Darüber hinaus wurde die Aussage, wonach .NET Framework weiterhin seinen Platz haben wird, auch direkt von MS Mitarbeitern bestätigt, u.a. von Immo Landwerth (seines Zeichens Program Manager des .NET Teams bei Microsoft).
Er hat das u.a. im Gespräch mit David Tielke in folgendem Video vor knapp 2 Monaten genau so geäußert, dementsprechend kann von Abkündigung keine Rede sein!
Das Video findet sich unter DevDaily 100 - .NET und .NET Core mit Immo Landwerth, die Aussage ungefähr bei Minute 56:00
Aber insgesamt will ich darüber nun auch keine große Diskussion führen, sondern ich wollte nur deutlich machen, dass das klassisches .NET Framework nicht abgekündigt ist sondern wohl noch länger erhalten bleiben wird und man auch darauf basierende Projekte weiterführen kann.
.NET 5 und seine Nachfolger werden aber ganz klar die Zukunft sein, weil dort alles an Innovation und Co stattfinden wird. Am Ende hängt es davon ab, was man machen möchte und was einem wichtig ist.
VG.
.net framework ist komplett abgekündigt und es gibt nur noch den lebenslauf von .net 5
Nur um das mal klar zu stellen...Diese Aussage ist so nicht richtig.
Das klassische .NET Framework (aktuell v4.8) ist NICHT abgekündigt, sondern wird nur nicht mehr proaktiv weiterentwickelt. Aber sehr wohl noch mit Bugfixes, Sicherheitspatches und notwendigen Anpassungen (z.B. Unterstützung für TLS 1.3) versorgt und das wird wohl auch noch viele Jahre so bleiben, da es als integraler Bestandteil von Windows 10 gilt und somit auch direkt an dessen Lebenszyklus hängt. So lange also Windows 10 lebt, wird auch das klassische .NET Framework leben.
Siehe .NET Framework Support Policy (unter dem Punkt "Support lifecycle")
Das ist IMHO ein deutlichter Unterschied zu "abgekündigt" 😉
Nichtsdestotrotz seh auch ich in .NET (Core) 5 die Zukunft und wenn ich die Wahl hab, dann würde ich das wählen.
Und noch ein Hinweis zu .NET Standard...
Der wurde quasi mit dem Release von .NET 5 auch wieder "abgeschafft", d.h. es wird keinen Nachfolger von .NET Standard 2.1 geben, wenn ich das richtig verstanden habe.
Dementsprechend muss man sich damit wohl nur befassen, wenn man noch das klassische .NET Framework (was nur max. .NET Standard 2.0 unterstützt) oder .NET Core ≤ 3.1 unterstützen möchte (z.B. in Form von Nuget Paketen)
Siehe The future of .NET Standard
VG
Als Ergänzung...Man kann dafür auch bequem LINQ in Form der OfType<T>-Methode verwenden.
var taskAObjects = taskList.OfType<TaskA>();
Grüße
Hallo Abt,
danke für die zusätzlichen Infos. In den Kommentaren im Blog las sich das noch etwas anders, aber so ziehe ich meinen Einwand zurück.
Grüße
Ich find es schade, dass Linux nicht unterstützt wird bzw. davon keine Rede ist. Nicht das ich das nun unbedingt brauch, aber wäre irgendwie nett gewesen 😉
Aber ansonsten schließ ich mich der Aussage von T-Virus an. Etwas worauf ich schon länger warte.
Grüße
Eine Alternative KANN an dieser Stelle dotPeek von Jetbrains sein. Neben der Möglichkeit Assemblies zu dekompilieren, kann man auch von einer Assembly PDB-Dateien generieren lassen und diese dann via lokal laufendem Symbolserver beim Debuggen via Visual Studio nutzen.
Zu beachten ist hierbei natürlich, dass man nur den kompilierten und evtl. optimierten Code debuggen kann, der sich evtl. deutlich vom Code bei Github und Co unterscheidet. Sollte aber bei Fehlersuche und Co keine entscheidende Rolle spielen IMHO.
Grüße, HiGHteK
Hallo HeikoAdams,
wenn du auf die UAC verzichten willst, dann solltest du deine Anwendung einfach in einen Ordner installieren in den der Benutzer schreiben darf. Im einfachsten Fall einfach unterhalb des Benutzerprofils unter C:\Users{MyUser}{MyApp}.
Läuft deine Anwendung von da, dann kannst du einfach ohne UAC Dateien kopieren und austauschen, da der Benutzer die notwendigen Zugriffsrechte schon hat (AFAIK macht es Chrome ähnlich, damit ein Update still im Hintergrund erfolgen kann).
Erscheint mir zumindest einfacher, als die UAC irgendwie umgehen zu wollen, was IMHO nicht oder nicht ohne Workarounds möglich ist.
Grüße, HiGHteK
Hallo Palladin007,
hast du schon mal in den Event Log (via EventViewer bzw. Ereignisanzeige) vom Betriebssystem selber nachgeschaut? Bisher hab ich da immer einen Hinweise auf die Ursache gefunden, wenn sich eine .NET Anwendung scheinbar grundlos verabschiedet hat.
Grüße, HiGHteK
Hallo Rabenrecht,
du musst innerhalb der Projektmappe / Solution Explorer einen Rechtsklick auf ein Projekt machen, nicht auf die Solution selber!
Grüße, HiGHteK