.NET
Der Begriff .NET bezeichnet grundlegend das Ökosystem, in dem wir uns bewegen. Im Alltag wird ".NET" jedoch für viele verschiedene Dinge verwendet, sowohl die Plattform, die Runtime oder auch eben das ganze Ökosystem.
.NET Framework - Runtime
Das .NET Framework ist die alte Laufzeitumgebung, die nur auf Windows betrieben werden kann. Das .NET Framework wurde bis heute maßgeblich über Windows-Releases veröffentlicht; Zwischen-Releases konnte man selbst installieren.
⚠ Es wird nicht mehr empfohlen mit .NET Framework neue Projekte zu starten, wenn dies nicht notwendig ist. ⚠
Microsoft selbst hat das .NET Framework nicht offiziell abgekündigt, aber mit .NET Core bzw. .NET 5 (und höher) offiziell den Nachfolger bekannt gegeben. Der Grund, dass es keine offizielle Abkündigung geben kann, ist, dass das Support-Modell von .NET Framework an Windows gekoppelt ist, sodass das .NET Framework selbst solange mit (Security) Patches versorgt wird, bis auch die entsprechende Windows Version, die das jeweilige .NET Framework mitliefert, abgekündigt ist.
⚠ Das .NET Framework wird nicht mehr aktiv weiter entwickelt und wird in neuen Technologien auch bereits nicht mehr unterstützt.
.NET Framework 4.8 ist die letzte Hauptversion.
.NET Core / .NET - Runtime
.NET Core bzw. seit Version 5 nur noch als ".NET" bezeichnet ist die neue Laufzeitumgebung, die Cross-Plattform auf verschiedenen Betriebssystemen bzw. Umgebungen betrieben werden kann; darunter Windows, Unix, Tizen - und gilt als Nachfolger des .NET Frameworks. Mit in .NET Core ist auch Xamarin eingeflossen; die mobile Plattform, die auf Mono basierte und von Microsoft im Jahr 2016 aufgekauft wurde.
Zuerst war .NET Core eine Abspaltung für die Web-Technologie ASP.NET Core, da das .NET Framework die modernen Anforderungen an Web-Plattformen (schlank, dynamisch, schnelle Weiterentwicklung) nicht mehr gerecht war, insbesondere auch nicht für moderne Cloud- und Container-Umgebungen wie zB. Docker. Der immense Erfolg und das extrem gute Feedback der Open-Source Gemeinde war letzten Endes dann der ausschlaggebende Punkt die gesamte Plattform neu zu entwickeln.
Entsprechend waren die ersten Versionen von .NET Core nur für Konsolen- und Webanwendungen nutzbar während mit .NET Core 3 dann auch Windows Forms sowie WPF langsam Einzug gehalten haben.
Mit .NET 5 waren dann beide Desktop-UI Frameworks dann in einem äquivalenten Zustand zu .NET Framework. Seit .NET 6 sind 100% der Kernfunktionalitäten von .NET Framework verfügbar.
Während das .NET Framework primär nur mit Visual Studio entwickelt werden konnte, basiert die neue .NET Welt auf der Kommandozeile, weshalb dadurch die Entwicklung mit jedem Editor möglich ist (Visual Studio, Visual Studio Code, Atom, Rider, Notepad,.....) und jeder Entwickler so nach seinen Wünschen seine Umgebung aufbauen kann.
Es wird empfohlen neue Projekte nur noch mit .NET 5 und höher umzusetzen, wenn möglich.
.NET Standard - Die Spezifikation
Weil es alles andere als einfach ist "mal so" die Runtime einer Plattform zu wechseln, hat man sich bei .NET dazu entschieden eine Spezifikation zu schaffen, gegen die entwickelt werden kann, ohne dass die Ziel-Runtime beim Kompilieren bekannt sein muss: den .NET Standard.
Dadurch konnte man Bibliotheken entwickeln, die in .NET Framework und .NET Core verwenden werden können.
Dies dient vor allem als Migrationshilfe, sodass der Wechsel von .NET Framework auf .NET Core überhaupt möglich ist bzw. für viele Anwendungen auch erst wurde.
Aus Code-sicht kann man sich den .NET Standard als Schnittstelle vorstellen, während .NET Framework, .NET Core, etc. konkrete Implementierungen dieser Schnittstelle darstellen:
D.h. .NET Standard in der jeweiligen Version gibt die verfügbaren APIs vor (das Interface) und die konkreten Implementierungen müssen (mindestens) diese APIs umgesetzt haben (die Klasse). In der Umsetzung können natürlich Unterschiede zwischen .NET Framework, Mono oder .NET Core vorhanden sein, aber "nach Außen" verhalten sich alle Runtimes identisch.
Mit .NET Standard 2.1 hat diese Spezifikation ihr Ende gefunden, da diese bereits nicht mehr in .NET Framework Projekten unterstützt wird. Ab .NET 5 empfiehlt sich, sofern möglich, Bibliotheken gegen .NET 5 (oder höher) zu kompilieren und nicht mehr gegen den .NET Standard.
Siehe auch Die Zukunft von .NET Standard
.NET Kompatibilität
Assemblies von .NET Framework und .NET Core sind nicht kompatibel zueinander. Es muss eine Migration von Framework auf Core vorgenommen werden.
Als Unterstützung gibt es ein Analyse Tool: .NET Portability Analyzer
Sofern Assemblies in beiden Welten zeitgleich verwenden werden müssen, so geht dies nur über den .NET Standard.
Für die entsprechenden Technologien in .NET gibt es ausführliche Migrationsanleitungen in der Microsoft Dokumentation, zum Beispiel:
Migrieren einer Windows Forms-Desktopanwendung zu .NET 5
Migrieren von WPF-Apps zu .NET Core
Portieren von EF 6 nach EF Core
Migrating from ASP.NET to ASP.NET Core
NuGet - die Paketverwaltung
NuGet ist das Paketsystem des .NET Ökosystems; vergleichbar mit Maven (Java), NPM (JavaScript/NodeJS), Conan (C++), PIP (Python), Composer (PHP), GEM (Ruby) und ersetzt dabei die manuelle Handhabung von Assemblies, sowohl .NET Framework Assemblies (Global Assembly Cache) wie auch alle anderen Arten von eigenen oder externen Abhängigkeiten. Ebenso können komplette Tools (.NET Tools) und vieles weiteres über NuGet Pakete verfügbar gemacht werden.
Über NuGet können sowohl offizielle .NET Abhängigkeiten heruntergeladen und verwendet werden, wie auch eigene Projekte paketiert und verteilt werden.
Von Haus aus hat sowohl Visual Studio wie auch die .NET Kommandozeile NuGet integriert.
C# / VB.NET / F# - Sprachen
Die mit sehr weitem Abstand am meisten verbreitete Sprache im .NET Ökosystem ist C#, aber alle drei Sprachen können in .NET Projekten - auch untereinander - verwendet werden.
Alle drei Sprachen haben sowohl technisch wie auch organisatorisch ihre Vor- und Nachteile; werden am Ende jedoch in die gleiche Zwischensprache (IL Code) kompiliert, sodass der Quellcode untereinander verwendet werden kann.
Welche Sprache ein Entwickler wählt ist am Ende also meist nicht Sache der Anforderung (wobei das insbesondere bei Alt-Software und bei Kunden-Software anders sein mag), sondern die Entscheidung des Entwicklers bzw. Teams.
Über die Historie
Im Jahr 2000 wurde von Microsoft ".Net-Framework" (damals noch nicht in Großbuchstaben) veröffentlicht und hat damals sowohl die Laufzeitumgebung (Runtime), die Framework-Klassenbibliotheken (Global Assembly Cache, kurz GAC) sowie den Compiler beinhaltet.
Das Ziel war damals vor allem die Desktop-Entwicklung, die durch die .NET Plattform vereinfacht, beschleunigt und stabiler gestaltet werden sollte.
Mit an Bord von Version 1 waren dabei* Windows Forms
Die Akzeptanz und eine weite Verbreitung gab es aber erst 2006 mit .NET 2.0, das dann auch Bestandteil des neuen Visual Studio 2005 war und auch neue Features hatte, insbesondere:* SQL Server Unterstützung
Mit Windows Longhorn (später dann Vista) sollte das .NET Framework - dann unter dem Namen WinFX - einen riesigen Sprung nach Vorn machen und die komplette Anwendungsplattform auf Windows Betriebssystemen werden. Letzten Endes (Gott sei dank?) wurde der Name WinFX aber fallen gelassen und das .NET Framework unter der Version 3.0 veröffentlicht. Mit den neuen Features:* Windows Presentation Foundation, WPF (damals Code Name "Avalon")
Damit hatte das .NET Framework ein riesiges Spektrum an Managed Code Technologien, das insbesondere in Enterprise Firmen immer mehr Akzeptanz gefunden hatte und viele C++ und vor allem Java-basierte Desktop-Anwendungen ersetzte.
Microsoft war zu diesem Zeitpunkt so rigoros, dass Features nur noch in Managed Code Implementierungen anbieten wollten und so auch auf Konfrontation mit Unmanaged-Entwickler gegangen sind. Das ist im Endeffekt der Grund, wieso wir heute in .NET problemlos Win32 Schnittstellen verwenden können, aber nicht umgekehrt.
Über die Jahre ist .NET als Closed-Source Plattform stark gewachsen, hat insbesondere durch die Nähe und das Verständnis von Microsoft für die Unternehmenswelt extrem für die Verbreitung gesorgt. Die Weiterentwicklung war damals also vor allem politisch getrieben. An ein Veröffentlichen des Quellcodes war nicht zu denken.
Die Zeiten haben sich jedoch geändert, sodass durch die immer schneller und offener werdende Entwickler-Welt .NET an Beliebtheit verloren hat und sich insbesondere Universitäten an kostenlosen Umgebungen wie Java oder Python orientiert haben, sodass Unternehmen langsam neue Entwickler gewonnen haben.
Das hat Microsoft dann - zum Glück für .NET - auch erkannt und den .NET Framework Quellcode als Shared Source veröffentlicht, sowie die .NET Foundation offen gegründet; nicht nur um Vertrauen durch Offenheit zu gewinnen, sondern auch durch Open Source Entwickler aktiv zu profitieren. Heute ist fast die komplette .NET Runtime- und Tooling-Welt Open Source - und das .NET Ökosystem bzw. Technologien aus dem .NET Ökosystem gehören zu den beliebtesten, schnellsten und weit verbreitetsten überhaupt.
Entstanden zusammen mit gfoidl, Coffeebean und Papst.
Historie:
2021-08-01: Veröffentlichung
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Sehr schöner Artikel, hab ihn nur überflogen, aber ist schon sehr informativ.
Lese ich mir bei Zeiten mal vollständig durch.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Sehr guter Artikel!
Aber noch ein paar Schreibfehler:
beschreitb
knapp, ...könnte
(konnte), ...VB.NET
hatte
(war?) und ...release
(released / veröffentlicht)Danke, sehr aufmerksam! Korrigiert 🙂
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Schöne Arbeit, danke dafür 🙂
lock
Alternative fürasync
/await
: https://github.com/loop8ack/AsyncTicketLock