.NET Framework -lib auf .NET Core oder .NET Standart migrieren
-
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
-
@hustbaer sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
@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
Nein, ist es nicht. Zumindest nicht, wenn man nach den ursprünglichen Vorschlägen und Definitionen von REST geht. Was aber tatsächlich passiert ist, dass sich REST völlig verblödet hat und es nur noch ein halb-herziges REST ist. Wenn es noch hoch kommt, werden immerhin noch die HTTP Verben korrekt eingesetzt. Man sollte in den Fällen besser von einer HTTP API reden. Aber REST Dokumente sollten eigentlich navigierbar sein und spezifische Antworten auf spezifische Anfragen liefern. REST ist viel komplizierter als was üblicherweise als REST angeboten wird.
Ich weiss leider gerade nicht, wo man dazu eine gute Zusammenfassung findet. Wikipedia ist da nicht wirklich gut. Ich habe lange eigentlich auch mehr HTTP APIs geschrieben. Als ich mich dann für GraphQL anfing zu interessieren und nach den Unterschieden suchte, wurde mir eigentlich erst klar, dass ich bisher HTTP REST falsch eingesetzt habe. Und wenn du nach sowas suchst, findest du z.B. das hier: https://goodapi.co/blog/rest-vs-graphql
Aber der bleibt dort immer noch recht oberflächlich.
-
Ja gut das ist dann wieder so ein Fall von "nein, X ist eigentlich voll cool, nur keiner macht X weil keiner X versteht". In dem Fall bin ich einer von denen die X - anscheinend - nicht richtig verstanden haben, und daher ist es für mich weiterhin nicht brauchbar.
-
@hustbaer sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Ja gut das ist dann wieder so ein Fall von "nein, X ist eigentlich voll cool, nur keiner macht X weil keiner X versteht". In dem Fall bin ich einer von denen die X - anscheinend - nicht richtig verstanden haben, und daher ist es für mich weiterhin nicht brauchbar.
Das ist in Ordnung. Und die Experten von X stimmen dir dann sogar zu.
-
Huhu, d.h. ASP.NET und ASP.NET Core unterscheiden sich so emorm?
Eine einfach Web- UI, um eine Applikation zu parametrieren, (als self-hostet-web-server in einem windows-dienst) aber schon da weiß ich nicht wie ich das vernünftig via ASP.Net machen soll, Layout Gestaltung etc. So der MVVM Gedanke von WPF und Kapselung in Controls etc. in ASP.NET in MVC nach zu empfinden, fällt mir schwer.
Cool wäre es , wenn es eine "WPF/XAML to HTML5 Converter" gäbe
Oder eine gescheites Tutorial , mit dem ich Step-by-Step ne Web- App basteln kann..damit es klick macht...
-
Ja, ASP.NET und ASP.NET Core unterscheiden sich enorm. Mit ersterem würde ich nicht mehr anfangen, da es eine der ganz wenigen Technologien ist die Microsoft nicht einmal mehr nach .NET 5 bringen wird, d.h. du baust quasi schon Legacy-Wissen auf.
Für ASP.NET Core gibt es eigentlich im Internet genügend Tutorials, hast du Google schon benutzt? Ganz offiziell ist der Getting-Started-Guide von Microsoft: https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/introduction/getting-started
MfG SideWinder
-
Guten Morgen,
ja hab Google schon benutzt, und habe mal ein Tutorial (aber ASP.NET) gemacht, was dann wohl fürn A..... war;)
Wenn ich mich entscheiden würde, ASP.NET nur als Backend zu nehmen, und die Frontend Geschichten mit anderen Technologien zu machen, was würde Ihr da empfehlen. Gibt es hierfür auch IDE und Frameworks, so das man das
html5 layout an Scripts nich komplett "von Hand" machen muss?Ich habe mal React angeschaut, was ich eigentlich ganz cool finde. Aber eine IDE bzw. ein Tool, mit dem ich Frontend content "relativ" einfach bauen kann wäre ideal.
Vielen Danke Euch bisher;)
