.NET Framework -lib auf .NET Core oder .NET Standart migrieren
-
Hallo Leute,
ich möchte eine .NET Framework Bibliothek in einem .NET Core (2.0) Projekt verwenden.
Nun stelle ich mir die Frage, ob ich diese Bibliothek (abgesehen davon dass auch alle Drittanbieter Abhängigkeiten auch für .net core existieren) in .NET Core ODER in .NET Standart migrieren soll.Die .NET Standard definiert ja die gemeinsame Grundlnage (API) für Framework und Core.
Aber ich kann ja eine .NET core lib in einer .Net Framework verwenden (oder irre ich mich).
Evtl. habe ich die Differenzierung Framework/Core/Standard nicht richtig verstanden....hmm
Schönen Tag Euch
-
Und was genau ist nun deine Frage? Wenn du eine Bibliothek in .Net Core verwenden willst, dann schreib sie für .Net Core.
Vergiss grundsätzlich etwas den .Net Standard. Der ist nur interessant, wenn du auch für Mono oder z.B. Unity entwickeln willst. Das .Net Framework selbst wird in Zukunft verschwinden und vollständig durch .Net Core ersetzt werden. Siehe dazu: https://devblogs.microsoft.com/dotnet/introducing-net-5/ und https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/
-
@SoIntMan sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Aber ich kann ja eine .NET core lib in einer .Net Framework verwenden (oder irre ich mich).
Ich glaube das ist seit kurzem möglich, ja - aber auch nur wenn die Library keine APIs verwendet die problematisch wären (bspw. AppDomains, Reflection.Emit, ...)
@Dravere : bis .NET 5 im Herbst 2020 kommt würde ich breit einzusetzende Libraries sehrwohl noch für .NET Standard schreiben.
MfG SideWinder
-
Guten Morgen,
naja die Frage habe ich mir gestellt, weil ich mir noch nicht 100% klar war /bin was eigentlich genau der Unterschied zwischen Standart und Core ist.
Wenn ich .auf NET core entwickle, habe ich ja die Möglichkeit Linux executables zu builden, für was brauche ich dann noch Mono?
Dewewegen bin ich da verwirrt..
.NET Standart definiert die Interfaces und core/framework implementieren diese !?
-
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
