Kurze Information für die Leute, die Microsoft .NET 7 einsetzen. Diese Laufzeitumgebung fällt am 14. Mai 2024 aus dem Support und wird keine weiteren Sicherheitsupdates mehr erhalten.
Microsoft hat zum 27. März 2024 im Blog-Beitrag .NET 7 will reach End of Support on May 14, 2024 auf diesen Sachverhalt hingewiesen. Danach wird Microsoft keine Service-Updates mehr für .NET 7 zur Verfügung stellen. Nutzer müssen ihre Laufzeitumgebung vor diesem Datum auf .NET 8 aktualisieren, um weiterhin unterstützt zu werden.
.NET 7 ist eine STS-Version, die für 18 Monate unterstützt wird. (via)
2015
In Unternehmensumgebungen macht es (auch aus Sicherheitsgründen) durchaus Sinn, veraltete Versionen der .NET Runtimes automatisiert zu deinstallieren.
Wir nutzen hierfür das .NET-Deinstallationstool von Microsoft, welches bei uns Bestandteil der Basisinstallation aller Clients ist.
Download und Syntax, siehe:
https://learn.microsoft.com/de-de/dotnet/core/additional-tools/uninstall-tool?tabs=windows
Vorab muss natürlich überprüft werden, ob von Programmen noch Abhängigkeiten zu den alten Versionen bestehen.
Mal eine Frage in die Runde hier, bin auf dem .NET Gebiet nicht wirklich informiert: Kommt die Windows Installation nicht mit einer vorinstallierten .NET-Installation? Ich meine es ist bei Windows 10 .NET 4.5 und bei Windows 10 .NET 4.8 (kann mich aber auch täuschen). Werden die vorinstallierten .NET-Umgebungen über den standardmäßigen Windows Update Mechanismus aktualisiert oder ist hier zwangsläufig ein Eingreifen des Benutzers notwendig?
Wie sieht das in Enterprise-Umgebungen aus, dort wird oftmals von einer Anwendung eine spezifische .NET-Version vorgeschrieben. Ich verstehe das so, dass jede neuere .NET-Version auch die älteren Anforderungen bedienen kann. Manchmal stellen sich aber Software-Anbieter quer und meinen es muss diese eine spezifische Version sein. Wie löst ihr sowas?
Was Du meinst ist das .NET Framework, der Artikel bezieht sich aber
auf .NET Core Runtime.
Die Unterschiede werden auf dieser Seite gut erläutert:
https://rightpeoplegroup.com/de/net-core-vs-net-framework-was-ist-das-richtige-fuer-ihr-unternehmen/
Für beide Entwicklungsumgebungen werden die Sicherheitsupdates
über WSUS bzw. Windows-Updates eingespielt
Die Versionen von .NET Framework sind übrigens abwärtskompatibel.
Sollte eine Anwendung z. B. .NET Framework 4.7 benötigen,
so läuft diese in der Regel auch, wenn .NET Framework 4.8.1 installiert ist.
Bei den .NET Core Runtimes sieht dieses anders aus.
Hier sind die Programme fest an die jeweilige Version gebunden.
So läuft eine Anwendung, die z. B. .NET Core 6 benötigt, nicht
wenn ausschließlich .NET Core 8 installiert ist.
Hier muss dann auf eine Anpassung der Anwendung seitens des Entwicklers bzw. Herstellers gewartet werden.
In der Regel kompiliert ein Anbieter immer gegen genau eine .Net-Version, weil die sich dann doch so unterscheiden, dass man multiple Läufe gegen mehrere Versionen nicht einfach hinbekommt.
Visual Studio ist auch erstaunlich anfällig beim Wechsel des Ziels – also einfach von 4.6 auf 8 und wieder zurück und man kann das Projekt gerne mal wegschmeissen… ;)
Wir stehen aktuell vor dem Problem, dass wir immer noch gegen 4.6.2 kompilieren (immerhin mit Support bis 2027) und jetzt eigentlich mal wechseln müssten. Aber das Paket besteht aus ungefähr 100 Einzelprojekten wir wir haben natürlich auch zugekaufte Komponenten mit eigenen Abhängigkeiten – wir müssten jetzt eigentlich auf .Net 8 wechseln, weil 7 schon durch ist und das Ende von 6 absehbar.
Rein theoretisch gibt es multitargeting, aber das bedeutet, dass man immer beim Feature-Set des niedrigsten Frameworks hängenbleibt und die Logs bestenfalls voller Warnmeldungen hat, weil Funktionen zum Beispiel in einem Teil der Targets abgekündigt sind.
Aber in dem Moment, wo wir das Framework wechseln, müssen alle Kunden auf das neue Framework umgezogen werden – wir haben immer noch Kunden mit Windows 7. Das ist nicht schön, aber eben Realität – und da sind viele KMUs dabei, die mit 15 Jahre alter Hard- und Software arbeiten und nicht die Ressourcen für die nötigen Upgrades haben: Nicht finanziell, aber erst recht nicht personell.
Und dummerweise ist es eben nicht so, dass ein 4.6.2-Projekt automatisch auch mit einem höheren Framework läuft… Es ist noch viel schlimmer: Die Frameworks haben Releases und die wuchern bei Windows – das ganze Drama im Bild -> "dotnet –list-runtimes".
So sieht das bei mir aus:
Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.28 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Wenn ich meine Anwendung gegen 8.0.2 kompiliere und die Kunden installieren das, müssen sie auch 8.0.2 installiert haben – ist im Übrigen in keinem aktuellen OS-Release mit drin, weil die 8 erst im November 2023 released wurde. Wenn ich jetzt auf 8.0.3 wechsle, müssen alle Kunden auch 8.0.3 nachinstallieren – was multitargeting für den Installer (hier Inno Setup) bedeutet, kann man hier erahnen: https://github.com/DomGries/InnoDependencyInstaller/blob/master/CodeDependencies.iss
Microsoft wollte mal vor 30 Jahren die DLL-Hell beenden… und hat stattdessen einfach nur eine neue Hölle aufgemacht.
Deswegen laufen die meisten .Net-Anwendungen mit genau einer Version des Frameworks, die auch explizit vorhanden sein muss. Das ist gar kein spezieller Unwillen der Anbieter, sondern Ergebnis von Abwägungen, die viel damit zu tun haben, dass viele Branchen sich in einem Race-to-the-bottom befinden.
Wie findet man heraus, ob auf dem System noch Programme .NET 7 benötigen?
Deinstallieren und darauf warten was nicht mehr funktoniert :(
Ohne eine genaue Dokumentation schwierig…
So werden bei uns zu jedem installierten Programm die Abhängigkeiten
bzw. Prerequisites wie .NET Framework, .NET Core, Visual Runtime,
Java Runtime, etc. dokumentiert.
Im Falle von .NET gibt es aber auch Tools wie z. B. "DependencyWalker for .NET", die die Abhängigkeiten auflisten:
https://github.com/isindicic/DependencyWalker.Net
Oder das Tool "All Dlls Dependencies":
http://jacquelin.potier.free.fr/AllDllDeps/
Wir entwickeln entweder (Legacy-Apps) mit .NET Franework 4.8 oder (neue Apps) mit .NET 6.0 bzw. 8.0. .NET 6.0 und 8.0 sind LTS-Versionen mit längerem Support. Auf die Zwischenversionen (5.0, 7.0) haben wir verzichtet.