Hey Leute,

ich wollte mich in meinem Urlaub mal daran Setzen sowas wie nen Einstieg in die neue Welt von .NET Core bzw. ASP.NET Core zu schreiben.
Da jedoch inzwischen .NET Core und .NET FX sich recht ähnlich sind, und grundlegende Tutorials bald wie Sand am Meer da sein werden, dachte ich mir, ich Sammle lieber Themen, die euch brennend Interessieren und beantworte die dann entweder hier nach und nach, oder aber gesammelt in einem neuen Thema, mit einem Roten Faden.

Ein kurzer Hinweis noch, wenn ich über ASP.NET Core rede, dann rede ich leider nur von der Erstellung von WebAPIs, nicht von ganzen Webseiten.
Ebenso bin ich auch noch nicht in EntityFramework (Core) bewandert.

Ansonsten sind alle Fragen zum Thema .NET Core erlaubt, die euch schon immer interessiert haben, egal ob ihr bereits mit .NET Core gearbeitet habt, oder bisher noch nie damit in Berührung gekommen seid.

@simpelSoft wie @slice bereits erwähnte, ist das lediglich eine Namensänderung. .NET Core wird einfach zu .NET.

Das ganze stammt daher, dass ursprünglich .NET Core wohl eher als, wie der Name es vermuten lässt, der absolute "Kern" von .NET darstellen sollte, der dann dafür aber Cross-Plattform fähig ist. Gleichzeitig dazu entstand ja auch .NET Standard, was Cross-Plattform Libraries ermöglicht und z.B. in Xamarin.Forms seit seiner Entstehung rege Anwendung findet, da die vorherige Lösung via Portable Class Libraries(PCL) seeehr viele Ecken und Kanten hatte.

Die beiden neuen Projekttypen fanden in der Community enormen Anklang, und war dann auch bereit an allen Ecken und Enden mitzuhelfen, da sämtliche Bestandteile von .NET Core, vom Compiler bis zum Hello-world Template, Open-Source sind. Dadurch sind wir nun bei .NET Core 3.2 und .NET Standard 2.1 die inzwischen das alte .NET Framework 4.8, soweit mir bekannt, komplett abdecken, und sogar neue Klassen eingeführt haben.
Deswegen dann auch nächstes Jahr der Wechsel vom Namen .NET Core zu .NET, denn das alte .NET Framework wird, abgesehen von Sicherheitspatches, und neueren TLS Versionen, nicht mehr großartig weiterentwickelt.

Edit:
Ich hatte völlig vergessen, dass .NET Core ursprünglich den Namen .NET 5.0 trug, das jedoch dann später aufgrund der Verwechslungsgefahr, und der wesentlich reduzierten API Abdeckung gegenüber dem eigentlichen .NET nicht wirklich tragbar war.


Und da komme ich nun zu @Nofear23m was die neuen Klassen bzw. APIs angeht.
Die höhere Performance wird erreicht, indem man näher am eigentlichen Speicher arbeitet bzw. Heap allocations versucht zu verhindern. Das wird hauptsächlich mit den beiden neuen
"Collections"
Memory<T> und Span<T> die direkt einen Bereich im Arbeitsspeicher abbilden.
Seit .NET Core 2.1 / .NET Standard 2.1 sind diese beiden Typen in .NET Implementiert und beschleunigen entweder durch das benutzen neuer Überladungen oder versteckt im Hintergrund viele Bereiche. Da wären z.B. String-Operationen, alles was mit Streams zu tun hat, egal ob aus dem Netzwerk, von der Platte, oder direkt aus dem Speicher. Mehr dazu kannst du auch hier nachlesen. Das Deutsch dort scheint sogar mal akzeptabel zu sein

Edit:
Das einzige was ich an direkten Performance-Tests zwischen .NET FX und .NET Core finden konnte, war dieses hier. Es handelt sich hierbei um ein Vergleich zwischen .NET 4.7 und .NET Core 2.0 in Bezug auf Operationen mit Collections. Die Performancesteigerungen beliefen sich hierbei auf 20-50%.

Edit Edit:
@xChRoNiKx hier ein Artikel zu dem was @slice angesprochen hat:
aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

simpelSoft schrieb:

muss ich ja wohl oder übel die Core 3.1 Desktop Runtime mit über 50MB ausliefern

Das kommt darauf an. In deinem Veröffentlichungsprofil kannst du entsprechend festlegen, ob du die App "Eigenständig", oder "Frameworkabhängig" ausliefern möchtest. Selbstständig liefert hierbei die Runtime mit, während Frameworkabhängig davon ausgeht, dass die entsprechende Runtime, oder eine höhere Patch-Version bereits auf dem Rechner installiert ist.

@simpelSoft Und noch was für nach der Portierung (falls du dich dazu entscheidest).
Wenn du komplett auf .NET Core 3.1 und .NET Standard 2.1 setzt, gibt es eine weitere Option im Veröffentlichungsprofil, die dir gefallen dürfte:
"Nicht verwendete Assemblys kürzen" : Das entfernt sämtliche dlls, egal ob aus Packages, oder aus der Runtime, die von deiner Anwendung nicht benötigt werden (Achtung bei Reflection). Es ist jedoch bisher ein Vorschaufeature, und scheint bereits mit .NET Standard 2.0 nicht mehr zu funktionieren. Zumindest habe ich es damit bisher nicht zum laufen gebracht.

Man kann natürlich auch festlegen, welche Assemblies nicht entfernt werden sollen:
github.com/mono/linker/blob/ma…rc/ILLink.Tasks/README.md