Aspnetcore: Diskussion: ASP.NET Core 3.0 kann nur unter .NET Core ausgeführt werden

Ich denke, das macht jetzt im Gesamtbild sehr viel Sinn. Sowohl .NET Core als auch ASP.NET Core gibt es schon lange genug, dass die Benutzer bereits die Möglichkeit hatten oder haben, zu diesem zu wechseln, ohne große Probleme zu verursachen (im Vergleich zu dem Zeitpunkt, als der Support in der Vergangenheit mit 2.0 zum ersten Mal eingestellt wurde). .

Ich bin jedoch traurig über die Auswirkungen auf bestimmte Komponenten von ASP.NET Core, die derzeit als separate Abhängigkeiten existieren können. Da dies wahrscheinlich bedeutet, dass die einzelnen Komponenten die netstandard-Unterstützung einstellen und stattdessen netcoreapp3.0 benötigen; und insbesondere mit # 3756 wären diese Komponenten außerhalb eines ASP.NET Core-Kontexts unbrauchbar.

Beispielsweise werden Projekte wie RazorLight dann effektiv gezwungen sein, die .NET Framework- und vor allem die .NET Standard-Unterstützung im Allgemeinen zu

Dies wird dazu führen, dass viele Leute, die den Umstieg auf das neue ASP.NET Core-Programmiermodell in ihrem Unternehmen verkauft haben, in weniger als 3 Jahren auf einer unterstützten und aktiv entwickelten Plattform auf einer nicht unterstützten Plattform im Dunkeln bleiben (. NET Core 2.1 LTS).

Ich bin nicht sicher, welche Analyse Sie verwendet haben, um diesen Schritt zu rechtfertigen, aber für das Ausführen von ServiceStack ASP.NET Core-Apps in .NET Framework sehen wir, dass die beliebteste Web-Corefx- Vorlage zum Ausführen von ASP.NET Core-Projekten in .NET Framework ist mehr als ein Drittel (33,8%) Anteil dann der gleiche leere Web - Vorlage , die für den Betrieb auf .NET Kern unsere beliebtestene Projektvorlage ist.

IMO 3 Jahre reichen nicht aus, um Kunden aufzugeben, die mit dem neuen ASP.NET-Programmiermodell begonnen haben oder auf dieses umgestiegen sind (um der stagnierenden ASP.NET Framework-Plattform zu entkommen), um jetzt herauszufinden, welche Plattform sie verkauft haben zu ihrer Organisation zu bewegen wurde aufgegeben.

Aus irgendeinem Grund gibt es Kunden, die aufgrund der Abhängigkeit von .NET Framework-Abhängigkeiten nicht zu .NET Core wechseln können. Wenn MS die Unterstützung für .NET Framework in ASP.NET Core 3.0 in zukünftigen IMO nicht beibehalten möchte, sollten Sie die Unterstützung erweitern für ASP.NET Core 2.1 unter .NET Framework über einen längeren Zeitraum von 7 Jahren. Die Migration bestehender Produktionssysteme kann Jahre dauern, seit dem Start von .NET Core ist klar, dass ASP.NET Framework stagnieren muss. Die offizielle Haltung lautet, dass ASP.NET Core das zukünftige Programmiermodell für .NET ist, jetzt werden es dieselben Kunden tun Stellen Sie bald fest, dass das neue Programmiermodell, zu dem sie umgezogen sind, in einigen Jahren nicht mehr unterstützt wird. Der beste Weg, um diese vorhandenen .NET-Kunden unterzubringen, besteht darin, .NET 2.1 für einen zusätzlichen LTS-Zeitraum zu unterstützen, zumindest für Sicherheitspatches (idealerweise auch zur Behebung von Fehlern).

".NET Framework töten", Folge 2: gleiche Geschichte, gleiche Charaktere : rofl:

Leider unterstreicht dies nur eines: Sie haben es völlig versäumt, .NET Standard zum Frontauto des .NET-Ökosystems zu machen . Es bewegt sich nicht so schnell wie es sollte und ist nichts anderes als ein kleinster gemeinsamer Nenner, der immer im allerletzten Moment aktualisiert wird, wenn alle Plattformen die neuen APIs enthalten (oder in Kürze enthalten werden).

Vielleicht bin ich es nur, aber ich habe nie verstanden, warum es sich nicht so schnell bewegte wie netcoreapp (was per Definition der erste ist, der die neuen APIs erhält).

Sie sind ein NuGet-Paketautor und möchten, dass sie die neuesten Inhalte verwenden? Ziel ist die neueste Version von netstandard : Sicher, dass zunächst nur Anwendungen auf der Basis von netcoreapp verwendet werden können, aber möglicherweise werden andere Plattformen - wie Xamarin, Mono oder .NET Framework - aufholen und die Leute können Ihre Pakete verwenden, ohne dass Sie etwas ändern müssen. So sollten die Dinge funktionieren.

Natürlich kann es eine Weile dauern, bis Nicht-.NET Core-Plattformen wie .NET Framework aufholen, da die Releases seltener und der Stabilitätsbalken viel höher sind, aber selbst wenn es 6, 12 oder sogar 18 Monate dauert, tue ich das nicht. Ich glaube nicht, dass es ein Problem ist, denn genau das wollen die Leute, wenn sie .NET Framework verwenden: ein stabiles Framework, kein sich schnell bewegendes Ziel.

Meiner Meinung nach wäre es ein viel besserer Ansatz, ASP.NET Core 3.0 als Ziel für ein neues netstandard TFM zu verwenden, das alle benötigten .NET Core-APIs verfügbar macht. Wenn Sie sicher sind, dass die neuen APIs stabil genug sind, portieren Sie sie zurück in .NET Framework, damit sie mit dem neuesten Standard kompatibel sind.

Ich bin sicher, die Leute würden es vorziehen, ein paar Monate warten zu müssen, bevor sie ihre .NET Framework-App auf die neueste ASP.NET Core-Version verschieben können, anstatt für immer auf einer alten Version mit einer superkurzen 3-Jahres-Unterstützung blockiert zu werden.

Tun Sie, was Sie versprochen haben: Machen Sie .NET Framework zu einem stabilen Framework, das sich langsamer entwickelt als eine Sackgasse für diejenigen, die Ihnen bei der Migration auf ASP.NET Core vertraut haben.

Das gefällt mir nicht. Zu Beginn des .net-Kerns hat Microsoft nicht mono oder .net framework als plattformübergreifende Option ausgewählt, und Sie sagten, dass es dort mehrere .net-Laufzeit gibt, also entwerfen Sie die .netstandard , jetzt gibt es noch viele Nuget-Pakete, die den .net-Kern nicht unterstützen (mittlerer Grund). Viele Entwickler werden das alte Programmiermodell für den asp.net-Kern beibehalten, wenn der asp.net-Kern nur auf dem .net-Kern ausgeführt wird. dann wird .net standard nur im Namen existieren (zumindest für den asp.net-Kern beginnen die Leute damit, nur netcoreapp Pakete zu erstellen).
Vielleicht kann der .net-Kern eines Tages das .net-Framework im Fenster ersetzen, aber was ist mit Mono und anderen Plattformen, die auf Mono (Xamarin, Unity3d) basieren?
und ein weiterer Grund, warum ich manchmal das .net-Framework bevorzuge, ist, dass das .net-Core-Share-Framework wirklich riesig ist. Wie groß ist Ihr Ordner C:/program file/dotnet wenn Sie Ihre App von .net Core 2.0 auf den neuesten .net Core 2.1 aktualisieren? In meinem Ordner befindet sich eine GB-Datei, die beim Aktualisieren der .net-Kernlaufzeit wächst. Das .net-Framework ersetzt jedoch nur die alte Version.

Tun Sie, was Sie versprochen haben: Machen Sie .NET Framework zu einem stabilen Framework, das sich langsamer entwickelt als eine Sackgasse für diejenigen, die Ihnen bei der Migration auf ASP.NET Core vertraut haben.

Wenn dies die optimale Strategie wäre, ist mein Vorschlag, das LTS zu erweitern, die Mindestgrenze, um bestehenden Kunden, die aggressiv für die Migration auf ASP.NET Core vermarktet wurden und nun auf einer zukünftigen, nicht unterstützten Plattform damit aufgegeben wurden, mehr Zeit zu geben Ankündigung.

Also .net Standard ist ein Witz? Ich hoffe, das Mono-Team wird Aspnetcore-Repos teilen und in Aspnetmono umbenennen, andernfalls kann ich den .net-Stack verlassen

Ich denke, dies bedeutet, dass wir bei meiner Arbeit niemals ASP.NET Core verwenden werden. Wir werden für immer bei ASP.NET bleiben, egal wie eine App auf Core portiert wird, da dies jetzt noch mehr Änderungen mit sich bringen würde.

Sicher, wenn Ihr Ziel darin besteht, keine Änderungen vorzunehmen, können Sie das Gleiche für immer tun. Wo ich arbeite, haben wir vor ein paar Jahren angefangen, ASP.NET Core zu verwenden, zunächst unter .NET Framework. Im Laufe der Zeit, als die .NET Core-Plattform ausgereift war und Funktionen erhielt, haben wir unsere Projekte auf netcoreapp umgestellt. Ein oder zwei ältere Projekte verwenden immer noch ASP.NET, und wir haben nicht vor, diese neu zu schreiben - es funktioniert Code. Aber für die neueren Sachen freuen wir uns auf Features wie Span.

Veränderungen können verschoben werden, aber sie können oder sollten nicht für immer vermieden werden - Technologie ändert sich und der Job eines Entwicklers erfordert immer das Erlernen neuer Dinge. Wenn Sie heute ASP.NET Core unter .NET Framework verwenden, ist es unwahrscheinlich, dass drei Jahre Arbeit erforderlich sind, um es auf .NET Core zu verschieben.

Komm zu .NET Core, das Wasser ist warm ...

Aus irgendeinem Grund gibt es Kunden, die nicht zu .NET Core wechseln können, weil sie sich nur auf .NET Framework-Abhängigkeiten verlassen ...

Im Ernst, Sie können .NET 4.x-Bibliotheken unter .NET Core 2.0 seit .NET Standard 2.0 verwenden . Es besteht jedoch die Möglichkeit, dass sie einige Funktionen verwenden, die .NET Core nicht bietet. Obwohl es das Windows Compatibility Pack für .NET Core gibt , das viele dieser Lücken schließt und viele weitere Funktionen in .NET Core 3.0 unterstützt werden, einschließlich WinForms und WPF usw.

Alle Blocker, die verhindern, dass eine ASP.NET Core-Anwendung von .NET Framework zu .NET Core wechselt, sollten wahrscheinlich in dotnet / corefx ausgelöst werden .

Für Xamarin; Ich könnte mich irren, aber ich gehe davon aus, dass es unwahrscheinlich ist, dass Sie damit einen Webserver unter iOS oder Android ausführen.

Bei Mono-Client-Apps kann der Webserver nicht mehr verarbeitet werden und auf .NET Core ausgeführt werden, während die Benutzeroberfläche in Mono ausgeführt wird. Kestrel war noch nie in der Lage, auf einer Big Endian-Plattform zu laufen , die einige der anderen Plattformen von Mono ausschließt, obwohl BSD-Varianten derzeit eine .NET Core-Lücke darstellen.

Für die Einheit; Spiele machen alle möglichen seltsamen Dinge. Vielleicht ist das ein Szenario, das nicht behandelt wird. wenn das Spiel den Webserver im Client verwendet hat; anstatt auf einem Server oder außerhalb von proc; wenn .NET Core diesen Teil ausführen könnte.

Außerhalb des ASP.NET Core-App-Modells; Beispiel: Für Bibliotheken ist .NET Standard wichtiger, da ASP.NET Core alle möglichen nützlichen Funktionen bietet, wobei Razor ein besonderes Beispiel ist.

Nicht alle Bibliotheken werden nur auf .NET Core umgestellt (z. B. Microsoft.Extensions.* bleiben als .NET-Standard erhalten), und es wäre wahrscheinlich hilfreich, bestimmte Szenarien anzugeben , die sich auf https: // auswirken würden github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416, damit sie berücksichtigt werden können; welche spezifischen Bibliotheken und / oder Funktionen in .NET Standard verfügbar gehalten werden können und nicht nur ein nebulöses "Alles".

ASP.NET Core führt viele Änderungen und neue APIs in .NET Core durch, und ich kann den Wunsch verstehen, diese Funktionen dann zu verwenden (da dies einer ihrer Anwendungsfälle war). Ansonsten ist es ein bisschen selbstzerstörerisch.

Auf der anderen Seite wäre es schön, wenn sie auch in einer .NET Standard-Version wären, damit andere Laufzeiten dann ASP.NET Core 3.0 unterstützen könnten, wenn sie mit der Implementierung beginnen. Realistisch gesehen würde das nicht bald sein (da .NET Standard 2.1 noch nicht fertiggestellt ist und es eine darüber hinausgehende Version sein müsste).

Vielleicht kehrt das ASP.NET Core-App-Modell zu einem späteren Zeitpunkt zu .NET Standard zurück, wenn die Dinge aufgeholt haben? Obwohl es für den .NET Standard-Prozess möglicherweise immer zu schnell ist, wie er derzeit funktioniert?

@ Gulbanana Was ist, wenn Ihr asp.net-Kern auf .net-Framework com verwendet? oder gibt es ein Nuget-Paket, das nur das .net-Framework unterstützt?

Ich glaube, es war nie eine Frage, ob der Umzug erfolgen sollte oder nicht, sondern nur wann.
Das letzte Mal, als dies zu einem ~ Diskussions-Shitstorm führte, war das Ökosystem nicht bereit, die Portierung vorhandener Apps zuzulassen.
Jetzt gibt es die Windows-Kompatibilitätspakete und WinForms und WPF kommen zu .NET Core.

Ich denke, dass die 2.1-Pakete, die es für .NET Framework gibt, einen guten Migrationspfad bieten: Migrieren Sie auf netfx zu 2.1 und dann zu .NET Core.

Dies ähnelt AngularJS vs Angular: Migrieren Sie vorhandenen Code zu Komponenten (hart) in der neuesten Version 1. * und wechseln Sie dann zur neuesten Angular-Version. Es ist super schwer, aber machbar.

Mit aufregenden neuen Funktionen, die sowohl zu CoreCLR als auch zu Mono hinzugefügt werden (z. B. Standardschnittstellenmethoden oder nur schnelle Spanne)s) die es niemals zu .NET Framework schaffen würden, erscheint es vernünftig, .NET Framework irgendwann hinter sich zu lassen.
Das bedeutet nicht unbedingt, dass .NET Framework nicht unterstützt wird, sondern dass es einfach so bleibt, wie es ist.

Es gibt immer noch einige Websites, die klassisches ASP verwenden (nicht ASP.NET, sondern das wirklich alte Zeug). Es funktioniert immer noch und wird unter Windows ausgeliefert. Sie würden damit einfach keine neuen Apps erstellen.
Ich glaube, dass dies in <10 Jahren bei .NET Framework der Fall sein kann.

Ich bin mit dem angeforderten erweiterten Support für 2.1 einverstanden, aber ich möchte, dass das Team die Downloads von 2.1-Paketen überwacht, um in 2-3 Jahren eine Entscheidung zu treffen, ob sie es ein wenig unterstützen (= wichtige Sicherheitsprobleme beheben) müssen etwas länger.

@ John0King COM wird in .NET Core 3.0 unterstützt.

Außerdem: Wir haben Legacy-Anwendungen, die Dinge wie .NET Remoting verwenden.
Aber das ist schon Vermächtnis.

Die Welt läuft im Wesentlichen mit Legacy-Code und wird dies auch weiterhin tun. Es ist eine geschäftliche Entscheidung, ob etwas auf eine "unterstützte" oder sogar "neue" Sache portiert werden soll oder nicht, aber bis dahin, wie

Ja, es ist erwähnenswert, dass es nicht so relevant ist, ob etwas „unterstützt“ wird - alte Apps müssen nicht auf ein neues Framework portiert werden, nur weil es verfügbar ist. Webserver sind jedoch aufgrund von Sicherheitsbedrohungen ein Sonderfall. Eine lange Zeit der Unterstützung von Sicherheitspatches für das LTS würde den Leuten helfen.

@gulbanana Beim Portieren von Anwendungen von System.Web auf ASP.NET Core wird nur eine höhere Leiste hinzugefügt, da Sie das Webframework und das zugrunde liegende Anwendungsframework ändern und dann inkompatible Abhängigkeiten aktualisieren oder austauschen müssen (was möglicherweise den Kauf neuer Anwendungen mit sich bringt Lizenzen).

Wenn Sie dann eine Kosten-Nutzen-Analyse durchführen würden, bin ich mir nicht sicher, ob dies für ASP.NET Core von Vorteil wäre.

Dies gilt insbesondere dann, wenn Sie Software auf Projektbasis entwickeln und natürlich jedes Projekt im Budget knapp genug ist. Obwohl eine regelmäßige Wartung natürlich möglich ist, ist es schwierig, den Austausch des gesamten Frameworks ohne erkennbaren greifbaren Nutzen zu rechtfertigen .

Wenn Sie dann eine Kosten-Nutzen-Analyse durchführen würden, bin ich mir nicht sicher, ob dies für ASP.NET Core von Vorteil wäre.

Also ... na ja ... lass es? Wenn Sie dann nicht zu ASP.NET - Core migrieren müssen es nicht tun ..
Ich versuche nicht, sarkastisch oder so zu klingen, aber wenn es keine geschäftliche Notwendigkeit gibt, eine Anwendung auf den "neuesten Dingen" zu halten, portieren Sie sie nicht. Der Vorteil ist, dass .NET Framework / ASP.NET classic weiterhin unterstützt wird und Ihre Anwendung unverändert ausgeführt wird.

Ich stimme zu, dass die Portierung häufig unnötig ist - ASP.NET zu ASP.NET Core ist eine große Änderung, und ein Teil dieser Änderung besteht darin, dass sich Core schneller bewegt (3.0 wird ebenso wie 2.0 API-Änderungen enthalten). In diesem Diskussionsproblem geht es jedoch um die Änderung von netfx zu corefx, und für die meisten ASP.NET Core-Apps ist dies keine große Änderung mehr.

Dies scheint den Zwischenpunkt "ASP.NET Core unter .NET Framework" zu entfernen, der Migrationen viel langsamer und einfacher machen würde. Danach migrieren Sie eine ASP.NET MVC / WebAPI / etc. Die Anwendung auf ASP.NET Core wird eine große Veränderung sein, bei der sowohl das Webframework als auch die zugrunde liegenden Laufzeiten gleichzeitig geändert werden.

Für große Unternehmensanwendungen erwarte ich, dass dies ziemlich schmerzhaft ist. Mein Team hat dies ein oder zwei Jahre lang genau beobachtet, aber:

• EntityFrameworkCore erledigt nicht alles, was wir benötigen, und erst jetzt mit .NET Core 3.0 kommt EntityFramework selbst zu .NET Core. Wie viel davon und auf welchen Plattformen es ausgeführt wird, wurde meines Erachtens nicht klar kommuniziert, und ich muss wahrscheinlich einen Vorschau-Build testen, um zu sehen.

• Die OData-Geschichte scheint in Bezug auf groß angelegte Anwendungen immer noch in der Luft zu liegen. Es ist eine beträchtliche Menge an (Neu-) Arbeit erforderlich, um von OData 3 / System.Data.Services zu OData 4 / WebAPI und höher zu wechseln. Dies ist etwas, das seit einigen Jahren nicht mehr gelöst wurde, und ich bin mir ehrlich gesagt nicht sicher, ob es jemals so sein wird.

Außerdem müssten wir jetzt alle anderen nicht unterstützten Technologien (AppDomains, Remoting usw.) zuerst abschneiden, anstatt diese Arbeit parallel oder zu einem späteren Zeitpunkt ausführen zu können.

Außerdem müssten wir jetzt zuerst alle anderen nicht unterstützten Technologien (AppDomains, Remoting usw.) abschneiden, anstatt diese Arbeit parallel oder zu einem späteren Zeitpunkt ausführen zu können.

Warum können Sie nicht zuerst auf 2.1 migrieren?

@davidfowl Wir könnten das wahrscheinlich als Vermittler verwenden, es sei denn, wir stoßen in 3.0 / 3.1 / etc. auf eine neue Funktion. das brauchen wir, um zu migrieren. Ich habe noch keine vollständige Analyse durchgeführt. Bisher wurden EF und OData größtenteils blockiert.

Neue Funktion in ASP.NET Core 2.1, die für die Migration benötigt wird? Ich meinte ASP.NET Core 2.1 unter .NET Framework.

Als dieses Problem vor ein paar Jahren auftauchte, habe ich mich darüber beschwert, dass es zu schwierig war, alles zu portieren. Hier ist ein Zitat aus einem alten Github-Kommentar, den ich damals gemacht habe:

Stellen Sie sich Webanwendungen vor, die Active Directory oder Office COM-Automatisierung verwenden oder mithilfe einer System.Drawing-basierten Bibliothek Miniaturansichten erstellen oder Code für eine WPF-App freigeben

Das Coole ist, dass ab .NET Core 3.0 alle diese Szenarien unterstützt werden. Es wurde viel Arbeit geleistet, um es einfacher zu machen.

@ Davidfowl auch ich.

Hypothetisch könnte es eine Funktion geben, die wir in ASP.NET/MVC/WebAPI verwenden und die nicht in 2.1 implementiert ist, sondern in einer späteren Version verfügbar ist. In diesem Fall wäre 2.1 kein praktikables Sprungbrett.

Ich müsste allerdings eine gründlichere Analyse durchführen, um zu sehen, ob wir tatsächlich etwas Kritisches brauchen, das nicht in 2.1 enthalten ist.

@PinpointTownes

Leider unterstreicht dies nur eines: Sie haben es völlig versäumt, .NET Standard zum Frontauto des .NET-Ökosystems zu machen . Es bewegt sich nicht so schnell wie es sollte und ist nichts anderes als ein kleinster gemeinsamer Nenner, der immer im allerletzten Moment aktualisiert wird, wenn alle Plattformen die neuen APIs enthalten (oder in Kürze enthalten werden).

Sie liegen nicht falsch, kennen aber die Ziele des .NET-Standards nicht. Das Ziel des Standards war nie, Innovationen voranzutreiben, sondern die Konvergenz voranzutreiben. Wenn Sie es aus diesem Blickwinkel betrachten, ist es eine Sache, die zurückbleiben muss, weil wir darüber nachdenken müssen, welche Konzepte universell sein können oder sogar universell sein sollten. Wenn Sie neugierig sind, wie dies aussieht, lade ich Sie ein, sich die über 35 PRs anzusehen, die ich in den letzten drei Wochen nach Überprüfung durch alle Eigentümer der .NET-Implementierung zusammengeführt habe.

Wir sehen .NET Core als die innovative Plattform, auf der Innovationen stattfinden. Wir haben verschiedene Funktionen entwickelt, mit denen wir die Abwanderung und die damit verbundenen Risiken besser bewältigen können als mit .NET Framework. Es sind jedoch nicht alle Funktionen, die für das .NET-Ökosystem von Bedeutung sind, Teil der .NET Core-Erfahrung. Beispielsweise ist die vorzeitige Kompilierung bei Xamarin und Unity viel wichtiger. Wenn wir .NET Core-Funktionen verwenden und zum Standard hinzufügen, müssen wir deren Laufzeitumgebungen, Betriebssysteme und Hardwareeinschränkungen berücksichtigen.

Vielleicht bin ich es nur, aber ich habe nie verstanden, warum es sich nicht so schnell bewegte wie netcoreapp (was per Definition der erste ist, der die neuen APIs erhält).

Die Realität ist, dass "sich schnell bewegen und Dinge zerbrechen" nicht etwas ist, das unser gesamtes Publikum schätzt. Es ist schon schlimm genug, wenn wir APIs in Hauptversionen von .NET Core entfernen müssen, aber mit dem .NET-Standard ist dies praktisch unmöglich. Wir müssen uns also etwas langsamer bewegen und nur Konzepte einbeziehen, von denen wir glauben, dass sie ausgereift genug sind, um hinzugefügt zu werden.

Tun Sie, was Sie versprochen haben: Machen Sie .NET Framework zu einem stabilen Framework, das sich langsamer entwickelt als eine Sackgasse für diejenigen, die Ihnen bei der Migration auf ASP.NET Core vertraut haben.

Das setzt immer noch die Annahme voraus, dass .NET Framework irgendwann alle Funktionen von .NET Core erhalten wird, jedoch mit einer zeitlichen Verzögerung. Wir haben gelernt, dass das einfach nicht realistisch ist. Wir können entweder entscheiden, keine drastischen Innovationen in .NET Core vorzunehmen, oder die technische Realität akzeptieren, dass ein guter Teil der neuen Funktionen niemals wieder zu .NET Framework zurückkehren wird. Wir glauben, dass wir unseren Kunden den bestmöglichen Service bieten, um die zentrale Wertschöpfung von .NET Framework (eine ausgereifte und umfassende Entwicklungsplattform) zu erhalten und Kunden gleichzeitig die Möglichkeit zu geben, neue Funktionen in .NET Core zu nutzen. In Zukunft würde ich erwarten, dass wir eher bereit sind, Innovationen in Bereichen durchzuführen, in denen Laufzeit-, Bibliotheks- und Sprachänderungen erforderlich sind, wie wir es für Span<T> getan haben. Diese Dinge sind zwar kostspielig, aber sie ermöglichen es uns auch, die Art und Weise zu ändern, wie Menschen Code schreiben können. Ein gutes Beispiel hierfür sind Standardimplementierungen von Schnittstellen, die Möglichkeit, generischen Code mit Arithmetik zu erstellen, Hardware-Eigenschaften zu verwenden usw. Und diese Funktionen sind wahrscheinlich genau die Art, die wir aufgrund des Risikos nicht auf .NET Framework zurückportieren werden .

Ich denke, es ist absolut sinnvoll, dass unser Web-Stack diese Funktionen nutzen kann. Die einzige Möglichkeit, dies zu tun, besteht darin, die Einschränkung aufzuheben, dass ASP.NET Core auch unter .NET Framework ausgeführt werden kann. Beachten Sie, dass der ursprüngliche Grund, warum wir ASP.NET Core unter .NET Framework ausgeführt haben, darin bestand, dass .NET Core einfach nicht über genügend APIs verfügte. Unter .NET Core 3.0 verfügen wir über mehr als 120.000 der vorhandenen APIs . Das ist mehr als die Hälfte des gesamten .NET Frameworks und umfasst sogar WinForms und WPF. Ja, es fehlen immer noch viele APIs, aber wir haben große Fortschritte im Long Tail gemacht. Obwohl wir niemals eine 100% ige Parität haben werden, erwarte ich, dass wir diese Lücke auf der Grundlage von Kundendaten noch weiter schließen.

@ yaakov-h Ich wäre überrascht, wenn das der Fall wäre. Wenn Sie die Analyse durchführen, lassen Sie es mich wissen.

Sie liegen nicht falsch, kennen aber die Ziele des .NET-Standards nicht. Das Ziel des Standards war nie, Innovationen voranzutreiben, sondern die Konvergenz voranzutreiben.

Und Sie bewegen sich genau in die entgegengesetzte Richtung: Sie geben .NET Standard für ASP.NET Core auf, weil es sich nicht schnell genug bewegt, und zwingen NuGet-Pakete, die auf ASP.NET Core abzielen, es ebenfalls aufzugeben. Lass mich nicht denken, dass es Konvergenz ist, ich bin nicht so unwissend : rofl:

Wenn Sie es aus diesem Blickwinkel betrachten, ist es eine Sache, die zurückbleiben muss, weil wir darüber nachdenken müssen, welche Konzepte universell sein können oder sogar universell sein sollten.

Es ist eine Wahl, kein technisches Problem: Nichts hindert Sie daran zu bestimmen, ob eine bestimmte API in einer neuen Version von .NET Standard enthalten sein soll, wenn Sie sie auf Aufnahme in corefx / coreclr überprüfen.

Wenn Sie neugierig sind, wie dies aussieht, lade ich Sie ein, sich die über 35 PRs anzusehen, die ich in den letzten drei Wochen nach Überprüfung durch alle Eigentümer der .NET-Implementierung zusammengeführt habe.

Ich sage nicht, dass es eine einfache Aufgabe ist, und es beweist meinen Standpunkt: Sie warten viel zu lange, um neue netstandard -Versionen zu erstellen, und in den seltenen Fällen, in denen Sie dies tun, ist dies ein schmerzhafter Prozess, da er mit Unmengen von Versionen verbunden ist neue APIs gleichzeitig.

Die Realität ist, dass "sich schnell bewegen und Dinge zerbrechen" nicht etwas ist, das unser gesamtes Publikum schätzt.

Genau so funktioniert jede ASP.NET Core-Iteration: Sie bringt (manchmal massive) Änderungen mit sich, die dazu führen, dass Pakete, die für eine Version geschrieben wurden, nicht mit den nächsten kompatibel sind. Sie geben uns jedoch nicht viele Optionen: Aktualisieren oder für immer auf älteren Versionen bleiben, mit einer Supportrichtlinie, die nichts mit dem zu tun hat, was wir früher hatten (es ist nicht nur ASP.NET/.NET, auch der Lebenszyklus von Windows ist viel kürzer in diesen Tagen).

In Zukunft würde ich erwarten, dass wir eher bereit sind, Innovationen in Bereichen durchzuführen, in denen Laufzeit-, Bibliotheks- und Sprachänderungen erforderlich sind, wie wir es für Span getan haben. Diese Dinge sind zwar kostspielig, aber sie ermöglichen es uns auch, die Art und Weise zu ändern, wie Menschen Code schreiben können. Ein gutes Beispiel hierfür sind Standardimplementierungen von Schnittstellen, die Möglichkeit, generischen Code mit Arithmetik zu erstellen, Hardware-Eigenschaften zu verwenden usw. Und diese Funktionen sind wahrscheinlich genau die Art, die wir aufgrund des Risikos nicht auf .NET Framework zurückportieren werden .

Was hindert Sie daran, eine neue .NET Framework-Version (z. B. .NET Framework 5) nebeneinander einzuführen, die diese "riskanten" Änderungen enthält? Auch hier handelt es sich nicht um ein technisches Problem.

Gibt es eine Chance, Microsoft.AspNetCore.Razor.Language und Microsoft.AspNetCore.Razor außerhalb von aspnet zu promoten oder auf der Welle von netstandard bleiben? Obwohl Razor nur für HTML ist, gibt es mehrere Bibliotheken, die es für Mail-Vorlagen verwenden, und es wäre großartig, wenn wir es weiterhin so verwenden könnten, wie es ist.

Dieser Schritt zeigt, dass netstandard in der .NET-Roadmap nicht unterstützt wird, im Gegensatz zu dem, was zuvor gesagt wurde. Wenn eine der wichtigsten neuen Bibliotheken den Netzstandard aufgibt, ist dies kein gutes Zeichen für ihre Einführung.

Ist dies ein Schritt, den .NET-Entwickler jetzt für alle anderen neuen Bibliotheken erwarten sollten, die von Microsoft im Freien entwickelt wurden? Kann die Community eine offiziellere Erklärung zur Zukunft des Netzstandards und seiner Einführung erhalten?

@terrajobst Ich verstehe vollkommen, dass Sie darauf hinweisen, dass Sie nicht diejenigen APIs zu .netstandard hinzufügen, die nicht bereit zu sein scheinen, alle Plattformen zu umfassen (und dies wahrscheinlich nie sein werden). Dies hat Sie (MS) jedoch nicht daran gehindert, netstandard2.0 einzuführen, wenn UWP beispielsweise nicht bereit war, dies zu unterstützen. Soweit ich weiß, war es einige Zeit später bemerkenswert, diese Unterstützung hinzuzufügen, aber Sie haben es geschafft. War das irgendwie eine andere Geschichte?

Und Sie bewegen sich genau in die entgegengesetzte Richtung: Sie geben .NET Standard für ASP.NET Core auf, weil es sich nicht schnell genug bewegt.

ASP.NET Core ist nur in .NET Framework und .NET Core sinnvoll, der .NET Standard muss jedoch von allen implementiert werden. Es ist einfach nicht sinnvoll, beispielsweise Xamarin / Unity APIs bereitstellen zu lassen, die überwiegend von einem Server-Webstack verwendet werden.

Es ist eine Wahl, kein technisches Problem: Nichts hindert Sie daran zu bestimmen, ob eine bestimmte API in einer neuen Version von .NET Standard enthalten sein soll, wenn Sie sie auf Aufnahme in corefx / coreclr überprüfen.

Das haben wir in .NET Core v1 Tagen gemacht. Wir haben den Standard von .NET Core mit v2 entkoppelt. Also ja, es ist eine Wahl, aber es war keine willkürliche. Ziel war es, mit .NET Core schneller vorankommen zu können. Es dauert einfach länger, zu überlegen, wie Features im Kontext von N anderen Laufzeiten als einer einzelnen funktionieren.

Es ist ein schmerzhafter Prozess, da es gleichzeitig Tonnen neuer APIs enthält.

Nein, es ist ein schmerzhafter Prozess, da Sie das Design mit mehreren Implementierern und mehreren unterschiedlichen Laufzeiten überprüfen müssen. Es ist jedoch viel billiger, dies nachträglich zu tun, als es zu koordinieren. Das CoreFx-Repo ist ein Repo mit hohem Volumen. Für Xamarin und Unity ist es viel einfacher, die gebündelten Funktionen zu überprüfen, als aus dem Firehose zu trinken und alle API-Diskussionen auf CoreFx zu abonnieren.

Genau so funktioniert jede ASP.NET Core-Iteration: Sie bringt (manchmal massive) Änderungen mit sich, die dazu führen, dass Pakete, die für eine Version geschrieben wurden, nicht mit den nächsten kompatibel sind.

Und weil Ihnen das nicht gefällt, möchten Sie es allen aufzwingen, indem Sie .NET Standard mit .NET Core übereinstimmen lassen? Entschuldigung, aber dieses Argument macht für mich keinen Sinn.

Was hindert Sie daran, eine neue .NET Framework-Version (z. B. .NET Framework 5) nebeneinander einzuführen, die diese "riskanten" Änderungen enthält? Auch hier handelt es sich nicht um ein technisches Problem.

Was lässt Sie denken, dass es kein technisches Problem ist? Der Versand von Side-by-Side-Versionen von .NET Framework ist keine praktikable Lösung. Erstens ist es ziemlich teuer, da es sich um eine Betriebssystemkomponente handelt und daher gewartet werden muss. Sie haben keine Ahnung, wie komplex unsere Strategie für Verzweigung / Wartung / Patching für .NET Framework 3.5 und 4.x ist. Das Hinzufügen eines dritten ist nahezu unpraktisch. Zweitens birgt dies auch Risiken, da wir Änderungen an der Aktivierung vornehmen müssen, um die richtige Laufzeit für Dinge wie COM-aktivierte verwaltete Komponenten auszuwählen. Und das wirft die Frage auf, ob wir In-Proc auch Seite an Seite unterstützen und mit wie vielen Kombinationen. Es ist keine einfache Aufgabe und auch nicht risikofrei.

Lass mich nicht denken, dass es Konvergenz ist

@PinpointTownes Es ist Konvergenz ... auf .NET Core 😉

Es ist einfach nicht sinnvoll, beispielsweise Xamarin / Unity APIs bereitstellen zu lassen, die überwiegend von einem Server-Webstack verwendet werden.

Es gibt Leute, die ASP.NET Core nicht nur unter .NET Core, sondern auch unter UWP verwenden möchten. Warum also nicht auch unter Xamarin? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

Es gibt einen Unterschied zwischen etwas, das für Sie keinen Sinn ergibt, und etwas, das Sie nicht unterstützen möchten.

Das CoreFx-Repo ist ein Repo mit hohem Volumen. Für Xamarin und Unity ist es viel einfacher, die gebündelten Funktionen zu überprüfen, als aus dem Firehose zu trinken und alle API-Diskussionen auf CoreFx zu abonnieren.

Habe ich einen so extremen Ansatz vorgeschlagen? Ich bin sicher, es gibt einen Kompromiss, den Sie finden könnten, z. B. die Diskussion neuer Standard-APIs kurz (dh einige Wochen) nach ihrer Einführung in .NET Core, sobald sich der Staub etwas gelegt hat.

Und weil Ihnen das nicht gefällt, möchten Sie es allen aufzwingen, indem Sie .NET Standard mit .NET Core übereinstimmen lassen? Entschuldigung, aber dieses Argument macht für mich keinen Sinn.

Sie nehmen an, dass mir das nicht gefällt, aber Sie irren sich: Ich mag schnelllebige Dinge - auch wenn es als Betreuer von 60 NuGet-Paketen manchmal ziemlich schmerzhaft ist. Was ich nicht mag, ist, alle zu zwingen, sich mit der gleichen Geschwindigkeit zu bewegen und die Leute mitten auf der Straße zu verlassen, weil sie nicht mithalten können.

Ich bin mir nicht sicher, wie es als Bestrafung angesehen werden kann, .NET Standard so schnell wie .NET Core zu bewegen: Nichts zwingt Sie dazu, das neueste netstandard TFM anzuvisieren. Sie tun dies nur, wenn Sie den neuesten API-Satz benötigen. Wenn Sie es nicht benötigen, wählen Sie eine ältere Version aus, damit Ihre Pakete von einer größeren Anzahl von Plattformen verwendet werden können.

Aus der Sicht eines durchschnittlichen Entwicklers ist dies ein voller Gewinn: Sie können Pakete mit den neuesten glänzenden APIs schreiben, die von der neuesten .NET Core-Laufzeit verwendet werden können. Wenn die anderen Plattformen aufholen, können Ihre Pakete auch dort verwendet werden: Sie müssen sich nicht für Multi-Targeting entscheiden oder Pakete erneut veröffentlichen.

Erstens ist es ziemlich teuer, da es sich um eine Betriebssystemkomponente handelt und daher gewartet werden muss. Sie haben keine Ahnung, wie komplex unsere Strategie für Verzweigung / Wartung / Patching für .NET Framework 3.5 und 4.x ist. Das Hinzufügen eines dritten ist nahezu unpraktisch.

Ich kann mir sicher vorstellen, dass es nicht ideal für Sie ist, genauso wie das Entfernen der .NET Framework-Unterstützung für ASP.NET Core 3.0 nicht ideal für Leute ist, die nicht zu .NET Core wechseln können. Aber irre ich mich völlig, wenn ich denke, dass Sie - Microsoft - viel mehr Ressourcen haben, um damit umzugehen, als das durchschnittliche Unternehmen auf .NET Core umsteigen muss? (Ich spreche nicht einmal über externe Abhängigkeiten, die Sie nicht besitzen und kontrollieren).

Zweitens birgt dies auch Risiken, da wir Änderungen an der Aktivierung vornehmen müssen, um die richtige Laufzeit für Dinge wie COM-aktivierte verwaltete Komponenten auszuwählen. Und das wirft die Frage auf, ob wir In-Proc auch Seite an Seite unterstützen und mit wie vielen Kombinationen. Es ist keine einfache Aufgabe und auch nicht risikofrei.

Sicher ist es nicht einfach. Und es ist riskant. Aber das ist es, was Hauptversionen anzeigen: Es besteht das Risiko, dass Dinge kaputt gehen. Was würden sich Ihrer Meinung nach entscheiden, wenn Sie gezwungen wären, für immer auf ASP.NET Core 2.2 zu bleiben, und das Risiko eingehen, auf .NET Framework 5 umzusteigen, um ASP.NET Core 3.0 zu verwenden?

Aber irre ich mich völlig, wenn ich denke, dass Sie - Microsoft - viel mehr Ressourcen haben, um damit umzugehen, als das durchschnittliche Unternehmen auf .NET Core umsteigen muss?

Nach meiner Erfahrung überschätzen die Leute immer wieder, wie viele Ressourcen wir haben und wie viel Arbeit wir leisten müssen, um den Status Quo allein zu unterstützen.

Aber in diesem Fall geht es nicht einmal um Ressourcen. Wir hätten einfach Open-Source-.NET Framework verwenden können, und dann würden alle PRs direkt zu .NET Framework gehen. Dies hängt mit der Komplexität der Maschinen und den damit verbundenen Risiken zusammen. Es handelt sich um ein zentrales Framework, und selbst nebeneinander liegende Releases verwenden gemeinsame Ressourcen wie die Aktivierung. Wir haben immer wieder bewiesen, dass wir nur kluge Leute zuweisen können, wenn es richtig herauskommt.

Was würden sich Ihrer Meinung nach entscheiden, wenn Sie gezwungen wären, für immer auf ASP.NET Core 2.2 zu bleiben, und das Risiko eingehen, auf .NET Framework 5 umzusteigen, um ASP.NET Core 3.0 zu verwenden?

Meiner Ansicht nach ist es viel praktischer, den Umschlag unterstützter APIs in .NET Core zu verschieben, damit mehr Benutzer reibungslos auf .NET Core migrieren können, als zu versuchen, .NET Core-Funktionen in .NET Framework zurück zu portieren. Alles was wir dort tun können, ist Trauer zu verursachen. Beachten Sie, dass Side-by-Side-Releases mit anderen Herausforderungen verbunden sind, z. B. der Installation durch die IT, der Verkettung mit Installationsprogrammen oder dem Warten, bis Ihr Hoster Ihnen Maschinen usw. zur Verfügung stellt.

Gilt dies für alle Teile von ASP.NET Core oder bleiben einige nützliche, allgemein wiederverwendbare Teile (wie Microsoft.AspNetCore.Http.Extensions ) in .NET Standard erhalten?

@andriysavin

@terrajobst Ich verstehe vollkommen, dass Sie darauf hinweisen, dass Sie nicht diejenigen APIs zu .netstandard hinzufügen, die nicht bereit zu sein scheinen, alle Plattformen zu umfassen (und dies wahrscheinlich nie sein werden). Dies hat Sie (MS) jedoch nicht daran gehindert, netstandard2.0 einzuführen, wenn UWP beispielsweise nicht bereit war, dies zu unterstützen. Soweit ich weiß, war es einige Zeit später bemerkenswert, diese Unterstützung hinzuzufügen, aber Sie haben es geschafft. War das irgendwie eine andere Geschichte?

Ja. .NET Standard 2.0 hatte keine neuen Netto-APIs. Es wurde als Schnittpunkt von .NET Framework und Xamarin definiert. Was auch immer das Delta ist, wir brauchen es einfach, um zu einer angemessenen Kompatibilitätsleiste mit vorhandenem Code zu gelangen. Die einzige Arbeit war in UWP und .NET Core. Und diese Codebasen waren ursprünglich als modernes Zurücksetzen von .NET konzipiert, von dem wir gelernt haben, dass es nicht realisierbar ist. Da die hinzuzufügenden APIs / Technologien weitgehend ausgereift waren und in eingeschränkten Umgebungen (Xamarin iOS) unterstützt wurden, war die Komplexität gering - nur eine Tonne Portierungsarbeit.

Aber jetzt sprechen wir über das Hinzufügen brandneuer Funktionen und Konzepte, und das ist ein anderes Biest, das man fahren muss.

Nach meiner Erfahrung überschätzen die Leute immer wieder, wie viele Ressourcen wir haben und wie viel Arbeit wir leisten müssen, um den Status Quo allein zu unterstützen.

Nach meiner Erfahrung überschätzen Microsofties immer wieder, wie viele Ressourcen wir haben und wie viel Arbeit wir tun müssen, um den Status Quo allein zu unterstützen. Ihr Argument funktioniert wirklich in beide Richtungen: heat_smile:

Meiner Ansicht nach ist es viel praktischer, den Umschlag unterstützter APIs in .NET Core zu verschieben, damit mehr Benutzer reibungslos auf .NET Core migrieren können, als zu versuchen, .NET Core-Funktionen in .NET Framework zurück zu portieren.

Lassen Sie uns klar sein: Ich bin alles dafür , aber es wird nicht funktionieren, bis .NET Core die meisten / alle Funktionen von .NET Framework einholt und implementiert. Bis dahin werden immer noch Personen durch eine fehlende Funktion oder eine fehlende API blockiert. Es fehlen so viele Dinge, dass es nicht vernünftig ist zu glauben, dass monolithische Big-Legacy-Apps ohne Probleme auf .NET Core umsteigen können.

Ich verstehe definitiv Ihre Bedenken. Aber was Ihr Leben letztendlich einfacher macht, kann unser Leben schmerzhafter machen: Wenn Sie .NET Framework nicht unterstützen, wird dies für uns eine PITA sein.

Ich verstehe definitiv Ihre Bedenken. Aber was Ihr Leben letztendlich einfacher macht, kann unser Leben schmerzhafter machen: Wenn Sie .NET Framework nicht unterstützen, wird dies für uns eine PITA sein.

Diesen Teil verstehe ich. Die Alternative wären jedoch nicht mehr Funktionen in .NET Framework, sondern lediglich ein weniger leistungsfähiger ASP.NET Core.

Wir haben in den letzten Jahren versucht, .NET Framework und .NET Core gemeinsam weiterzuentwickeln. Es ist nicht so, als wollten wir die Arbeit vermeiden. Ich habe persönlich eine Unmenge Stunden damit verbracht, mit unseren Laufzeitingenieuren zu sprechen, um beispielsweise den Albtraum der verbindlichen Umleitung zu beheben. Oder die kaputte .NET Standard 2.0-Unterstützung in 4.6.1. Wir haben es versucht. Es geht nicht um Willenskraft, es geht um Praktikabilität.

Es wird nicht funktionieren, bis .NET Core die meisten / alle Funktionen von .NET Framework einholt und implementiert

Nach meiner Erfahrung ist die Verfügbarkeit einiger APIs nicht einmal so relevant. In Unternehmensumgebungen ist die Komplexität des Supports und der Bereitstellung von großer Bedeutung. Und „unterstützt, ausgeliefert und automatisch mit dem Betriebssystem aktualisiert“ ist viel ansprechender als die 3-jährige Unterstützung, die wir von .NET Core LTS-Versionen erhalten, und die schwierige Bereitstellung, die derzeit noch erforderlich ist. Und seien wir ehrlich: Es gibt immer noch kein stabiles Tool für .NET Core und ASP.NET Core. Ich kann zuversichtlich sagen, dass es in einem Jahr immer noch der Status Quo sein wird. Wir hatten mit jeder Version Änderungen und wer weiß, ob die neue Framework-Referenz mit 3.0 die richtige Lösung sein wird. Das ist definitiv ein großer Schmerzpunkt im Umgang mit Unternehmen, bei denen man nicht einfach Dinge aktualisieren oder so machen kann, wie es gemacht werden sollte. Normalerweise möchten sie, dass es so gemacht wird, wie sie es in den letzten 5+ Jahren gemacht haben. Sie werden durch das Framework verwöhnt und alles, was ihnen nicht so angenehm ist , ist fast ein Showstopper.

Die Alternative wären jedoch nicht mehr Funktionen in .NET Framework, sondern lediglich ein weniger leistungsfähiger ASP.NET Core.

Das ist ziemlich genau das, was ich letztes Jahr vorgeschlagen habe: ASP.NET Core-Pakete, die immer noch unter .NET Framework funktionieren (z. B. durch Ausrichtung auf netstandard20 und netcoreapp30 ), aber einen eingeschränkteren Funktionsumfang mit viel weniger bieten interessante Leistung. Manchmal wollen die Leute Dinge, die funktionieren. Nicht die neuen glänzenden Dinge. Nicht das superschnelle Zeug.

Wir haben in den letzten Jahren versucht, .NET Framework und .NET Core gemeinsam weiterzuentwickeln. Es ist nicht so, als wollten wir die Arbeit vermeiden. Ich habe persönlich eine Unmenge Stunden damit verbracht, mit unseren Laufzeitingenieuren zu sprechen, um beispielsweise den Albtraum der verbindlichen Umleitung zu beheben. Oder die kaputte .NET Standard 2.0-Unterstützung in 4.6.1. Wir haben es versucht. Es geht nicht um Willenskraft, es geht um Praktikabilität.

Wir sind uns natürlich nicht in allen Punkten einig, aber ich bin natürlich sehr beeindruckt von dem, was ihr getan habt (ja, auch wenn es ziemlich schmerzhaft war, mit Dingen wie dem HttpClient Schluckauf umzugehen).

Es tut mir wirklich leid, dieser Typ zu sein: heat_smile:

Bisher habe ich bei ASP.NET Core gesehen, dass Razor etwas Konkretes ist, das die Leute gerne außerhalb von ASP.NET Core im Allgemeinen verfügbar wären. Ich denke, das ist vernünftig und wir sollten mehr Bereiche wie diesen identifizieren (es wird eine nützlichere Diskussion sein). ASP.NET Core 2.1 und 2.2 unterstützen weiterhin .NET Framework, aber ich halte es nicht für sinnvoll, .NET Framework für immer zu unterstützen.

@terrajobst

Ein gutes Beispiel hierfür sind Standardimplementierungen von Schnittstellen, ... und diese Funktionen sind wahrscheinlich genau die Art, die wir aufgrund des Risikos nicht auf .NET Framework zurückportieren werden.

Und mit dieser Aussage starb DIM. Der springende Punkt ist die Entwicklung des Erbes. Wenn es nicht für Legacy gilt und nicht einmal für Bibliotheken, die versuchen, Legacy und New zu verbinden, hilft es niemandem.

Bisher habe ich bei ASP.NET Core gesehen, dass Razor etwas Konkretes ist, das die Leute gerne außerhalb von ASP.NET Core im Allgemeinen verfügbar wären.

Sie können das Paket Microsoft.Owin.Security.Interop backcompat ', ASP.NET Core Data Protection und die zugrunde liegenden Abhängigkeiten zur Liste hinzufügen.

Das ist ziemlich genau das, was ich letztes Jahr vorgeschlagen habe: ASP.NET Core-Pakete, die immer noch unter .NET Framework funktionieren (z. B. durch Ausrichtung auf netstandard20 und netcoreapp30 ), aber einen eingeschränkteren Funktionsumfang mit viel weniger bieten interessante Leistung. Manchmal wollen die Leute Dinge, die funktionieren. Nicht die neuen glänzenden Dinge. Nicht das superschnelle Zeug.

Wir haben auch darüber gesprochen. Die Herausforderung besteht darin, dass wir dies nicht vollständig kapseln können, da einige der zugrunde liegenden Plattform-APIs und -Funktionen in die öffentliche API übergehen müssen. Das bedeutet, dass Bibliotheken, die in die Middleware von ASP.NET Core integriert werden, auch mehrere Implementierungen bereitstellen müssen. Schlimmer noch, es ist möglicherweise nicht einmal möglich, ohne ein Schisma zu erstellen, da der öffentliche Austauschtyp möglicherweise nur für den Kern bestimmt ist, wodurch zwei Versionen von ASP.NET Core erstellt werden, die nicht mehr kompatibel sind.

@HaloFour

Und mit dieser Aussage starb DIM. Der gesamte Evolutionspunkt des Erbes. Wenn es nicht für Legacy gilt und nicht einmal für Bibliotheken, die versuchen, Legacy und New zu verbinden, hilft es niemandem.

Ich denke, Sie verbinden Legacy-Code mit vorhandenen Installationen . Selbst wenn wir DIM auf .NET Framework portieren würden, müssten Sie immer noch auf eine neuere Version aktualisieren, um die Funktion nutzen zu können. Obwohl es sich wahrscheinlich nur um eine .NET Core-Funktion handelt, können wir .NET Core weiterentwickeln und gleichzeitig Code verwenden, der mit .NET Framework kompiliert wurde.

@terrajobst Du

Unity verfügt über mehrere .NET-Implementierungen, einschließlich der eigenen Nicht-Mono-AOT-Version IL2CPP. Ihre Klassenbibliothek und unterstützten APIs unterscheiden sich ebenfalls von Standard-Mono.

@terrajobst

Ich denke, Sie verbinden Legacy-Code mit vorhandenen Installationen.

Es gibt keinen großen Unterschied, wenn es darum geht, dass "Legacy" -Anwendungen noch aktiv gewartet und entwickelt werden. Es gibt einen großen Unterschied zwischen der Aktualisierung des Frameworks und der Migration auf .NET Core.

Obwohl es sich wahrscheinlich nur um eine .NET Core-Funktion handelt, können wir .NET Core weiterentwickeln und gleichzeitig Code verwenden, der mit .NET Framework kompiliert wurde.

Zu welchem ​​Ende? Keine dieser "weiterentwickelten" APIs in .NET Core wird jemals auf .NET Standard anwendbar sein. Und kein Bibliotheksschreiber wird es berühren, wenn es zu inkompatiblen Abweichungen in seinen eigenen APIs kommt.

Ich stimme @HaloFour zu. Die einzigen Personen, die DIM verwenden können, sind die Bibliotheksautoren, die nur auf .NET Core abzielen ... also im Grunde nur CoreFX und Aspnetcore. Ich kann mir nicht vorstellen, dass jemand anderes in die Nähe kommen würde.

Die einzigen Personen, die DIM verwenden können, sind die Bibliotheksautoren, die nur auf .NET Core abzielen ... also im Grunde nur CoreFX und Aspnetcore.

Eine andere Art der Formulierung wäre, dass die einzige Plattform, auf der Sie sie nicht verwenden können, .NET Framework ist, während Sie dies unter .NET Core, Xamarin, Mono und Unity können.

Ich kann mir nicht vorstellen, dass jemand anderes in die Nähe kommen würde.

Ich stelle mir vor, dass Funktionen wie diese ein Adoptionsmuster für Hockeyschläger in Bibliotheken haben, was Sinn macht. Am Ende werden Autoren der Bibliothek immer die Reichweite gegenüber dem Funktionsumfang berücksichtigen. Für Apps ist die Entscheidung einfacher, da Sie Ihre Zielumgebung kennen (und häufig steuern).

@ yaakov-h

Gilt dies für alle Teile von ASP.NET Core ...

Die vorläufige Liste der Vorgänge mit welchem ​​Paket finden Sie hier: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst Ich dachte, dass Standard-Schnittstellenimplementierungen eine

Wir führen einige .NET Core-Workloads aus, führen aber auch Projekte aus, die mehrjährige .NET FX sind.

Ein sicheres Upgrade auf .NET Core (auch unter .NET Framework) ist eine sehr große Aufgabe.

Gibt es Pläne für Microsoft, Tools zu veröffentlichen, mit denen Projekte von mindestens ASP.NET unter .NET FX auf ASP.NET Core auf .NET FX "aktualisiert" werden können?

Es gibt MSDN-Artikel über das Erstellen neuer VS-Projekte und das Importieren von Ansichten und das Neuausrichten von Projekten, aber es gibt so viel Legacy-Material (Global Asax, Routing, ...), dass ich mir wünschte, es gäbe einen zentralen Ort, der die alte und die neue Art der Hilfe dokumentiert alles portieren.

Was hindert Sie daran, eine neue .NET Framework-Version (z. B. .NET Framework 5) nebeneinander einzuführen, die diese "riskanten" Änderungen enthält?

Gibt es zu diesem Zeitpunkt einen Vorteil, wenn es sich nicht um .NET Core 3.0 handelt? Es ist bereits Seite an Seite und hat die "riskanten" Änderungen. Würden die nächsten Funktionen für .NET Core dann ein .NET Framework 6 usw. benötigen?

Mit den APIs, die bereits in .NET Core 2.0 enthalten sind, und dem neuen Funktionsumfang von .NET Core 3.0 erfüllt .NET Core nicht das ".NET Framework 5", wobei Framework 4.x die extrem lange LTS-Version ist?

Bei einer Vermutung; Zu diesem Zeitpunkt wäre es eine kleinere technische Herausforderung, bestimmte identifizierte Lücken zu schließen, die .NET Core 3.0 gegenüber .NET Framework 4.x aufweist, anstatt .NET Framework so zu ändern, dass es sich wie .NET Core verhält.

Praktischer Vorschlag: Gibt es eine Chance, dass ASP.NET Core 2.2 LTS mit einer erweiterten Supportdauer über den üblichen 3 Jahren wird?

Ich bin sicher, dass dies diejenigen zufriedenstellen würde, die sich vorerst an das vollständige Framework halten müssen, und ihnen gleichzeitig (1) genügend Zeit für die tatsächliche Migration auf .NET Core und (2) genügend Motivation für die Migration von ASP.NET MVC zu ASP geben würde .NET Core (wenn sie noch nicht zu .NET Core verschoben werden können).

Ich denke immer noch nicht, dass dies klar ist. Folgt ASP.NET Core unter .NET Framework .NET Core 2.1 LTS oder folgt es dem .NET Framework v4.6.1 + -Unterstützungszyklus (dh da es unter .NET FX ausgeführt wird), wo wird es in absehbarer Zeit unterstützt?

@mythz ASP.NET Core wird vom .NET Core-Support-Lebenszyklus abgedeckt, unabhängig davon, auf welcher Plattform Sie es ausführen.

Ich denke, der beste Schritt hier wäre, den .net-Standard für mindestens 3.0, 4.0 und 5.0 auf dem neuesten Stand zu halten und tatsächlich zu kommunizieren, dass das .net-Framework irgendwann vollständig auf den .net-Kern migriert wird.
alles andere ist nur halb gebacken.

Haben Sie Kunden, die bereits heute für LTS-Support bezahlen? (Nur eine Sondierungsfrage). Wie viel Zeit ist genug Zeit?

@terrajobst Es klingt das eigentliche Problem ist, dass Netstandard monolithisch ist. Es hört sich so an, als bräuchten wir stattdessen keine netstandardisierten, sondern versionierte API-Sets. Dies wird auch das TFM sein, zum Beispiel wäre base2.0 + span zwei API-Sets.

Sie könnten dann den Standard basierend auf API-Sets weiterentwickeln und möglicherweise nur einige API-Sets im vollständigen Framework implementieren. (Dies würde auch anderen Plattformen die Implementierung von Netstandard erleichtern, da einige API-Sätze weggelassen werden können.)

Mit den vorhandenen API-Sets würde ein separater Build von ASP.NET Core für die weniger unterstützenden Ziele wie das vollständige Framework erstellt.

@Sebazzz das ist extrem seltsames Thema. Können wir diesen Thread nicht mit Versuchen entgleisen, den Netzstandard neu zu gestalten? Sie können dafür ein Problem bei dotnet / standard einreichen, aber ich werde Ihnen sagen, dass diese Idee bereits vorgeschlagen und abgeschossen wurde.

@davidfowl Ich denke nicht, dass das überhaupt "seltsam" oder "entgleist" ist. Es klingt genau so, wie wir es brauchen, wenn auch etwas weniger feinkörnig als er es vorgeschlagen hat. Wenn das Problem bei all dem ist, dass wir all diese Webserver-Inhalte in Implementierungen wie Xamarin und Unity einbinden müssen, die sich nicht um Webserver kümmern, erstellt IMO eine separate API-Gruppe ".NET Web Server Standard" wäre die ideale Lösung.

@Sebazzz @masonwheeler

@terrajobst Es klingt das eigentliche Problem ist, dass Netstandard monolithisch ist. Es hört sich so an, als bräuchten wir stattdessen keine netstandardisierten, sondern versionierte API-Sets. Dies wird auch das TFM sein, zum Beispiel wäre base2.0 + span zwei API-Sets.

Wir haben dies in verschiedenen Varianten versucht (Profile, PCLs, lose Verträge und dann versionierte Vertragssätze, die zu .NET Standard 1.x wurden). Es ist zu schwierig, Kompatibilitätsregeln im Laufe der Zeit zu bearbeiten und zu verstehen (wenn sich Plattformversionen und API-Sets weiterentwickeln). Der heutige .NET-Standard kommt einem funktionsfähigen Modell am nächsten. Obwohl es nicht perfekt ist, kann ich es zumindest in wenigen Minuten erklären, ohne dass der Kopf der Leute explodiert.

Ich freue mich, .NET Standard ausführlicher zu diskutieren, aber ich stimme @davidfowl zu, dass dies nicht hierher gehört. Wenn Sie möchten, melden Sie ein Problem unter https://github.com/dotnet/standard.

Bearbeiten Ich habe unsere .NET Standard-Kommentare als nicht zum Thema gehörend markiert.

@ Shayan-To

@terrajobst Ich dachte, dass Standard-Schnittstellenimplementierungen eine

Es ist eine Funktion, die sowohl Sprachänderungen als auch Laufzeitänderungen erfordert. Es ähnelt Generika, da es die Regeln des Typsystems ändert. Im Allgemeinen weiß C # nicht, für welches Framework Sie kompilieren (es wird lediglich eine Reihe von Referenzassemblys übergeben, die die vom Framework angebotenen APIs beschreiben). Alle C # -Funktionen, für die keine API-Änderungen erforderlich sind (z. B. der Null-Koaleszenz-Operator ?. oder der _ zum Verwerfen von Ausdrücken), werden unterstützt. Insofern ist es identisch mit der Funktionsweise des Compilers, als Sie die neueste Compiler- und Sprachversion verwendet und auf eine ältere Version von .NET Framework abgezielt haben, der die entsprechenden APIs fehlen. Zum Beispiel funktioniert async / await nicht, wenn Sie auf .NET Framework 3.5 oder 4.0 abzielen. Sie müssen mindestens 4.5 verwenden, um Task .

Mann, ich fühle für euch. Es ist imo das Richtige, langfristig auf den .net-Kern umzusteigen, und ich bevorzuge das höhere Innovationstempo, das sich daraus ergibt.

Jedoch werden die Leute darüber verärgert sein. Ein beträchtlicher Teil davon ist die Kommunikation. Als die 2.1 3-Jahres-LTS angekündigt wurde, erwarteten die Mitarbeiter von fullfx, dass sie in der Lage sein werden, auf 3.0 umzusteigen und weiterhin fullfx auszuführen. Sie haben asp.net-Kern an ihre Arbeitgeber und Kunden verkauft, um ihren eigenen Ruf in Frage zu stellen Jetzt haben sie das Gefühl, dass der Teppich unter ihnen herausgezogen wurde. Was sie als langfristige Lösung verkauften, die Zukunft von asp.net, ist jetzt (perzeptuell) auf 3 Jahre Support begrenzt

Es spielt keine Rolle, dass die Migration jetzt einfacher ist. Das Wechseln der Plattform ist immer ein Risiko, und das ist ein Risiko und ein Entwicklungsaufwand, den diese Leute nicht erwartet, geplant oder budgetiert haben.

Die meisten Entwickler werden auf .net Core 3 umsteigen wollen, aber abgesehen davon, dass sie möglicherweise Abhängigkeiten haben, die sie nicht ändern können (oder mit einer Risikoänderung verbunden sind), müssen sie jetzt erneut eine Migration durchführen und versprechen, dass es sich diesmal um eine langfristige Investition handelt. Es kann ein harter Verkauf sein, aber sie werden sich aufgrund des 3-jährigen Support-Zyklus dazu gezwungen fühlen.

Auch hier bin ich dafür, fullfx fallen zu lassen, aber ich denke wirklich, dass Sie erwägen sollten, das LTS für die letzte Version zu erweitern, die es um einen beträchtlichen Betrag unterstützt. Kommunizieren Sie auch sehr klar, wie in Blogs, Konferenzen / Sitzungen usw., welche Teile noch netzstandardisiert sind und wie Personen, die sich noch im 2.1 / Full-Framework befinden, diese weiterhin nutzen können.

Andernfalls besteht ein großes Risiko, dass die Erzählung zu "Microsoft lässt seine engagierten Entwickler wieder zurück" wird. Das ist nicht fair , sondern versucht Sie nur zu warnen, was passieren könnte.

Was ist eine vernünftige Zeit für die LTS?

6 Jahre vielleicht? Ich denke, dass Messaging eine große Rolle beim Empfang spielen wird. Am Ende werden einige Leute verärgert sein, egal was passiert: /

@davidfowl @ aL3891

Als Referenz beträgt der Java LTS "Premier Support" 5 Jahre, der "Extended Support" (kostenpflichtig) weitere drei Jahre. Java 11, eine LTS-Version, die letzten Monat veröffentlicht wurde, wird bis September 2023 bzw. September 2026 unterstützt

Wir untersuchen ein LTS-Angebot mit "erweitertem Support" und werden weitere Details bereitstellen, sobald wir diese haben. Dies würde Kunden, die einen unterstützten ASP.NET Core unter .NET Framework-Version (2.1.x) benötigen, möglicherweise eine Option bieten, die länger als der aktuelle LTS-Supportzeitraum ist.

Außerdem habe ich mich heute ein wenig über die Ankündigungen im ASP.NET Community Standup unterhalten: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

Bitte zielen Sie auf den .net-Standard. Der asp.net-Kern kann auf .netstandard2.1 oder 3.0 abzielen und Mono und .netframework später aufholen lassen. Wenn der asp.net-Kern jedoch auf netcoreapp abzielt, versucht jede Bibliothek, auf einen Typ zuzugreifen Diese Aspnetcore-Bibliothek muss eine .netcoreapp -Bibliothek sein.

und .net Core wird immer schneller als .net framework und mono veröffentlicht.
mono und .netframework verbrauchen schließlich .netcoreapp Assemblys, wenn Microsoft Start mehr Frameworks / Bibliotheken auf netcoreapp zielt (was auch mehr Bibliothek auf Nuget-Ziel .netcoreapp ).

In diesem Fall wird aus .netstandard .netcoreapp 😂

@ John0King Bitte geben Sie Beispiele für Typen an, die Sie außerhalb von ASP.NET Core benötigen.

1. Rasiermesser wie @poke erwähnt
2. MVC-Filter-Schnittstellen / -Attribute (Ich habe eine Hilfsklassenbibliothek, die einige ActionFilters und TagHelpers sowie eine allgemeine statische / Erweiterungsmethode für Zeichenfolge, Int, Long usw. enthält. Ich verwende PrivateAssert="All" um auf MVC-Pakete zu verweisen, wenn ich diese verwende Bibliothek woanders, dieses Projekt muss nicht auf MVC-Assemblys verweisen, ich denke, ich muss die Bibliothek in zwei trennen, eine ist .netstandard und eine andere .netcoreapp )

Eine andere Frage ist: Wird es ein Problem für welche Art von Klassenbibliothek sein, die ich erstellen soll? ( .netstandard vs .netcoreapp ). Heute ist es in asp.net Core 2.1 ziemlich einfach. Wählen Sie .netstandard für die Klassenbibliothek, wählen Sie .netcoreapp oder net461 für das Webprojekt.

mono und .netframework verbrauchen möglicherweise .netcoreapp-Assemblys, wenn Microsoft Start mehr Frameworks / Bibliotheken auf netcoreapp abzielt (dies führt auch zu mehr Bibliotheken auf dem Nuget-Ziel .netcoreapp).

Dies wird passieren, wenn die Leute sich nicht mehr bemühen, zu trennen, was zu einer .netstandard Bibliothek und was zu .netcoreapp Bibliothek kommen soll

MVC-Filter Schnittstellen / Attribute (Ich habe eine Hilfsklassenbibliothek, die einige ActionFilters und TagHelpers sowie eine allgemeine statische / Erweiterungsmethode für Zeichenfolge, Int, Long usw. enthält. Ich verwende PrivateAssert = "All", um auf MVC-Pakete zu verweisen, wenn ich diese Bibliothek verwende An einigen anderen Stellen muss dieses Projekt nicht auf MVC-Assemblys verweisen. Ich denke, ich muss die Bibliothek in zwei trennen, eine ist .netstandard und eine andere .netcoreapp.

Können Sie das näher erläutern? Das macht keinen Sinn. MVC ist ein ASP.NET Core-Framework und kann nicht eigenständig verwendet werden.

@davidfowl Diese Bibliothek ist eine

@davidfowl Diese Bibliothek ist eine

Ich verstehe immer noch nicht. Sprechen Sie über eine Bibliothek, die MVC-Dinge und andere zufällige Dinge enthält?

Leider ist so etwas in Unternehmenssoftware üblich - "Hilfsbibliotheken", die wie die Dienstprogramme des Unternehmens für MVC + die Dienstprogramme des Unternehmens für WPF + die Dienstprogramme des Unternehmens für Telerik ...
Es war sinnvoller, als '.NET' eine einzige einheitliche Plattform war.

@ Davidfowl ja. Es gibt einige Klassen / Methoden in der Hilfsbibliothek, die Sie überall verwenden können. und wenn Sie diese Bibliothek in einem MVC-Projekt referenzieren, können Sie die MVC-bezogene Klasse / Methode verwenden.

Na ja, das zwingt deine Bibliotheken nur dazu, besser geschichtet zu werden 😉

Leider bedeutet dies, dass jeder, der noch vor Ort Bereitstellungen durchführt, seine Software nicht länger als 3 Jahre unterstützen kann. Sobald Sie beispielsweise eine App für .netcore 3.0 veröffentlichen, haben Ihre Kunden 3 Jahre Zeit und müssen dann ein Upgrade durchführen. Einige Branchen, in denen es gut geht, andere sicherlich nicht.

Das ist das größte Problem dabei und macht .net Core für viele Leute zu einem absoluten Non-Go, würde ich mir vorstellen. Ich stimme tatsächlich zu, dass dies am Ende die richtige Richtung ist, aber ich bin mir sicher, dass dies viele Orte davon abhalten wird, zum .net-Kern zu gelangen.

Ich hätte wirklich gerne eine Antwort vom .net-Team dazu.

Die Sache ist, ASP.NET Core ist ein Webframework. In welcher Branche ist es sicher, eine Website > drei Jahre lang völlig unverändert zu betreiben? Wenn es sich nicht um Sicherheitslücken handelt, sind es Browser, die das, worauf Sie sich verlassen haben, oder TLS 1.4 ablehnen, oder Benutzer, die verlangen, dass die Site in ihrem neuen Watchlet funktioniert.

In diesem Zeitraum sollten Sie nur mit kleinen Änderungen und geringfügigen Abhängigkeitsaktualisierungen davonkommen können. Es ist jedoch rücksichtslos, zu planen, eine Webanwendung jahrelang überhaupt nicht zu aktualisieren.

Ich denke, dies wäre für die Community angenehmer, wenn Sie nur den LTS-Zeitraum für ASP.NET Core 2.1 auf 5-7 Jahre verlängern.

Nach unserer Erfahrung bewegt sich die Unternehmensentwicklung im Vergleich zur "modernen" Webentwicklung rasant und sie möchten dennoch sicherstellen, dass sie keine neuen Investitionen in wesentlich ältere Plattformen tätigen. Diese Anwendungen brauchen oft mehr als ein Jahr, um überhaupt zu starten, geschweige denn, um innerhalb von 3 Jahren ein größeres Upgrade durchzuführen. Diese Unternehmenswebanwendungen (normalerweise nur für interne Zwecke) werden häufig 7 bis 10 Jahre lang unterstützt, obwohl ich es für unangemessen halte, dass LTS für ASP.NET Core 2.1 10 Jahre beträgt. 5 Jahre fühlen sich wie eine bessere Lösung an als 3, wobei 7 Jahre eine Zahl sind, die es sicherlich fast jedem bequem machen würde.

Dies ist nur erforderlich, da für ASP.NET Core 3.0 eine wichtige Änderung erforderlich ist, um die Unterstützung für .NET Framework zu entfernen. Zukünftige LTS-Versionen sollten nicht diesem Standard entsprechen, vorausgesetzt, die Änderungen sind nicht so groß.

Ich bin mir nicht sicher, wie es als Bestrafung angesehen werden kann, .NET Standard so schnell wie .NET Core zu bewegen: Nichts zwingt Sie dazu, das neueste netstandard TFM anzuvisieren. Sie tun dies nur, wenn Sie den neuesten API-Satz benötigen. Wenn Sie es nicht benötigen, wählen Sie eine ältere Version aus, damit Ihre Pakete von einer größeren Anzahl von Plattformen verwendet werden können.

Was ist, wenn die Plattform nie aufholt? Dann haben Sie eine Bibliothek, die auf netstandard2.3 abzielt und die Funktion A benötigt, die nur unter .NET Core und Xamarin verfügbar ist, für .NET Framework jedoch nicht möglich ist.

Dann kommt netstandard2.4 heraus, mit ein paar neuen Apis und einigen dieser APIs, die auf .NET Framework portiert werden können. Was jetzt?

Wie können Sie auf eine Bibliothek abzielen, die eine Funktion von netstandad2.4 benötigt, die unter .NET Framework ausgeführt wird, aber netstandard2.4 kann nicht auf .NET Framework abzielen, da sie netstandard2.2 nicht implementieren kann.

Dann müssten Sie die Kompilierung auf drei Plattformen durchführen:
netstandard2.2 für die alten Plattformen und net4x für den Nettostandard, nur um die Funktion zu unterstützen, die in netstandad2.4 hinzugefügt wurde und die net4x can also implement but not support because of APIs that went into netstandard2.3`.

Wie würde dies Paketautoren das Schreiben und Versenden ihrer Nugget-Pakete erleichtern?

Das Ganze kann nur funktionieren, wenn der kleinste gemeinsame Nenner, den alle Plattformen unterstützen, in netstandard fließt. Es sei denn, Sie möchten, dass noch mehr APIs PlatformNotSupported Ausnahmen auslösen, da dies sonst zu einer Fragmentierung innerhalb des Netzstandards führt.

Ich kann mir sicher vorstellen, dass es nicht ideal für Sie ist, genauso wie das Entfernen der .NET Framework-Unterstützung für ASP.NET Core 3.0 nicht ideal für Leute ist, die nicht zu .NET Core wechseln können. Aber irre ich mich völlig, wenn ich denke, dass Sie - Microsoft - viel mehr Ressourcen haben, um damit umzugehen, als das durchschnittliche Unternehmen auf .NET Core umsteigen muss? (Ich spreche nicht einmal über externe Abhängigkeiten, die Sie nicht besitzen und kontrollieren).

Was ist das eigentliche Problem hier? Personen, die nicht von ASP.NET Legacy zu ASP.NET Core wechseln können, können nicht verschieben, unabhängig davon, ob ASP.NET Core auf .NET Framework abzielt oder nicht. Der wahrscheinlichste Grund, warum sie keine System.Web spezifischen Bibliotheken können oder wollen, funktioniert weder unter ASP.NET Core unter .NET Framework. Die Leute, die jetzt ihre Bewerbungen haben, haben offensichtlich bereits das Arbeitsset.

Und die Leute, die bereits mit ASP.NET Core 2.1 unter .NET Framework arbeiten, wenn es funktioniert, warum dann umziehen wollen? Offensichtlich ist alles, was benötigt wird, bereits vorhanden und alles andere, was neu in ASP.NET Core 3.0 kommt, ist schön zu haben.

Was die anderen betrifft:
Es gibt viele Möglichkeiten, eine Anwendung auf .NET Core zu migrieren, dh Teile aus den alten monolithischen Anwendungen herauszubrechen und sie als Microservices neu zu implementieren. Auf diese Weise können Sie auch das Risiko senken und es über die Zeit verteilen

Was ist, wenn die Plattform nie aufholt? Dann haben Sie eine Bibliothek, die auf netstandard2.3 abzielt und Feature A benötigt, das nur unter .NET Core und Xamarin verfügbar ist, für .NET Framework jedoch nicht möglich ist.

Wenn eine API von den meisten Plattformen, die .NET Standard unterstützen, nicht implementiert werden kann, stehen die Chancen gut, dass sie nicht Teil des Standards sein sollte, oder? (In der Praxis ist es sehr wahrscheinlich umgekehrt, da Plattformen, auf denen Xamarin ausgeführt wird, im Allgemeinen viel eingeschränkter sind.) Ich würde erwarten, dass diese Art von Problem erkannt wird, wenn die API auf Aufnahme in .NET Standard überprüft wird, aber ich könnte mich irren.

Und die Leute, die bereits mit ASP.NET Core 2.1 unter .NET Framework arbeiten, wenn es funktioniert, warum dann umziehen wollen?

• Unterstützung? (Eine 3-jährige Unterstützung ist wahnsinnig kurz)
• Ein Bugfix, der nur in 3.0 vorhanden ist? (LTS-Versionen erhalten nur Korrekturen für kritische Fehler und Schwachstellen.)
• Sie müssen auf eine Bibliothek verweisen, die nur mit der neuesten ASP.NET Core-Version kompatibel ist?

Es gibt viele Möglichkeiten, eine Anwendung auf .NET Core zu migrieren, dh Teile aus den alten monolithischen Anwendungen herauszubrechen und sie als Microservices neu zu implementieren. Auf diese Weise können Sie auch das Risiko senken und es über die Zeit verteilen

Ja, theoretisch ist das der ideale Weg, um damit umzugehen. Aber:

• Einige Apps hängen von externen Bibliotheken ab, über die Sie keine Kontrolle haben. Wenn die Bibliothek unter .NET Core nicht funktioniert und der Anbieter sie nicht portieren möchte (oder kann), haben Sie kein Glück.
• Die Migration zu .NET Core kann kostspielig und zeitaufwändig sein. Glauben Sie wirklich, dass es für ein durchschnittliches Team so einfach sein wird, wenn selbst die besten Teams von Microsoft damit zu kämpfen haben? Wir müssen auf 3.0 warten, um zu sehen, dass Entity Framework 6 endlich mit .NET Standard kompatibel ist.

Verstehen Sie nicht falsch, was ich sage: Ich bin alle dafür, .NET Core für neue Apps zu verwenden. Die Tatsache, dass ASP.NET Core mit .NET Framework kompatibel war, half vielen Unternehmen, zu angemessenen Kosten auf ASP.NET Core umzusteigen. Ich bin überzeugt, dass es ohne diesen "nicht zu harten" Migrationspfad nie so beliebt gewesen wäre.

Microsoft, wäre es zu viel verlangt, die 2.1-Unterstützung zu erweitern? 2021 ist nicht lang genug für uns und wir haben nicht genug Ressourcen / Zeit, um diese Konvertierung durchzuführen. Vielleicht zumindest bis 2022? Ein zusätzliches Jahr würde uns wirklich die Chance geben, die Änderungen vorzunehmen, wenn auch schmerzhafte.

Beachten Sie, dass viele unserer Drittanbieter ihre Bibliotheken noch nicht auf .NET Core-Kompatibilität migriert haben. Dies ist der Hauptgrund für unser Auflegen.

Zu Ihrer Information https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

Während ich die Erweiterung von LTS nach Bedarf betrachte, sollte auch das IMO-Rolling von ASP.NET Core unter .NET FX in den .NET FX-Unterstützungszyklus berücksichtigt werden. Für den Anfang ist es verwirrend, verschiedene Teile von .NET Framework in verschiedenen Unterstützungszyklen zu haben, in denen das Zusammenrollen sinnvoller wäre. Zweitens ist der Code für 2.1 bereits geschrieben, freigegeben und abhängig davon, sodass für die Unterstützung von 2.1 erheblich weniger Ressourcen erforderlich sind, als wenn er aktiv in Verbindung mit .NET Core 3.0 entwickelt wird. Wenn dasselbe Team beide verwaltet, würde ich auch davon ausgehen, dass die aktuelle und bekanntere modulare aktive ASP.NET Core-Codebasis einfacher zu unterstützen ist als die völlig andere klassische ASP.NET-Codebasis.

Als MS 2012 EOL von Silverlight 5 ankündigte, unterstützen sie es noch bis Oktober 2021 (obwohl es 2015 in Chrome und 2017 in Firefox eingestellt wurde). Dies gilt für Technologien, die vollständig aufgegeben wurden, was hier nicht der Fall ist. Es wird weitgehend dieselbe Codebasis, dasselbe Programmiermodell und ein aktives Entwicklerteam noch daran gearbeitet. Es wird nur vorhandene Software in .NET Framework ausgeführt, die aufgegeben wird.

Vor dieser Ankündigung gab es starke Nachrichtenübermittlung MS gab .NET Framework nie auf, dass es sich hervorragend für reine Windows-Workloads eignet (im Gegensatz zu .NET Core für plattformübergreifende / hochleistungsfähige Workloads) und dass ASP.NET Core die Zukunft ist Programmiermodell, das in Zukunft sowohl .NET Framework als auch .NET Core mit .NET Standard als Lösung für die Entwicklung von Bibliotheken für mehrere Plattformen unterstützen würde.

Es ist jetzt klar, dass .NET Core die Zukunft für alle neuen Projekte ist, aber hier geht es darum, wie bestehende Investitionen und bestehende Kunden behandelt werden, die bisher Entscheidungen auf der Grundlage dieser Leitlinien getroffen haben. Wie entwickeln sich vorhandene .NET Dev-Teams, wenn sie vorhandene Systeme unterstützen müssen? Sie werden gezwungen sein, auf klassischem ASP.NET zu bleiben (wo ihre vorhandenen Fähigkeiten / Kenntnisse täglich veraltet sind), während der Kontext wechselt, um neue Apps zu entwickeln auf .NET Core.

Wenn ich gezwungen wäre, Systeme unter .NET Framework zu warten, würde ich es vorziehen, sie auf dem neuen ASP.NET-Programmiermodell mit Zugriff auf eine aktive Wissensbasis / ein aktives Ökosystem zu entwickeln, und dann gezwungen sein, wieder altes ASP.NET zu verwenden Auf unbestimmte Zeit, aber das wird nur möglich sein, wenn ASP.NET Core unter FX dieselbe Unterstützung wie WebForms bietet.

MS hat auch die Möglichkeit, ASP.NET Core unter FX als "stabile" Entwicklungsumgebung zu positionieren (dh auf ASP.NET Core 2.1 festgelegt). In den letzten Jahren seit dem Start von .NET Core war es nicht einfach, .NET-Entwickler zu sein. Wir mussten effektiv alle Anstrengungen aufgeben, um zu versuchen, auf .NET Core <1.x zu portieren, da es schwierig war, mit dem ständigen Strom von Änderungen Schritt zu halten. Dies war nur bis zu .NET Core 2.x möglich um es zu unterstützen und vorhandene Apps zu migrieren. Auf der anderen Seite haben bestehende ASP.NET Framework-Entwickler gesehen, dass ihre gewählte Plattform stagniert und dann durch das neue ASP.NET Core-Programmiermodell und durch die Erweiterung ersetzt wurde, die ihre vorhandenen Fähigkeiten / Kenntnisse untergraben. Durch die Beendigung der Unterstützung für ASP.NET Core unter FX wird eine beliebte abgestufte Migrationsstrategie in Richtung .NET Core beendet, bei der das Risiko (ohne Notfall-Fallback) auf einer verlassenen Plattform besteht, es sei denn, sie können ihr gesamtes System auf .NET Core aktualisieren (ein Risiko) Dies kann verhindern, dass Migrationsversuche in Betracht gezogen werden. Außerdem wird die Möglichkeit zunichte gemacht, am zukünftigen ASP.NET Core-Entwicklungsmodell teilnehmen zu können, wenn sie nicht in der Lage sind, ihre vorhandenen Systeme zu migrieren, an denen sie täglich arbeiten nur möglich, wenn es die gleiche Unterstützung wie WebForms genießt - was hoffentlich noch in Betracht gezogen wird.

Niemand erwähnte: In unserer asp.net-Kernanwendung müssen wir WCF-Dienste hosten, und dies ist der einzige Schmerzpunkt bei der Migration vom .net-Framework. Ich sehe leider keine Neuigkeiten über die serverseitige wcf-Unterstützung auf .net Core 3.

@DamianEdwards @davidfowl @natemcmaster Wir sitzen im selben Boot. Mein Unternehmen verfügt über eine Reihe von Produkten, die auf ASP.Net Core unter .Net Full Framework ausgeführt werden. Wir unterstützen diese Produkte aufgrund der langsamen Entwicklung der Branchen, die wir verkaufen, viel länger als drei Jahre. Die Erweiterung des LTS für .net Core 2.2 wäre in unserer Situation bedeutungslos, da wir unsere ASP.net Core-Anwendungen zurück auf ASP.Net portieren müssten. Sicherlich besiegt dies den Punkt Jungs! Würden Sie nur vorschlagen, Anwendungen für kürzere Zeiträume zu unterstützen? Leider haben wir auch keine Kontrolle darüber. Die Branchen, in denen wir arbeiten, können ein Jahr brauchen, um unsere neue Software einzuführen.

Leider bedeutet dies, dass jeder, der noch vor Ort Bereitstellungen durchführt, seine Software nicht länger als 3 Jahre unterstützen kann. Sobald Sie beispielsweise eine App für .netcore 3.0 veröffentlichen, haben Ihre Kunden 3 Jahre Zeit und müssen dann ein Upgrade durchführen. Einige Branchen, in denen es gut geht, andere sicherlich nicht.

Das ist das größte Problem dabei und macht .net Core für viele Leute zu einem absoluten Non-Go, würde ich mir vorstellen. Ich stimme tatsächlich zu, dass dies am Ende die richtige Richtung ist, aber ich bin mir sicher, dass dies viele Orte davon abhalten wird, zum .net-Kern zu gelangen.

Ich hätte wirklich gerne eine Antwort vom .net-Team dazu.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

Na ja, das zwingt deine Bibliotheken nur dazu, besser geschichtet zu werden 😉

Funktioniert dieses Argument nicht in die entgegengesetzte Richtung?

Was ich nicht verstehen kann, ist, was Sie tatsächlich daran hindert, die richtige Layering-Architektur von ASP.NET Core zu erstellen?
Ja, einige Laufzeitfunktionen sind in .Net Framework nicht verfügbar, z. B. Span<T> . Dies bedeutet jedoch nicht, dass sie überhaupt nicht verfügbar sind. Es ist verfügbar , es ist einfach nicht so performant wie auf dem .Net-Kern. Damit könnten wir umgehen.

Einige Low-Level-Implementierungen könnten in Variationen speziell für den .net-Kern und für den .net-Standard implementiert werden. Und ich bezweifle, dass dafür viel Platz ist, da APIs normalerweise als NuGet-Pakete verfügbar sind.
Viele Bibliotheksautoren unterstützen unterschiedliche Implementierungen für unterschiedliche Plattformen. Dies war schon immer so.

Könnten Sie bitte näher erläutern, was Sie genau daran hindert, .Net Framework / .Net Standard zu unterstützen? Ein paar einfache Beispiele, die nicht für plattformspezifische Implementierungen abstrahiert werden können?

verhindert, dass Sie .Net Framework / .Net Standard unterstützen. Ein paar einfache Beispiele, die nicht für plattformspezifische Implementierungen abstrahiert werden können?

Auf den ersten Blick Elemente, die Laufzeit- oder Framework-Änderungen erfordern

• Innen-GC-Zeiger; Erstellen einer sicheren Spanne aus einem Ref nur ohne Objekt: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Standardschnittstellenimplementierungen
• Benutzerdefinierte Threadpool-Arbeitselemente
• Überlastungen für Basistypen: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable-Überladungen für Basistypen: Stream, Sockets, TextReader / TextWriter, WebSockets usw.
• IAsyncEnumeratorÜberladungen von Basistypen: Stream, Sockets, TextReader / TextWriter, WebSockets usw.

Bonusartikel

• Hardware-Eigenschaften (x86, x64, ARM)
• Escape-Analyse (neue Zuordnungen zum Stapeln)
• Side-by-Side-Laufzeitversionen
• Korrigieren von Bindungsumleitungen und Versionsverwaltung

Ich verstehe nicht, warum wir nicht einfach eine Netstandard-Version haben können, die Netframework nicht mehr unterstützt. Genau wie Windows Phone gibt es keine Standardunterstützung über 1.2 hinaus. Warum können wir den Standard nicht weiterentwickeln und zulassen, dass Implementierungen wie Netcore, Mono, Xamarin usw. irgendwann oder nie mit ihm übereinstimmen? Dann muss der Bibliothekshersteller entscheiden, welche Netstandard-Version er implementieren möchte, um die Abdeckung zu maximieren.

Diese Änderung macht es so, dass Xamarin und Mono Aspnetcore nicht mehr verwenden können. Es macht es so, dass Bibliothekshersteller gezwungen sind, sowohl auf Netcore als auch auf Netstandard zu zielen, oder schlimmer noch, Netstandard insgesamt aufzugeben und nur auf Netcore abzuzielen.

Dies wird letztendlich zum Tod von netstandard führen.

verhindert, dass Sie .Net Framework / .Net Standard unterstützen. Ein paar einfache Beispiele, die nicht für plattformspezifische Implementierungen abstrahiert werden können?

Auf den ersten Blick Elemente, die Laufzeit- oder Framework-Änderungen erfordern

• Innen-GC-Zeiger; Erstellen einer sicheren Spanne aus einem Ref nur ohne Objekt: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Standardschnittstellenimplementierungen
• Benutzerdefinierte Threadpool-Arbeitselemente
• Überlastungen für Basistypen: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable-Überladungen für Basistypen: Stream, Sockets, TextReader / TextWriter, WebSockets usw.
• IAsyncEnumerator überlastet Basistypen: Stream, Sockets, TextReader / TextWriter, WebSockets usw.

Bonusartikel

• Hardware-Eigenschaften (x86, x64, ARM)
• Escape-Analyse (neue Zuordnungen zum Stapeln)
• Side-by-Side-Laufzeitversionen
• Korrigieren von Bindungsumleitungen und Versionsverwaltung

Elemente in dieser ersten Liste klingen wie Dinge, die Kandidaten für Änderungen des Netzstandards wären?

Die meisten von ihnen scheinen nicht unmöglich zu anderen Laufzeiten zu bringen, aber es scheint, dass niemand die CLR für eine neue Version überarbeiten möchte, um Standardschnittstellenimplementierungen in .NET Framework zu bringen.

Gleichzeitig scheint Microsoft nicht mit einer Version von .NET Standard vorankommen zu wollen, die für immer mit .NET Framework nicht kompatibel ist. Andernfalls wäre dies kein wirkliches Problem - treiben Sie einfach netstandard30 oder netstandard40 voran und lassen Sie die Framework-Unterstützung fallen. und .NET Core auf einen dieser neueren Standards abzielen lassen.

Ich denke, dieser Thread usw. ist das Ergebnis von Microsoft, das sich effektiv in eine Ecke malt.

Gleichzeitig scheint Microsoft nicht mit einer Version von .NET Standard vorankommen zu wollen, die für immer mit .NET Framework nicht kompatibel ist.

Dies ist unaufrichtig; .NET Standard 2.1 wird derzeit finalisiert und verfügt über 3104 neue APIs über .NET Standard 2.0, einschließlich Span Überladungen für Basis-Framework-Typen. Dies kann dazu führen, dass es nicht mit .NET Framework kompatibel ist.

.NET Standard ist noch in Bewegung.

Andernfalls wäre dies kein wirkliches Problem - treiben Sie einfach netstandard30 oder netstandard40 voran und lassen Sie die Framework-Unterstützung fallen. und .NET Core auf einen dieser neueren Standards abzielen lassen.

Das Problem besteht darin, dass jede Laufzeit und nicht nur Framework mit einem der neueren Standards inkompatibel ist. und danach nicht mehr mit jedem Standard kompatibel. Was in .NET Standard enthalten ist, muss von den verschiedenen Laufzeiten als Dinge vereinbart werden, die implementiert werden können.

Werden die verschiedenen GCs von Mono und Unity bald Innenzeiger unterstützen? Wenn Sie sie nicht zu .NET Standard hinzufügen, werden sie für jeden zukünftigen .NET Standard von diesem .NET Standard blockiert, bis ihre GCs geändert werden, um mit ihnen umzugehen. Jedoch; Es ist besser, APIs hinzuzufügen, die sie jetzt implementieren können, und diejenigen, die sie nicht können, für einen zukünftigen Standard zu speichern.

Werden die Apis zu Core hinzugefügt, um die richtigen Apis für immer dauerhaft zu reparieren und jede Laufzeit zu erzwingen? das will mit dem nächsten standard kompatibel sein, um es umzusetzen?

Einige der Core 2.1-APIs haben sich zwischen Vorschau 1 und Vorschau 2 geändert (aufgrund von Nutzungsrückmeldungen). Es ist also schwer zu wissen, was die Apis sind, die in Core X neu sind, bis sie veröffentlicht werden und an diesem Punkt in Stein gemeißelt sind. Welche von ihnen sind die richtigen, die zum Standard hinzugefügt werden sollen, damit alle Laufzeiten implementiert werden (oder von denen sie zurückgelassen werden).

Der Ansatz für .NET Standard ist immer noch aggressiver als für Browserstandards, wenn zwei Browser die Funktion implementieren müssen, bevor ein Standard akzeptiert wird.

Es wäre schön, wenn ein neuer .NET Standard gleichzeitig mit .NET Core ausgeliefert werden könnte und alle Laufzeiten ihn sofort implementieren könnten und ASP.NET Core dann alle neuen APIs über .NET Standard verwenden könnte. aber obwohl es als Ideal schön ist, ist es auch nicht praktisch. Es gibt sogar einige genehmigte APIs, die nicht in .NET Core implementiert wurden

Die grundlegende Frage ist, ob ASP.NET Core die von ihm angeforderten APIs verwenden und in der mitgelieferten .NET Core-Version versenden kann (da sie gleichzeitig ausgeliefert werden). oder kann es nur die APIs verwenden, die in der vorherigen Version von .NET Core ausgeliefert wurden - die daher die Chance haben, in der .NET Standard-Version für diesen .NET Core zu sein? (Da es so aussieht, als ob .NET Standard-Versionen derzeit in der apis 1-Version hinter .NET Core zurückbleiben; unter Verwendung der Stichprobengröße 1)

Wenn ASP.NET Core die API verwenden kann; Dann werden die Apis auf ihre Verwendung getestet und bewertet, ob sie gute Apis sind. Wenn dies nicht der Fall ist, können bessere Apis vorgeschlagen werden. Wenn ASP.NET Core sie nicht verwenden kann, ist es noch ziemlich unbekannt, ob sie gute APIs sind, wenn sie zu .NET Standard-Kandidaten werden.

Niemand möchte die CLR für eine neue Version überarbeiten, um Standardschnittstellenimplementierungen in .NET Framework zu bringen.

.NET Core durch die Unterstützung traditioneller .NET Framework-Workloads (einschließlich WinForms und WPF) ist im Wesentlichen die Überarbeitung der CLR. aber nachhaltiger und zukunftssicherer?

Dies ist unaufrichtig; .NET Standard 2.1 wird derzeit fertiggestellt und verfügt über 3104 neue APIs gegenüber .NET Standard 2.0, einschließlich Span-Überladungen für Basis-Framework-Typen. Dies kann dazu führen, dass es nicht mit .NET Framework kompatibel ist.

Einschließlich .NET Framework 4.8 und .NET Framework 4.9?

Es besteht immer die Möglichkeit, dass zukünftige Framework-Updates diese neuen APIs erhalten. Im Moment scheint es in Stein gemeißelt, dass .NET Framework niemals DIM erhalten wird, daher könnte eine Schnittstelle mit einer DIM-Methode niemals auf .NET Framework portiert werden.

.NET Core durch die Unterstützung traditioneller .NET Framework-Workloads (einschließlich WinForms und WPF) ist im Wesentlichen die Überarbeitung der CLR. aber nachhaltiger und zukunftssicherer?

Und nicht rückwärtssicher. So sehr Microsoft Dinge wie Paint.Net unter .NET Core vorführte, kann ich meine vorhandenen serverseitigen Projekte nicht unter .NET Core ausführen, und die meisten Benutzer auch nicht.

Es wäre schön, wenn ein neuer .NET Standard gleichzeitig mit .NET Core ausgeliefert werden könnte und alle Laufzeiten ihn sofort implementieren könnten und ASP.NET Core dann alle neuen APIs über .NET Standard verwenden könnte. aber obwohl es als Ideal schön ist, ist es auch nicht praktisch.

Dies mag auch nicht praktikabel sein, aber ich denke, die Leute wären insgesamt ein bisschen glücklicher, wenn es zwei Versionen von ASP.NET Core geben könnte:

• Eine schnelllebige Version, die an .NET _Core_ gebunden ist und jede neue API verwenden kann, die sie wünscht.
• Eine langsamere LTS-Version, die an .NET _Standard_ gebunden ist und an mehreren Stellen ausgeführt wird. was schließlich ältere blutende Builds einholt, aber immer zurückbleibt.

Indem Sie es an .NET Core binden, erzwingen Sie einen Kompromiss, mit dem nicht jeder zufrieden ist. Ich verstehe die Gründe für den schnellen Ansatz, aber es gibt auch berechtigte Bedenken hinsichtlich des gesamten .NET-Ökosystems.

• Eine schnelllebige Version, die an .NET Core gebunden ist und jede neue API verwenden kann, die sie wünscht.
• Eine langsamere LTS-Version, die an .NET Standard gebunden ist und an mehreren Stellen ausgeführt wird. was schließlich ältere blutende Builds einholt, aber immer zurückbleibt.

Wenn also ASP.NET Core 3.0 nur als .NET Core 3.0 herauskam; aber zu einem späteren Zeitpunkt, als es sich um einen .NET-Standard handelte, der die Apis hatte; Es wurden Pakete für ASP.NET Core 3.x veröffentlicht, die ebenfalls .NET Standard waren (selbst wenn ASP.NET Core auf 4.0 umgestellt wurde). würde das Ihren Anforderungen entsprechen?

@ yaakov-h

Eine langsamere LTS-Version, die an .NET Standard gebunden ist und an mehreren Stellen ausgeführt wird. was schließlich ältere blutende Builds einholt, aber immer zurückbleibt.

Was bedeutet das? Sie können ASP.NET Core 2.1 jederzeit mit der von @DamianEdwards erwähnten erweiterten Unterstützung

Sie können ASP.NET Core 2.1 immer mit der erweiterten Unterstützung verwenden, die

Teilen Sie die Community bitte nicht auf !!
Erwarten Sie, dass 1/3 der Entwickler in asp.net Core 2.1 bleiben? oder erwarten Sie 2/3 Entwickler, die Nuget-Pakete erstellen, die 2 Versionen ihrer Bibliothek verwalten müssen?

@benaadams

Wenn also ASP.NET Core 3.0 nur als .NET Core 3.0 herauskam; aber zu einem späteren Zeitpunkt, als es sich um einen .NET-Standard handelte, der die Apis hatte; Es wurden Pakete für ASP.NET Core 3.x veröffentlicht, die ebenfalls .NET Standard waren (selbst wenn ASP.NET Core auf 4.0 umgestellt wurde). würde das Ihren Anforderungen entsprechen?

Genau.

@ Davidfowl

Sie können ASP.NET Core 2.1 jederzeit mit der von @DamianEdwards erwähnten erweiterten Unterstützung

Hier scheint es widersprüchliche Botschaften zu geben:

1. Es ist in Ordnung, auf 2.1, der älteren LTS-Version, zu bleiben
2. ASP.NET Core bewegt sich so schnell, dass wir nicht einmal einen Release-Zyklus zwischen .NET Core und dem nachfolgenden .NET Standard abwarten können.

Ich denke, (2) verursacht viel Verwirrung und Angst, zurückgelassen zu werden.

@ John0King

Erwarten Sie, dass 1/3 der Entwickler in asp.net Core 2.1 bleiben? oder erwarten Sie 2/3 Entwickler, die Nuget-Pakete erstellen, die 2 Versionen ihrer Bibliothek verwalten müssen?

Ich erwarte, dass Bibliotheksautoren entscheiden, welche Mindestversion von ASP.NET Core sie unterstützen möchten, und darauf abzielen. Das machen sie schon heute. Einige Bibliotheken unterstützen ASP.NET Core 1.x und 2.x, andere nur 2.x. Das ist nicht anders.

@ yaakov-h

Ich verstehe die widersprüchlichen Botschaften nicht ganz. Die aktuelle Version 2.1 ist LTS und läuft unter .NET Core und .NET Framework und wird 3 Jahre lang unterstützt. Dies ist keine neue Nachricht, sondern dieselbe Nachricht, die wir von Anfang an erhalten haben.

ASP.NET Core bewegt sich so schnell, dass wir nicht einmal einen Release-Zyklus zwischen .NET Core und dem nachfolgenden .NET Standard abwarten können.

Das ist Spekulation basierend auf den hier gemachten Kommentaren. Offiziell sind wir an den Versandzyklus von .NET Core gebunden und fügen mit jeder Version bereits neue APIs hinzu und verwenden diese. ASP.NET Core, das unter .NET Framework ausgeführt wird, war nie als dauerhafte Sache gedacht (es wird sogar als ASP.NET Core bezeichnet), sondern immer als Sprungbrett. Wir mussten nur genug der Kern-APIs wieder hinzufügen, damit Kunden vernünftigerweise voll funktionsfähige Anwendungen schreiben konnten.

Irgendeine Antwort des ms-Teams dazu?

Leider bedeutet dies, dass jeder, der noch vor Ort Bereitstellungen durchführt, seine Software nicht länger als 3 Jahre unterstützen kann. Sobald Sie beispielsweise eine App für .netcore 3.0 veröffentlichen, haben Ihre Kunden 3 Jahre Zeit und müssen dann ein Upgrade durchführen. Einige Branchen, in denen es gut geht, andere sicherlich nicht.

Das ist das größte Problem dabei und macht .net Core für viele Leute zu einem absoluten Non-Go, würde ich mir vorstellen. Ich stimme tatsächlich zu, dass dies am Ende die richtige Richtung ist, aber ich bin mir sicher, dass dies viele Orte davon abhalten wird, zum .net-Kern zu gelangen.

Ich hätte wirklich gerne eine Antwort vom .net-Team dazu.

Leider bedeutet dies, dass jeder, der noch vor Ort Bereitstellungen durchführt, seine Software nicht länger als 3 Jahre unterstützen kann

Das ist nur Schwachsinn, man kann eigentlich nur ein Upgrade haben. Das einzige Mal, wenn es nicht funktioniert, ist in einer eingebetteten Umgebung, aber eingebettete Software hat so viel mehr Probleme als ein Support-Fenster von 3 Jahren.

@schmitch Ich bin mir nicht sicher was du meinst? Natürlich können Sie nur ein Upgrade durchführen, aber für einige Branchen wird das Upgrade auf eine neue Softwareversion zu einem massiven Projekt, das Jahre dauern kann, abhängig von den Veröffentlichungszyklen und dem technischen Fortschritt (oder nicht) dieser Branchen.

@ Davidfowl

Ich vermute jedoch, dass selbst wenn diese Unterstützung 10 Jahre betragen würde, die Leute, die sich beschweren, nicht zufrieden sein würden.

Sie sind sich nicht sicher, wie Sie damit gerechnet haben, aber jeder, für den diese Entscheidungseffekte gelten, hat mit der Plattform zu kämpfen, auf die er verkauft wurde. Er hat nicht nur keine Zukunft, sondern seine bestehenden Investitionen, die auf dem neuesten Programmiermodell basieren, werden weitergeführt eine nicht unterstützte Plattform (die ab dieser Ankündigung) in weniger als 3 Jahren. Andere, die über eine sorgfältige schrittweise Migration zu .NET Core über die Migration zu .NET Framework nachgedacht haben, sind jetzt dem Risiko ausgesetzt, dass es keinen Notfall gibt, auf den zurückgegriffen werden kann - es wird auf einer neuen .NET Core-Laufzeit oder -Pleite ausgeführt.

Eine Entwicklerplattform sollte nicht das Ziel an sich sein, da auf der Plattform ein exponentiell größerer Wert geschaffen wird als der Wert der Plattform selbst. Blindsiding-Bewegungen wie diese lassen den Eindruck entstehen, dass die maximale Effizienz von Ressourcen zur Erhöhung der Geschwindigkeit der Plattform wichtiger ist als Investitionen des darauf geschaffenen Ökosystems. Die Tinte auf den .NET Core 2.1-Bits ist noch nicht einmal trocken, aber vorhandene Systeme (unter FX) werden bereits als Verbindlichkeit (mit dem Ziel einer minimalen Unterstützung) behandelt, anstatt des Vermögenswerts und des Werts, den sie dem Ökosystem hinzufügen.

Wie bereits erwähnt, können sich Unternehmenssysteme in rasantem Tempo bewegen und oft gleichzeitig Entwicklerteams ausgleichen, um kontinuierliche Verbesserungen zu erzielen, die eine Anzahl von Mitarbeitern und Kunden benötigen, um daraus einen konstanten ROI zu erzielen. Viele Migrationen müssen "während des Fluges" mit sorgfältiger Planung und strengen Tests durchgeführt werden, was Jahre dauern kann - Zeit, die sie lieber nutzen würden, um Wert zu schaffen, als sich zu krabbeln, um von der Plattform zu verschwinden, auf der Unterstützung von ihnen abgezogen wird. Große Brownfield-Systeme sind keine Standardprodukte wie iPhones, die alle paar Jahre leicht verworfen und nahtlos aktualisiert werden können. Je älter und länger Systeme in der Entwicklung sind, desto mehr Wert wird in sie investiert und desto schwieriger wird es, sie zu migrieren, was besonders wichtig wird Schwer zu absorbieren, da bei Migrationen kein Wert geschaffen wird, Ressourcen benötigt werden, Opportunitätskosten absorbiert werden, das Risiko erhöht wird und das Beste, auf das sie hoffen können, eine fehlerfreie Migration ist, bei der die vorhandenen Systeme genauso ausgeführt werden wie zuvor.

Unabhängig davon, welches Ablaufdatum für die FX-Unterstützung festgelegt wurde, werden vorhandene Systeme daran vorbeigehen, die auf Straßensperren stoßen oder auf andere Weise nicht migriert werden konnten. Was wird dann die Anleitung?

ASP.NET Core 2.1 ist bereits entwickelt. Die Bemühungen, ASP.NET Core unter FX / .NET Core auszuführen, sind bereits gesunkene Kosten. Daher sollte die Entscheidung als eine Frage der MS-Ressourcen getroffen werden, eine bereits entwickelte Plattform (nach LTS) zu erhalten, im Vergleich zu den kumulierten Kosten, dem schlechten Willen und der Trägheit, die für die Aufgabe einer beliebten Plattform entstehen.

Ich bin mir nicht sicher, ob ich verstehe, wonach gefragt wird. Der Lebenszyklus für LTS hat sich seit dem Erscheinen von 2.1 nicht geändert. Wenn Sie eine App für die LTS-Version (.NET Core oder .NET Framework) geschrieben haben, dauert es 3 Jahre, bis Sie nicht mehr unterstützt werden. Ich verstehe nicht ganz, wie der Teppich in Bezug auf die Unterstützung unter Ihnen hervorgezogen wird, das hat sich nicht geändert. Sie müssten ein Upgrade durchführen, um Plattform-Updates zu erhalten.

Jetzt verstehe ich , dass 2.1 die letzte LTS - Version auf .NET Framework unterstützt wird Mittel gibt es keinen Ort , um ein Upgrade auf, aber das ist , wo die Unterstützung LTS erweitert kommt in. Wenn die Anwendung nie auf .NET - Core auch nach diesen 6 Jahren bewegen kann , weil APIs fehlt, bitte Probleme einreichen, damit wir die Lücken verstehen.

Ich bin mir nicht sicher, ob ich verstehe, wonach gefragt wird.

Dieser Thread fordert von MS unterschiedliche Verpflichtungen an: Weiterentwicklung in Zusammenarbeit mit .NET Core, Weiterentwicklung in einem "langsamen Zug", ohne ASP.NET Core 2.1 aufzugeben und das gleiche Maß an Unterstützung wie WebForms beizubehalten, LTS zu erweitern . Ich würde es vorziehen, es nicht als Hosting-Option für ASP.NET Core aufzugeben (bearbeiten: obv alles darüber wäre vorzuziehen), was .NET Core nur v3 + nicht zurückhalten würde und gleichzeitig viel Nutzen für vorhandenes .NET bietet FX-Investitionen.

Jetzt verstehe ich, dass 2.1 als letzte von .NET Framework unterstützte LTS-Version bedeutet, dass es keinen Ort gibt, auf den ein Upgrade durchgeführt werden kann

Das heißt, es ist zu einer nicht unterstützten Plattform geworden. Jeder, der sich darauf befindet, muss es wie Lava behandeln und durcheinander bringen, bevor es sein nicht unterstütztes EOL-Ende erreicht.

• Jeder, der darüber nachgedacht hat, es als Staging-Plattform für die Umstellung auf .NET Core zu verwenden, ist zu einer weniger praktikablen Option geworden, da er dem Risiko ausgesetzt ist, auf einer nicht unterstützten Plattform gestrandet zu sein, wenn die Migration länger als erwartet dauert, oder wenn eine der Abhängigkeiten auf Straßensperren stößt Sie verlassen sich darauf, dass sie nicht auf .NET Core ausgeführt werden können.
• Jeder, der gezwungen ist, die .NET Framework-Server der vorhandenen verwalteten Infrastruktur seines Unternehmens zu verwenden, kann nicht an der Verwendung des neuen Entwicklungsmodells und Ökosystems teilnehmen und muss feststellen, dass die vorhandenen klassischen ASP.NET-Kenntnisse / -Fähigkeiten von Tag zu Tag weniger wert sind.
• Teams können ihre vorhandenen, für .NET Framework erforderlichen Systeme nicht migrieren und müssen den Kontext auf neue ASP.NET Core-Projekte in .NET Core umstellen.
• Kein Unternehmen möchte zu einer ungeplanten Migration gezwungen werden, da sich die Richtlinien, auf die es sich bei der Budget-, Planungs- und Investitionsentscheidung verlassen hat, geändert haben.

Auch dies ist kein Problem für Greenfield-Projekte, für Personen, die ohnehin auf .NET Core migrieren können oder wollten, oder für alle, die keine Legacy-Systeme warten müssen, dies wirkt sich jedoch auf das vorhandene .NET FX-Ökosystem und ASP.NET Core aus ist ärmer geworden, weil es nicht mehr in Betracht gezogen wird, die beliebte Option des Hostings auf .NET FX zu nutzen.

In einer perfekten Welt wäre jeder auf .NET Core, aber es gibt eine beträchtliche Menge an Investitionen in .NET FX, die mit dieser Entscheidung abgewertet werden.

Wenn die Anwendung auch nach diesen 6 Jahren nicht mehr auf .NET Core umgestellt werden kann, weil APIs fehlen,

Es gibt viele Leute, die nicht zu .NET Core wechseln können oder wollen. Sie möchten, dass es den gleichen Grad an Unterstützung wie klassisches ASP.NET hat (was in den aktuellen Nachrichten auf unbestimmte Zeit vorgeschlagen wird).

Fehlende APIs sind nicht der einzige Grund, der die Migration verhindert. Sie können sich beispielsweise auf eine Abhängigkeit stützen, in der das vom Entwicklerteam erstellte nicht mehr vorhanden ist. Es handelt sich um eine kritische Komponente, die nicht geändert werden kann und nicht sicher umgestaltet werden kann (z keine Tests), wird mit anderen Nur-.NET-FX-Systemen geteilt, von einer anderen Abteilung verwaltet, die kein Budget, keine Änderungskapazität oder aufgrund externer Faktoren wie der von ihrem Unternehmen verwalteten Infrastruktur nur die Ausführung auf .NET Framework-Servern unterstützt.

Vielen Dank, dass Sie .NET Standard mit dieser Art von Entscheidungen beendet haben.

Bisher haben wir .NET Core ignoriert, da es viele Assemblys von Drittanbietern gibt, die noch nicht auf Core abzielen.

Viele der Anbieter, die bereit sind, Core zu unterstützen, tun dies auf halbherzige Weise, z. B. Managed ODP.NET ohne die nativen APIs, die nur in .NET Framework verfügbar sind.

Dann kommen Sie mit solchen Entscheidungen herum.

Nein, wir werden .NET Core nicht schneller einführen, nur weil es für Microsoft zu viel Arbeit ist, .NET Framework zu unterstützen, und es nicht in der Lage ist, den .NET-Standard zu liefern, den Sie von Anfang an vorangetrieben haben.

@davidfowl Ich kann Ihnen zwei Beispiele geben, die die Migration auf .NET Core erschweren - WCF (viele vorhandene Unternehmensanwendungen verwenden es, ich glaube, andere haben dieses Problem bereits angesprochen) und das Fehlen einer Adomd-Bibliothek in .NET Core / NET Standard (für die Kommunikation mit SSAS, das auch in Unternehmensanwendungen verwendet wird und in SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core verfolgt wird). Einige andere (Winforms) sollten mit dem .net Core 3-Kompatibilitätspaket behoben werden (yay!) - wir müssen abwarten, wie es wirklich funktioniert.

@mythz

Dieser Thread fordert von MS unterschiedliche Verpflichtungen an: Weiterentwicklung in Zusammenarbeit mit .NET Core, Weiterentwicklung in einem "langsamen Zug", ohne ASP.NET Core 2.1 aufzugeben und das gleiche Maß an Unterstützung wie WebForms beizubehalten, LTS zu erweitern . Ich würde es vorziehen, es nicht als Hosting-Option für ASP.NET Core aufzugeben, die .NET Core nur v3 + nicht zurückhält und gleichzeitig viel Nutzen für vorhandene .NET FX-Investitionen bietet.

Nun, wir prüfen derzeit die Erweiterung der LTS-Unterstützung, erwägen jedoch nicht für immer die erstklassige .NET Framework-Unterstützung für ASP.NET Core (was Sie verlangen). Diese Version von ASP.NET Core, für die Sie die gleiche Unterstützung wie WebForms suchen, würde immer nur Sicherheitskorrekturen und Zuverlässigkeitskorrekturen erhalten. Ich kann Ihnen garantieren, dass mit dem Erscheinen von Funktionen in neueren Versionen von ASP.NET Core die Zufriedenheit derjenigen, die ASP.NET Core 2.1 verwenden, sinken wird (zumindest sagt mir das mein Bauch), da diese Änderungen immer noch nicht zutreffen erreichen.

Fehlende APIs sind nicht der einzige Grund, der die Migration verhindert. Sie können sich beispielsweise auf eine Abhängigkeit stützen, in der das vom Entwicklerteam erstellte nicht mehr vorhanden ist. Es handelt sich um eine kritische Komponente, die nicht geändert werden kann und nicht sicher umgestaltet werden kann (z keine Tests), wird mit anderen Nur-.NET-FX-Systemen geteilt, von einer anderen Abteilung verwaltet, die kein Budget, keine Änderungskapazität oder aufgrund externer Faktoren wie der von ihrem Unternehmen verwalteten Infrastruktur nur die Ausführung auf .NET Framework-Servern unterstützt.

Dies ist sehr häufig (auch innerhalb von Microsoft) und deshalb haben wir diese Möglichkeit hinzugefügt, auf .NET Framework-DLLs in .NET Core 2.0 zu verweisen, da sich herausstellt, dass die meisten Assemblys kompatibel sind, auch wenn sie nicht für .NET Core kompiliert wurden. Nun gibt es einige Dinge, die niemals funktionieren werden (wie AppDomains ...), aber ich gehe davon aus, dass die Anzahl der Bibliotheken, die nicht nur funktionieren, auf eine unbedeutende Zahl schrumpfen wird, wenn wir mehr API-Oberfläche hinzufügen.

@pjmlp

Ich sehe nicht, wie dies .NET Standard tötet. .NET Standard ist viel größer als ASP.NET Core. Es geht darum, wiederverwendbare gemeinsam genutzte Bibliotheken (wie Microsoft.Extensions *) zu erstellen, die auf jeder unterstützenden .NET-Plattform funktionieren.

Bisher haben wir .NET Core ignoriert, da es viele Assemblys von Drittanbietern gibt, die noch nicht auf Core abzielen.

Welche? Sind Unterstützung für unterwegs oder werden diese Assemblys niemals .NET Core unterstützen?

Viele der Anbieter, die bereit sind, Core zu unterstützen, tun dies auf halbherzige Weise, z. B. Managed ODP.NET ohne die nativen APIs, die nur in .NET Framework verfügbar sind.

Ich bin damit einverstanden und habe Tonnen von verkrüppelten Versionen von Bibliotheken auf .NET Core gesehen (sogar mit einigen Bibliotheken, die Microsoft ausliefert), aber ich würde sagen, dass die Gezeiten das ändern. Einige der Gründe dafür waren die anfänglich fehlenden APIs, die in .NET Core 1.0 vorhanden waren. Mit 2.0 und 2.1 haben wir festgestellt, dass eine große Anzahl von Bibliotheken einfacher auf Core / Standard portiert werden kann, ohne dass die Funktionalität stark beeinträchtigt wird.

@voltcode Danke für das konkrete Feedback! Wir gehen davon aus, dass einige dieser Kompatibilitätsprobleme in der Zeitspanne, in der wir heute .NET Core-Projekte unterstützen (ca. 3 Jahre), verschwinden oder minimal sind.

@ Davidfowl

....

Bisher haben wir .NET Core ignoriert, da es viele Assemblys von Drittanbietern gibt, die noch nicht auf Core abzielen.

Welche? Sind Unterstützung für unterwegs oder werden diese Assemblys niemals .NET Core unterstützen?

In unserem Fall ist ODP.NET die offensichtliche, da Oracle nicht 100% der Treiberfunktionen in Core portiert.

Viele der Anbieter, die bereit sind, Core zu unterstützen, tun dies auf halbherzige Weise, z. B. Managed ODP.NET ohne die nativen APIs, die nur in .NET Framework verfügbar sind.

Ich bin damit einverstanden und habe Tonnen von verkrüppelten Versionen von Bibliotheken auf .NET Core gesehen (sogar mit einigen Bibliotheken, die Microsoft ausliefert), aber ich würde sagen, dass die Gezeiten das ändern. Einige der Gründe dafür waren die anfänglich fehlenden APIs, die in .NET Core 1.0 vorhanden waren. Mit 2.0 und 2.1 haben wir festgestellt, dass eine große Anzahl von Bibliotheken einfacher auf Core / Standard portiert werden kann, ohne dass die Funktionalität stark beeinträchtigt wird.

Das sehen aber nicht so viele unserer Kunden.

Damit Sie ein Gefühl dafür bekommen, wie sich diese Art von Entscheidungen auf die Zukunft von .NET auswirkt, hat der Kunde bei einem kürzlich durchgeführten Projekt den Entwicklungsaufwand für die Verlagerung einer Anwendung von .NET Framework auf Java für die UNIX-Bereitstellung bezahlt, da er dies nicht wollte Wetten Sie auf .NET Core und die verkrüppelte ODP.NET-Implementierung, während der JDBC-Treiber eine 1: 1-Feature-Parität mit dem .NET Framework ODP.NET-Treiber bietet.

Andere könnten auch andere alternative Stapel wählen.

Es gibt eine Menge Abhängigkeiten, die in einer durchschnittlichen Unternehmensanwendung nicht portiert werden können und können.

Dieses Problem tauchte oben auf HN auf. Ihr (@MSFT) wollt vielleicht auch dort nachsehen. Nur 1 Stunde und bereits 50+ Kommentare.

@ Davidfowl

Ich sehe nicht, wie dies .NET Standard tötet. .NET Standard ist viel größer als ASP.NET Core. Es geht darum, wiederverwendbare gemeinsam genutzte Bibliotheken (wie Microsoft.Extensions *) zu erstellen, die auf jeder unterstützenden .NET-Plattform funktionieren.

Ich verstehe nicht, was ASP.NET Core ist, wenn es sich nicht um eine wiederverwendbare gemeinsam genutzte Bibliothek handelt. Wenn der Trend für Bibliotheken, modern und schnell zu sein, darin besteht, die .NET Standard-Unterstützung einzustellen, ist dies eine schwierige Nachricht. Sollte Newtonsoft.Json nur zu .NET Core 3 wechseln, wenn es viel schneller laufen kann? Sollte Autofac?

Ich verstehe die Gründe dafür, bin mir aber nicht sicher, ob sich die Argumente und die Bewertung seit dem letzten Mal stark geändert haben! Ich denke wir werden abwarten und sehen ...

Ich werde meinen Anwendungsfall da draußen werfen und eine Perspektive geben, wie die Dinge in unserem Shop im Moment aussehen, wenn es darum geht:

AspNetCore war für unseren Stack in Bezug auf Self-Hosting (http.sys), eine Web-API und statische Webinhalte rund um verschiedene Dienste erstaunlich . Wir kamen aus Nancy, was solide war, aber auch viele Mängel aus unserer Sicht hatte, also sind wir vor ungefähr einem Jahr zu AspNetCore gewechselt. Heute führen wir jede unserer Codebasen auf 2.x aus. In vielen Fällen wäre es völlig in Ordnung, auf ein reines .NET Core-Ziel umzusteigen. Es gibt aber auch viele Dienste, die wir entwickelt haben, um AspNetCore zu nutzen, die auch auf Dingen wie System.DirectoryServices und System.Drawing basieren. Aus der Sicht dieser Dienste würden wir die Webhosting-Technologie ändern, bevor wir von .Net Framework abrücken. Leider würden wir aufgrund der Komplexität der gleichzeitigen Verwaltung von zwei verschiedenen Webhosting-Technologien und unserer Teamgröße AspNetCore wahrscheinlich auch von den übrigen Diensten insgesamt zugunsten einer Kompatibilität zwischen beiden Zielen streiken.

Um es kurz zu machen - Diese Entscheidung wird uns irgendwann in der Zukunft (wahrscheinlich wenn LTS für 2.x abläuft) vollständig von AspNetCore abbringen, für das, was ich derzeit nicht weiß. Wenn es darauf ankommt, werden wir wahrscheinlich unsere eigene interne Lösung schreiben, um AspNetCore zu ersetzen, da unsere Anwendungsfälle in Bezug auf die tatsächliche Anzahl der verwendeten AspNetCore-Funktionen recht eng sind (das heißt, die Funktionen, die wir nutzen) ein großer Mehrwert für uns heute).

Andere könnten auch andere alternative Stapel wählen.

Das ist fair, aber alternative Stacks haben die gleiche Support-Richtlinie. Java ist zu einem ähnlichen LTS-Modell übergegangen (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Es gibt eine Menge Abhängigkeiten, die in einer durchschnittlichen Unternehmensanwendung nicht portiert werden können und können.

@bencyoung

Es ist ein Framework, keine Bibliothek. Es besteht aus einer sehr großen Anzahl von Bibliotheken, die zusammen geliefert werden.

Ich verstehe nicht, was ASP.NET Core ist, wenn es sich nicht um eine wiederverwendbare gemeinsam genutzte Bibliothek handelt. Wenn der Trend für Bibliotheken, modern und schnell zu sein, darin besteht, die .NET Standard-Unterstützung einzustellen, ist dies eine schwierige Nachricht. Sollte Newtonsoft.Json nur zu .NET Core 3 wechseln, wenn es viel schneller laufen kann? Sollte Autofac?

Ich sehe nicht, wie schwierig es ist. Ich bin zu 97% sicher, dass diese Bibliotheken keine Frameworks entfernen, weil sich ihre Kunden beschweren würden. Die Messlatte für das Entfernen von Frameworks ist extrem hoch. Aus demselben Grund haben wir Microsoft.Extensions. * In .NET Standard 2.0 beibehalten. Ich bin damit einverstanden, dass es verschwommen wäre, wenn wir alles dorthin verlegen würden, aber das ist hier nicht der Fall.

In gewisser Weise ist dies nur eine Formalisierung dessen, was die Realität bereits in .NET Core ist. Wir liefern ASP.NET Core mit .NET Core. Unter .NET Core ist ASP.NET Core ein gemeinsam genutztes Framework, nicht nur eine Reihe von Paketen. Diese Pakete werden niemals getrennt vom Gesamtprodukt geliefert, daher sind die Vorteile der Referenzierung dieser einzelnen Pakete gering (die Paketliste ist übrigens auch klein).

@robkeimig

Es gibt jedoch auch viele Dienste, die wir entwickelt haben, um AspNetCore zu nutzen, die auch auf Dingen wie System.DirectoryServices und System.Drawing basieren

Diese sind im Windows Compact Pack unter .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack vorhanden.

Um es kurz zu machen - Diese Entscheidung wird uns irgendwann in der Zukunft (wahrscheinlich wenn LTS für 2.x abläuft) vollständig von AspNetCore abbringen, für das, was ich derzeit nicht weiß. Wenn es darauf ankommt, werden wir wahrscheinlich unsere eigene interne Lösung schreiben, um AspNetCore zu ersetzen, da unsere Anwendungsfälle in Bezug auf die tatsächliche Anzahl der verwendeten AspNetCore-Funktionen recht eng sind (das heißt, die Funktionen, die wir nutzen) ein großer Mehrwert für uns heute).

Wäre das auch der Fall, wenn die Unterstützung erweitert würde?

Außerdem müssten wir jetzt zuerst alle anderen nicht unterstützten Technologien (AppDomains, Remoting usw.) abschneiden, anstatt diese Arbeit parallel oder zu einem späteren Zeitpunkt ausführen zu können.

Warum können Sie nicht zuerst auf 2.1 migrieren?

Der größte Grund, warum ich zögern würde, ist, dass das 3-Jahres-Support-Limit bedeutet, dass Sie nicht bei ihnen bleiben können. Es ist ein Sprungbrett für die kurzfristige Migration, kein Punkt, an dem Sie eine stabile langfristige Plattform haben können. Dies bedeutet, dass Sie den ganzen Schmerz der Vorwärtsmigration in einem Klumpen auf sich nehmen müssen, da Sie nicht riskieren können, die Migration auf halbem Weg anzuhalten, um eine Reihe neuer Funktionen mit hoher Priorität zu erstellen, und dann versuchen müssen, die Migration nur zu beenden, um einen harten Block zu finden und müssen alle Ihre neuen Funktionen auf die alte Codebasis zurückportieren.

Der größte Grund, warum ich zögern würde, ist, dass das 3-Jahres-Support-Limit bedeutet, dass Sie nicht bei ihnen bleiben können.

Sicher, deshalb würden wir, wie @DamianEdwards erwähnt, erweiterten Support

Nur um zu zeigen, wie viel Konsequenz diese Entscheidung hat - was ist mit Blazor? Wird es aufhören, auf Netstandard zu basieren? Sollten wir das auch erwarten? Blazor wird als das nächste große Ding beworben. Was sonst von github.com/aspnet, das derzeit vom Netzstandard abhängt, wird es fallen lassen und bei der nächsten Hauptversion zum Netzkern wechseln? Was sind die Pläne für andere Dinge, in der MSFT-Kontrolle, aber außerhalb von Aspnet Repo, die das Schicksal von Aspnetcore teilen werden?

@ Davidfowl

Andere könnten auch andere alternative Stapel wählen.

Das ist fair, aber alternative Stacks haben die gleiche Support-Richtlinie. Java ist zu einem ähnlichen LTS-Modell übergegangen (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Das kleine Detail, das Sie übersehen, ist, dass Java und andere Stacks im Gegensatz zu .NET Framework und .NET Core weiterhin über Versionen kompatibel sind, ohne dass ein Standard erforderlich ist, der nur teilweise über Laufzeitimplementierungen implementiert wird.

Für das, was es wert ist, arbeite ich derzeit an der Bereitstellung der ersten ASP.Net-Kern-App meines Unternehmens. Wir haben sehr viel in .NET Framework investiert, daher war die Verwendung von ASP.Net Core auf .NET Framework im Gegensatz zu .NET Core der offensichtliche Ansatz.

Jetzt frage ich mich, ob ich uns später auf große Schmerzen einstellen werde.

Hier gibt es viele miteinander verbundene Bedenken. Sie sagen, dass der ASP.Net-Kern niemals nur unter .NET Framework ausgeführt werden sollte. Die Nachrichten von Microsoft über ASP.Net Core in der Vergangenheit haben dies nicht besonders deutlich gemacht.

Ähnlich viele .NET-Entwickler sind an die Idee gewöhnt, dass .NET Framework die Hauptimplementierung ist und dass die anderen im Allgemeinen Teilmengen sind, außer natürlich für umgebungsspezifische APIs. Dies hat sich mit .NET Core geändert, aber viele Menschen hatten im Allgemeinen den Eindruck, dass das "vollständige" .NET Framework am Ende alles unterstützen würde, was fast .NET Core tut (mit Ausnahme der Tools und der plattformübergreifenden Kompatibilität natürlich), aber Nur auf einer langsameren Zeitskala, warten Sie darauf, dass die Knicke behoben werden, bevor Sie sie einbeziehen.

In letzter Zeit gab es viele Hinweise darauf, dass einige wirklich wichtige Funktionen möglicherweise nie in .NET Framework gelangen. (zB dass die Kompatibilitätsrisiken des SpanTyp, der für die Implementierung in .NET Framework 4.8 als zu schwerwiegend angesehen wird, deutet darauf hin, dass er möglicherweise nie implementiert wird, da diese Risiken in 4.9 geringer sein sollten. Ähnliche Bedenken betreffen offenbar Standardschnittstellenmethoden.) Dies ist ein wichtiger Paradigmenwechsel, mit dem viele Entwickler nicht zufrieden sein werden!

Die Meldungen in diesem Thread deuten darauf hin, dass Microsoft beginnt, .NET Framework als Legacy-Funktion zu betrachten, die im Laufe der Zeit immer weniger Aufmerksamkeit für die Entwicklung erhält, bis wirklich nur noch Sicherheitskorrekturen durchgeführt werden.

Microsoft war in der Vergangenheit schrecklich darüber, klar zu machen, was sie aktiv entwickeln, was sie meist nur mit nur sporadischen neuen Funktionen warten und wofür sie wirklich nur Sicherheits- und Stabilitätskorrekturen bereitstellen wollen. Es hört sich für mich sehr danach an, dass .NET Framework jetzt nicht nur in dieser zweiten Kategorie liegt, sondern auch fast in der dritten Kategorie liegt.

Das ist wirklich nervig. .NET Core weist einige Probleme auf, die es für einige Unternehmensanwendungen nicht optimal machen. Sicherlich kann die Verwendung in Anwendungen mit kontinuierlicher Weiterentwicklung in Ordnung sein. Beispielsweise verfügen die meisten Unternehmen jedoch auch über einige Anwendungen, die bereitgestellt werden und nur alle paar Jahre einmal berührt werden. Das funktioniert schlecht mit .NET Core. Hier haben Unternehmen bei den meisten Releases mit kurzen Supportzyklen zu kämpfen. Unter Windows gibt es derzeit keinen Mechanismus, um die neuen Patch-Versionen automatisch zu installieren, um die Sicherheitsupdates usw. zu erhalten.

Unternehmen, die neue Projekte starten, fragen sich daher, was sie tun sollen. Das unternehmensfreundlichere .NET Framework zeigt ziemlich deutliche Anzeichen dafür, dass es veraltet ist, und daher wird etwas für Neuentwicklungen besser vermieden. Auf der anderen Seite existiert .NET Core, ist aber wesentlich weniger unternehmensfreundlich.

Das wurde also im Grunde genommen zu einem Scherz, aber ich hoffe, dass dies die Bedenken vieler Entwickler besser verdeutlicht.

@ Davidfowl

Es gibt jedoch auch viele Dienste, die wir entwickelt haben, um AspNetCore zu nutzen, die auch auf Dingen wie System.DirectoryServices und System.Drawing basieren

Diese sind im Windows Compact Pack unter .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack vorhanden.

Mir war nicht bekannt, dass das Kompatibilitätspaket diesen Anwendungsfall unterstützt. Im Idealfall möchten wir alles auf .NET Core umstellen, und dies scheint eine wirklich gute Antwort zu sein (die wir anfangs möglicherweise übersehen haben). Wir haben nicht vor, das Hosting unserer Dienste auf Linux / OSX zu verlagern, daher könnten diese Teile gut zu uns passen.

Wäre das auch der Fall, wenn die Unterstützung erweitert würde?

In Bezug auf die Unterstützung - Ich bin der Meinung, dass eine LTS von 2.x bis 2021 angemessen ist, wenn man alle anderen Einschränkungen berücksichtigt, die mit etwas so weitreichendem verbunden sind.

Nach meinem derzeitigen Verständnis werden wir wahrscheinlich ein Upgrade auf AspNetCore 3.x durchführen, sobald wir die Möglichkeit haben, .NET Framework-Projekte zu überprüfen und in .NET Core-Projekte zu konvertieren (mit der erforderlichen Verwendung des Kompatibilitätspakets).

Vielen Dank für Ihr Follow-up.

Ich habe 15 Jahre lang in .NET (meistens C #) in Hochdruckprojekten geschrieben. Ich habe so viele Jahre und Kunden Geld verschwendet, indem ich Zeit mit einem überentwickelten Framework verschwendet habe. Ich habe das Konzept von .NET Core geliebt. Für mich war es die Geschwindigkeit, mit der NodeJS-Projekte geschrieben wurden, aber in dem erstaunlichen .NET-Ökosystem (einschließlich des gesamten Fettes). Leider ist es bei diesem Versprechen gescheitert, es ist (trotz dieser neuen Ankündigung) immer noch viel zu kompliziert für einen blutigen Gebrauch. In den letzten 3 Jahren habe ich in NodeJS gebaut, sorry Leute, es ist einfach nicht vergleichbar. Machen Sie es einfacher und benutzerfreundlicher und Sie werden wieder die breite Entwicklergemeinde anziehen.

Bei Projekten mit harten, kompilierten binären .NET Framework-Abhängigkeiten (Herstellermaterial ohne Quellcode), die in ASP.NET Core 2.1-Apps ausgeführt werden können, die auf unter Windows bereitgestelltes .NET Framework abzielen, wird das Windows-Kompatibilitätspaket zum Projekt hinzugefügt, damit diese weiterarbeiten Core 3.0, wenn die vom Paket bereitgestellten Referenztypen für harte Abhängigkeiten?

Es gibt ein riesiges Ökosystem extrem ausgereifter kommerzieller Bibliotheken, die leider von System.Drawing, GDI und manchmal der Registry (!) Abhängig sind. Wenn diese erst jetzt mit 2.1 funktionieren und nur drei Jahre lang unterstützt werden, ist dies ein Problem, das die Einführung von Core in einigen Unternehmen stoppen könnte.

.NET Core schließt den Kreis, um den Startpunkt zu erreichen.

Ich würde einen anderen Ansatz vorschlagen: Lassen Sie .NET Framework die nützlichen Funktionen von .NET Core integrieren und entfernen Sie dann .NET Core insgesamt als experimentelle Sackgasse. So wird die Segmentierung gestoppt und die Technologie zum größeren Nutzen der Kunden gespeichert. Etwas kontrovers, aber produktbezogen viel vernünftiger.

@ Davidfowl

ASP.NET Core, das unter .NET Framework ausgeführt wird, war nie als dauerhafte Sache gedacht, sondern immer als Sprungbrett

Das stimmt einfach überhaupt nicht. Das Messaging in ASP.NET Core war schon immer so, dass es sowohl in .NET Core als auch in .NET Framework unterstützt wird. Selbst die frühesten Ankündigungen von .NET Core erwähnen beide Plattformen für ASP.NET Core (damals ASP.NET 5).

Das sehr bekannte Image, das .NET Standard zeigt, verfügt auch über ASP.NET Core, das sowohl Core als auch das gesamte Framework umfasst. In der offiziellen Dokumentation heißt es sogar: "Es gibt keine Pläne, die Unterstützung für das Targeting von .NET Framework in ASP.NET Core zu entfernen."

Also ja, es ist offensichtlich , dass diese Entscheidung jetzt geändert hat, aber zu sagen , dass es immer so , dass entweder nur eine Lüge, oder eine sehr schlechte Kommunikation erfolgt durch Microsoft über Jahre.

Es heißt sogar ASP.NET Core

Ach komm schon. Nach all dieser Zeit mussten Leute wie ich gegen Leute kämpfen, um .NET Core und ASP.NET Core zu trennen, weil sie nicht dasselbe sind. Verwenden Sie hier nicht einfach den gleichen Namen zu Ihrem Vorteil. Das ist einfach nicht fair. Die Namensänderung in "Core" bestand sicherlich nicht darin, sie explizit mit .NET Core zu verknüpfen. Außerdem verfügt EF Core über einen „Core“, der jedoch weiterhin auf Netstandard ausgeführt wird, sodass das Argument nicht funktioniert.

Hier kommt die erweiterte LTS-Unterstützung ins Spiel. Wenn die Anwendung auch nach diesen 6 Jahren nicht mehr auf .NET Core umgestellt werden kann […]

Woher kam das überhaupt jetzt? Beim letzten Mal lautete die Nachricht immer noch: "Wir untersuchen ein LTS-Angebot mit erweitertem Support." Ist das jetzt eine echte Sache und wir bekommen 6 Jahre?

@pjmlp

Das kleine Detail, das Sie übersehen, ist, dass Java und andere Stacks im Gegensatz zu .NET Framework und .NET Core weiterhin über Versionen kompatibel sind, ohne dass ein Standard erforderlich ist, der nur teilweise über Laufzeitimplementierungen implementiert wird.

Fairer Punkt, aber ich verstehe nicht, was das mit besserer Unterstützung zu tun hat. Es wurde behauptet, dass ein Wechsel zu Java aufgrund weniger verkrüppelter Bibliotheken (was ein Zeitpunktproblem darstellt) und Unternehmensunterstützung (längerer Supportzyklus) besser wäre.

@ KevinCathcart

Die Meldungen in diesem Thread deuten darauf hin, dass Microsoft beginnt, .NET Framework als Legacy-Funktion zu betrachten, die im Laufe der Zeit immer weniger Aufmerksamkeit für die Entwicklung erhält, bis wirklich nur noch Sicherheitskorrekturen durchgeführt werden.

Microsoft war in der Vergangenheit schrecklich darüber, klar zu machen, was sie aktiv entwickeln, was sie meist nur mit nur sporadischen neuen Funktionen warten und wofür sie wirklich nur Sicherheits- und Stabilitätskorrekturen bereitstellen wollen. Es hört sich für mich sehr danach an, dass .NET Framework jetzt nicht nur in dieser zweiten Kategorie liegt, sondern auch fast in der dritten Kategorie liegt.

Siehe https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

Bei Projekten mit harten, kompilierten binären .NET Framework-Abhängigkeiten (Herstellermaterial ohne Quellcode), die in ASP.NET Core 2.1-Apps ausgeführt werden können, die auf unter Windows bereitgestelltes .NET Framework abzielen, wird das Windows-Kompatibilitätspaket zum Projekt hinzugefügt, damit diese weiterarbeiten Core 3.0, wenn die vom Paket bereitgestellten Referenztypen für harte Abhängigkeiten?

Ja, es ist binär kompatibel.

Es gibt ein riesiges Ökosystem extrem ausgereifter kommerzieller Bibliotheken, die leider von System.Drawing, GDI und manchmal der Registry (!) Abhängig sind. Wenn diese erst jetzt mit 2.1 funktionieren und nur drei Jahre lang unterstützt werden, ist dies ein Problem, das die Einführung von Core in einigen Unternehmen stoppen könnte

Wie ich schon mehrmals in diesem Thread erwähnt habe. Wir haben die Möglichkeit hinzugefügt, Abhängigkeiten, die mit .NET Framework für .NET Core-Projekte kompiliert wurden, direkt zu referenzieren.

@poke Du hast Recht mit der Nachricht, es war überhaupt nicht klar, mein Fehler.

Woher kam das überhaupt jetzt? Beim letzten Mal lautete die Nachricht immer noch: "Wir untersuchen ein LTS-Angebot mit erweitertem Support." Ist das jetzt eine echte Sache und wir bekommen 6 Jahre?

Ich habe 6 erfunden, ich weiß nicht, wie erweitert der Support sein wird, wenn wir ihn anbieten.

.NET Core sollte immer .NET Framework ersetzen (ursprünglich war es .NET Framework 5), aber das Umschreiben war so ehrgeizig, dass es jetzt zur Unterstützung von Desktop-Apps verwendet wird.

Wow, gibt es hier jemals viele lustige Kommentare? Es scheint, als gäbe es eine Menge fehlgeleiteter Nerd-Wut, durchsetzt mit Leuten, die den Artikel nicht lesen.

bereithalten

@edandersen hast du ApiPort auf diesen externen DLLs ausgeführt? Es wird angezeigt, ob APIs verwendet werden, die in .NET Core nicht verfügbar sind. Wenn nur verfügbare APIs verwendet werden, sollte dies kein Problem sein. Andernfalls hilft die Kenntnis der fehlenden APIs bei der Diskussion und Priorisierung der Funktionen.
Das Windows-Kompatibilitätspaket bietet bereits Funktionen für system.drawing und die Registrierung. Haben Sie bereits versucht, diese Dinge auf .NET Core auszuführen? System.Drawing funktioniert sogar unter * nix mit monos libgdiplus. Dies ermöglicht es uns, ClosedXML auf Nicht-Windows-Systemen zu verwenden, um mit Excel-Dateien zu arbeiten.

Die größte .NET Framework-Abhängigkeit für "aktuelle" Anwendungen in unserem Unternehmen ist die WCF-Funktionalität.
Die .NET Core WCF-Clientbibliotheken werden verbessert. Ich habe nicht überprüft, wie gut sie mit einigen von uns genutzten Diensten funktionieren, aber in der Vergangenheit konnten wir nicht mit einigen Diensten sprechen. Die fehlende Funktionalität war jedoch bereits in der Problemliste enthalten. Einfache Dienste funktionieren dagegen gut!
Auf der anderen Seite gibt es keinen "Drop-in" -Ersatz für das Hosten von SOAP-Diensten in .NET Core. Dies würde die Migration einiger Anwendungen auf .NET Core blockieren (aber wie bereits erwähnt - dies ist nicht erforderlich).
Für eine neuere ASP.NET Core-Anwendung haben wir eine zusätzliche ASP.NET-Proxy-Webanwendung erstellt, die nur einen WCF-Dienst hostet und dann über HTTP / JSON an die ASP.NET Core-Anwendung weiterleitet. Nicht sehr hübsch und erhöht die Komplexität der Bereitstellung, ermöglicht jedoch einige Integrationspunkte.

Ich sage nicht, dass ich wirklich WCF-Hosting-Funktionen in .NET Core möchte, da ich Kopfschmerzen beim Konfigurieren bekomme. Eine Option zum Hosten von SOAP-Diensten und zum Generieren von WSDL wäre jedoch cool. Ich habe bereits einige OSS-Bibliotheken gesehen, die versucht haben, dies zu tun. Vielleicht reicht das aus.

@ Davidfowl

Fairer Punkt, aber ich verstehe nicht, was das mit besserer Unterstützung zu tun hat. Es wurde behauptet, dass ein Wechsel zu Java aufgrund weniger verkrüppelter Bibliotheken (was ein Zeitpunktproblem darstellt) und Unternehmensunterstützung (längerer Supportzyklus) besser wäre.

Der Punkt ist, dass Java LTS-Versionen zwar auch drei Jahre alt sind, die Kompatibilität zwischen allen wichtigen Implementierungen jedoch Gold ist, was ihr bereit seid, hier aus dem Fenster zu werfen.

Diese ganzen Fehltritte von .NET Framework, .NET Core, Xamarin und .NET Standard sehen zur Abwechslung aus wie die guten alten Zeiten von WinDev gegen DevTools, nur innerhalb von .NET-Teams.

Daher sind Kunden natürlich bereit, auf Plattformen umzusteigen, die nicht so aussehen, als würden interne Teams um Roadmap-Funktionen kämpfen.

Diese Entscheidungen schaffen kein Vertrauen.

Dies ist wirklich ein Fehler des .NET-Teams, insbesondere im Kontext des aktuellen Klimas!

Haben Sie sich für diejenigen, die Java erwähnen, tatsächlich angesehen, was dort in letzter Zeit vor sich geht? Zwischen ihrer absolut wahnsinnigen Klage gegen Google wegen der Verwendung in Android und ihren neuesten Lizenz-Spielereien scheint das Verhalten von Oracle durchweg das eines Unternehmens zu sein, das ein unerwünschtes Produkt töten will, anstatt eines, das es gedeihen lassen will!

Dies ist der perfekte Zeitpunkt für Microsoft, um davon mit einem leistungsstarken Marketing zu profitieren, das darauf hindeutet, dass genau das Gegenteil der Fall ist, und dass .NET der richtige Ort für vernünftige, stabile und sichere Entwicklungsoptionen ist. Stattdessen bekommen wir ... das. :enttäuscht:

@masonwheeler

Wir, die wir in beiden Umgebungen arbeiten, schätzen die Arbeit von Oracle
hat mit Java gemacht.

Es sind diejenigen, die Java selten in der Produktion verwenden, Oracle verachten, die bekommen
verloren in Hassargumenten gegen sie.

In Bezug auf Android unterstütze ich die Klage als Google voll und ganz
schaffte es, die Java-Plattform zu verzweigen und damit erfolgreich zu sein, wo Microsoft versagte
mit J ++. Freuen Sie sich immer noch auf den Tag, an dem jede zufällige JAR in Maven Central garantiert tatsächlich auf Android funktioniert.

Was .NET betrifft, fange ich an, die kontinuierlichen Neustarts von .NET satt zu bekommen
wie wir auf Microsoft-Plattformen abzielen sollen.

Das gesamte WinRT, UAP, UWP, .NET Native, das F #, XNA, Core 1.0 löscht, ist übrig geblieben
viele saure Trauben und diese jüngste Entscheidung macht die Dinge nicht besser
insgesamt.

.NET ist meine Lieblingsplattform, also verderben Sie es bitte nicht noch weiter.

@mythz

Jetzt verstehe ich, dass 2.1 als letzte von .NET Framework unterstützte LTS-Version bedeutet, dass es keinen Ort gibt, auf den ein Upgrade durchgeführt werden kann

Das heißt, es ist zu einer nicht unterstützten Plattform geworden. Jeder, der sich darauf befindet, muss es wie Lava behandeln und durcheinander bringen, bevor es sein nicht unterstütztes EOL-Ende erreicht.

Das ist einer der Punkte, die ich in der gesamten Diskussion nicht wirklich verstehe. Was erhalten Sie wirklich vom LTS-Support außer Sicherheitskorrekturen (die durch den erweiterten LTS-Support abgedeckt werden könnten)?

Bei der Mainstream-LTS-Unterstützung sind nur zwei Dinge zu erwarten:

• Sicherheitskorrekturen
• Kritische Bugfixes

Die meisten der ersteren (Sicherheitskorrekturen) werden über das Windows Update gepatcht (da Sie auf .NET Framework abzielen). Es sind also nur noch Sicherheits- und kritische Fehlerbehebungen in ASP.NET Core selbst vorhanden.

Nehmen wir an, es ist bereits bekannt, dass der Support 2018 endet. Ich würde nicht erwarten, dass jemand 2020 neue Projekte startet. Daher ist es (imho) unwahrscheinlich, dass Sie nach 2021 (oder 2026 oder wie lange der erweiterte Support gemeint ist) einen kritischen Show-Stopper-Fehler finden sein).

Das lässt nur Sicherheitslücken offen, was mit LTS vernünftig zu decken ist.

In früheren Antworten wurde TLS 1.4 usw. erwähnt. Diese werden in einem LTS sowieso nicht behandelt, da dies sowieso eine neue Funktion ist, die auch für Java gilt (Java 6 bietet nur TLS 1.0-Unterstützung - TLS 1.1, wenn Sie in der Liste mitzählen nicht öffentliche Updates, die nur den Abonnenten des erweiterten Supports von Oracle zur Verfügung stehen).

• Jeder, der darüber nachgedacht hat, es als Staging-Plattform für die Umstellung auf .NET Core zu verwenden, ist zu einer weniger praktikablen Option geworden, da er dem Risiko ausgesetzt ist, auf einer nicht unterstützten Plattform gestrandet zu sein, wenn die Migration länger als erwartet dauert, oder wenn eine der Abhängigkeiten auf Straßensperren stößt Sie verlassen sich darauf, dass sie nicht auf .NET Core ausgeführt werden können.
  Aber welche APIs fehlen, die Sie jetzt mit ASP.NET Core unter .NET Framework verwenden können, aber nicht mit ASP.NET Core unter .NET Framework + -Kompatibilitätspaketen?

Ich denke, dies ist der kritischere Punkt, um diese zu identifizieren und entweder die fehlenden APIs mit zukünftigen Kompatibilitätspaketen zu versenden oder sie zu .NET Core hinzuzufügen, sodass es möglich ist, auf die .NET Framework-Bibliotheken zu verweisen, selbst wenn auf .NET Core abgezielt wird.

Seit .NET Core können Sie auf jede .NET Framework-Bibliothek in einem .NET Core-Projekt verweisen (und diese verwenden), sofern nur APIs verwendet werden, die in .NET Standard oder .NET Core verfügbar sind .

Dies erfordert nicht, dass der Bibliotheksautor seine Bibliotheken auf netstandard / netcoreapp aktualisiert.

Vielleicht würde es helfen, wenn Microsoft die NuGet-Webseite / Bibliothek um eine Funktion / einen Link neben jedem Nuget-Paket auf nuget.org erweitern würde, die einen Bericht anzeigt, wenn diese Bibliothek inkompatible APIs verwendet, die in bestimmten Versionen von .NET Core nicht verfügbar sind?

Zum Beispiel

'Company.Example.MyLib` würde zeigen

• .NET Core 2.1: Teilunterstützung (detaillierter Bericht) - wo der detaillierte Bericht Apis zeigen würde, dass dies funktioniert und was nicht
• .NET Core 3.0:; voll unterstützt

Dies sollte durch Ausführen des .NET Portability Analyzer möglich sein. Ein Bonus wäre, wenn eine Liste öffentlicher APIs hinzugefügt wird, die sicher aufgerufen werden können (indem der IL-Code analysiert wird und festgestellt wird, welche anderen APIs aufgerufen werden, um sicherzustellen, dass sie sicher sind oder nicht).

Dies würde es Entwicklern zumindest erleichtern, festzustellen, ob eine bestimmte Bibliothek, die sie für ihr Projekt benötigen, unter .NET Core ausgeführt werden kann oder nicht, selbst wenn sie nicht explizit aufgerufen wird.

Im Moment ist es ein bisschen schwierig herauszufinden, ob die APIs unterstützt werden oder nicht. Sie benötigen die Bibliothek und führen den Analysator lokal darauf aus. Viele Entwickler wissen möglicherweise nicht, dass sie einige der Bibliotheken verwenden können, die Netstandard offiziell nicht unterstützen.

@davidfowl @terrajobst Wäre das eine mögliche Ergänzung zu NuGet? Um die Auffindbarkeit von -NET Core-kompatiblen .NET Framework-Bibliotheken einfacher und schneller zu machen?

• Jeder, der gezwungen ist, die .NET Framework-Server der vorhandenen verwalteten Infrastruktur seines Unternehmens zu verwenden, kann nicht an der Verwendung des neuen Entwicklungsmodells und Ökosystems teilnehmen und muss feststellen, dass die vorhandenen klassischen ASP.NET-Kenntnisse / -Fähigkeiten von Tag zu Tag weniger wert sind.

Das ist kaum ein Argument für oder gegen die Unterstützung von .NET Framework oder nicht. Personen, die an älteren Abhängigkeiten festhalten und nicht auf .NET Core (mit Kompatibilitätspaket oder mit .NET Framework-Bibliotheken) migrieren können, können dies auch nicht tun. Wie würde das etwas ändern?

Teile der monolithischen Anwendungen können zwar aufgeteilt und Teile der Legacy-Anwendung schrittweise in eine neue verschoben werden, aber das ist eine andere Geschichte.

• Kein Unternehmen möchte zu einer ungeplanten Migration gezwungen werden, da sich die Richtlinien, auf die es sich bei der Budget-, Planungs- und Investitionsentscheidung verlassen hat, geändert haben.

Wenn die Vorteile die Investitionen übersteigen, warum nicht? dh wenn es einzigartige Funktionen gibt, die Ihnen einen großen Gegenwert oder eine enorme Leistungssteigerung bieten.

Wenn nicht, bleiben Sie auf dem alten System. Die Softwareentwicklung war schon immer so. Es gibt immer noch Unternehmen, die in Fortune und Cobol entwickelte Software ausführen.

Es gibt viele Leute, die nicht zu .NET Core wechseln können oder wollen. Sie möchten, dass es den gleichen Grad an Unterstützung wie klassisches ASP.NET hat (was in den aktuellen Nachrichten auf unbestimmte Zeit vorgeschlagen wird).

Fehlende APIs sind nicht der einzige Grund, der die Migration verhindert. Sie können sich beispielsweise auf eine Abhängigkeit stützen, in der das vom Entwicklerteam erstellte nicht mehr vorhanden ist. Es handelt sich um eine kritische Komponente, die nicht geändert werden kann und nicht sicher umgestaltet werden kann (z keine Tests), wird mit anderen Nur-.NET-FX-Systemen geteilt, von einer anderen Abteilung verwaltet, die kein Budget, keine Änderungskapazität oder aufgrund externer Faktoren wie der von ihrem Unternehmen verwalteten Infrastruktur nur die Ausführung auf .NET Framework-Servern unterstützt.

Ja aber welche Abhängigkeiten? Konkrete Beispiele wären erforderlich, um festzustellen, welche APIs diese externen Abhängigkeiten verwenden. Diese API kann zu .NET Core 3.0 oder einer zukünftigen Version von .NET Core hinzugefügt werden.

Dies ermöglicht die Verwendung dieser .NET Framework-Bibliothek in .NET Core-Projekten. Das einzige Problem besteht darin, dass die .NET Framework-Bibliotheken APIs verwenden, die in .NET Standard oder .NET Core nicht verfügbar sind. Um dieses Feedback zu beheben, ist es jedoch erforderlich, die Bibliotheken zu identifizieren.

@pjmlp

@ Davidfowl

Andere könnten auch andere alternative Stapel wählen.

Das ist fair, aber alternative Stacks haben die gleiche Support-Richtlinie. Java ist zu einem ähnlichen LTS-Modell übergegangen (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Das kleine Detail, das Sie übersehen, ist, dass Java und andere Stacks im Gegensatz zu .NET Framework und .NET Core weiterhin über Versionen kompatibel sind, ohne dass ein Standard erforderlich ist, der nur teilweise über Laufzeitimplementierungen implementiert wird.

Dies gilt auch nicht für die späteren Java-Editionen. Java 9 hat den ersten Schritt zur Modularisierung der Laufzeit hinzugefügt, was eine wichtige Änderung darstellt . In Version 9 wurde dies standardmäßig deaktiviert. In zukünftigen Versionen wird das Flag jedoch standardmäßig aktiviert (oder kann nicht deaktiviert werden). Dadurch werden wichtige Änderungen an älteren Anwendungen vorgenommen.

Zum Beispiel für die vielen Bibliotheken, die interne APIs durch Reflexion verwenden, kann und wird Magie mit dieser Änderung brechen. Und viele dieser Bibliotheken werden, wie in der .NET-Welt, nicht mehr gewartet, sodass Updates nicht zu erwarten sind.

@ TsengSR

Trotz der in Java 9 eingeführten grundlegenden Änderungen funktionieren 100% aller relevanten Java-Frameworks in Java 9, 10 und 11, was in .NET Framework, UWP und Core definitiv nicht der Fall ist.

Stellen Sie sich vor, es gibt sogar zwei offizielle plattformübergreifende GUI-Frameworks, während wir noch keine offizielle Roadmap für Core erhalten!

@pjmlp

@ TsengSR

Trotz der in Java 9 eingeführten grundlegenden Änderungen funktionieren 100% aller relevanten Java-Frameworks in Java 9, 10 und 11, was in .NET Framework, UWP und Core definitiv nicht der Fall ist.

Stellen Sie sich vor, es gibt sogar zwei offizielle plattformübergreifende GUI-Frameworks, während wir noch keine offizielle Roadmap für Core erhalten!

Entschuldigung, das ist völlig unsinnig.

Die internen Module von Java 9, die verhindern, dass in diese Module reflektiert wird, es sei denn, --add-opens wird aufgerufen (und es sollte immer eine temporäre Lösung sein, damit Benutzer ihre Legacy-Anwendung weiterhin ausführen und einige Versionen später entfernen können).

Falls Sie das Drama und den Shitstrom verpasst haben, als Java 9 veröffentlicht werden sollte, war dies die Antwort darauf:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

Um das gesamte Ökosystem bei der Migration auf die modulare Java-Plattform zu unterstützen
entspannteres Tempo Ich schlage hiermit vor, illegalen reflektierenden Zugang zuzulassen
Standardmäßig aus Code im Klassenpfad in JDK 9 und nicht in Codeeine zukünftige Version.

Ansonsten war Java EE 9 veraltet JAX-WS war veraltet und soll in Java EE 11 entfernt werden. Dies könnte grob als das Äquivalent von WCF angesehen werden. Alle anwendbaren Anwendungen können nicht auf eine neuere Version portiert werden, ohne sie durch etwas anderes zu ersetzen, bei dem es sich um einen Migrationsprozess handelt. Nicht mehr oder weniger anders als die Migration von ASP.NET Core unter .NET Framework zu ASP.NET Core unter .NET Core (oder von ASP.NET nach ASP.NET Core @ .NET Core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Höhere Plattformintegrität - Vor Java 9 konnten viele Klassen auf der Plattform verwendet werden, die nicht für die Klassen einer App vorgesehen waren. Mit einer starken Kapselung sind diese internen APIs wirklich gekapselt und vor Apps verborgen, die die Plattform verwenden. Dies kann die Migration von Legacy-Code auf modularisiertes Java 9 problematisch machen, wenn Ihr Code von internen APIs abhängt.

Jede Anwendung, die diese internen APIs verwendet hat (einschließlich aller im Namespace sun.* die einige der alten Bibliotheken verwendet haben - oder die verwendet wurden, als Java 9 veröffentlicht werden sollte) oder eine Bibliothek eines Drittanbieters verwendet, die davon abhängt Bei diesen APIs oder einer anderen Bibliothek kann diese grundlegende Änderung auftreten. Das Problem dabei ist, wie in .NET Framework und .NET Core, dass Sie nicht allein aus der Bibliothek sehen, welche APIs aufgerufen werden oder nicht.

@TsengSR

Die internen Module von Java 9, die verhindern, dass diese Module reflektiert werden, es sei denn, --add-opens wird aufgerufen (und iirc sollte immer eine temporäre Lösung sein, damit Benutzer ihre Legacy-Anwendung weiterhin ausführen und einige Versionen später entfernen können).

Oder Sie können den Klassenpfadmodus verwenden und das Durcheinander der Module überspringen. Dieser Modus wird auf absehbare Zeit bestehen bleiben. Und wenn Sie in Module einsteigen, können Sie Abhängigkeiten explizit in den Paketen anderer Module deklarieren.

Ansonsten war Java EE 9 veraltet JAX-WS war veraltet und soll in Java EE 11 entfernt werden. Dies könnte grob als das Äquivalent von WCF angesehen werden.

J2EE wurde in Java 11, das bereits verfügbar ist, veraltet und entfernt. J2EE definiert jedoch nur die Schnittstellen, nicht die Implementierung. Um J2EE weiterhin zu verwenden, müssen Sie lediglich die Abhängigkeiten wechseln. Alle Implementierungen waren ohnehin getrennt und funktionieren in Java 11 einwandfrei.

Jede Anwendung, die diese internen APIs verwendet hat (einschließlich aller in sun. * Namespace, die einige der alten Bibliotheken verwendet haben - oder verwendet haben, als Java 9 veröffentlicht werden sollte) oder eine Bibliothek eines Drittanbieters verwendet, die von diesen APIs abhängt oder eine andere Bibliothek kann dieser Änderung unterliegen.

Welches war schon immer der Fall. Sie waren undokumentierte APIs. Niemand hätte sie benutzen dürfen und sie hätten jederzeit geändert oder entfernt werden können. Viele der häufig (ab) verwendeten internen APIs wurden so belassen, dass vorhandene Programme nicht beschädigt werden, sodass sie in Zukunft auf geeignete APIs migriert werden können.

Einige APIs sind veraltet, aber es handelt sich um bestimmte APIs und nicht um die Gesamtheit des JRE- oder Java-Ökosystems. Der Aufwand für den Wechsel von diesen APIs zu neueren, offiziellen und dokumentierten APIs ist im Allgemeinen minimal.

Und Java war schon immer eher bereit, die Abwärtskompatibilität zu brechen als .NET. In Java ist es jetzt beispielsweise illegal, einen Typ mit dem Namen var zu deklarieren, da dieser für lokale Inferenzen reserviert ist. In Java ist es illegal, eine Variable _ zu benennen, da diese für die Verwendung als Discard / Wildcard reserviert ist. C # traf in beiden Fällen genau das Gegenteil, um die Abwärtskompatibilität zu gewährleisten.

Versteh mich nicht falsch, Java ist ein eigenes Durcheinander. Zwischen den Modulen, dem Ende der Unterstützung für Java 8 und der Tatsache, dass Oracle mit der JRE-Lizenzierung gierig wird, gibt es für Microsoft eine enorme Chance, Menschen zu konvertieren. Dies ist jedoch sehr unwahrscheinlich, wenn Microsoft gemischte Nachrichten über die zukünftige Unterstützung und Weiterentwicklung seiner Plattformen veröffentlicht.

@TsengSR

Das ist einer der Punkte, die ich in der gesamten Diskussion nicht wirklich verstehe. Was erhalten Sie wirklich vom LTS-Support außer Sicherheitskorrekturen (die durch den erweiterten LTS-Support abgedeckt werden könnten)?

Es gibt eine tickende Uhr auf diesem LTS, die mit einem Nirgendwo endet Upgrade durchgeführt werden kann. Dies ist der entscheidende Punkt, der beschönigt wird, wenn Java LTS im Vergleich herumgeworfen wird. Mit Java und .NET Framework hatten Sie immer ein hohes Maß an Vertrauen, dass Sie vorhandene Systeme mit minimalem Aufwand aktualisieren können, da der Schwerpunkt auf der Abwärtskompatibilität liegt. Da es keinen Upgrade-Pfad mehr gibt, müssen vorhandene Systeme auf eine neue Laufzeit migrieren oder auf einer nicht unterstützten Plattform weiterlaufen. Aus verschiedenen Gründen wird es Systeme geben, auf denen eine Migration auf .NET Core nicht möglich ist und deren Zukunft (mit dieser Entscheidung) die Ausführung ihrer kritischen Geschäftsfunktionen auf einer nicht unterstützten Plattform ermöglicht.

Sie sind sich nicht sicher, welche Metapher für diese Entscheidung in Java am nächsten kommt, und zwingen möglicherweise vorhandene Systeme dazu, auf GraalVM zu migrieren. Viele Dinge werden funktionieren. Einige werden es nicht tun. Je größer das System ist, desto weniger Vertrauen besteht in der Vorhersage der Kompatibilität Probleme, bis eine Migration physisch versucht wird.

Ich würde zustimmen, dass viel getan wurde, um Migrationen zu .NET Core zu ermöglichen, aber es wird immer noch eine Reihe externer Faktoren (einschließlich außerhalb der MS-Kontrolle) geben, die Migrationen verhindern, und diese Entscheidung wird nur getroffen Migrationen weniger wahrscheinlich als vor dieser Ankündigung ASP.Core / FX war ein beliebter Migrationspfad, aber es wird nicht mehr ratsam sein, eine allgemeine Migrationsstrategie zu empfehlen, die die Migration auf eine zukünftige nicht unterstützte Plattform umfasst, wodurch viele Migrationen verhindert werden Dies führt dazu, dass mehr vorhandene Systeme / Entwickler auf stagnierendem klassischem ASP.NET verbleiben.

Die meisten der ersteren (Sicherheitskorrekturen) werden über das Windows Update gepatcht (da Sie auf .NET Framework abzielen). Es sind also nur noch Sicherheits- und kritische Fehlerbehebungen in ASP.NET Core selbst vorhanden.

Unternehmen möchten ihr Unternehmen nicht auf einer teilweise unterstützten Plattform aufbauen, in der Hoffnung, dass zukünftige Fehler oder Sicherheitsprobleme nur in den Bibliotheken auftreten, die für den Support vorgesehen sind. Es wäre ein langer Weg, wenn ASP.Core / FX von der gleichen Unterstützungsstufe wie der Rest von .NET Framework abgedeckt würde, bei der zukünftige Sicherheitslücken behoben werden.

Derzeit können nur MS aktualisierte ASP.Core NuGet-Pakete patchen und freigeben, wobei der Verbindungsbaum der Abhängigkeiten OSS hier nicht viel hilft, es sei denn, 2.1 PRs, die sie erhalten (nach LTS), werden überprüft, akzeptiert und veröffentlicht.

Am Ende, nachdem alle Details besprochen wurden, ist die letzte Frage, die noch wichtig ist:

Können wir unsere vorhandenen Systeme weiterhin auf ASP.Core / FX ausführen?

Technisch wird es möglich sein, aber ohne die Zusicherung, dass zukünftige kritische Fehler / Sicherheitslücken behoben werden, ist die Empfehlung NEIN geworden, sodass das betroffene externe Ökosystem den Schmerz dieser Entscheidung absorbiert.

Wenn ASP.NET Core nur .NET Core sein soll, wie sollten wir uns über die gesamte .NET Standard-Sache fühlen?

Wenn Microsoft selbst aus (zweifellos gültigen) Gründen nicht darauf setzt, warum sollten wir dann?

Wird es erstklassige, hochmoderne .NET Core-Bibliotheken und „einfachere“, weniger fortgeschrittene .NET Standard-Bibliotheken geben?

Dies scheint das Laufwerk zu töten, um alle Nicht-.NET-Core-Plattformen zu verbessern.

Hoffentlich kann mir jemand zeigen, dass ich falsch liege, und meine Bedenken zerstreuen.

Hallo,
Ich sehe den Wert des Vorantreibens und ich liebe es, aber ich sehe 3 Hauptprobleme bei dieser Entscheidung:
1) netstandard wird ein Bürger zweiter Klasse sein, wenn niemand in Microsoft etwas Schwieriges damit baut. Wenn ihr kein Hundefutter habt, wie könnt ihr andere Entwickler bitten, es zu tun? Heutzutage müssen Bibliotheksautoren wirklich hart arbeiten, die Unterstützung wird sich nicht verbessern, wenn interne Benutzer den Standard nicht verwenden.
2) Es ist sinnvoll, den Aspnet Core in anderen Laufzeiten auszuführen.
3) Software, die in alten Laufzeiten ausgeführt wird (mit einer Abhängigkeit, die niemals berührt wird), hat einen Wert, der nicht leichtfertig verworfen werden sollte.

Dann gibt es Kommunikation: Ich denke, jeder würde nur eine .net-Laufzeit lieben, die überall läuft, aber das ist auf absehbare Zeit eine Utopie, und Netstandard wurde als Ersatz erstellt. Aus meiner Sicht ist jedes Projekt, das nicht auf Netstandard, sondern auf eine Plattform abzielt, ein Schritt, der nicht in Richtung dieser Vision geht.
Es ist klar, dass sich das .net-Framework im Wartungsmodus befindet, .netcore seinen Platz einnimmt (wobei ein toter Körper zurückbleibt) und Mono auf Geräten ausgeführt wird. Aot Story und CoreRT versuchen nicht, voranzukommen.

Mit Netcore 3.0 erledigen Sie zwei Dinge gleichzeitig: Unterstützung von Desktop-Workloads und "Aufforderung an die Benutzer, sofort zu springen, um relevant zu bleiben". Ich denke, dies erfordert einen Vertrauenssprung von Entwicklern und ist viel zu optimistisch, da jeder weiß, dass viele Projekte aufgrund fehlender Abhängigkeiten nicht migriert werden, die wahrscheinlich in zukünftigen 3.1 / 3.2-Versionen in 1-2 Jahren hinzugefügt werden ( sehr nahe an den 3 LTS-Jahren von 2.1). In der Zwischenzeit werden Entwickler, die relevant sein möchten, aufgrund von Abhängigkeiten, auf die sie keinen Einfluss haben, für die Verwendung der 3,0-Bits blockiert.

Wird es möglich sein, diese Entscheidung zu verschieben, nachdem ppl sie getestet hat und die tatsächlichen Auswirkungen erkannt hat?
Ist es möglich, Aspnet Core sowohl nach Netstandard als auch nach Netcoreapp kompilieren zu lassen, wie Sie es Bibliotheksautoren vorschreiben? Es ist in Ordnung, wenn eine verminderte Leistung auf dem .net-Framework ausgeführt wird

Roslyn läuft jetzt unter .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

Das zählt sicherlich als etwas Schwieriges!

@ Davidfowl

Ich glaube, dies wird die Optionen für die zukünftige Entwicklung von .Net Framework-Systemen, die aus verschiedenen Gründen nicht migriert werden können, stark einschränken, da die Community ihre Bemühungen auf ASP.Net Core verlagert.

Zum Beispiel ist Identity Server bereits zu ASP.Net Core gewechselt , und in dem kürzlich veröffentlichten Beitrag zur

Ich weiß, dass die LTS-Unterstützung für ASP.NET Core bereits auf 3 Jahre festgelegt wurde, aber für die lokale Bereitstellung ist ein längerer Lebenszyklus erforderlich, da wir unseren Kunden Support in dieser Richtung (4 Jahre) bieten müssen.
Während dieser Zeit müssen wir in der Lage sein, Patches mit Sicherheitskorrekturen ohne größere Anwendungsänderungen zu veröffentlichen. Dies dient dazu, mit den Änderungskontrollprozessen unserer Kunden in Einklang zu bleiben, die umfangreiche Benutzerakzeptanztests für größere Änderungen erfordern würden, und damit wir keine größeren Änderungen vornehmen müssen, z. B. die Migration auf eine neuere Version bei Releases, die sich im Wartungsmodus befinden .

Gibt es eine Chance, dass sich die LTS-Richtlinie ändert? So etwas wie Ubuntus Strategie einer LTS-Version alle 2 Jahre mit 5 Jahren Support - obwohl ich um 6 bitten würde, damit die aktuelle Version mehr als 3 Jahre Support bietet, während die Arbeit zur Migration auf die neue Version durchgeführt wird.

Ich verstehe, dass erweiterter Support erwähnt wurde, aber ich gehe davon aus, dass dies etwas ist, das jeder unserer Kunden kaufen müsste. Ich glaube nicht, dass dies schmackhaft wäre, wenn seine Erstinstallation (nach Entwicklung, Verkaufsprozess, UAT usw.) dies bestenfalls tun würde 2 Jahre Unterstützung.

Auch neugierig, wie man .netstandard Bibliothek in .netcore 3.0 mal behandelt.
Der Slogan von .netstandard lautet "Eine Bibliothek, die alle regiert".
Vorher sieht es so aus, als ob es alles bedeutet.
Danach sieht es so aus, als würde es ein wenig bedeuten.

Nur um zu zeigen, wie viel Konsequenz diese Entscheidung hat - was ist mit Blazor? Wird es aufhören, auf Netstandard zu basieren? Sollten wir das auch erwarten?

Kann jemand das klarstellen?

Ist die Empfehlung für Bibliotheken wie Newtonsoft.Json (die von einer hohen Leistung profitieren können), auf .NET Core anstatt auf .NET Standard zu wechseln? Ich sehe keinen großen Unterschied zwischen dieser Art von Bibliothek und ASP.NET Core. Wir binden REST-Services in größere Anwendungen ein, von denen einige problemlos auf .NET Core umgestellt werden können und andere nicht.

Nach meinem Verständnis ist die Empfehlung für Bibliotheken, sowohl auf .NET Core 3 als auch auf .NET Standard 2.x abzuzielen, wenn Sie die Vorteile der neuen APIs nutzen möchten, aber keine Zielgruppen verlieren möchten.

Nach meinem Verständnis ist die Empfehlung für Bibliotheken, sowohl auf .NET Core 3 als auch auf .NET Standard 2.x abzuzielen, wenn Sie die Vorteile der neuen APIs nutzen möchten, aber keine Zielgruppen verlieren möchten.

Ich dachte, die Straße vor uns sei überall netzstandardisiert , und derzeit befinden wir uns gerade in einem Übergang. Aber mit einem solchen Schritt werden (oder müssen) andere folgen und wir kehren zum Multi-Targeting zurück.

.NET Framework und .NET Core spielen dieselbe Rolle, daher wird davon ausgegangen, dass ASP.NET Core eines Tages nicht mehr auf .NET Framework ausgeführt wird, sei es jetzt oder später.

Ich sehe jedoch ein großes Problem darin, nicht auf .NET Standard X laufen. Um ehrlich zu sein, brauche ich keinen asp.net-Kern, um auf Xamarin oder Unity zu laufen, aber es ist schön zu sagen, dass dies möglich ist - es ist nur ein weiterer Satz von Bibliotheken, die auf der .NET-Plattform ausgeführt werden. Durch das Abbrechen erhalten wir eine engere Integration zwischen .NET Core und ASP.NET Core, und ich befürchte, dass wir mit .NET Core 4.5 Microsoft.AspNetCore und @davidfowl ab DNX 2.0 verurteilen.

Auf der anderen Seite ist .NET Standard definitiv kein Ort zum Experimentieren und es ist schwierig, die Dinge richtig einzubinden. Können wir also vielleicht einen Kompromiss eingehen? Wäre es möglich, dass ASP.NET Core derzeit nur auf .NET Core abzielt, LTS-Versionen jedoch auf .NET Standard? Wenn eine API den Weg zu .NET Standard nicht findet, lohnt es sich wirklich, sie zu verwenden?

Wir könnten dies auch so betrachten, wie Sie es wahrscheinlich beabsichtigen:

• .NET Core ist für Konsolen- / Web- / Drittanbieter-Desktops (Standard + webspezifische API)
• Unity ist für Spiele (Standard + spielspezifische API)
• Xamarin ist für Geräte / Desktop (Standard + Gerät / Desktop-spezifische API)

Aber wer treibt .NET Standard voran? Wie Sie bereits gesagt haben, sind die Ressourcen begrenzt, so dass ich befürchte, ohne dass tatsächlich etwas unternommen werden muss (was in meinem Vorschlag auf das Kernteam von .net core / asp.net fallen würde, wenn Änderungen zur Veröffentlichung von LTS erforderlich wären). NET Standard wird schnell abgestanden.

Für diejenigen, die nicht aufpassen, scheint .NET Standard 2.1 die Unterstützung für .NET Framework eingestellt zu haben.

Da viele der API-Ergänzungen in .NET Standard 2.1 Laufzeitänderungen erfordern, um sinnvoll zu sein, bleibt .NET Framework 4.8 in .NET Standard 2.0 erhalten, anstatt .NET Standard 2.1 zu implementieren. .NET Core 3.0 sowie kommende Versionen von Xamarin, Mono und Unity werden aktualisiert, um .NET Standard 2.1 zu implementieren.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

So sehr es mich auch schmerzt, wenn ich sehe, dass das .NET Framework Silverlight-ed wird, ist es für mich in Bezug auf ASP.NET Core wichtig, dass es auf .NET Standard abzielt.

Als eine der wahrscheinlich größten Referenzanwendungen im Core / Standard-Ökosystem glaube ich, dass ASP.NET Core die Verantwortung hat, ein Champion von .Net Standard und all den guten Dingen zu sein, für die es steht.

Ich halte es für sinnvoll, dass ASP.NET Core Änderungen am Standard anfordert, die dann in .NET Core implementiert werden.

Genauso wie Span usw. in .Net Framework über ein Nuget-Paket verfügbar ist, halte ich es für vernünftig, dass diese Abhängigkeit einbezogen werden sollte, wenn ASP.NET Core von etwas abhängig sein muss / möchte, das noch nicht im .Net-Standard enthalten ist in über ein Nuget-Paket.

Schließlich hoffe ich (gegen alle gegenteiligen Beweise), dass es ein .Net Framework 5.0 geben wird, das auf .Net Standard 3.0+ abzielt und eine Side-by-Side-Installation mit 4.x sein wird.

Schließlich hoffe ich (gegen alle gegenteiligen Beweise), dass es ein .Net Framework 5.0 geben wird, das auf .Net Standard 3.0+ abzielt und eine Side-by-Side-Installation mit 4.x sein wird.

Ja genau. Das sage ich schon seit Jahren: Die CLR 2.0-Architektur hat uns schon lange gute Dienste geleistet, aber es wird langsam langweilig, und es ist Zeit für ein grundlegendes Upgrade, wie es Generics war. Es mag etwas schmerzhaft sein, die notwendigen Änderungen vorzunehmen, aber sie sind notwendig; Ein Update mit neuen, leistungsstärkeren Funktionen ist genauso erforderlich wie Generika. Wenn Sie es aufschieben, wird dieser Schmerz nur noch schlimmer, nicht weniger, wenn er schließlich auftritt.

Genau das ist .NET Core, und dieser Thread ist der vorübergehende Schmerz, der auftritt.

@terrajobst sagte, dass es nicht passieren wird: siehe Thread: https://twitter.com/terrajobst/status/1059525279431815168?s=19

@ Gulbanana
Ja, außer zwei Dingen.

1. Core ist kein Upgrade von Framework. Es ist ein paralleles Konzept. Es gibt so viele wirklich grundlegende Dinge, die es nicht kann, von denen viele, wie AppDomains, wahrscheinlich nie passieren werden. Um Himmels willen, wir haben noch nicht einmal ein funktionierendes Reflection.Emit ! Wenn man bedenkt, wie häufig dies in Compilern und Tools zur Codegenerierung vorkommt, würde man meinen, dass dies buchstäblich eine der ersten Prioritäten gewesen wäre, und doch sind wir 4 Jahre später hier und es funktioniert nicht! Dies macht es sehr schwierig, den Begriff "Core als Ersatz / Upgrade für .Net Framework" ernst zu nehmen.
2. Core aktualisiert die Laufzeit im CLR 2.0-Stil nicht radikal. Drüben bei "Welche Sprachvorschläge würden von CLR-Änderungen profitieren?" Wir haben eine großartige Liste aus der Community der fehlenden Funktionen, die die Leute für wichtig halten, die die CLR nicht unterstützen kann (oder zumindest nicht ohne massive, hässliche Kludges unterstützen kann, um die Einschränkungen der CLR zu umgehen), im Allgemeinen aufgrund fehlender Funktionen im Typensystem. Wie viele der Vorschläge zu diesem Thema werden vom Kernteam überhaupt ernst genommen? Und wie viele von ihnen wurden sofort entlassen, weil die Leute, die das Projekt leiten, die Laufzeit nicht aktualisieren müssen? Wir bekommen DIMs und ... noch etwas? Irgendwas überhaupt?

Nein, .NET Core ist kein aktualisiertes .NET Framework, das die dringend benötigten CLR-Updates vornimmt, da es sich nicht um ein aktualisiertes .NET Framework handelt und das Projektteam alles daran setzt, die CLR nach Möglichkeit nicht zu aktualisieren. Es ist buchstäblich das genaue Gegenteil davon.

Um Himmels willen, wir haben noch nicht einmal eine funktionierende Reflexion. Wenn man bedenkt, wie häufig dies in Compilern und Tools zur Codegenerierung vorkommt, würde man meinen, dass dies buchstäblich eine der ersten Prioritäten gewesen wäre, und doch sind wir 4 Jahre später hier und es funktioniert nicht! Dies macht es sehr schwierig, den Begriff "Core als Ersatz / Upgrade für .Net Framework" ernst zu nehmen.

Es wäre toll zu verstehen, was nicht funktioniert. ASP.NET Core und EF verwenden an einigen Stellen Reflexionsemissionen, sodass mir die großen Lücken nicht bewusst sind. Können Sie hier näher darauf eingehen?

Es ist seit mindestens 2.0 da. Iirc hatte sogar 1.0 DefineDynamicAssembly, obwohl vielleicht nicht die ganze Suite von Emit-Sachen.

Es fällt mir auch schwer, die Idee ernst zu nehmen, dass sie die Aktualisierung der CLR vermeiden. Haben Sie gesehen, wie viel Arbeit geleistet wird? https://github.com/dotnet/coreclr/commits/master
Es gibt Sprachfunktionen für C # 8, die aufgrund von CLR-Änderungen auch nur in .NET Core funktionieren. Viele dieser Einwände scheinen nur alte Informationen zu sein (was fair genug ist, da sich die Pläne von Microsoft zeitweise schnell geändert haben ...)

@ Davidfowl

Es wäre toll zu verstehen, was nicht funktioniert. ASP.NET Core und EF verwenden an einigen Stellen Reflexionsemissionen, sodass mir die großen Lücken nicht bewusst sind. Können Sie hier näher darauf eingehen?

Zugegeben, es ist ein paar Monate her, seit ich das überprüft habe. Dies hat sich möglicherweise kürzlich geändert. Soweit mir bekannt ist, ist es jedoch möglich, eine neue Assembly im Speicher zu erstellen, diese jedoch aus arkanen Gründen, die die Generierung von betreffen, nicht auf einer Disc zu speichern PDB-Dateien, wodurch Core für Compiler-Betreuer wie mich unbrauchbar wird.

Wurde dies behoben? Ich würde mich freuen zu hören, dass es ...

@ Gulbanna

Es fällt mir auch schwer, die Idee ernst zu nehmen, dass sie die Aktualisierung der CLR vermeiden

Was ich gesagt habe ist, dass sie es vermeiden, die CLR auf die gleiche Weise wie das 2.0-Update (Generika) radikal zu aktualisieren.

Insbesondere scheinen sie aktiv Änderungen zu vermeiden, die dem Typensystem neue grundlegende Arten von Typen (Formen, Metaklassen, DUs usw.) oder neue IL-Anweisungen zum Befehlssatz hinzufügen würden.

@masonwheeler

Zugegeben, es ist ein paar Monate her, seit ich das überprüft habe, also hat sich dies möglicherweise kürzlich geändert, aber soweit ich weiß, ist es möglich, eine neue Assembly im Speicher zu erstellen, aber nicht auf einer Disc zu speichern

Unter https://github.com/dotnet/corefx/issues/4491 (wo Sie in der Vergangenheit kommentiert haben) denke ich, dass die Situation immer noch dieselbe ist. Obwohl ich denke, dass das Fehlen einer bestimmten Funktion (auch wenn es eine wichtige ist) ganz anders ist als "Wir haben immer noch nicht einmal ein funktionierendes Reflection.Emit ".

Das macht Core für Compiler-Betreuer wie mich nutzlos

Wie ist Reflection.Emit jemals für einen Compiler-Writer nützlich? Ich dachte, es sei auf die Erstellung von Assemblys für das aktuelle Framework beschränkt, daher könnte es überhaupt nicht zum Erstellen von z. B. .Net Standard-Assemblys verwendet werden, was meiner Meinung nach eine erhebliche Einschränkung für jeden Compiler darstellt.

Was ich gesagt habe ist, dass sie es vermeiden, die CLR auf die gleiche Weise wie das 2.0-Update (Generika) radikal zu aktualisieren.

Ich denke, es gab eine gewisse Trägheit, die CLR nicht zu ändern, obwohl es auch einige sehr gute Gründe dafür gibt, insbesondere wenn Sie der Meinung sind, dass solche Änderungen am nützlichsten und am wenigsten schmerzhaft sind, wenn eine Plattform jung ist.

Ich denke, dass DIM ein Zeichen dafür ist, dass sich dies möglicherweise ändert, aber ich würde immer noch keine neuen IL-Anweisungen erwarten, wenn JIT-Intrinsics oft genauso gut funktionieren können, oder neue Arten von Typen, wenn sie im vorhandenen Typsystem angemessen codiert werden können.

@svick

Obwohl ich denke, dass das Fehlen einer bestimmten Funktion (auch wenn es eine wichtige ist) ganz anders ist als "Wir haben immer noch nicht einmal eine funktionierende Reflection.Emit".

Wenn Sie einen Texteditor hätten, mit dem Sie Textdateien eingeben, aber nicht speichern könnten, würden Sie nicht sagen, dass dies nicht funktioniert?

Wie ist Reflection.Emit jemals für einen Compiler-Writer nützlich?

Bisher hat es gut funktioniert. Soweit mir bekannt ist, ist es das einzige verfügbare Compiler-Backend, mit dem Sie neue Assemblys generieren und speichern oder neue Assemblys im Speicher generieren und ausführen können.

Ich würde immer noch keine neuen IL-Anweisungen erwarten, wenn JIT-Intrinsics oft genauso gut funktionieren können

Sicher, aber was ist mit den Fällen, in denen dies nicht der Fall ist?

oder neue Arten von Typen, wenn sie im vorhandenen Typensystem angemessen codiert werden können.

Haben Sie den Vorschlag für die Umsetzung Formen innerhalb des bestehenden Typsystem gesehen? Daran ist nichts Vernünftiges; Es ist ein großer, hässlicher Kludge von Anfang bis Ende. (Nichts gegen die Leute, die sich das ausgedacht haben; es muss angesichts der Einschränkungen, mit denen es arbeitet, so sein.) Und viel Glück beim Implementieren von Metaklassen ohne Unterstützung auf CLR-Ebene!

Wir brauchen eine aktualisierte CLR, um übergeordnete Funktionen auf effiziente Weise zu entwickeln, und niemand arbeitet tatsächlich daran, dies auf Core zu erreichen.

Kann jemand aus dem .net-Team bitte klarstellen, welche Empfehlung er für On-Premise-Bereitstellungen hat? Ist es nur "asp.net normal verwenden"? Ich spreche speziell mit den Kommentaren von @ Edward84

Betrifft dies die Unterstützungsbibliotheken Microsoft.Extensions.* ? Insbesondere Microsoft.Extensions.Logging und Microsoft.Extensions.Configuration .

Wir haben eine große Codebasis, die eine gemeinsame Kern-API verwenden. Einige davon sind WinForms, andere sind klassisches ASP.NET, andere WCF usw. Und die neuesten Anwendungen sind .NET Core (derzeit nicht, aber schließlich, wenn wir unsere Kernbibliotheken auf den .NET-Standard portiert haben).

Wir haben uns entschieden, unsere zentrale Protokollierungs- und Konfigurations-API auf die Abstraktionen in den oben genannten Bibliotheken zu stützen.

Ich frage mich also, ob diese sicher in einer .NET Standard-API verwendet werden können, auf die sowohl .NET Core als auch .NET Framework (4.7.2+) verweisen, oder ob sie möglicherweise auch nur .NET Core-Funktionen verwenden.

@mvestergaard Wie in der Ankündigung selbst erwähnt :

Microsoft.Extensions- Pakete (wie Protokollierung, Abhängigkeitsinjektion und Konfiguration) unterstützen weiterhin .NET Standard

Und in @benaadams 'Kommentar in diesem Thread :

Nicht alle Bibliotheken werden nur auf .NET Core umgestellt (z. B. Microsoft.Extensions.* bleiben als .NET Standard erhalten).

@mvestergaard Wie bereits erwähnt,

Das größte Problem, das ich dabei habe, ist, dass ich nicht in der Lage bin, die ausgereiften Pakete zu verwenden, die nur für das Targeting von .NET Framework verwendet werden können, oder solche, die außerhalb von .NET Framework einfach nicht verfügbar waren, wie diejenigen, die System.Drawing und GDI + benötigten.

Es scheint, dass das letztere Szenario in .NET Core 3.0 unterstützt wird, aber AFAICT, wir werden immer noch die Verwendung der stabilen, ausgereiften Bibliotheken verpassen, die nur in .NET Framework verwendet werden können.

Ein Beispiel hierfür ist Entity Framework . Wir müssen auf den unreifen EF Core umsteigen, der weit davon entfernt zu sein scheint, alle komplexen Szenarien zu bewältigen, die die vollständige EF könnte, und der auf die In-Memory-Client-Bewertung hinter Ihrem Rücken zurückgreift, um das Problem zu verbergen, das die Leistung verursacht Probleme .

Ein Beispiel hierfür ist Entity Framework. Wir müssen auf den unreifen EF-Kern umsteigen, der weit davon entfernt zu sein scheint, alle komplexen Szenarien zu bewältigen, die der vollständige EF ...

EF6 wird in .NET Core 3.0 unterstützt, wie von @DamianEdwards in dieser Woche erklärt. ASP.NET Community Standup - 6. November 2018 - ASP.NET Core 3.0-Funktionen um 19:06 Uhr

@benaadams das sind tolle Neuigkeiten! ziemlich dunkel für so eine große Sache! :) gute Arbeit, das zu finden. Ich habe hier eine weitere Erwähnung gefunden .

@SaebAmini : Sie können System verwenden. Zeichnen auf .NET Core. Siehe System.Drawing.Common und Scott Hanselmans Blogpost: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ,

Und davor existierte CoreCompat.System.Drawing als Port von Monos System.Drawing .

Gibt es eine Funktion, die für Ihren Anwendungsfall unter .NET Core fehlt?

@TsengSR Mein spezifisches Szenario, das uns dazu brachte, das .NET Framework ins Visier zu nehmen, war:

1. Die Notwendigkeit, das Microsoft Solver Foundation-Paket zu verwenden, das nur in .NET Framework verfügbar ist.
2. Ein Barcode-Bilderzeugungspaket, das System.Drawing verwendet.
3. Die Notwendigkeit, EF6 zu verwenden.

Das war vor ungefähr einem Jahr.

@SaebAmini : Wie bereits erwähnt, ist die EF6-Unterstützung in .NET Core 3.0, System.Drawing bereits vorhanden (und zuvor war das CoreCompat-Paket vorhanden und hat in Ihrem Fall möglicherweise funktioniert) und danach für das Microsoft Solver Foundation-Paket Ausführen von Portability API Analyzer:

Siehe Verwenden des Portability Analyzer

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (laden Sie es herunter und öffnen Sie den HTML-Code, haben keinen anderen Ort zum Einfügen gefunden).

Es zeigt eine 97,93% ige Kompatibilität mit .NET Core 2.0 + Platform Extensions (das vor etwa einem Jahr veröffentlicht wurde) und listet inkompatible APIs auf, die hauptsächlich mit veralteten System.Web und System.ServiceModel / zusammenhängen System.Data.Linq .

Jetzt habe ich dieses Paket vorher nicht verwendet, und ich bin nicht sicher, warum ein Löser Zugriff auf System.Web und HttpContext oder die System.ServiceModel benötigen würde, aber wenn Sie dies nicht tun Sie benötigen keine dieser Thesen (und Sie wissen, dass Ihr Anwendungsfall diese APIs nicht aufruft), die Chancen stehen ziemlich hoch, dass Sie sie unter .NET Core 2.0 / 2.1 + Platform Extensions oder sogar unter .NET Core 3.0 verwenden können wenn es nicht speziell auf den Ziel-Moniker netstandard oder netcoreapp20 abzielt.

Technisch gesehen standen die Chancen also gut, dass Sie Ihre Anwendung vor einem Jahr auf .NET Core 2.0 + Platform Extensions migriert haben könnten, wenn EF Core 2.0 die Anforderungen Ihrer Anwendungen hätte erfüllen können (dies erfordert natürlich einige Migrationsarbeiten und Aktualisierungen mit EF Core 2.0).

Ja, die Analyse der fraglichen Bibliotheken oder der Funktion für das Ersatzframework (EF6 -> EF Core 2.0 / 2.1) erfordert etwas mehr Arbeit, ist jedoch keineswegs unmöglich. Ich glaube nicht, dass die Leute damit rechnen können oder sollten, ihren gesamten Code 1: 1 auf ASP.NET Core zu portieren, ohne Änderungen vorzunehmen (außerhalb von ASP.NET Core selbst).

Ich wünschte nur, es wäre offensichtlicher, wenn die API-Kompatibilität angezeigt würde, beispielsweise mit einem "Badge" (.NET Core 3.0-kompatibel) und / oder einem detaillierten API-Kompatibilitätsbericht irgendwo auf der Nuget-Seite, um dies offensichtlicher zu machen, als das Paket herunterladen zu müssen und führen Sie es dann durch den Paketanalysator.

Ich denke, diese Ankündigung wäre besser angekommen, wenn sie betont hätte, wie viel kompatibler .NET Core geworden ist. Es gibt zwei Faktoren, die es ermöglichen, ASP.NET Core aus .NET Framework zu entfernen:
1) Reduzieren Sie den Bedarf an .NET Framework, stellen Sie Legacy-Deps zur Verfügung und verbessern Sie Interop und so weiter
2) Steigerung der Vorteile von .NET Core, Funktionen und Leistung sowie Reduzierung des Wartungsaufwands

Faktor 2 spielt in den Köpfen von Menschen eine große Rolle, die tatsächlich ASP.NET erstellen müssen! Aus Sicht des Benutzers gibt es jedoch wenig Vorteile. Menschen haben eine Sache, die funktioniert, und ihre höchste Priorität ist, dass sie weiter funktioniert. Die gute Nachricht ist, dass dies in den meisten Fällen der Fall sein wird.

Ich stimme @gulbanana zu. .NET Core ist jetzt viel kompatibler mit .NET Framework. Tatsächlich konnte ich ziemlich große .NET Framework-Apps starten, indem ich .exe in .dll umbenannte und dem Prüfpfad einige fehlende .DLLs hinzufügte.

Der Fortschritt dotnet Befehlszeilentools

Eine AOT-Zusammenstellung mit crossgen ist großartig. Ich kann weiter und weiter gehen.

tl / dr .NET Core ist heutzutage sehr beeindruckend.

Was fehlt:

• Die aktuelle Kundenkommunikationsstrategie fehlt. Kunden sind sehr enttäuscht, wenn sie hören, dass ihre bevorzugte .NET-Plattform von Microsoft fragmentiert wird. Sie sollten hier klarer sein. Zum Beispiel wäre es ein viel besserer Ansatz, die einzigartige, hochkompatible, schnelle und zukunftssichere .NET-Implementierung direkt für Menschen zu bewerben. Wie .NET Core, die Zukunft von .NET, die die meisten Ihrer Probleme lösen wird, die Produktivität von Raketen, die Kreativität, die Erschließung neuer Marktnischen usw.
• Noch mehr Kompatibilitätsstrategien
• Grafische Benutzeroberfläche. Ich meine, dotnet Befehlszeilentools sind großartig, aber derzeit müssen wir zusätzliche Texteditoren und Konsolen verwenden, um an fast jedem Projekt im .NET SDK-Format zu arbeiten. Die Visual Studio-Benutzeroberfläche fehlt in dieser Hinsicht. Dies stellt viele Menschen vor große Hindernisse, die die Gewohnheit haben, nur zu zeigen und zu klicken. Dies sollte ebenfalls verbessert werden
• LTS-Unterstützung

@TsengSR Vielen Dank für Ihre ausführliche Antwort Kumpel, tolle Infos! Zu diesem Zeitpunkt würde die Verwendung des Barcode-Pakets nicht funktionieren, da das Projekt einfach keine Beschwerden über verschiedene Ziele kompilieren würde. Vielleicht sollte ich es noch einmal versuchen. (es sei denn, Sie wollten es selbst neu kompilieren und irgendwie erben)

Keine Sorge um den Aufwand, wenn das vernünftig ist. Mein Hauptanliegen war es, hoch und trocken zu bleiben, ohne dass EF der Hauptblocker war, und das wird anscheinend nicht passieren. Schön zu sehen, dass es gut durchdacht ist. Obwohl ich @gulbanana zustimme, dass diese besser beworben werden können.

Hier gibt es viele miteinander verbundene Probleme. Meine persönlichen 2 Cent sind, dass es keine so große Sache ist, .NET Framework hinter sich zu lassen. Was jedoch betrifft, ist das völlige Fehlen jeglicher offensichtlicher Unterstützung für Standardisierungsbemühungen (.NET Standard). Sicher, Sie möchten ASP.NET Core wahrscheinlich nicht ausführen, sagen Sie Unity heute, aber es geht nicht um heute. Es ist ungefähr ein oder zwei Jahre später, als eine weitere .NET-Laufzeit kommen könnte . Ich möchte sagen können: "Ja, sobald SuperNetRuntime .NET Standard 2.2 unterstützt, können wir ASP.NET Core 3 darauf ausführen." ...

Gibt es eine Möglichkeit, mindestens alle in .NET Core 3 für ASP.NET Core 3 erforderlichen Änderungen zu "sammeln" und als Vorschläge an die .NET Standard-Arbeitsgruppe weiterzuleiten?

Hallo, werden Pakete, die für .NetStandard 2.0 oder .NetCore 2.0 veröffentlicht wurden, weiterhin mit .NetCore 3.0 funktionieren. Zum Beispiel: Oracle.ManagedDataAccess.Core-Ziel .NetCore 2.0

Wenn Abwärtskompatibilität besteht, ist die Umstellung auf .NetCore 3.0 geeignet. Wenn ältere Versionen jedoch nicht unterstützt werden, ist dies wirklich nutzlos, es sei denn, alle Spiele holen auf.

.NetFramework hat eine lange Kompatibilitätshistorie, auch wenn Sie .NetFramework 2.0 in den neuesten Versionen verwenden können. Daher muss für .NetCore auch mindestens 2.0 bis 3.0 usw. gewartet werden.

Vielen Dank

Hallo, werden Pakete, die für .NetStandard 2.0 oder .NetCore 2.0 veröffentlicht wurden, weiterhin mit .NetCore 3.0 funktionieren. Zum Beispiel: Oracle.ManagedDataAccess.Core-Ziel .NetCore 2.0

Ja, .NET Core 3.0 ist abwärtskompatibel und kann daher .NetStandard 1.0 -> .NetStandard 2.1- und .NetCore 1.0 -> .NetCore 2.2-Bibliotheken verwenden

@benaadams dann ist das gut. Funktioniert die .net Framework DLL auch, wenn keine fehlende API verwendet wird?

Vielen Dank

Funktioniert die .net Framework DLL auch, wenn keine fehlende API verwendet wird?

Ja, obwohl es sicherer ist, eine .NET Standard-Bibliothek zu verwenden, wie Sie wissen, die unter .NET Core (und unter Mono, Xamarin, Unity, UWP) funktioniert.

Durch die Verwendung des Windows-Kompatibilitätspakets werden zusätzlich zu .NET Standard 2.0 weitere 20.000 APIs hinzugefügt, um .NET Core näher an .NET Framework heranzuführen (was Sie mit .NET Core 2.1 tun können). und .NET Core 3.0 ist das bisher kompatibelste mit EF6 (Cross-Plat) und unter Windows: WinForms, WPF, COM Interop usw.

Hallo Leute,
Um Kunden ein angemessenes Sprungbrett auf dem Weg zur Migration von Anwendungen auf ASP.NET Core unter .NET Core zu bieten, werden wir den Support und Service für ASP.NET Core 2.1.x unter .NET Framework erweitern, um ihn an den aktuellen Support anzupassen Richtlinie für die anderen paketbasierten ASP.NET-Frameworks , z. B. MVC 5.x, Web API 2.x, SignalR 2.x. Dies bedeutet effektiv, dass die ASP.NET Core 2.1.x-bezogenen Pakete (endgültige detaillierte Liste TBD) auf unbestimmte Zeit über den 3-jährigen LTS-Zeitraum für den .NET Core 2.1-Zug insgesamt hinaus unterstützt werden.

Hervorragende Nachrichten. Vielen Dank, dass Sie Ihren Kunden zuhören.

Es wird sehr lange dauern, bis wir unsere alte MVC-App portiert haben, da wir seit CTP3 auf MVC sind und fast jeden Erweiterungspunkt verwendet haben. Dies deckt unsere Bedenken ab.

@ DamianEdwards Das sind großartige Neuigkeiten! Ich frage mich nur, ob dies auf

@poke Während ich Ihr Anliegen verstehe, müssen wir irgendwo eine Linie ziehen, und in diesem Fall halten wir es für besser, die Version an der LTS auszurichten, die ihr vorausgeht. Dies ist der Kompromiss, den Kunden bei der Wahl zwischen einem LTS- oder einem aktuellen Zug selbst entscheiden müssen. LTS bietet keine neuen Funktionen, da es um Stabilität geht. Das Feedback war für eine längerfristige Unterstützung und wir haben bereits einen Zug dafür, so dass dies eine Erweiterung des Zuges ist. 2.2 wird nicht LTS.

@ DamianEdwards Ja, das verstehe ich, danke für deine Antwort. Ich habe nur gefragt, weil der letzte Kommentar dazu war, dass es noch nicht entschieden wurde , also wollte ich nur wissen, ob diese erweiterte Unterstützung sich fortsetzen würde, wenn 2.2 LTS würde.

Und ich denke, es ist wichtig genug, dies hervorzuheben, damit die Benutzer ihre Framework-Apps nicht auf 2.2 aktualisieren, wenn sie sich auf diese erweiterte Unterstützung verlassen müssen. Andernfalls müssen sie erneut downgraden.

LTS bietet keine neuen Funktionen, da es um Stabilität geht.

Das stimmt jedoch nicht wirklich mit den vorherigen LTS-Entscheidungen überein.

@Sack

Das stimmt jedoch nicht wirklich mit den vorherigen LTS-Entscheidungen überein.

Das hat mich verwirrt. Inwiefern? Beziehen Sie sich auf die Tatsache, dass 1.1 zum 1.x LTS-Zug hinzugefügt wurde? Wenn ja, war das eine Anomalie unseres ersten Zuges, die nicht wiederholt wird. In Zukunft ist es unsere Absicht, konsistenter zu werden, welche Releases zu LTS vs. Current werden (dh woher bekomme ich Stabilität vs. Features).

@DamianEdwards Ich bezog mich hauptsächlich auf die Tatsache, dass jede Veröffentlichung bisher eine große Feature-Veröffentlichung war und jede LTS-Entscheidung normalerweise im Nachhinein (zumindest öffentlich) getroffen wurde.

@poke OK. Nun, bisher hatten wir 4 Releases (1.0, 1.1, 2.0, 2.1), das fünfte kommt in Kürze (2.2). Von diesen waren ursprünglich nur 1.0 und 2.0 als LTS gedacht, aber aufgrund einer Reihe von Faktoren (die hauptsächlich damit zusammenhängen, dass wir auf diese Weise wirklich neu im Ingenieurwesen sind 😉), waren 1.0, 1.1 und 2.1 die LTS-Züge. 2.0 und 2.2 sind (waren, werden) aktuelle Releases. Zu diesem Zeitpunkt wird 3.0 mit ziemlicher Sicherheit auch aktuell sein (was dazu führt, dass 2.2 in die aktuelle "Nachfrist" von 3 Monaten eintritt), bevor 3.1 zum 3.x-Zug-LTS wird. Wir hoffen, dass das Muster und die Trittfrequenz danach gleichmäßiger sind (das würden wir lieben), aber bisher hat uns unsere Kristallkugel gescheitert.

@ DamianEdwards Danke für die Einblicke! 😄 (Übrigens habe ich nicht versucht darüber zu streiten, ich war nur neugierig;))

Ein größeres Problem für uns sind neue REST-APIs, die von älteren Anwendungen in Bearbeitung gehostet werden und die wahrscheinlich nicht so schnell von .NET Framework entfernt werden. Zumindest wissen wir, dass wir jetzt nicht über .NET Standard 2 hinausgehen müssen, das Bibliotheken und ASP.NET Core 2.1 unterstützt! Es ist gut, dass die LTS-Frist verlängert wird

Hallo zusammen, eine kurze Frage: Was ist mit denen von uns, die native Pakete in Form von C ++ / CLI konsumieren? Wird das bald in .Net Core unterstützt oder sind wir verwaist, es sei denn, wir führen eine massive Überarbeitung durch, um P / Invoke zu verwenden?

@lokitoth - das wäre eine gute Frage für die Leute von https://github.com/dotnet/core, da es allgemeiner ist als nur ASP.NET Core.

@lokitoth ja, das wird unterstützt, siehe https://github.com/dotnet/coreclr/issues/18013

oO Wie habe ich das vermisst?

Okay, dann habe ich keine Probleme damit.

@ danroth27 Können Sie uns die Auswirkungen dieses Problems auf Client-Side-Blazor mitteilen?

@Slkebe Ich erwarte keine Auswirkungen. Clientseitige Blazor-Apps sind unabhängig von der Laufzeit oder Plattform, die Sie auf dem Server ausführen möchten.

@ danroth27 Nach meinem Verständnis kann clientseitiges Blazor auf Mono ausgeführt werden, da abhängige Microsoft.AspNetCore.* -Pakete auf den Nettostandard abzielen.
Vermisse ich etwas Blazor muss weiterhin auf Microsoft.AspNetCore.* 2.1.X zielen?

@Slkebe Die clientseitigen Blazor-Bibliotheken hängen nur von Komponenten ab, die weiterhin auf .NET Standard abzielen (wie Microsoft.Extensions. * Und Freunde). Die serverseitigen Teile von Blazor, die von ASP.NET Core abhängen, zielen auf .NET Core ab, wie in dieser Ausgabe beschrieben.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Was ist jetzt die Entscheidung? Ziel auf .net Standard 2.1?

@ John0King Es gibt keine neue Entscheidung.

Das sind Bananen! BANANEN

Ich bin mit Ihrem Standpunkt einverstanden.

Entschuldigung, wenn dies bereits erwähnt wurde, aber was ist mit Anwendungsfällen, in denen ich nur Kestrel + Middleware als Teil einer Nicht-ASP.NET-Anwendung verwenden möchte? Muss ich den gesamten 3.0-Baum abrufen (was nicht ideal ist, da in meinem Anwendungsfall ein benutzerdefiniertes SDK für Verbraucher definiert wird), oder wird dieser Anwendungsfall in 3.x nicht unterstützt?

Derzeit entwickle ich aufgrund der enthaltenen Bibliotheken eine ASP.NET Core-Anwendung, die unter .NET Framework ausgeführt wird. Ich verwende ASP.NET Core aufgrund seiner Multi-Auth-Funktionen. Ich fühle mich betrogen und tot eingesperrt.

Ich verwende ASP.NET Core aufgrund seiner Multi-Auth-Funktionen.

@FlorianGrimm Was genau? Microsoft.Owin stellte ähnliche Authentifizierungsfunktionen für ASP.NET 4 bereit.

Es handelt sich um einen Hybrid-App-One-Quellcode (.exe), der lokal und in Azure ausgeführt wird und derzeit Windows Auth, AAD, Basic Auth und anonym verwendet.

@FlorianGrimm Welche Bibliotheksabhängigkeiten hindern Sie daran, .NET Core zu verwenden?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom und Microsoft.SharePointOnline.CSOM.

Ich hoffe, das SharePoint-Team wird fertig
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
und ich finde andere Möglichkeiten als ilspy.

Auf jeden Fall mag ich ASP.NET Core und ich hoffe, dass die anderen Microsoft-Teams mehr .NET Core-Assemblys bereitstellen.

Wir schließen regelmäßig Diskussionsfragen, die seit langem nicht mehr aktualisiert wurden.

Wir entschuldigen uns, wenn dies zu Unannehmlichkeiten führt. Wir bitten Sie, wenn Sie immer noch auf ein Problem stoßen, ein neues Problem mit aktualisierten Informationen zu protokollieren, und wir werden dies untersuchen.