myCSharp.de - DIE C# und .NET Community (https://www.mycsharp.de/wbb2/index.php)
- Externes (https://www.mycsharp.de/wbb2/board.php?boardid=80)
-- Szenenews (https://www.mycsharp.de/wbb2/board.php?boardid=75)
--- .NET Standard 2.1 vs 2.0 (https://www.mycsharp.de/wbb2/thread.php?threadid=121246)


Geschrieben von Abt am 06.11.2018 um 19:34:
  .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


Geschrieben von trashkid2000 am 06.11.2018 um 21:36:
 
Lieben Dank Daumen hoch
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 smile


Geschrieben von T-Virus am 06.11.2018 um 21:50:
 
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


Geschrieben von Abt am 06.11.2018 um 22:03:
 
Das sieht teilweise nur so aus, weil sich viele Klassen nur durch den Kopf geändert haben, weil zB das Attribut

C#-Code:
[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.

Zitat von T-Virus:
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.


Geschrieben von david.m am 06.11.2018 um 22:05:
 
.NET Standard 2.1 wird wohl nicht vom .NET Framework unterstützt.

 https://www.heise.de/developer/meldung/NET-Standard-2-1-bindet-rund-3000-neue-APIs-ein-4212045.html
 https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/


Geschrieben von Abt am 06.11.2018 um 22:08:
 
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)


Geschrieben von david.m am 07.11.2018 um 07:49:
 
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.


Geschrieben von HeikoAdams am 07.11.2018 um 08:34:
 
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.


Geschrieben von Abt am 07.11.2018 um 10:17:
 
Zitat von david.m:
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.


Geschrieben von david.m am 07.11.2018 um 10:28:
 
Zitat von Abt:
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?


Geschrieben von gfoidl am 07.11.2018 um 11:45:
 
Hallo,

Zitat:
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".

Zitat:
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.

Zitat:
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ü


Geschrieben von HeikoAdams am 08.11.2018 um 08:05:
 
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.


Geschrieben von gfoidl am 08.11.2018 um 10:05:
 
Hallo,

Zitat:
provokant sagen, das .NET Core die Spielwiese ist

Ich verstehe HeikoAdams, aber damit keine Missverständnisse auftreten zur Klarstellung: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ü


Geschrieben von Abt am 08.11.2018 um 11:04:
 
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.


Geschrieben von HeikoAdams am 12.11.2018 um 09:48:
 
Zitat von Abt:
.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 cool


Geschrieben von Abt am 12.11.2018 um 10:19:
 
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.


Geschrieben von gfoidl am 12.11.2018 um 16:38:
 
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ü


Geschrieben von HeikoAdams am 14.11.2018 um 09:48:
 
Genau so habe ich es gemeint, wie gfoidl es geschrieben hat. Daumen hoch


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 23.10.2019 04:45