myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Externes » Szenenews » .NET Standard 2.1 vs 2.0
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

.NET Standard 2.1 vs 2.0

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.903
Herkunft: Stuttgart/Stockholm


Abt ist offline

.NET Standard 2.1 vs 2.0

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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/...dard2.1_diff.md
06.11.2018 19:34 Beiträge des Benutzers | zu Buddylist hinzufügen
trashkid2000 trashkid2000 ist männlich
myCSharp.de-Mitglied

Dabei seit: 27.12.2010
Beiträge: 155


trashkid2000 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
06.11.2018 21:36 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.269
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
06.11.2018 21:50 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.903
Herkunft: Stuttgart/Stockholm

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
06.11.2018 22:03 Beiträge des Benutzers | zu Buddylist hinzufügen
david.m
myCSharp.de-Mitglied

Dabei seit: 02.06.2013
Beiträge: 82


david.m ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

06.11.2018 22:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.903
Herkunft: Stuttgart/Stockholm

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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)
06.11.2018 22:08 Beiträge des Benutzers | zu Buddylist hinzufügen
david.m
myCSharp.de-Mitglied

Dabei seit: 02.06.2013
Beiträge: 82


david.m ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
07.11.2018 07:49 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
HeikoAdams HeikoAdams ist männlich
myCSharp.de-Mitglied

avatar-4083.jpg


Dabei seit: 19.05.2017
Beiträge: 60
Entwicklungsumgebung: Visual Studio 2017 | VS Code
Herkunft: Coburg


HeikoAdams ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
07.11.2018 08:34 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.903
Herkunft: Stuttgart/Stockholm

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
07.11.2018 10:17 Beiträge des Benutzers | zu Buddylist hinzufügen
david.m
myCSharp.de-Mitglied

Dabei seit: 02.06.2013
Beiträge: 82


david.m ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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?
07.11.2018 10:28 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.550
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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ü
07.11.2018 11:45 Beiträge des Benutzers | zu Buddylist hinzufügen
HeikoAdams HeikoAdams ist männlich
myCSharp.de-Mitglied

avatar-4083.jpg


Dabei seit: 19.05.2017
Beiträge: 60
Entwicklungsumgebung: Visual Studio 2017 | VS Code
Herkunft: Coburg


HeikoAdams ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von HeikoAdams am 08.11.2018 08:05.

08.11.2018 08:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.550
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo,

Zitat:
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ü
08.11.2018 10:05 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.903
Herkunft: Stuttgart/Stockholm

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
08.11.2018 11:04 Beiträge des Benutzers | zu Buddylist hinzufügen
HeikoAdams HeikoAdams ist männlich
myCSharp.de-Mitglied

avatar-4083.jpg


Dabei seit: 19.05.2017
Beiträge: 60
Entwicklungsumgebung: Visual Studio 2017 | VS Code
Herkunft: Coburg


HeikoAdams ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
12.11.2018 09:48 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.903
Herkunft: Stuttgart/Stockholm

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
12.11.2018 10:19 Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.550
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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ü
12.11.2018 16:38 Beiträge des Benutzers | zu Buddylist hinzufügen
HeikoAdams HeikoAdams ist männlich
myCSharp.de-Mitglied

avatar-4083.jpg


Dabei seit: 19.05.2017
Beiträge: 60
Entwicklungsumgebung: Visual Studio 2017 | VS Code
Herkunft: Coburg


HeikoAdams ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Genau so habe ich es gemeint, wie gfoidl es geschrieben hat. Daumen hoch
14.11.2018 09:48 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 9 Monate.
Der letzte Beitrag ist älter als 9 Monate.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 20.08.2019 22:55