Microsoft .NET 7 fällt am 14. Mai 2024 aus dem Support

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 Support

.NET 7 ist eine STS-Version, die für 18 Monate unterstützt wird. (via)


Anzeige

Dieser Beitrag wurde unter Sicherheit, Software abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

8 Antworten zu Microsoft .NET 7 fällt am 14. Mai 2024 aus dem Support

  1. Bernie sagt:

    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.

  2. Anonymous sagt:

    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?

    • Bernie sagt:

      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.

    • Georg sagt:

      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.

  3. leetoo sagt:

    Wie findet man heraus, ob auf dem System noch Programme .NET 7 benötigen?

  4. Jan Steinhardt sagt:

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.