.NET Framework -lib auf .NET Core oder .NET Standart migrieren
-
Dann lies auch mal den Artikel zu .NET Standard.
Ja, .NET Standard ist ein Interface und beschreibt welche Features (je Version) verfügbar sein müssen/sollen und .NET Core bzw. .NET Framework implementieren diese (ab jeweils einer bestimmten Version), aber diese bieten darüberhinaus aber auch weitere Funktionalität an, so daß du bei einer .NET Standard-Library also nur den kleinsten gemeinsamen Nenner abdeckst.
-
@SoIntMan sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
der Unterschied zwischen Standart und Core
Das eine ist ein Rechtschreibfehler und das andere Englisch.
-
@SoIntMan Mono erfüllt ebenfalls den .NET Standard. Mono setzt aber andere Schwerpunkte als .NET Core. Bspw. ausführbar auf anderen Prozessorarchitekturen, bspw. auf Mobiltelefonen (Einsatz bei Xamarin), es kann .NET Bytecode interpretieren, etc.
https://stackoverflow.com/questions/37738106/net-core-vs-mono fand ich einmal sehr gut, aber es ist an vielen Stellen schon sehr veraltet.
MfG SideWinder
-
@SideWinder sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
@Dravere : bis .NET 5 im Herbst 2020 kommt würde ich breit einzusetzende Libraries sehrwohl noch für .NET Standard schreiben.
Naja, bloss wozu? Erst recht wenn .Net Framework 4.8 nur den .Net Standard 2.0 implementiert und keine Pläne vorhanden sind, dieses noch irgendwie mit dem .Net Standard mitzuführen. Und die Bibliothek die er migrieren will, läuft ja bereits auf dem .Net Framework. Dann würde ich mich wirklich nur auf .Net Core konzentrieren, ausser er will noch Mono und Unity unterstützen.
@SoIntMan Das .Net Framework ist viel umfassender als der .Net Standard. Mono ist entstanden bevor der .Net Standard definiert wurde oder .Net Core rauskam. Mono hatte das Ziel die meisten Teile vom .Net Framework auf andere Plattformen zu bringen. Heisst somit, dass Mono viel mehr kann als der .Net Standard und als .Net Core (wobei .Net Core stark aufholt). Ein einfaches Beispiel davon ist die Unterstützung von WinForms. Dies ist (noch) nicht im .Net Standard definiert.
Ich denke es ist wichtig hier auch ein wenig den historischen Aspekt zu sehen. Es kam das .Net Framework (ca. Feb 2002), dann Mono (ca. Jun 2004), viel später .Net Core (ca. Jun 2016) und erst dann der .Net Standard (ca. Sep 2016).
-
Ich glaube nicht, dass Windows Forms jemals Teil von .NET Standard wird, das wäre komisch. Hast du dafür Quellen?
Naja, bloss wozu?
Damit fremde Personen die Library sowohl für .NET FX als auch für .NET Core installieren können. Und nicht zwei verschiedene NuGet-Packages notwendig sind.
MfG SideWinder
-
@SideWinder sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Ich glaube nicht, dass Windows Forms jemals Teil von .NET Standard wird, das wäre komisch. Hast du dafür Quellen?
Naja, indirekt. So wie ich es verstehe, werden die Unterstützung für Desktop Packs ein Teil des Standards werden. Die konkreten Desktop Packs dagegen werden nicht im Standard sein. Siehe z.B. die Graphik hier drin: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/
Aber ich muss sagen, dass ich noch nie genaue Details dazu gelesen habe. Meistens wird bei Desktop Packs von .Net Core geredet. Es macht die Sache auch nicht gerade einfacher, weil Micrsoft .Net Core und .Net Standard gerne etwas vermischt.
Naja, bloss wozu?
Damit fremde Personen die Library sowohl für .NET FX als auch für .NET Core installieren können. Und nicht zwei verschiedene NuGet-Packages notwendig sind.
Klar, dass stimmt im Allgemeinfall. Aber in diesem Fall? Vielleicht verstehe ich auch SoIntMan nicht richtig. Wenn ich eine Bibliothek ausschliesslich für .Net Core verwenden möchte, dann würde ich aktuell nicht gegen den .Net Standard entwickeln. Und trotzdem wäre die Bibliothek sehr zukunftssicher ausgerichtet.
-
Guten Morgen Leute,
vielen Dank für die vielen Antworten, ist mir jetzt schon alles klarer. Ich habe die Bibliothek jetzt auf .NET Standard migriert, und kann ihn nun in Framework und Core verwenden.. yeah.:)
Aber es hätte auch gereicht ihn in .NET Core zu migrieren, da in Zukunft nur auf das .NET Core gesetzt ,aber eigentlich
auch egal ist .NET 5 vereint ja dann eh alles!?Ich habe immer gedacht das MONO ausgestorben sei, und nicht mehr weiter entwickelt wird. Und ja auch durch das Core ersetzt werden kann (hinsichtlich Plattform-Unabhängigkeit) oder nicht?
-
@SoIntMan sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Ich habe immer gedacht das MONO ausgestorben sei, und nicht mehr weiter entwickelt wird. Und ja auch durch das Core ersetzt werden kann (hinsichtlich Plattform-Unabhängigkeit) oder nicht?
Mono ist sehr lebendig und hat grosse Fortschritte gemacht, jetzt wo Microsoft mit vielem in .Net Open-Source gegangen ist. Sie haben z.B. selber stark vom Roslyn Compiler in .Net Core profitieren können. Tot war es definitiv nie: https://github.com/mono/mono/graphs/contributors
Mono wird an vielen Stellen eingesetzt und ich sehe nicht, dass es so schnell verschwindet. Core wird zwar Desktop Packs bekommen, aber bisher habe ich von Microsoft nur die Unterstützung von Windows mittels Desktop Packs mitbekommen. Wenn du also GUIs unter Linux, Android, iOS, usw. haben möchtest, bist du weiterhin auf Mono angewiesen. Unity selber setzt auch immer noch auf Mono.
Das einzige was .Net Core plattformunabhägig kann sind Headless-Applikationen und über Asp .Net Core und Kestrel Webanwendungen. Gerade die Webanwendungen scheinen mir etwas zu sein, worauf Microsoft viel Wert legt. Ich vermute, dass daher eine gewisse Motivation stammt, plattformunabhängig zu sein, da viele Webserver Linux verwenden. Mit .Net 5 soll ja auch die plattformunabhängigkeit vom Entity Framework besser werden.
-
Hmm .... aber ab .NET Core 3.0 soll doch Froms und WPF dabei sein? Dann müssten doch auch GUI Applikationen Plattform unabhängig sein!?
-
@SoIntMan sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Hmm .... aber ab .NET Core 3.0 soll doch Froms und WPF dabei sein? Dann müssten doch auch GUI Applikationen Plattform unabhängig sein!?
Nein. Desktop Packs sind plattformspezifisch. DotNet Core 3.0 wird Desktop Packs unterstützen. Ein solches Desktop Pack wird dabei sein für Windows, welches Forms, WPF und all das Zeug beinhaltet.
-
Ich habe die Tage bei einem .NET Meetup in Wien mit einem Xamarin-Mitarbeiter der an Mono arbeitet gesprochen (haha, ja, Xamarin ist jetzt Microsoft, d.h. Microsoft entwickelt derzeit als einer der Hauptteilnehmer an Mono) und der meint Mono langfristig kann man nicht sagen, aber mittelfristig (die nächsten 5 Jahre) verschwindet es sicher nicht, da damit Dinge möglich sind (wie gesagt: Interpretieren, lauffähig auf alternativen Prozessorarchitekturen, Mobiltelefon-Tauglichkeit) die mit dem .NET Core Framework so noch nicht möglich sind.
MfG SideWinder
-
Vielleicht hilft das ja zum Einstieg in was und wofür: Demystifying .NET Core and .NET Standard
-
Ok hmm .. d.h. wenn ich GUI Apps mit NET.Core Plattform-Übergreifend entwickeln wollen würde, müsste ich GtkSharp oder so wohl nehmen.
Ist es denn ausgeschlossen, das solche Desktop-Packs nicht auch für andere Plattformen geben wird?EDIT: habe das hier gefunden https://github.com/AvaloniaUI/Avalonia , habt ihr schonmal davon gehört /gemacht?
-
Nein, ausgeschlossen ist es nicht, ich könnte es mir sogar sehr gut vorstellen, aber das wird nicht von heute auf morgen passieren.
Mit Avalonia habe ich noch nichts gemacht, ich schreibe nur ASP.NET Core Anwendungen in C#.
MfG SideWinder
-
JA ASP.NET finde ich auch sehr interessant, aber ich traue mich da nicht so ran, sofern ich mich mit Web-programmierung kaum auskenne, Tutorials habe ich bzg. asp.net auch schon gemacht, aber wenn ich was umsetzen will fehlt mir anfangs noch eine professionelle Hand. Will da nichts zusammenhacken um ans Ziel zu kommen
Apropo: Was wäre denn diesbezüglich ein guter weg, wenn ich mit ner WEB-GUI starten würde, Back-/Frontend mit ASP.NET und die Vorzüge von Razor nutzen, oder ASP.NET nur als backend (REST API) und eine Frontend-Framework benutzen ? Evtl. ist das auch eine sehr doofe Frage
-
Ist beides möglich, "moderner" ist wahrscheinlich Zweiteres, aber ersteres ist sicherlich einfacher. Wir nutzen auch in erster Linie server-side rendering weil man es sich an vielen Stellen sehr einfach machen kann (volles Typsystem, etc.) Client-side würde ich nur machen wenn du wirklich flüssige und häufige Updates benötigst.
MfG SideWinder
-
@SideWinder sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Ist beides möglich, "moderner" ist wahrscheinlich Zweiteres, aber ersteres ist sicherlich einfacher. Wir nutzen auch in erster Linie server-side rendering weil man es sich an vielen Stellen sehr einfach machen kann (volles Typsystem, etc.) Client-side würde ich nur machen wenn du wirklich flüssige und häufige Updates benötigst.
Aber mit TypeScript hast du auch ein volles Typsystem. Und in Zusammenarbeit mit z.B. VueJS und einem CSS Framework, womöglich die beiden gleich kombiniert wie bei Buefy, kann man sehr schöne, dynamische und moderne UIs basteln. Eine REST oder GraphQL Schnittstelle auf der Serverseite hilft dann auch gleich mit, dass man eine sehr schöne SoC hinbekommt.
Ich stimme aber definitiv zu, dass das erstere deutlich einfacher ist und womöglich für einen Anfänger geeigneter. Erst recht, wenn dieser vielleicht nicht so sattelfest in den sonstigen Websprachen und -frameworks ist.
@SoIntMan Noch ein womöglich wichtiger Hinweis. Es gibt Asp .Net und Asp .Net Core. Das sind zwei unterschiedliche Dinge. Wenn du mit .Net Core entwickeln willst, stelle sicher, dass du gegen Asp .Net Core entwickelst, heisst auch entsprechende Dokumentationen und Tutorials liest.
-
@Dravere sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Eine REST oder GraphQL Schnittstelle auf der Serverseite hilft dann auch gleich mit, dass man eine sehr schöne SoC hinbekommt.
Da bin ich mir nie sicher. Wenn die Web-Anwendung nur mit der auch-ansonsten-angebotenen REST-Schnittstelle programmiert, ist der Client meist sehr chatty, da das Web meist verschiedenste Domänen-Concerns auf einer Seite vereint. Da ist man dann oft performanter wenn man einen einzigen neuen Request gegen den Server macht und die ganze Seite neu aufbaut...ich befürchte man muss die REST-API und das REST-Backend oft trennen.
MfG SideWinder
-
@SideWinder Ich kann dir da nicht direkt folgen. Geht es dir um Performance oder Separation of Concerns (SoC)? Bezüglich Performance muss natürlich unbedingt eine gute REST-API vorhanden sein. Da ist allerdings meistens das Problem da, dass die REST-APIs eigentlich keine REST-APIs sind, sondern irgendwie indirekte SQL-Abfragen und es werden einfach die Tabellendaten rausgeliefert. In so einem Fall macht dann GraphQL viel mehr Sinn und hilft auch mit, dass mehrere Daten in einem einzelnen Request gebündelt werden.
Und mag sein, dass der Client etwas mehr Chatty wird, wobei ich mir da nicht wirklich sicher bin, aber wenn du z.B. kein Server-Rendering mehr hast und auch sonst die Logik auf der Serverseite einfacher wird, dann kannst du auch mehr Abfragen abhandeln.
Zudem sind es am Ende ziemlich sicher weniger Daten, welche übertragen werden. Wenn du Server-Rendering machst, dann überträgst du die Daten und die Darstellung. Im anderen Fall aber nur die Daten. Nur der Kaltstart der Seite ist etwas aufwendiger.
-
@Dravere sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Da ist allerdings meistens das Problem da, dass die REST-APIs eigentlich keine REST-APIs sind, sondern irgendwie indirekte SQL-Abfragen und es werden einfach die Tabellendaten rausgeliefert.
Was ja ziemlich genau das ist was REST predigt wie man es machen soll. Weswegen ich REST auch kacke finde
