BUILD 2019: Nachtrag zu .NET 5 und .NET Core 3.0 (Klarstellung)

BUILD 2019: Nachtrag zu .NET 5 und .NET Core 3.0 (Klarstellung)

Manchmal kommt es vor, dass man Nachrichten nachträglich korrigieren muss, weil die Informationen aus dem vorab zugesandtem Material des Entwicklers nicht allzu gut formuliert waren. Deswegen muss ich leider eine „Falschmeldung“ korrigieren, die ich im Sammelbeitrag zu den Developer Tools hinterlassen habe. Konkret hatte ich geschrieben, dass das klassische .NET Framework im nächsten Jahr in der neuen Version 5.0 veröffentlicht wird. Genau das stimmt nicht, sondern die .NET-Plattform an sich wird komplett neu aufgebaut und strukturiert. Aber der Reihe nach…

Tatsächlich ändert sich in diesem Jahr noch nicht allzu viel. Während das klassische .NET Framework mit Version 4.8 bereits vor wenigen Wochen sein (letztes?) Feature-Release gesehen hat, stehen in diesem Jahr für .NET Core noch zwei Releases an: Version 3.0 kommt im September, anschließend folgt mit Version 3.1 noch eine LTS-Version im November. Danach folgt .NET 5.0, welches genau wie bei der PowerShell das „Core“ aus dem Namen streicht und die besten Elemente aus dem klassischen .NET Framework, .NET Core und der freien Implementierung Mono in sich vereinen soll. Entsprechend dem .NET Standard sollen dabei alle relevanten Plattformen, für die es .NET gibt, bedient werden.

dotnet5_platform

Sobald die Stränge der einzelnen Implementierungen vereinheitlicht wurden, schwenkt Microsoft auf einen jährlichen Releasezyklus um, wobei immer im November eine neue Hauptversion sowie alle zwei Jahre eine LTS-Version von .NET erscheinen soll. Das nächste LTS-Release erscheint 2021 mit .NET 6.0, anschließend wird .NET 8.0 im Jahr 2023 die nächste Version mit Langzeitunterstützung. Entsprechende Pläne könnt ihr auch nochmal der nachfolgenden Grafik entnehmen.

dotnet_schedule

Alle weiteren Informationen könnt ihr dem Blogpost von Richard Lander (englisch) entnehmen, der mittlerweile verfügbar ist.

Ich möchte mich an dieser Stelle auch nochmal für den Fehler entschuldigen. Allerdings muss ich auch sagen, dass ich diesen ausführlichen Blogpost von Microsoft zu dem Zeitpunkt, als ich besagten Sammelbeitrag verfasst habe, noch nicht hatte und mir wirklich nur ein sehr knapper Absatz aus dem Vorabmaterial zur Verfügung stand. Insofern bitte ich da um Nachsicht.

Über den Autor
Kevin Kozuszek
  • Kevin Kozuszek auf Twitter
Seit 1999 bin ich Microsoft eng verbunden, daneben schlägt mein Herz aber auch für die OpenSource-Welt, wo mein besonderes Interesse der Mozilla Foundation gilt. Wenn ich mich mal nicht mit Technik beschäftige, tauche ich gerne in die japanische Kultur mit all ihren Facetten ab oder widme mich einem meiner zahlreichen anderen Hobbies.

Schreibe einen Kommentar

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



Kommentare
  1. Danke, das ist mal für mich eine Super Nachricht. Es kommt zusammen was eigentlich schon von Beginn an zusammengehörte. Aber nur eine Frage stellt sich mir allerdings. Es heißt die meisten Features vom klassischen .NET Framework. Also ich hab das jetzt soweit verstanden, dass es eine Weiterentwicklung von .NET Core ist, oder? Dieses ist ja dann plattformübergreifend. Was ist aber mit WPF. Ich habe immer gehofft, dass dieses irgendwann auch Plattformübergreifend eingesetzt werden kann. Im Schaubild ist es drauf unter Desktop. Desktop würde für mich auch Linux bedeuten. Zumal die Quellen von WPF mittlerweile auch freigegeben wurden. Ob es Mono je implementieren wird ist fraglich.
    Wie lange wird LTS unterstützt? Nur ~2 Jahre, das wäre den Namen nicht wert?
    .NET ist nicht verlässlich.
    .NET 1 läuft afaik nicht mehr.
    .NET 4 wird nicht weiterentwickelt. Support bleibt erst mal auf unbestimmte Zeit, MS hat genug eigenen Code, der das braucht.
    .NET 5/Core ist (wieder mal) die Zukunft
    Win32 läuft und läuft und läuft.
    @BGeiger Soweit ich informiert bin arbeitet MS an einer Portierung von WPF auf Linux. Genauer gesagt wird eine Schicht eingebaut die die DirectX Calls unter Windows nach OpenGL unter Linux migriert und die ersten Tests sehen sehr viel versprechend aus!
    LowerBavarian
    @BGeiger Soweit ich informiert bin arbeitet MS an einer Portierung von WPF auf Linux. Genauer gesagt wird eine Schicht eingebaut die die DirectX Calls unter Windows nach OpenGL unter Linux migriert und die ersten Tests sehen sehr viel versprechend aus!

    Nein, tun sie nicht. Das Ganze wurde in einem Thread auf GitHub Anfang Dezember erst lang und breit diskutiert, ob Windows Presentation Foundation für Mac und Linux portiert werden soll. Genau das wurde unter anderem durch Rich Lander von Microsoft abgelehnt. Ich zitiere mal:
    Just like @dotMorten says, we are not taking cross-platform implementations, per our Contributor Guide.
    We look forward to many contributions to WPF. This request is out of scope for the project.
    From a technical standpoint, WPF depends on multiple Windows components: D3D (DirectX), DWrite, User32, GDI+, WISP (Touch), and several others (including Windows Runtime dependencies). The interaction with these components is complex, critical and not architected with cross-platform in mind. As a result, our focus is on completing open source of WPF and bringing it to parity with .NET Framework.
    I am closing this issue as a result.

    Was du wahrscheinlich meinst, ist DXVK. Das ist ein Kompatibilitätslayer, der auf Vulkan basiert und Calls von DX11 und DX10 unter Wine in Linux übersetzen kann. Damit hat Microsoft aber nichts zu tun, dass ist ein Projekt eines deutschen Indy-Entwicklers. Wenn du was anderes meinst, wäre es nett, wenn du einen Link hättest, dann kann ich mir das mal anschauen.
    ------------------------------------------------------------
    @BGeiger
    Aber nur eine Frage stellt sich mir allerdings. Es heißt die meisten Features vom klassischen .NET Framework. Also ich hab das jetzt soweit verstanden, dass es eine Weiterentwicklung von .NET Core ist, oder? Dieses ist ja dann plattformübergreifend.

    Richtig, wobei Microsoft dort eigentlich zwei Sachen macht: Erstens soll .NET 5 mehr oder weniger Parität mit dem .NET Framework erreichen, zweitens räumt man das Chaos bei den quelloffenen Implementierungen mal auf und führt auch Mono mit .NET Core zusammen, damit es eine verlässliche und quelloffene Implementierung gibt. Das, was für .NET Core heute gilt, gilt nach derzeitigem Stand auch weiterhin für .NET 5 und folgende. Es wird nur das Core aus dem Namen gestrichen, genau wie bei PowerShell 7.
    Das klassische .NET Framework kann Microsoft aber nicht so schnell einstampfen, das würde auch voraussetzen, dass die Massen an altgedienter Software ihren Weg zu .NET 5 etc. finden und Windows müsste auch entsprechend vorbereitet werden. Das wird Jahre dauern, also wird Microsoft die kumulativen Updates zumindest für die Versionen 3.5 und 4.8 bei Windows 10 noch länger fahren müssen.
    Was ist aber mit WPF. Ich habe immer gehofft, dass dieses irgendwann auch Plattformübergreifend eingesetzt werden kann. Im Schaubild ist es drauf unter Desktop. Desktop würde für mich auch Linux bedeuten. Zumal die Quellen von WPF mittlerweile auch freigegeben wurden. Ob es Mono je implementieren wird ist fraglich.

    Wie gesagt, wie bei .NET Core. WinForms, WPF und WinUI betreffen nur den Windows Desktop, für Mac und Linux stellt Microsoft nur die Kommandozeilentools zur Verfügung. Außerdem bevorzugt Microsoft, was die Desktop-Entwicklung unter Linux angeht, entweder Electron und HTML bzw. C++ und GTK, das ist ja allgemein bekannt.
    Das Problem ist halt auch, dass die offiziellen Arbeiten an GTK# vom Mono-Projekt irgendwann eingeschlafen sind. Es gibt zwar eine GTK#3-Version eines Drittentwicklers, aber offiziell wurde die 64-bit-Version von Xamarin (bzw. auch Microsoft als Sponsor dahinter) nie fertiggestellt. Momentan ist es das Beste, wenn man auf Eto.Forms oder AvaloniaUI ausweicht.
    @Kevin Kozuszek
    Danke für die ausführlichen Informationen. Wobei mich die Aussage bzgl. WinForms wundert, weil die ja komplett von Mono selbst unterstützt werden. Naja meiner Meinung nach zwar schlecht unterstützt, aber unterstützt. WPF ist echt schade, weil ich ein paar WPF Programme gerne auch für Linux bereitstellen würde. Danke für die Alternativen, ich werde Sie mir mal anschauen.
    BGeiger
    @Kevin Kozuszek
    Danke für die ausführlichen Informationen. Wobei mich die Aussage bzgl. WinForms wundert, weil die ja komplett von Mono selbst unterstützt werden. Naja meiner Meinung nach zwar schlecht unterstützt, aber unterstützt. WPF ist echt schade, weil ich ein paar WPF Programme gerne auch für Linux bereitstellen würde. Danke für die Alternativen, ich werde Sie mir mal anschauen.

    Ist schon richtig, dass Mono auch WinForms halbherzig unterstützt, aber am anderen Ende kommt trotzdem eine GTK-Anwendung raus und dafür brauchst du GTK#. Zwei Beispiele dafür sind ja der Musikplayer Banshee und das Bildbearbeitungprogramm Pinta, was auf älteren Komponenten von Paint.NET aufbaut. Das Problem ist dabei auch nicht, dass Mono und GTK# nicht mehr funktionieren würden, sondern dass du unter Linux zumindest von offizieller Seite weiterhin nur GTK# in der 32-bit Version ausführen kannst. Mono hat die offizielle Unterstützung von 64-bit zwar bei der Entwicklung von GTK#3 angefangen, aber sie haben es nie fertiggestellt. Bis heute existiert die Komponente für die 64-bit Version von Mono nicht im stabilen Zweig. Das hat ein Drittentwickler zwar übernommen (ich meine sogar, das war Unity, weil diverse Games mit der Engine auf Linux portiert wurden), aber offiziell ist das nie ans Mono-Projekt zurückgeflossen.
    Mittlerweile stellen immer mehr Distributionen auf 64-bit only um, wobei man aktuell noch das Glück hat, dass viele Multilib integrieren (32-bit Anwendungen unter reinen 64-bit Systemen). Wie lange das so sein wird, kann keiner absehen.
Nach oben