Laden...

.NET Standard 2.1 vs 2.0

Erstellt von Abt vor 5 Jahren Letzter Beitrag vor 5 Jahren 19.014 Views
Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 5 Jahren
.NET Standard 2.1 vs 2.0

Auf GitHub gibt es einen sehr netten, sehr einfachen Vergleich, was sich zwischen .NET Standard 2.1 zu 2.0 geändert hat:

https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.1_diff.md

T
156 Beiträge seit 2010
vor 5 Jahren

Lieben Dank 👍
Wurde auf dem ersten Blick viel InteropServices und das ISerializable bei Exceptions rausgeschmissen...

Aber auch sonst ganz viele Neuerungen, die man sich mal anschauen sollte.
Bzw. Eigenimplementierungen nun im Framework sind 🙂

T
2.219 Beiträge seit 2008
vor 5 Jahren

Mir ist dabei aufgefallen, dass teilweise fundamentale Methoden der String Klasse nun erst hinzugekommen sind.
Gab es diese tatsächlich vorher nicht im .NET Standard?

Gerade Methoden wie Contains, Trim* etc. werden doch recht häufig verwendet.
Auch andere bekannte Klassen wie TimeSpan etc. werden jetzt erst abgedeckt.
Kann ich fast nicht glauben, dass solche Dinge jetzt erst zum Standard werden.
Muss aber auch zugeben, dass ich dem Standard leider auch beruflich kaum Beachtung schenken kann.
Wir entwickeln aktuell nur fast .NET Framework Webs und mit Xamarin für iOS Apps.
Das einzige Core Projekt was wir hatten, wurde mangels freier Entwickler quasi weit nach hinten verschoben 😦

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.

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 5 Jahren

Das sieht teilweise nur so aus, weil sich viele Klassen nur durch den Kopf geändert haben, weil zB das Attribut

[System.Runtime.InteropServices.ComVisible(true)]
[Serializable]

generell entnommen wurde.

Teilweise gibt es aber tatsächlich auch neue Overloads.

TimeSpan ist nicht neu; sieht man auch im Diff.

Das einzige Core Projekt was wir hatten, wurde mangels freier Entwickler quasi weit nach hinten verschoben 😦

T-Virus

.NET Core != .NET Standard

.NET Standard ist für .NET Framework mindest genauso wichtig wie .NET Core.
Wer das nicht verinnerlicht hat, hat das aktuelle und zukünftige .NET Ökosystem noch nicht verstanden.

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 5 Jahren

Durch Span<T> kommt eine Menge Arbeit auf das .NET Framework zu.
Ich vermute, dass dies erst mit .NET Framework 4.9 kommen wird; aber Microsoft hat bereits bestätigt, dass Span<T> in den Standard und in das Framework kommt.

Span<T> und Co ist extrem wichtig für die Welt rund um .NET Core (und damit Web-nahe Technologien wie Web und Apps); u.a. wegen UTF-8 Strings, mit der nun mal die ganze Übertragung im Web läuft und damit das ständige Casten in .NET wegfällt.
Daher war es notwendig, dass dies in den Standard kommt - auch wenn das Framework das erst später bekommt.

Span<T> ist aber weniger wichtig für das .NET Framework bzw. üblicherweise für Applikationen, die das .NET Framework benötigen.
Siehe dazu auch die Inhalte von ASP.NET Core 3.0 nur noch mit .NET Core, nicht mehr mit .NET Framework (Platzhalter)

D
152 Beiträge seit 2013
vor 5 Jahren

Wenn Span<T> ins .NET Framework kommt, wird darauf wohl auch ASP.NET Core laufen werden.
ASP.NET Core wird doch bestimmt auf .NET Standard 2.1 aufsetzen.

62 Beiträge seit 2017
vor 5 Jahren

Wobei Microsoft ja immer betont, das die Entwicklung des .NET Frameworks langsamer verlaufen wird, weil man darauf achten will/muss, das es möglichst keine breaking changes gibt und das Dinge, die z.B. mit dem Framework 4.8 funktionieren, auch mit dem Framework 4.9 funktionieren. Bei .NET Core ist das ja nicht zwangsläufig der Fall, weswegen man die einzelnen Runtimes und SDKs ja auch parallel installieren (und sich den Rechner damit zumüllen) kann.

Wer ordentlichen Code schreibt, lebt entspannter 8)

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 5 Jahren

Wenn Span<T> ins .NET Framework kommt, wird darauf wohl auch ASP.NET Core laufen werden.

Microsoft muss einen halben Handstand machen, damit beide Frameworks funktionieren.

ASP.NET Core läuft schließlich als Applikation gegen eine Runtime(netcoreapp), nicht gegen einen Standard (netstandard).
Daher nein: Ab ASP.NET Core 3.0 fliegt die .NET Framework Unterstützung raus.

D
152 Beiträge seit 2013
vor 5 Jahren

ASP.NET Core läuft schließlich als Applikation gegen eine Runtime(netcoreapp), nicht gegen einen Standard (netstandard).

Das ist schon klar das ASP.NET Core auf einer Runtime läuft.
Aber die Entwicklung/Kompilieren läuft doch gegen den .NET Standard. Und solange die Runtime den Standard unterstützt sollte es doch auf jeder entsprechenden Runtime laufen.
Was bisher doch der Fall ist. Oder irre ich mich da, bzw. ändert sich das?

6.911 Beiträge seit 2009
vor 5 Jahren

Hallo,

Durch Span<T> kommt eine Menge Arbeit auf das .NET Framework zu. Span<T> ist über das NuGet-Paket System.Memory auch für .NET Full verfügbar. Allerdings in der Implementierungs-Variante "Slow Span", d.h. ohne direkte Runtime-Unterstützung (JIT + GC) wie es bei .NET Core ("Fast Span") der Fall. Also funktionieren tut es, nur nicht so performant wie bei "Fast Span". Die fehlenden JIT + GC Teile werden durch eine etwas andere Implementierung "emuliert".

UTF-8 Strings, mit der nun mal die ganze Übertragung im Web läuft und damit das ständige Casten in .NET wegfällt.

Nicht nur das Casten, sondern v.a. das Allozieren von Speicher fällt weg. Generell vereinfach sich das typische Parsen von utf-8 -> parser -> string (allocate + utf-16) -> logic -> writer -> utf-8 zu utf-8 parser (uses memory pool) -> logic -> writer -> utf-8 writer. Es fallen somit auch die Konvertierungen zwischen UTF-8 und der String-Repräsentation in UTF-16 vom Framework weg. Das spart natürlich eine Menge Zeit und Arbeit für den GC.

Wenn Span<T> ins .NET Framework kommt, wird darauf wohl auch ASP.NET Core laufen werden.

Es geht ja nicht nur um Span<T> (siehe oben), sondern auch um sonst jede Menge APIs, die sich in .NET Core schneller umsetzen lassen als in .NET Full, da bei .NET Full die (in-place) Kompatibilität ein wichtiges Ziel ist.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

62 Beiträge seit 2017
vor 5 Jahren

Man könnte auch ein wenig provokant sagen, das .NET Core die Spielwiese ist und allles, was sich bewährt hat und keine Inkompabilitäten verursacht, mit hoher Wahrscheinlichkeit früher oder später im .NET Full landet.

Wer ordentlichen Code schreibt, lebt entspannter 8)

6.911 Beiträge seit 2009
vor 5 Jahren

Hallo,

provokant sagen, das .NET Core die Spielwiese ist

Ich verstehe HeikoAdams, aber damit keine Missverständnisse auftreten zur Klarstellung:
*.NET Core wird nach https://semver.org/ versioniert und Installationen sind side-by-side. *.NET Full hat irgendeine MS-Versionierung, aber die Installation (der gleichen Haupt-Versionsnummer) is in-place, d.h. eine neue Version überschreibt die Alte. Hier kann MS sich nicht erlauben Inkompatibilitäten einzubauen. Es wäre fatal wenn eine Anwendung die unter .NET 4.7.1 fehlerfrei lief unter .NET 4.7.2 Bugs hat. Bei .NET Core kann der Entwickler explizit gegen eine Version testen und so die "Freigabe" dafür erteilen, zumindest lässt sich das Testen.

Hinzu kommt dass bei MS die Ressourcen -- zumindest sagen sie das so -- gar nicht so groß sind, um .NET Core und .NET Core die gleiche Liebe zukommen zu lassen und der Fokus liegt klar auf Ersterem.

Mit der "Spielwiese" hat HeikoAdams aber insofern recht, dass .NET Core als Open-Source-Projekt entwickelt wird und somit via Issues / PR die Community ungleich mehr Mitwirken an der "Gestalt" der APIs, vom Framework, etc. hat.
Während bei .NET Full der Weg via Connect / UserVote eher mühsam und langatmig war.

Anmerkung: der Schritt .NET Core als OS-Projekt zu erstellen war großartig.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 5 Jahren

Naja; aber HeikoAdams auch entsprechend gleich-provokant zu antworten: seine Aussage ist Bullshit.

.NET Core hat einen anderen Fokus als das .NET Framework.
Zu behaupten, dass .NET Core eine Spielewiese sei: siehe oben.

62 Beiträge seit 2017
vor 5 Jahren

.NET Core hat einen anderen Fokus als das .NET Framework.
Zu behaupten, dass .NET Core eine Spielewiese sei: siehe oben.

Hättest Du meinen Post richtig gelesen, dann hättest Du gemerkt, das ich mit "Spielwiese" gemeint habe, das man dort quasi Dinge ausprobieren kann, ohne auf .NET Full Rücksicht nehmen zu müssen.

Wenn sich diese Dinge dann bewährt haben, kann man sie ggf. in die nächste Major-Version von .NET Full portieren.

Aber falls Dich einfach nur der Begriff gestört hat: Testlabor 8)

Wer ordentlichen Code schreibt, lebt entspannter 8)

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 5 Jahren

Auch der Begriff TestLabor ist völlig an den Haaren herbei gezogen, an der Sache und Realität völlig vorbei - und typisches Stammtisch-Gebrabbel.
.NET Core ist keine Plattform mit einer gering(er)en Qualität (zum Framework), wie Du es - egal mit welchen Worten - versuchst zu verbreiten.

Wenn Du bei diesem Aussageinhalt - egal mit welchem Wort - bleibst, dann kann man Dir leider nur attestieren, dass Du das Ziel bzw. die unterschiedlichen Ziele von .NET Framework und .NET Core leider noch nicht verinnerlicht hast.
Genau das würde ich aber von einem Software Entwickler im .NET Stack erwarten.

6.911 Beiträge seit 2009
vor 5 Jahren

Hallo Abt und HeikoAdams,

ich hab den Verdacht ihr redet (schreibt) aneinander vorbei. HeikoAdams' Begriff sind hier zwar nicht die treffensten, aber ich lese schon heraus dass er verteht worum es geht.

Das Testlabor für .NET findet sich in https://github.com/dotnet/corefxlab
Dort werden neue "Dinge" ausprobiert und zu einer bestimmten Reife gebracht. Sollte es sich dort als nützlich herausstellen, so wird es nach https://github.com/dotnet/corefx übertragen und zur "Serienreife" weiter entwickelt. corefx ist somit kein Labor und keine Spielwiese 😉
Aber Features können hier rascher umgesetzt werden als es bei .NET Full der Fall ist -- siehe oben. Ist ein Feature jedoch nützlich, so kann es auch nach .NET Full portiert werden -- wie hier der Ablauf genau ist, bleibt wohl eher intern bei MS.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

62 Beiträge seit 2017
vor 5 Jahren

Genau so habe ich es gemeint, wie gfoidl es geschrieben hat. 👍

Wer ordentlichen Code schreibt, lebt entspannter 8)