Aspnetcore: Die neuen ASP.NET Core 2.0-Pakete können nicht mehr auf .NET Desktop verwendet werden

Dies wäre eine äußerst seltsame und schlechte Änderung. Ich habe viel reinen netfx-Kerncode für asp.net geschrieben und möchte nicht, dass diese Investition verschwendet wird. Generell müssen .NET-Kunden in absehbarer Zeit in der Lage sein, zwischen ASP.NET Core- und Desktop-Code interoperabel zu sein – stellen Sie sich Webapps vor, die Active Directory oder Office-COM-Automatisierung verwenden oder die Miniaturansichten auf Basis von System.Drawing erstellen Bibliothek oder teilen Sie Code mit einer WPF-App. Es ist trivial, sich viele solcher Szenarien vorzustellen, und ich hoffe, wir haben einfach falsch verstanden, was vor sich geht.

Wir sind derzeit auf AspNetCore 1.1.1 – dh dem „aktuellen“ Support-Zweig. Wenn wir aufgrund von Abhängigkeiten von Net4XX nicht zu 2.0 wechseln können, bedeutet das, dass wir nicht mehr unterstützt werden, wenn 2.0 + 3 Monate fallen?

Wir verwenden eine Kombination aus WPF und ASP.NET Core und zielen in beiden Fällen auf das vollständige Framework ab.
Also schätze ich kein 2.0 in absehbarer Zeit?

Aber Full Framework 4.6.1 wird netstandard 2 unterstützen? übersehe ich etwas? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

ist das nicht, dass die aktuellen Werkzeuge nicht aktualisiert werden?

es wäre völlig in Ordnung und es wäre zu erwarten, dass asp.net core auf net standard 2 läuft. das alarmierende ist diese aussicht, auf net core app2.0 umzusteigen, was bedeuten würde, dass kein älterer code innerhalb von asp.net verwendet werden könnte Kern-Websites

oh, das ist ein Problem. Ich nehme an, dass es ein wenig durch die Compat-Shims in netcore2 gemildert wird, mit denen Sie auf alte Assemblies verweisen können, aber dennoch bedeutet es, alle Projekte auf das neue Projektsystem zu portieren und eine Menge anderer Arbeit.

Wäre schön zu hören, wie die Teams dazu argumentieren

oh, Sie denken also, dass netcoreapp2.0-Projekte dank der Typenvereinheitlichung einfach in der Lage sein werden, auf netfx-Bibliotheken zu verweisen? das würde einiges erklären. Meine Frage, wenn ja, ist, wie viel Code tatsächlich funktioniert, wenn er unter Windows, aber auf der Kern-CLR ausgeführt wird.

Beeindruckend. Dies würde uns total blockieren und im Grunde sicherstellen, dass wir diese Pakete auf absehbare Zeit niemals aktualisieren könnten. Möglicherweise müssen wir sogar unser MvcCore-Projekt zurück auf Mvc migrieren, da wir derzeit nicht um die Ausrichtung auf net462+ herumkommen.

Darauf bin ich auch sehr gespannt. Ich hoffe wirklich, dass dies in einem Zwischenschritt (und kurzlebigen) oder einem großen Missverständnis liegt. Es wäre sicherlich auch ein Hindernis für die Akzeptanz der meisten unserer Anwendungen.

Alles auf Core zu verschieben ist einfach zu viel für eine große vorhandene Codebasis (ohne Entwickler daran zu hindern), die Umstellung auf die neuen ASP.NET-Klassen (HttpRequest, Controller usw.) als Zwischenschritt muss für unsere Hauptprojekte erfolgen.

Vielleicht können @DamianEdwards oder @davidfowl die Pläne hier kommentieren? Ich habe auch Probleme, zusätzliche Argumente zu finden.

Ich kann verstehen, warum dies zunächst ein beängstigender WTF-Moment ist. Lassen Sie mich erklären, weil es weniger ausgeflippt ist, als es scheint.

• Sie haben gesagt, dass .NET-Kunden zusammenarbeiten müssen. Völlig einverstanden.
  
  
  
  • Wir können Netstandard-Bibliotheken zwischen ASP.NET Core 2.0 und ÜBERALL teilen.
  
  
  • Aufgrund von Typeforwarding und netstandard20 können wir sogar auf viele net461+-Assemblys von ASP.NET Core 2.0 verweisen
  
  
• Sie sagten, WebApps müssen möglicherweise Folgendes verwenden:
  
  
  
  • AD – Insgesamt ist dies eine Lücke, wenn Sie LDAP direkt aufrufen möchten. Sie können sich sicherlich JETZT gegen Windows Auth authentifizieren. Wir planen, um den Sommer herum speziell den DirectoryServices-Namespace für Core 2.0 zu haben
  
  
  • Zeichnen – Das ist absolut eine Lücke. Wir planen, dies für Core 2.0 im Sommerzeitraum zu haben. Bis dahin existieren diese Netzstandard-Optionen auch ImageSharp, ImageResizer, Mono-Optionen usw
  
  
  • COM-Automatisierung – Dies war unter Core 2.0 noch nie möglich, aber Sie können sicherlich PInvoke verwenden, wenn Sie sich verletzen möchten. Sie können WebAPI auch für einen net461+-Prozess lokalisieren, wenn Sie sich wirklich verletzen wollen.
  
  
  • Code mit WFP-Apps teilen – JA. Mit netstandard2.0 durchaus möglich.
  
  
• Dies ist eine seltsame Änderung.
  
  
  
  • Fühlt sich so an, aber…
  
  

Denken Sie so darüber nach. WPF ist nicht netstandard2.0, es weiß, dass es auf net461+ ist und das ist in Ordnung. Es ist optimiert, kann aber auf Netstandard-Bibliotheken verweisen. ASP.NET Core 2.0 ist für Core 2.0 optimiert, kann aber auf gemeinsam genutzte Bibliotheken verweisen. Xamarin ist das gleiche.

.NET Core ist Seite an Seite und entwickelt sich schnell. Es ist VIEL schneller als .NET (Full) Framework bewegen kann, was gut ist. Durch den Aufbau von ASP.NET Core 2.0 auf .NET Core 2.0 (was, wie Sie sich erinnern, ein SUPERSET von .NET Standard ist), bedeutet dies, dass Dinge schneller als NetFx oder sogar Netstandard erstellt werden können.

NetCore > Net Standard > NetFx, wenn es um Entwicklungsgeschwindigkeit und Innovation geht.

Punkt ist, wenn Sie neue Arbeiten machen, netstandard20. Wenn Sie über ältere net461+-Bibliotheken verfügen, können die meisten davon unter ASP.NET Core 2.0 referenziert werden.

ASP.NET Core 1.1, das auf .NET Framework ausgeführt wird, wird nach der Veröffentlichung von 2.0 ein Jahr lang vollständig unterstützt. Diese Workload wird bis mindestens Juli 2018 vollständig unterstützt.

Die verbleibenden großen Lücken, die in .NET Core 2 fehlen, sind System.DirectoryServices und System.Drawing. Wir arbeiten an einem Windows-Kompatibilitätspaket, das beide in diesem Sommer auf .NET Core unter Windows ermöglichen würde.

Was wir von Ihnen allen brauchen, ist eine klare Liste/ein Verständnis dafür, WARUM Sie denken, dass Sie ASP.NET Core 2.0 benötigen, um auf net461+ zu laufen.

Ich dachte, bei .NET Standard 2.0 dreht sich alles um Kompatibilität und Interoperabilität, die die Lücke zwischen .NET Core und .NET fx schließt, auf die alle warten – das scheint das zu beenden.

Aus irgendeinem Grund wird es viele Kunden geben, die Abhängigkeiten haben, die .NET 4.x erfordern, sei es benutzerdefinierte externe Abhängigkeiten, kommerzielle Komponenten, Legacy-Lib-Abhängigkeiten usw.

Ist es beabsichtigt, dass Kunden keine ASP.NET Core 2.0-Apps erstellen können, die auf Desktop CLR ausgeführt werden, damit sie auf ihre vorhandenen .NET 4.x-Deps verweisen können?

@shanselman Danke für die Antwort - viele gute Beispiele drin.

Ein Follow-up über Bibliotheken:
Bleiben alle Abstraktionsbibliotheken crosskompiliert? Wenn ich beispielsweise HttpRequest verwende, wäre es etwas, 1.x- und 2.x-Builds auf der Version von ASP.NET Core zu verwalten, die Sie verwenden (die jetzt zumindest sauber einem TFM zugeordnet sind). Ich würde es vorziehen , zu vermeiden ... also hoffe ich, dass die Abstraktionen auf netstandard bleiben. Ist das der allgemeine Plan?

Wir pflegen bereits mehrere Varianten für Dinge, die von ASP.NET/MVC abhängen, weil System.Web 's HttpRequest völlig anders ist, also ist das eine ganz andere Bibliothek (z. B. MiniProfiler vs . MiniProfiler.AspNetCore ). Ich möchte nur sicherstellen, dass wir die Anzahl der Varianten im Hinterkopf behalten, die wir für die Wartung von Bibliotheksautoren laden, wenn sich ihre Abhängigkeiten von netstandard entfernen ... und hoffentlich diese Kopfschmerzen alle zusammen vermeiden.

Ich bin sehr froh, dass dies nicht so eine große Sache zu sein scheint, wie es scheint, danke für die detaillierte Klärung.

Ich habe zwei Fragen/Bedenken:

• Es hört sich so an, als ob die Verwendung von .NET Framework-Bibliotheken von ASP.NET Core nur minimale Reibungsverluste aufweisen sollte. Das ist großartig! Was ist andersherum? Es gibt wahrscheinlich .NET Framework- oder Netstandard-Bibliotheken und -Anwendungen, die Teile oder Komponenten von Mvc und anderen unterstützenden ASP.NET Core-Bibliotheken einbetten (ich weiß, weil ich ein paar habe). Die gehen kaputt, richtig? Gibt es Tipps, wie man dieses Szenario umgehen kann? Wenn Netstandard-Bibliotheken keine ASP.NET Core-Bibliotheken mehr nutzen können, scheint das eine große Sache für eingebettete ASP.NET Core-Szenarien zu sein.

• Aus einer nicht-technischen Perspektive scheint dies eine Menge Verwirrung stiften zu können. Abgesehen von den Leuten, die auf GitHub aktiv sind, auf Twitter mitmachen usw. gibt es bereits eine große Verwirrung um die verschiedenen Plattformen usw. Ich sehe Entwickler, die nur teilweise mitgemacht haben oder die gerade aufstehen sehr frustriert, wenn sie ASP.NET Core verwenden (vielleicht nach einem veralteten Tutorial) und es nicht auf ihren .NET Framework-Plattformen zum Laufen bringen können. Nicht sicher, was, wenn überhaupt, dagegen getan werden kann.

Aufgrund von Typeforwarding und netstandard20 können wir sogar auf viele net461+-Assemblys von ASP.NET Core 2.0 verweisen

Leider bedeutet dies nicht, dass eine Bibliothek, die für das vollständige Framework kompiliert und entworfen wurde, auf .NET Core funktioniert (das Risiko ist hoch, dass Dinge zur Laufzeit explodieren!).

Viele der „alten“ APIs, die in .NET Core 2.0 wieder eingeführt wurden, sind Stubs, die niemals (funktional) funktionieren werden. Ganz zu schweigen davon, dass noch viele APIs fehlen und sogar ganze Bereiche, die bewusst aus .NET Core ausgeschlossen wurden (IdentityModel, WCF-Server, Remoting, vollständige AppDomain-Unterstützung usw.)

Der Versuch, Leute davon zu überzeugen, dass sie ihre ASP.NET Core 1.0 mit .NET Desktop-Apps „sicher“ auf ASP.NET Core 2.0 mit .NET Core migrieren können, ist meiner Meinung nach eine Lüge.

.NET Core ist Seite an Seite und entwickelt sich schnell. Es ist VIEL schneller als .NET (Full) Framework bewegen kann, was gut ist. Durch den Aufbau von ASP.NET Core 2.0 auf .NET Core 2.0 (was, wie Sie sich erinnern, ein SUPERSET von .NET Standard ist), bedeutet dies, dass Dinge schneller als NetFx oder sogar Netstandard erstellt werden können.

Ich glaube nicht, dass (die meisten) Leute danach suchen. Viele Leute brauchen keine schnelllebigen Bibliotheken, sie brauchen stabile Sachen , die sich elegant in ihre älteren Sachen integrieren lassen, ohne das Risiko einzugehen, alles kaputt zu machen.

@daveaglick

• Richtig, dass es keine implizite Möglichkeit gibt, auf netcoreapp2.0 von net461 oder sogar netstandard2.0 zu verweisen. Die Brücke geht in eine Richtung. Sie können es immer umgehen, indem Sie TFMs für Paket-Fallback angeben, aber das ist offensichtlich eine Notlösung, kein unterstütztes Szenario (obwohl es ausreichen wird, um viele Leute zu entsperren). Es ist eine nicht triviale Menge an Arbeit für uns, Subsysteme von ASP.NET Core außerhalb des größeren Stacks zu unterstützen (was das Targeting netstandard impliziert).
• Das Verwechslungspotential geht in beide Richtungen. Beispielsweise haben wir viele Rückmeldungen erhalten, dass die Tatsache, dass „ASP.NET Core“ auf .NET Framework (das nicht .NET Core ist) ausgeführt werden kann, verwirrend ist. Durch diese Änderung wird ASP.NET Core effektiv Teil des .NET Core-Stacks, d. h. wenn Sie ASP.NET Core verwenden, verwenden Sie .NET Core.

@shanselman Übrigens , du hast nicht gesagt, warum Cross-Compilation keine Option war. ASP.NET Core-Komponenten, die von netcoreapp2.0 -only APIs profitieren könnten, könnten sowohl net46 / netstandard1.x / netstandard2.0 als auch netcoreapp2.0 TFMs haben und Machen Sie die neuen coolen/schnellen Sachen nur für .NET Core.

@NickCraver derzeit sieht der Plan nicht vor, die *.Abstractions-Pakete zu verlassen, die auf netstandard abzielen. Die Trennung ist einfach nicht so sauber wie auf der ganzen Linie. Für die Zwecke von jemandem, der eine Migration versucht, wie Sie sie vorschlagen, sollte Sie die Verwendung von Paketziel-Fallback trotzdem dorthin bringen (aber ich verstehe Sie möglicherweise falsch).

Auch Ihre Aussage zur sauberen TFM-Aufteilung ist richtig und stellt einen Vorteil dieses Plans dar, da ein einzelnes Paket jetzt ASP.NET Core 1.x und 2.0+ gleichzeitig unter Verwendung des TFM als Drehpunkt anvisieren kann.

Ich spiele mit dem Gedanken an "Mixed Applications". B. eine WPF-Anwendung, die eine Web-API verfügbar macht, oder ein Server, der sowohl eine REST-API als auch WCF-Endpunkte anbietet (dies kann für die Kompatibilität mit früheren Clients dienen). Diese Szenarien werden mit dieser Änderung unmöglich gemacht und machen ASP.NET Core nur für neue Anwendungen geeignet, anstatt „nur eine Bibliothek“ zu sein.

@PinpointTownes Wie @shanselman sagte, sind wir sehr an den spezifischen Anforderungen und Hindernissen interessiert, die Kunden haben, wenn es darum geht, weiterhin direkt auf .NET Framework abzuzielen. Unsere bisherige Arbeit mit Kunden in diesem Boot hat gezeigt, dass System.DirectoryServices und System.Drawing und die Blocker Nr. 1 und 2 sind, und wir haben einen Plan, das anzugehen. Darüber hinaus sehen wir uns das Feedback an und bewerten es.

Cross-Compiling ist ein Mehraufwand, der mit den Kunden- und Produktanforderungen in Einklang gebracht werden muss. Aus diesem Grund möchten wir dieses Feedback erhalten, damit wir konkreter definieren können, wie die Landschaft sowohl für unsere Kunden als auch für uns aussieht, während wir ASP.NET Core weiterentwickeln.

@DamianEdwards Danke für die weitere Klarstellung. Die Netstandard -> ASP.NET Core-Bibliotheken sind für mich eine große Sache. Ich bette Kestrel (das anscheinend auch auf Netcoreapp umgestellt wird) in mehrere Netstandard-Bibliotheken ein. Ich bette Razor auch an mehreren Stellen ein, und ich weiß, dass Sie an der neuen, modulareren Version arbeiten, aber wenn das auch nur auf netcoreapp abzielt, wird es weh tun. Es gibt auch Unmengen von Bibliotheken, die „Teil“ von ASP.NET Core sind, aber außerhalb davon viel Nutzen haben.

Mit anderen Worten, ich mache mir viel mehr Sorgen darüber, Netstandard-Bibliotheken die Möglichkeit zu nehmen, ASP.NET Core-Pakete zu nutzen, als mich um das Gegenteil zu kümmern. Es scheint, als ob dadurch eine ganze Klasse von Anwendungsfällen aus der Betrachtung genommen wird.

@daveaglick Razor selbst (die Engine) wird weiterhin auf netstandard abzielen. Auch hier ist die Unterstützung bestimmter Subsysteme eines großen komplexen Graphen (wie ASP.NET Core 2.0) auf verschiedenen Plattformen mit Kosten verbunden. Für Dinge wie das Einbetten gibt es andere Optionen (Quelleinbettung, Kopieren usw.), aber natürlich haben sie ihre eigenen Kompromisse.

Hören Sie auf jeden Fall auf die verschiedenen Klassen von Anwendungsfällen, wir haben in der Tat unterschiedliche Kundengruppen zu berücksichtigen, wenn wir einen Stack wie den unseren entwerfen und versenden.

Ich teile die Bedenken von @daveaglick hier: ASP.NET Core möchte die neuesten APIs verwenden, ist völlig verständlich, aber für alles andere Downstream wird es etwas chaotischer, wenn dasselbe erforderlich ist. Sie haben keine Wahl nach 1.0 von Stable oder Upgrade, Sie sind auf dem schnellsten verfügbaren Zug mit netcoreapp2.0 und das ist die einzige Wahl. Wenn nicht alle Bits (selbst die grundlegenden Abstraktionen) konsumiert werden können, ohne dass die Benutzer netcoreapp2.0 verbrauchen, bedeutet das, dass es effektiv kein netstandard2.0 für diese gesamte Reihe von Bibliotheken gibt ... und für alle das hängt von ihnen ab.

Ich bringe den Kernanwendungsstapel in Bewegung, aber ich bin nicht unbedingt damit einverstanden, dass sich insbesondere die Abstraktionen bewegen. Einer der Hauptpunkte der Abstraktionen war es, zumindest aus meiner Sicht als Verbraucher, eine solche enge Kopplung zu vermeiden. Ich wäre sehr gespannt auf einige Beispiele, bei denen netstandard2.0 nicht über die dafür erforderlichen APIs verfügt, netcoreapp2.0 jedoch schon. Gibt es da draußen einige Beispiele? Geht es hauptsächlich um neue Arten von Methodenparametern? Ich bezweifle nicht, dass es reichlich Argumente gibt, ich bin nur sehr neugierig - Beispiele zu sehen, würde helfen, die Wartungskosten zu zeigen, zu denen wir täglich nicht annähernd so viel Einblick haben.

Der Kestrel-Fall ist komplizierter, aber ich sehe sicherlich die Argumente dafür, ihn auf dem neuesten API-Set zu haben. Ich könnte mir vorstellen, dass angesichts der Arbeit, die es vorantreibt, ständig neue APIs für Kestrel erstellt werden.

@PinpointTownes Wie @shanselman sagte, sind wir sehr an den spezifischen Anforderungen und Hindernissen interessiert, die Kunden haben, wenn es darum geht, weiterhin direkt auf .NET Framework abzuzielen.

Als Berater habe ich einer Reihe von Kunden geholfen, ihre Apps auf ASP.NET Core zu verschieben, und ich musste oft auf .NET Desktop abzielen, um Bibliotheken von Drittanbietern (Closed Source) abhängig von IdentityModel / WCF oder auf Basis von AppDomain verwenden zu können Unterstützung.

Diese Dinge nicht in ASP.NET Core 2.0 zu haben, wäre ein großes Hindernis für sie.

Es gibt auch Bibliotheken, die unter .NET Core nicht funktionieren würden, selbst wenn die APIs vorhanden wären, da sie funktional anders wären. Hier ist ein konkreter Fall, den ich schon oft gesehen habe:

Auf .NET Core gibt RSA.Create() eine RSACng -Instanz unter Windows zurück, aber auf .NET Desktop wird eine RSACryptoServiceProvider -Instanz zurückgegeben. Viele Bibliotheken – einschließlich der BLC selbst – versuchen jedoch, RSA in RSACryptoServiceProvider , was unter .NET Core immer fehlschlägt, da RSACng nicht in RSACryptoServiceProvider umgewandelt werden kann

@NickCraver welche Abstraktionen insbesondere? Das Problem beim Verschieben nur der Abstraktionen besteht darin, dass Sie als Nächstes alles wollen, was auf diesen Abstraktionen aufbaut (es sei denn, Sie sagen wörtlich, dass Sie nur Microsoft.AspNetCore.Http.Abstractions und nichts anderes benötigen).

@davidfowl Ja , nur die Abstraktionen: zB HTTP, Hosting, HTML und Protokollierung. Es sieht so aus, als ob Microsoft.Extensions.* durch frühere Kommentare abgedeckt sind, was die meisten davon sind. Das sind die, mit denen ich mich heute austausche.

Für ein konkretes Beispiel: Die MiniProfiler Middleware antwortet nur auf Abstraktionen ( Link )

Wenn Sie MVC und dergleichen zusätzlich verwenden, dann sind Sie sowieso auf netcoreapp2.0 , und das ist es (und meiner Meinung nach ist das in Ordnung). Aber derzeit habe ich die Freiheit, APIs logisch aufzuteilen, wo sie geteilt werden, und das ganz einfach, weil sie Abstraktionen sind. Ich bin ein großer Fan der aktuellen Aufteilung, bitte sperrt das nicht unnötig.

Heh. Als Berater habe ich definitiv die Frage „Was? ASP.NET Core läuft auf dem Desktop .NET Framework!?“ gehört. Frage ziemlich oft. Dass „ASP.NET Core“ wörtlich „.NET Core“ im Namen trägt, ist wirklich schade.

Wie auch immer ... So wie ich ein Fan davon war, veraltete/legacy/kaputte APIs zu löschen, als .NET Core gestartet wurde (ein „neuer“ Start), bin ich auch ein Fan dieser Änderung, um ein schnelleres, schlankeres Framework zu erhalten mit mehr Features und einer höheren Innovationsrate.

Abgesehen davon habe ich auch Verständnis für alle Entwickler da draußen, die aus irgendeinem Grund ihren gesamten Code nicht vor Juni nächsten Jahres auf .NET Core migrieren können.

Dazu gehört mein aktueller Client, der über eine wahnsinnig große Legacy-Bibliothek/Framework verfügt, die auf .NET Framework abzielt und von mehreren ASP.NET Core-Projekten genutzt wird, die derzeit parallel entwickelt werden. Wenn diese Systeme in Produktion gehen, wird es wenig bis gar keine Zeit geben, um entweder a) alles auf .NET Core zu portieren oder b) alles auf das vollständige ASP.NET-Framework zu verschieben, bevor ASP.NET Core 1.x nicht mehr unterstützt wird.

Reicht hier ein Jahr Support wirklich aus? Ich kann mir vorstellen, dass es noch andere ähnliche Fälle gibt...

@khellang wie bereits erwähnt, können sie weiterhin auf Bibliotheken/Frameworks verweisen, die auf .NET Framework abzielen, und das wird gut funktionieren, vorausgesetzt, die von ihnen aufgerufenen APIs sind Teil der Schließung von netstandard2.0 . Weißt du, ob sie sich auf Dinge außerhalb dieses Raums verlassen? Dazu würden wir wirklich gerne Feedback erhalten, damit wir die Priorität der Portierung dieser APIs (wie System.DirectoryServices und System.Drawing ) einschätzen können.

Das Hosten einer Web-API (z. B. Kommunikationsschicht) oder sogar kommender asp.net-Core-Sockets wird für einen aktuellen Windows-Dienst oder eine WPF-Desktop-App unmöglich? (mit unterstützten Versionen).

Ich kann mir vorstellen, dass es eine Liste mit Dingen geben wird, die früher netstandard1.x waren und jetzt netcoreapp2.0 sind

Ich habe die Repos durchsucht und es scheint, dass MVC-spezifische Dinge netcoreapp2.0 sind, aber HttpAbstractions, Protokollierung, Konfiguration usw. sind immer noch netstandard Oder gibt es weitere Änderungen?

@NickCraver Ich sehe, dass Sie Erweiterungen verwenden, aber immer noch System.Web verwenden. Haben Sie Pläne, Microsoft.AspNetCore.Http.HttpContext mit System.Web.HttpContext zu shimen? Haben Sie eine Vorstellung davon, wie viel API Sie benötigen?

Wenn Sie MVC und dergleichen zusätzlich verwenden, dann sind Sie sowieso auf netcoreapp2.0, und das ist es (und meiner Meinung nach ist das in Ordnung). Aber derzeit habe ich die Freiheit, APIs logisch aufzuteilen, wo sie geteilt werden, und das ganz einfach, weil sie Abstraktionen sind. Ich bin ein großer Fan der aktuellen Aufteilung, bitte sperrt das nicht unnötig.

Ich spreche jedoch nicht von MVC, ich spreche nur von anderen Helfern, die mehr Funktionalität zusätzlich zu den zugrunde liegenden Abstraktionen bereitstellen. Der große Wert des von uns gewählten Musters „Abstraktionen“ besteht darin, dass andere Dinge darauf aufbauen können, nicht so sehr die Abstraktionen selbst. Mein Bauchgefühl sagt mir, dass wir, wenn wir die ASP.NET-Abstraktionen zum Netzstandard machen, am Ende auch die gesamte Middleware zum Netzstandard machen müssen.

@dasMulli- Windows-Dienste funktionieren, sobald wir die API portiert haben (es gibt auch Open-Source-Bibliotheken, die Windows-Dienste auf .NET Core unterstützen).

WPF-Desktop-App? (mit unterstützten Versionen).

Jawohl. Dies wird nicht mehr der Standard sein. Wir werden es mit .NET Core 2.0 nicht mehr standardmäßig unterstützen.

@davidfowl Ich bin mir nicht sicher, ob Sie sich dort die richtigen Teile angesehen haben:

verwenden aber immer noch System.Web

... wegen dieser Aufteilung nicht in denselben Bibliotheken. Um minimalen Overhead und keine Lastwagenladung von Abhängigkeiten für Verbraucher zu erreichen, gibt es MiniProfiler für ASP.NET MVC < 6 (System.Web) und MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (viele NuGet ).

Ich glaube, Sie sprechen von System.Web Überresten, die sich auf MiniProfiler.Shared – ich habe darauf gewartet, diese zu bereinigen, bis das NuGet-Problem erst letzte Nacht auf Framework-Assemblys behoben wurde. Ich habe es nur entfernt , um die Dinge zu klären.

@DamianEdwards Ich bin nicht zu 100 % bei der Schließung von netstandard2.0 , aber ich würde gerne (mit ihrer Erlaubnis) einen Portabilitätsanalyselauf durchführen und die Ergebnisse teilen. Ist Portability Analyzer noch aktuell und aktuell?

ASP.Net Core wird schnell zum neuen Python 3*; nur schlimmer. Das scheint mir ein Schritt in die falsche Richtung zu sein. Das bedeutet nur, dass eine Menge Szenarien Entwickler dazu zwingen werden, Code auf den „alten Plattformen“ für viele Jahre zu warten (und neuen zu schreiben), anstatt umzuziehen. "Schnellere Entwicklung" scheint kein sehr gutes Argument zu sein, wenn es nur bedeutet, dass Sie "schneller" an einen schlechteren/ungeeigneteren Ort gelangen.

*Ich mag Python 3, aber es ist fast ein Jahrzehnt her und die Python-Community ist immer noch zersplittert

Nur um es klar zu sagen - gibt es einen technischen Blocker (ausgefallenes Perf-Zeug) oder dient dies nur dazu, die Kosten für die Aufrechterhaltung der Kompatibilität in der Zukunft zu sparen?
Ich denke, die meisten von uns wussten, dass dieser Schritt kommen würde, aber niemand erwartete ihn so bald. Angesichts der Übergangszeit dauert es noch (wie Libs werden portiert, .net Standard 2.0 um die Ecke, aber es werden noch keine Libs dafür gebaut). - Es wäre großartig, den net*-Support für mindestens eine Version beizubehalten (z. B. 2.0, nicht 2.1).

@shanselman Ich verstehe deine Punkte und ich persönlich stimme sogar zu, aber _viele_ Leute werden es nicht so sehen.

Das Hauptproblem besteht nicht darin, net46-Assemblys vom Kern aus aufzurufen, die Compat-Shims befassen sich in den meisten Fällen damit. Das Problem ist vorhandener net46-Code und asp.net-Core-1.*-Code, der auf 46 läuft. Wie jemand erwähnte, bestand der ganze Sinn von netstandard darin, Code, einschließlich asp.net, überall laufen zu lassen, das wird sich wie ein Schritt anfühlen davon entfernt und für manche Menschen vielleicht sogar ein Scheitern dieser Vision.

Ich glaube nicht, dass das Problem darin besteht, dass die Leute nicht auf Net Core umsteigen _wollen_. Das Problem ist, dass Organisationen, Manager, CTOs und dergleichen davon überzeugt werden müssen, dass sich das Kosten-Nutzen-Verhältnis lohnt. Die Portierung ist nicht nur zeitaufwändig genug, um Lieferungen aufzufressen, sondern birgt auch das Risiko von Regressionen usw.

Mit anderen Worten, es sind nicht immer technische Gründe, die Menschen daran hindern, sich zu bewegen. Ich würde sogar sagen, dass es selten ist, _technisch_ kann fast jedes Projekt den Sprung schaffen. Aber diesen Kosten-/Lieferschein zu motivieren, das ist das Problem. Es kann ein sehr harter Verkauf sein, einer, den ich ein paar Mal machen musste. In diesen Fällen war es jedoch eine Möglichkeit, diesen Schritt voranzutreiben, wenn man sagen konnte: "Aber Sie können mit dem vollen Framework laufen".

Wenn du dich verletzen willst

Genau das ist es. Net46-Entwickler und -Management werden es nicht so sehen, sie werden es so sehen, als ob _Sie_, Microsoft, ihnen schaden wollen, um mit der neuesten Version Schritt zu halten. "Nun, bewegen Sie sich nicht", könnte man sagen, aber mit der Unterstützung von asp.net core 1.x, so kurz es auch ist, müssen sie es tun, zumindest aus der Perspektive von Managern, die dafür verantwortlich gemacht werden müssen, wenn a Fehler verursacht Ausfallzeit oder Informationsverlust. (auch wenn der Rahmen nicht verantwortlich ist)

Viele Entwickler, die wirklich auf asp.net Core 1.1 gedrängt haben, werden sich auch betrogen fühlen, dass sie jetzt ohne Core nicht auf 2.0 umsteigen können. Das mag gerechtfertigt sein oder auch nicht, aber ich sage Ihnen nur, viele Leute werden so denken, sie werden diejenigen sein, die sich vor ihren konservativeren Kollegen verantworten müssen

Spielt das eine Rolle? Wird asp.net core2/dotnet core2 deswegen „sterben“? Nein, aber es wird die Akzeptanz verlangsamen und das Ökosystem zerbrechen, und das ist imo wirklich traurig. Ich möchte, dass die Leute in der Lage sind, all diese großartigen Sachen zu nutzen, die in 2.0 kommen, und das Schneiden der Cross-Compilation auf den Netzstandard wird sich darauf auswirken. Sicherlich werden die meisten Leute, die in diesen Repos rumhängen, kein Problem haben, es sind die Entwickler von Joe und Jane und noch mehr ihr Manager, das ist das Problem.

@DamianEdwards
Ich stimme zu, dass dies eine Quelle der Verwirrung war, ich musste es viele Male erklären, aber das Ergebnis davon war immer, dass ein enttäuschter Entwickler ein aufgeregter wurde, weil sie dachten, sie könnten das neue coole Zeug nicht verwenden aber es stellte sich heraus, dass sie es konnten.

Zusammenfassend bin ich sicher, dass diese Entscheidung nicht leichtfertig getroffen wurde, aber wenn Sie dies tun müssen, müssen Sie meiner Meinung nach wirklich _wirklich_ vorsichtig mit dem Messaging sein. x auf net46 ist _super_ einfach und super ausgefeilt. Die Geschichte für die Referenzierung anderer Netstandard-Bibliotheken von net46 sowohl als Projektreferenzen als auch anderweitig muss felsenfest sein. Ich denke, Sie müssen dies explizit zeigen / ansprechen, um zu vermeiden, dass die Leute ausflippen

@khellang paging @terrajobst für die Portability Analyzer-Frage.

@hellang

Ja, wir haben gerade VSIX für 2017 aktualisiert, aber ich verwende einfach die Befehlszeilenversion von here .

@NickCraver Sicher, Sie können ein Stück Middleware schreiben, das auf netstandard abzielt, was nützt Ihnen das als Bibliotheksautor, wenn ASP.NET Core netcoreapp2.0 unterstützt.

@aL3891 tolle Zusammenfassung! Ein großes Problem, das wir in Zukunft haben, ist, wie wir neue APIs für Dinge nutzen, die auch im Netzstandard sind. .NET Core erhält neue APIs, die wir zum Implementieren neuer Funktionen benötigen (eine, die mir in den Sinn kommt, ist SSLStream ALPN-Unterstützung für HTTP2-Unterstützung in Kestrel). Man könnte also argumentieren, dass wir auf Netstandard bleiben und ständig die höchste Version verwenden (die .NET Framework noch nicht unterstützt), aber dann würden wir im selben Boot sitzen.

Ein großes Problem, das wir in Zukunft haben, ist, wie wir neue APIs für Dinge nutzen, die auch im Netzstandard sind. .NET Core erhält neue APIs, die wir zum Implementieren neuer Funktionen benötigen (eine, die mir in den Sinn kommt, ist SSLStream ALPN-Unterstützung für HTTP2-Unterstützung in Kestrel).

Laut https://github.com/dotnet/corefx/issues/4721 wird die ALPN-Unterstützung für SslStream nicht für .NET Core 2.0 bereit sein. Angenommen, dies wird schließlich einige Monate später implementiert, bedeutet das, dass man es verwenden kann, wenn man auf das netcoreapp2.0 TFM abzielt? Was passiert in diesem Fall, wenn ich mich entscheide, eine netcoreapp2.0 basierende Bibliothek zu veröffentlichen, die neue APIs verwendet, die nicht Teil der ursprünglichen netcoreapp2.0 -Form waren, wenn meine Benutzer eine ältere .NET Core-Laufzeit verwenden ? Wird es abstürzen? Oder wird netcoreapp2.x an netstandard1.x ausgerichtet, dessen Vertrag nicht geändert werden kann, ohne die TFM-Version zu erhöhen?

@davidfowl für andere Implementierungen von Teilen des Stacks und Tests. Und weil mit der Art und Weise, wie Abstraktionen (kein MVC erfordern) eine anständige Aufteilung zwischen 2 Bibliotheken sind, anstatt "anzunehmen, dass jeder MVC hat und alle Abhängigkeiten will".

Wenn die Abstraktionen eigentlich keine Abstraktionen sind und so eng mit ASP.NET Core selbst gekoppelt sind, warum entfernen wir diese Pakete dann nicht einfach? Es ist eine ehrliche Frage, denn das würde das Leben einfacher und klarer machen, wenn das das übergeordnete Ziel der Beziehung ist. Ich versuche zu verstehen, warum es Sinn macht, Abstraktionen als separate Pakete zu haben, wenn sie effektiv an eine einfache Implementierung/Verwendung gebunden sind. Ich würde behaupten, dass niemand außerhalb von Microsoft die Ressourcen haben möchte oder hat, um einem konkurrierenden netcoreapp2.x -Webserver zu widmen (gerne, dort korrigiert zu werden!).

Können Sie erklären, welchen Sinn die Abstraktionen in einer netcoreapp2.x -Welt haben würden? Oder ob es Pläne gibt, sie in 2.0 einfach abzuschaffen?

Laut dotnet/corefx#4721 wird die ALPN-Unterstützung für SslStream nicht für .NET Core 2.0 bereit sein. Angenommen, dies wird schließlich ein paar Monate später implementiert, bedeutet das, dass man es verwenden kann, wenn man auf die netcoreapp2.0-TFM abzielt? Was passiert in diesem Fall, wenn ich mich entscheide, eine netcoreapp2.0-basierte Bibliothek zu veröffentlichen, die neue APIs verwendet, die nicht Teil der ursprünglichen netcoreapp2.0-Form waren, wenn meine Benutzer eine ältere .NET Core-Laufzeit verwenden? Wird es abstürzen? Oder wird netcoreapp2.x an netstandard1.x angeglichen, dessen Vertrag nicht geändert werden kann, ohne die TFM-Version zu erhöhen?

ASP.NET Version x wird einfach an .NET Core Version x ausgerichtet. Das TFM wird aktualisiert, um es an jede Version von .NET Core anzupassen. Es ist ein einzelnes Produkt, das endlich als solches behandelt werden kann. Das ist eine der wichtigsten Vereinfachungen, die wir vornehmen, wie @DamianEdwards oben erwähnt hat. Wir werden Leute, die Bibliotheken erstellen, nicht unterbrechen, indem wir neue APIs im Kern hinzufügen, ohne das TFM zu ändern.

@ Nick Craver

für andere Implementierungen eines beliebigen Teils des Stapels und zum Testen.

Welche anderen Implementierungen? Gibt es andere Teile des Stacks, die ASP.NET Core implementieren?

Wenn die Abstraktionen eigentlich keine Abstraktionen sind und so eng mit ASP.NET Core selbst gekoppelt sind, warum entfernen wir diese Pakete dann nicht einfach? Es ist eine ehrliche Frage, denn das würde das Leben einfacher und klarer machen, wenn das das übergeordnete Ziel der Beziehung ist. Ich versuche zu verstehen, warum es Sinn macht, Abstraktionen als separate Pakete zu haben, wenn sie effektiv an eine einfache Implementierung/Verwendung gebunden sind. Ich würde postulieren, dass niemand außerhalb von Microsoft die Ressourcen haben möchte oder hat, um einem konkurrierenden netcoreapp2.x-Webserver zu widmen (glücklich, dort korrigiert zu werden!).

Können Sie erklären, welchen Sinn die Abstraktionen in einer netcoreapp2.x-Welt haben würden? Oder ob es Pläne gibt, sie in 2.0 einfach abzuschaffen?

Wir könnten alles in eine einzige Assembly packen, aber das Refactoring ermöglicht uns eine zukünftige Flexibilität, die wir sonst nicht hätten, wenn wir dies tun würden. Es eröffnet sogar die Möglichkeit, andere Implementierungen zu haben, und schließt dies langfristig nicht wirklich aus.

Einfach ausgedrückt geht es bei Abstraktionen darum, die Anzahl der Abhängigkeiten zu verringern, nicht um Plattformportabilität.

Wir werden Leute, die Bibliotheken erstellen, nicht unterbrechen, indem wir neue APIs im Kern hinzufügen, ohne das TFM zu ändern.

Sie sagten, dass Sie sich für netcoreapp2.0 entscheiden wollten – nur weil es sich schneller bewegte – im Vergleich zu .NET Desktop und damit zu .NET Standard – aber was bringt es, statt auf netcoreapp2.0 zu zielen netstandard2.0 wenn Sie nicht von den neuen .NET Core-APIs profitieren können, ohne das TFM zu ändern? (zB netcoreapp2.1 )

Sie sagten, dass Sie sich für netcoreapp2.0-only entscheiden wollten, da es sich schneller bewegte - im Vergleich zu .NET Desktop und damit zu .NET Standard -, aber was bringt es, netcoreapp2.0 anstelle von netstandard2.0 ins Visier zu nehmen, wenn Sie können Sie können nicht von neuen .NET Core-APIs profitieren, ohne das TFM zu ändern? (zB netcoreapp2.1)

Tut mir leid, ich habe mich falsch ausgedrückt, ich meine netcoreapp2.x nicht netcoreapp2.0 .

Okay, ich bin jetzt total verwirrt.

Entschuldigung, ich habe mich falsch ausgedrückt, ich meine netcoreapp2.x, nicht netcoreapp2.0.

Ich bin mir nicht sicher ob ich das verstehe. Meinen Sie damit, dass es eine Äquivalenz zwischen den ASP.NET Core 2.1-Paketen und dem netcoreapp2.1 TFM geben wird?

Meinen Sie damit, dass es eine Äquivalenz zwischen den ASP.NET Core 2.1-Paketen und dem netcoreapp2.1-TFM geben wird?

Ja. Stellen Sie sich die 2 als ein und dasselbe vor. Siehe https://github.com/aspnet/Home/issues/2022#issuecomment -299544884

Was hindert Sie also daran, ein ähnliches Muster anzunehmen, aber mit netstandard ? Meiner Meinung nach wäre dies der beste Ansatz: Neue APIs könnten über neue TFMs übernommen werden, und Personen, die .NET Desktop unterstützen müssen, könnten ihre ASP.NET Core-Apps weiterhin auf dem vollständigen Framework ausführen.

ASP.NET Core 2.1/.NET Core 2.1/.NET Desktop 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET Desktop 4.8 -> netstandard2.2 .

@PinpointTownes, da .NET Framework auf dem Desktop nicht schnell genug ausgeliefert werden kann, ist dies der Kern der meisten Versionsprobleme mit Core. Es ist ein schwieriges Problem in einer riesigen Kette.

.NET Standard bewegt sich nicht mit der gleichen Geschwindigkeit wie .NET Core. In Wirklichkeit nicht annähernd so weit. Eine Verschiebung in .NET Standard lässt im Wesentlichen alle Plattformen hinter sich, bis sie aufholen, und .NET Framework ist sowohl die langsamste als auch die größte.

Point Token, obwohl ich nicht sicher bin, wie schnell .NET Framework ausgeliefert werden soll (z. B. wurden die neuen ECDSA-APIs in weniger als einem Jahr von CoreFX auf NetFX portiert, was für solch sensible Kryptokomponenten ein angemessener Zeitrahmen zu sein scheint ).

Cross-Compiling ist ein Mehraufwand, der mit den Kunden- und Produktanforderungen in Einklang gebracht werden muss.

Wenn Sie eine Minute Zeit haben, würde ich gerne mehr über die genaue Art des Overheads erfahren, der durch die Cross-Kompilierung verursacht wird. Danke.

Was wir von Ihnen allen brauchen, ist eine klare Liste/ein Verständnis dafür, WARUM Sie denken, dass Sie ASP.NET Core 2.0 benötigen, um auf net461+ zu laufen. Seien Sie spezifisch, damit wir diese Lücken schließen und alle erfolgreich sein lassen können.

Im Moment benötigen wir die Fullframework-Version der WCF-Clientbibliotheken, da die netstandard / netcore -Versionen (https://github.com/dotnet/wcf) noch nicht annähernd vollständig sind.

Wenn Sie eine Minute Zeit haben, würde ich gerne mehr über die genaue Art des Overheads erfahren, der durch die Cross-Kompilierung verursacht wird. Danke.

In sehr naher Zukunft wird es eine Zeit geben, in der wir Funktionen wie die ALPN-Unterstützung für SSLStream buchstäblich nicht mehr ausfüllen können. Außerdem haben wir noch nicht einmal damit begonnen, unsere Beine zu vertreten und APIs in .NET Core hinzuzufügen, bisher waren wir damit beschäftigt, Dinge zurück zu .NET Standard und .NET Core 2.0 (dem gesamten Zweck von .NET Standard 2.0) zu portieren. . Wir werden neue APIs hinzufügen und sie schließlich am ersten Tag in ASP.NET Core nutzen.

Im Moment benötigen wir die Fullframework-Version der WCF-Client-Bibliotheken - da die netstandard / netcore-Versionen (https://github.com/dotnet/wcf) nicht annähernd vollständig sind.

@ctolkien Das ist ein Problem und der Grund, warum wir den WCF-Client überhaupt portiert haben. Weißt du, was dich blockiert? Dies ist eine gute Gelegenheit, uns bei der Priorisierung zu helfen.

@davidfowl https://github.com/dotnet/wcf/issues/8

Es könnte noch mehr geben, dies war nur die erste Hürde, die wir vor dem Übergang zum Full Framework wcf genommen haben.

In sehr naher Zukunft wird es eine Zeit geben, in der wir Funktionen wie die ALPN-Unterstützung für SSLStream buchstäblich nicht mehr ausfüllen können.

Wie ist das ein Problem? AFAICT, nein hier hat jemals gesagt, dass die .NET Desktop- und .NET Core-Varianten von ASP.NET Core exakt denselben Funktionssatz unterstützen müssen. Wenn eine Funktion auf .NET Desktop aufgrund fehlender APIs (z. B. HTTP 2/0) nicht verfügbar ist, warum machen Sie sie nicht nur auf .NET Core und werfen ein PlatformNotSupportedException aus, das dem Entwickler mitteilt, dass die Funktion, nach der er sucht, vorhanden ist Nicht verfügbar?
Es wäre viel besser, als alle ASP.NET Core-Pakete nur für .NET Core zu machen, auch wenn die meisten von ihnen wahrscheinlich keine neuen BCL-APIs verwenden werden.

@davidfowl Ich denke, eine große Angst ist, dass die Dinge nicht in netcoreapp2.3 behoben werden, sondern in netcoreapp2.4 . Wenn sich ASP.NET Core auf den schnellsten Zug konzentriert, wie lange dann mit jeder Nebenversion Liebe? Wenn wir ständig aufrüsten müssen, muss jeder Verbraucher ständig aufrüsten.

Das ist großartig, um das Neueste und Beste zu bekommen, aber es ist nicht das Beste für die meisten Unternehmen. Daher müssen wir entweder viele Versionen (jede Nebenversion) mit unseren Bibliotheken für jeden Verbraucher von ASP.NET Core verwalten (um nicht auf die neueste Version angewiesen zu sein und Schritt zu halten) oder Benutzer auf die neueste Version ziehen, um Schritt zu halten. Dies ist nicht freundlich zu Dingen wie einer validierten Umgebung.

Wenn die Abstraktionen nicht so schnell drehen müssen (Beispiele?), Wäre es vorzuziehen, sie getrennt zu haben. Auf diese Weise ziehen Sie nicht bei jedem Upgrade das gesamte Ökosystem mit. Ich denke, ich mache mir mehr Sorgen, nicht dass sie auf netcoreapp sind, sondern dass sie ständig aktualisiert werden und alles eng miteinander verbunden ist.

Wenn die Abstraktionen jede kleinere Version beibehalten und den Schmerz (um ehrlich zu sein) auf Ihre Seite verlagern, mache ich mir viel weniger Sorgen. Könnt ihr die Absichten mit Überarbeitungen hier näher erläutern?

@PinpointTownes :

warum nicht nur .NET Core verwenden und eine PlatformNotSupportedException auslösen, die dem Entwickler mitteilt, dass das gesuchte Feature nicht verfügbar ist?
Es wäre viel besser, als alle ASP.NET Core-Pakete nur für .NET Core zu machen, auch wenn die meisten von ihnen wahrscheinlich keine neuen BCL-APIs verwenden werden.

Neinoooooo, bitte nicht. Das ist ein Laufzeitfehler und ein sehr unerwünschtes Verhalten. Wir möchten so viele Zusicherungen zur Kompilierzeit haben, dass unsere Bibliotheken wie möglich funktionieren. Es gab viele Debatten darüber, das ist einfach kein guter Weg. PlatformNotSupported sollte so weit wie möglich vermieden werden.

Das ist ein Laufzeitfehler und ein sehr unerwünschtes Verhalten.

Genau das passiert mit dem Ansatz „Bringen Sie Ihre .NET Desktop-Assemblys auf .NET Core“, wenn Ihre Assemblys versuchen, eine nicht unterstützte API zu verwenden, außer dass Sie ein MissingMemberException anstelle von PlatformNotSupportedException erhalten

Mit meinem Ansatz könnten Sie zumindest eine bessere Tooling-Story mit Dingen wie Roslyn-Analysatoren definieren, die zur Kompilierzeit feststellen könnten, ob die von Ihnen verwendeten APIs unterstützt werden oder nicht.

Und übrigens, ein PlatformNotSupported zu werfen, wäre wirklich ein Eckfall. Bei der Cross-Kompilierung wäre die beste Option, die nicht unterstützten APIs einfach aus dem öffentlichen Vertrag auszuschließen.

@PinpointTownes Das dachte ich auch, aber die Realität ist, dass neue Plattformen ausgeliefert werden und es einfach nicht so einfach ist. Nachdem ich das viele Male diskutiert habe, hat sich meine Meinung darüber, wie man hier Kompatibilität macht, stark geändert. Wenn Sie sich für die Richtung netcoreapp entscheiden, können Fixes in Nebenversionen ausgeliefert werden. Wenn Sie in die andere Richtung gehen, müssen Sie auf .NET Desktop warten, um Fixes zu liefern, was … viel Glück. Das ist ein sehr langsames Vehikel für Vorsätze.

AFAICT, nein hier hat jemals gesagt, dass die .NET Desktop- und .NET Core-Varianten von ASP.NET Core exakt denselben Funktionssatz unterstützen müssen. Wenn eine Funktion auf .NET Desktop aufgrund fehlender APIs (z. B. HTTP 2/0) nicht verfügbar ist, warum machen Sie sie nicht nur auf .NET Core

Die erste Hälfte davon ist netstandard . Die Differenzierung zu netcoreapp ist genau das, was sie hier tun. Ohne die gewollten Ausnahmen. Es ist ein richtiger Vertrag auf dieser Route.

Sie wollen in die Richtung dessen gehen, was schneller behoben und verbessert werden kann, wenn es um Lücken geht, nicht umgekehrt. „PlatformNotSupported“-Ausnahmen können morgen in der Bibliothek behoben werden, anstatt darauf zu warten, dass die Plattform in 3 Monaten aktualisiert wird. .NET Core kann sie schneller unterstützen, da der eigentliche Code damit geliefert wird und die meiste Zeit nicht separat als Weiterleitungen.

[@PinpointTownes] Wenn eine Funktion auf .NET Desktop aufgrund fehlender APIs (z. B. HTTP 2/0) nicht verfügbar ist, warum machen Sie sie nicht nur auf .NET Core und werfen ein PlatformNotSupportedException aus, das dem Entwickler mitteilt, dass die Funktion vorhanden ist er sucht ist nicht verfügbar?

Wir müssen die Einfachheit der API-Oberfläche und -Reichweite mit der Entwicklerproduktivität in Einklang bringen. Bisher haben wir hauptsächlich PlatformNotSupportedException verwendet, um eine API-Oberfläche bereitzustellen, die mit der Vergangenheit kompatibel ist. Wir beabsichtigen nicht, PlatformNotSupportedException zu verwenden, um in Zukunft disjunkte Feature-Sets bereitzustellen. Stattdessen stellen wir entweder die Unterstützung für Versionen der .NET-Plattformen ein, die nicht über die Funktionen verfügen, oder stellen die Funktion als unabhängiges NuGet-Paket bereit, das selbst nicht überall unterstützt wird.

Wenn Sie sich an die netcoreapp-Richtung halten, können Fixes in Nebenversionen ausgeliefert werden.

Wie unterscheidet sich das vom 1.0-Ansatz? @davidfowl sagte, dass neue APIs neue TFMs erfordern würden, was bedeutet, dass Sie sich von LTS abmelden müssen, um Korrekturen zu erhalten, die auf neuen .NET Core-APIs basieren. Keine wirklich ideale Situation.

Die Differenzierung zu netcoreapp ist genau das, was sie hier tun.

Differenzieren ist völlig in Ordnung, und ich stimme definitiv zu, dass .NET Core das bevorzugte Ziel für ASP.NET Core sein sollte. Das bedeutet jedoch nicht, dass .NET Desktop vollständig aufgegeben werden muss, insbesondere wenn Alternativen wie die Cross-Kompilierung vorhanden sind.

Wir müssen die Einfachheit der API-Oberfläche und -Reichweite mit der Entwicklerproduktivität in Einklang bringen.

Sicher. Sie müssen dies jedoch auch mit der Tatsache in Einklang bringen, dass Legacy-Bibliotheken – die für .NET Desktop entwickelt wurden und Funktionen verwenden, die in .NET Core nicht verfügbar sind – in ASP.NET Core 2.0 genauso gut funktionieren sollten wie in 1.0.

Stattdessen stellen wir entweder die Unterstützung für Versionen der .NET-Plattformen ein, die nicht über die Funktionen verfügen, oder stellen die Funktion als unabhängiges NuGet-Paket bereit, das selbst nicht überall unterstützt wird.

Das ist theoretisch völlig in Ordnung. Aber die Plattform, der derzeit wichtige Funktionen fehlen, ist .NET Core, nicht .NET Desktop. Dies wird sich wahrscheinlich in ein paar Jahren ändern, aber sicher ist, dass die Leute immer noch fehlende Funktionen in .NET Core 2.0 finden werden.

Könnte es sich lohnen, ein forward-port Repo in dotnet zu haben, wo Leute API-Anfragen für bestimmte Elemente stellen können, die ihrer Meinung nach in .NET Core von .NET Framework fehlen?

Dann können Feedback, Überprüfungen und Anleitungen außerhalb des alltäglichen Lärms der Code-Repos erfolgen? Oder ein allgemeines API-Review / Spec-Repo (ähnlich wie csharplang vs roslyn)

Auch eine gute Wahl für: "Ich habe ein Konvertierungsproblem und muss nach einem Problem im Zusammenhang mit X api suchen", während corefx dafür sehr laut ist.

[@benaadams] Könnte es sich lohnen, ein Forward-Port-Repository in dotnet zu haben, wo Benutzer API-Anfragen für bestimmte Elemente stellen können, die ihrer Meinung nach in .NET Core von .NET Framework fehlen?

Ich würde sagen, das sind einfach Probleme in CoreFx. Unser allgemeines Versprechen lautet außerdem: Wenn der Typ von .NET Framework und .NET Core gemeinsam genutzt wird, beabsichtigen wir, neu hinzugefügte Member nach .NET Framework zu portieren. In sehr seltenen Fällen ist dies möglicherweise nicht möglich, aber der Grundstein liegt darin, dass sie automatisch berücksichtigt werden.

[@benaadams] Oder ein allgemeines API-Review/Spec-Repo

Ich bin mir nicht sicher, ob es das wert ist. API-Überprüfungen sind bereits etwas schwerfällig; Das Extrahieren in ein anderes Repo scheint dies zu verstärken. Ich würde es vorziehen, CoreFx weiter zu rationalisieren, damit das Hinzufügen neuer APIs so einfach ist wie beispielsweise in ASP.NET.

Wie bereits erwähnt, können sie weiterhin auf Bibliotheken/Frameworks verweisen, die auf .NET Framework abzielen, und das wird gut funktionieren, vorausgesetzt, die von ihnen aufgerufenen APIs sind Teil der Schließung von netstandard2.0

@DamianEdwards Was ist mit den APIs, die nicht in der Schließung von netstandard2.0 enthalten sind? Die meisten Bibliotheken von Drittanbietern sind Closed Source. Woran erkenne ich, dass sich jeder Grenzfall in der Schließung von netstandard2.0 befindet?
Wie @PinpointTownes angedeutet hat, ist dies ein bisschen so, als würde man russisches Roulette spielen.

@MJomaa- Tools werden hier helfen, aber offensichtlich ist der einzige Weg, dies mit Sicherheit zu wissen, die tatsächliche Ausführung. Das unterscheidet sich eigentlich nicht von einer .NET Standard-Bibliothek, die auf einem von .NET Standard unterstützten Framework ausgeführt wird. Die vorhandenen APIs ersetzen nicht die Notwendigkeit, diese Bibliotheken zu testen. Das soll nicht heißen, dass Netstandard -Implementierungen nicht darauf abzielen, kompatibel zu sein, aber sie sind Edges, z

Dies sind APIs, die in NS 2.0, aber nicht in .NET Framework 4.6.1 vorhanden sind.

Ich wurde sehr nervös wegen dieser Änderung, aber nachdem ich den Thread gelesen habe, scheint es theoretisch in Ordnung zu sein. Wir haben 5 ASP.NET Core-Apps, davon 4 im vollständigen Framework, aber das lag hauptsächlich daran, dass wir vor allem defensiv waren und den Weg des geringsten Widerstands gingen.

Ich denke, eine Art von Tooling, das in VS integriert ist, wie der .NET Core Portability Analyzer, könnte den Entwicklern helfen, die auf Twitter/GitHub nicht auf dem neuesten Stand sind und nicht wissen, dass diese Erweiterung überhaupt existiert. Das Popup "Erweiterung vorschlagen" kommt mir in den Sinn, aber ich bin mir nicht sicher, welche Maßnahmen eine Person ergreifen würde, um dies auszulösen. Versuchen Sie vielleicht, einer ASP.NET Core 2+-App eine net46x-Bibliothek hinzuzufügen?

Dinge, die Microsoft nicht kontrollieren kann, wie der Support von Drittanbietern mit Telerik, Syncfusion usw., werden ebenfalls ein potenzieller Blocker sein, je nachdem, was sie tun.

Die Nachrichten in diesem GitHub-Thread müssen so schnell wie möglich in einen Blog-Beitrag mit einer FAQ oder ähnlichem aufgenommen werden. Ich habe das Gefühl, dass ich den Überblick über alles behalten habe, und ich war mir immer noch nicht 100% sicher, ob dies bedeutet, dass wir auf net46x-Bibliotheken verweisen können oder nicht. Ich war offensichtlich auch nicht der Einzige, der davon verwirrt war.

Um zu wiederholen, was andere gesagt haben. Ich habe mit mindestens 10 Entwicklern gesprochen, die nicht wussten, dass ASP.NET Core auf dem vollständigen Framework ausgeführt werden kann. Ich hatte die gleiche Erfahrung wie @aL3891, obwohl die Entwickler wirklich glücklich waren, dass sie ASP.NET Core auf dem vollständigen Framework ausführen konnten und ihre internen Bibliotheken einfach funktionierten. Nochmals: Die Botschaft, dass .NET Core 2.0 eine große Mehrheit von Anwendungsfällen hat, wird sehr, sehr wichtig sein. Der Artikel darüber, dass mindestens eine reine Windows-Lösung für ähnliche System.DirectoryServices in Arbeit ist, wird ebenfalls wichtig sein. Viele NET-Entwickler, mit denen ich spreche, zucken mit den Schultern, wenn sie hören, dass .NET Core plattformübergreifend ist, und kümmern sich mehr um das Funktionieren ihres vorhandenen Codes als um x-plat/perf.

Leute, das ist Müll :(
Wir haben auf ASP.NET Core aufgebaut, weil es die Möglichkeit gibt, es mit netfx zu verwenden, und wir haben Dinge gebaut, die für 5-10 Jahre gedacht waren, nicht für maximal 1 Jahr Support. Das ist die Bedeutung des Namens ASP.NET im Geschäftsleben, und das ist der Grund, warum große, sich langsam entwickelnde Organisationen es gegenüber den Flavor-of-the-Month-Frameworks wählen. Lassen Sie mich zu den konkreten Anwendungsfällen übergehen.

Ich arbeite in einer Tooling-Gruppe, die Branchenbibliotheken und Anwendungen zur internen Verwendung in einem Unternehmen und zum Verkauf an „Unternehmens“-Kunden erstellt. In unserem Fall hauptsächlich Regierungsorganisationen, aber ich bin sicher, dass Sie dasselbe aus dem Privatsektor hören werden. Wir haben interne Frameworks, die Geschäftsmuster in gemeinsame Abstraktionen codieren – denken Sie an „IDatabaseConnection“, „IEntityProvider“, „IWizardFlow“, „ICodeGenerator“ – und bauen RAD-Frontends auf diesen austauschbaren Backends auf.

In unserem Stack ist ASP.NET Core ein „Plugin“ – es ist ein HTTP-Ziel, das als Datenspeicherabstraktion und zum Hosten von Diensten usw. verwendet wird. Es ist auch ein "Frontend" - offensichtlich sind viele der LOB-Apps da draußen Websites, und es ist ein großartiges neues Framework für Webapps. Wir haben also bidirektionale Interoperabilitätsanforderungen - AN-C-Code, der auf zufällige andere Komponenten verweist, und zufälliger anderer Code, der auf AN-C verweist.

Wir sind absolute Fans von Core CLR und Portabilität, und wir haben eine Reihe unserer Komponenten auf Ziel- oder Multiziel-Netzstandard portiert. Wir haben bisher eine App, die auf Linux gehostet wird, und hoffen, dass weitere folgen werden. Es gibt jedoch keine Möglichkeit, dass in absehbarer Zeit alles portiert wird! Wir haben immer noch aktiven, aktiv entwickelten Code, der sich darauf stützt

• NTLM-Authentifizierung (einschließlich erweiterter Szenarien rund um Token und SPNs)
• System.Drawing wie oben (interessante Falte hier: wir brauchen alte Bildformate wie TIFF, die neue OSS-Bibliotheken nicht unterstützen)
• Verbindung zu WCF/SOAP-APIs - immer noch tonnenweise davon da draußen
• Windows-Krypto-APIs (einschließlich RSACng, ECDSA und CSP für PKI-Token)
• WPF-Guis – unsere Kunden wechseln in absehbarer Zeit nicht zu Windows 10, und selbst wenn sie dies tun, möchten sie keine Store-Apps
• Microsoft Office Interop (insbesondere Access und Excel) für Datenimport und -export
• Visual Studio-Erweiterbarkeit
• Plugins von Drittanbietern wie der Oracle ADO.NET-Anbieter

Einige dieser Technologien werden niemals von Core CLR unterstützt. Aber es sind echte Technologien, die die Grundlage für die Entwicklung neuer Apps bilden – wir brauchen eine Version von .NET, die Zugriff auf dieses Zeug hat. Im Moment ist unsere Position überschaubar: Wir isolieren "alte" (eigentlich: plattformspezifische) Abhängigkeiten in ihre eigenen Komponenten, die net461-spezifisch sind. Bestimmte Business-Apps nehmen dann eine Abhängigkeit von netfx an, wenn sie diese Funktionen benötigen, und nicht anders. Ich stelle mir eine Zukunft vor, in der dies für neue Apps selten ist, aber es ist schwer vorstellbar, dass es jemals 0 % sein wird.

Sie haben all diese Arbeit an csproj und dem SDK geleistet, weil Interop wichtig ist. ASP.NET Core ist das Zuckerbrot, der Grund für Interop. Wegnehmen halte ich nicht für sinnvoll. Und nein, "Sie können Ihre Referenzen in eine Richtung laden, aber sie werden wahrscheinlich zur Laufzeit fehlschlagen" ist keine Interoperabilität.

@gulbanana Können Sie die Teile des Systems beschreiben, die ASP.NET Core verwenden, warum sie sich im selben Prozess wie .NET Framework befinden müssen. Ich schätze die Liste (Visual Studio-Plug-ins, Office-Interop usw.), aber ist ASP.NET Core heute an all diesen Stellen eingebettet (ich habe kein gutes Bild aus der obigen Beschreibung)?

Was haben Sie auch verwendet, bevor ASP.NET Core existierte? Oder ist dies nur ein neues Unterfangen, das ASP.NET nie verwendet hat, aber eine 5-10-jährige Wette darauf eingegangen ist, dass ASP.NET Core auf .NET Framework eine Sache ist? Hast du dir Katana angeschaut?

OK, hier sind einige konkrete Fallstudien. Ich sage gleich vorweg, dass ich sicher bin, dass viele davon durch Ausführen der Desktop-spezifischen Arbeit in einem separaten Prozess gehandhabt werden könnten , obwohl es wie ein großer Aufwand erscheint, eine Reihe von Schnittstellenimplementierungen im Grunde in RPC umzuwandeln. Es ist auch nicht so, dass wir einfach Remoting oder binäre Serialisierung zwischen Kern- und Desktop-CLRs verwenden können.

NTLM/AD

Für Single-Sign-On-Zwecke haben wir Apps, die darauf angewiesen sind, dass der Browser Windows-Anmeldedaten an IIS weiterleitet, der sie an eine ASP.NET Core-Website weiterleitet. Ein Teil des Authentifizierungsprozesses besteht dann darin, nach Informationen zu suchen, z. B. ob der Benutzer einer bestimmten AD-Gruppe angehört. Ich würde wirklich gerne mehr über das "Windows Support Pack" erfahren und ob es solche Dinge abdecken soll.

System.Zeichnung

Dies wird in einer Webanwendung verwendet, die Miniaturansichten und grundlegende Bildbearbeitungen (Rotation, Wasserzeichenüberlagerung) erstellt. Viele der verwendeten Bilder stammen aus der Zeit der Dinosaurier, also gibt es Dinge wie TIFF darin. Es handelt sich um Daten, die von einer Regierungsbehörde verwaltet werden und sich auf bestimmte Immobilienangebote und Landmanagement beziehen. In diesem Fall war die Anwendung ursprünglich ASP.NET MVC und wurde durch MVC 2, 4, 5 und jetzt Core aktualisiert/umgeschrieben.

VSIX

Dies ist ein Fall der Einbettung von AN-C in netfx und nicht umgekehrt. Wir haben Visual Studio-Erweiterungen für die Codegenerierung, die „Vorlagen“ für verschiedene RAD-Szenarien ausführen. Einige dieser Vorlagen wurden für die Webentwicklung erstellt und beziehen sich zur Entwurfszeit auf AN-C-Typen (sie werden mit Präprozessor/Laufzeit T4 erstellt).

Krypto

Dieser muss meiner Meinung nach wirklich in-proc sein - wir haben Lizenzierungsszenarien, in denen der Code sehr sicherheitsrelevant ist. Im Großen und Ganzen entschlüsselt und verifiziert es Lizenzdateien in Bezug auf die Umgebung, in der der Code ausgeführt wird – dies ist eine gängige Bibliothek, die im Backend von Webapps sowie Desktop-Apps verwendet wird. Irgendwann scheint .NET Core wahrscheinlich genug Krypto-Unterstützung zu bekommen, dass dieser portiert werden kann, aber das ist heute nicht der Fall. Eine Option, die wir heute zum Beispiel haben, ist Fortinet/ePass2003 PKI-Token-Unterstützung, wo ihre Middleware Core definitiv nicht unterstützt (und es gibt keinen Zeitrahmen dafür).

Oracle ADO.NET

Die Verwendung von Entity Framework 6 mit einem Oracle-Back-End muss nicht prozessintern sein, aber es wäre sicherlich unpraktisch für unsere Websites, eine zusätzliche Ebene hinzuzufügen, nur um zu einer Datenbank zu gelangen!

WPF-Interop

Heutzutage verwenden wir Microsoft.Extensions.Logging in all unseren Desktop-Anwendungen – die Protokollierungsabstraktionen selbst müssen prozessintern sein, auch wenn Implementierungen dies nicht sind.

Was wir vor ASP.NET Core verwendet haben – ASP.NET MVC! Wir könnten zurückkehren, aber es wäre eine große Schande, auf alle Vorteile zu verzichten.

Als Architekt ist es mein Fehler, nicht untersucht zu haben, ob „ASP.NET Core wird auf dem vollständigen Framework ausgeführt“ über die erste Version hinaus bestehen bleiben würde. Es ist mir ehrlich gesagt nie in den Sinn gekommen, dass dies nicht der Fall wäre. Ich hätte einfach nicht gedacht, dass es schon 2018 zB keine unterstützte Version geben könnte, die Office-Dokumente laden könnte ...

Eine Sache, die mir nicht klar ist, ist, wo ASP.NET Core in jedem der von Ihnen erwähnten Szenarien verwendet wird.

NTLM/AD

Dieser macht Sinn und ich würde gerne verstehen, auf welche APIs das am Ende abgebildet wird. Ist das nur System.DirectoryServices? Daran wird aktiv gearbeitet (Sie können es in Corefx sehen).

System.Zeichnung

Dies ist eine bekannte Lücke, die wir angehen wollen. Ich habe hier noch keine Antworten und werde kein Umschreiben mit ImageSharp vorschlagen (obwohl dies eine Option ist). Dies muss angegangen werden.

VSIX

Wo ist hier der ASP.NET Core? Läuft es innerhalb einer Visual Studio-Erweiterung?

Krypto

Gibt es ein Corefx-Problem für diesen? Warum wird es nicht einfach portiert? Im Gegensatz zu .NET Framework sind .NET Core-Releases vom Betriebssystem entkoppelt, sodass dies eher früher als später passieren könnte, wenn es als wichtig erachtet wird. (Haftungsausschluss: Ich weiß nicht genug über Krypto, um die Auswirkungen dieser plattformübergreifenden Ausführung zu verstehen).

Oracle ADO.NET

Wo kommt hier ASP.NET Core ins Spiel? Wollen Sie damit nur sagen, dass der Oracle-Anbieter noch nicht auf .NET Core portiert wurde?

Heutzutage verwenden wir Microsoft.Extensions.Logging in all unseren Desktop-Anwendungen – die Protokollierungsabstraktionen selbst müssen prozessintern sein, auch wenn Implementierungen dies nicht sind.

Microsoft.Extensions.* bleibt netstandard, sodass Sie dort abgedeckt sind.

Warum keine Ankündigung/Diskussion?
Ich liebe, was das Kernteam von aspnet/.net tut, aber ich habe die gleichen Befürchtungen wie @jhurdlow.

Freut mich, von MEL zu hören. Zu den anderen Punkten -

NTLM

Hier ist eine Klasse, die in den meisten unserer Anwendungen verwendet wird. Es nutzt die API ziemlich trivial, Dinge, die hoffentlich theoretisch portiert werden könnten (aber nicht).
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

Die für den asp.net-Kern spezifischen Codegen-Vorlagen verwenden das Aktions-/Routingsystem (IFileProvider usw.), um Controller und Ansichten usw. zu erkennen und unser Gerüst auszufüllen. Wir hosten keinen ASP.NET-Webhost innerhalb von Visual Studio, sondern prüfen nur ASP.NET-Anwendungen.

Krypto

Ich vermute, dass die von uns verwendeten Algorithmen portiert werden , aber das ist noch nicht geschehen. Dies würde alles ganz anders aussehen, wenn die Prämisse eine Ankündigung eines langfristigen Plans wäre, die Unterstützung für asp.net-core-on-netfx einzustellen, und eine Diskussion darüber, wann dies möglich sein könnte!

Orakel

Ja, dies würde behoben werden, wenn ein Oracle-Port passiert (vorausgesetzt, er ist voll funktionsfähig und so weiter).

Noch ein Anwendungsfall:
Eine unserer Anwendungen importiert Altdaten aus einer Access-Anwendung. Im Moment läuft dieser Importprozess auf einem Server in einer asp.net-Core-Website. Es verwendet COM-Interop, um acedao.dll aus der weiterverteilbaren accdb/jet-Engine zu laden, liest Tabellen in unsere Entity-Abstraktionen und speichert sie dann in einer moderneren SQL-Datenbank.

Dies ist ein weiterer Fall von 'könnte außerhalb des Prozesses sein, aber warum sollte es sein'. Wir würden AN-C im Wesentlichen als Frontend für eine WebAPI 2-Website oder so etwas verwenden, in diesem Fall sind wir zu dieser Abhängigkeit von der Vergangenheit zurückgekehrt :(

Insgesamt ist es unser Ziel, den Großteil unserer Arbeit auf .NET Core zu verlagern. Wir möchten so viel Interop wie möglich und so lange wie möglich, während wir die Dinge verschieben ...

WTF!!! 😨
Wollen Sie damit sagen, dass ASP.NET Core 2 nicht mehr auf Full .NET Framework 4.x abzielt !!!
Wir haben gerade vor einem Monat ein Projekt mit ASP.NET Core 1.1 gestartet und uns auf .NET 4.6 konzentriert, weil wir auf einige vollständige .NET-Bibliotheken verweisen. Und wir wollten auf ASP.NET Core 2 upgraden. Aber was ich aus diesem Beitrag höre ... 😞
Sehen Sie, wir haben ASP.NET Core aufgrund seiner Vorteile ausgewählt (DI, zusammengeführte API und MVC, ... leistungsstark), also geben Sie bitte als Wechselmann an.

Wir haben gerade vor einem Monat ein Projekt mit ASP.NET Core 1.1 gestartet und uns auf .NET 4.6 konzentriert, weil wir auf einige vollständige .NET-Bibliotheken verweisen

Was machen diese Bibliotheken? Haben Sie die erste Antwort von @shanselman https://github.com/aspnet/Home/issues/2022#issuecomment -299536123 gelesen? Es ist möglich, auf einige .NET Framework-Bibliotheken in .NET Core 2.0 zu verweisen (vorausgesetzt, sie bleiben innerhalb der Teilmenge von APIs).

Was machen diese Bibliotheken? Haben Sie die erste Antwort von @shanselman #2022 (Kommentar) gelesen? Es ist möglich, auf einige .NET Framework-Bibliotheken in .NET Core 2.0 zu verweisen (vorausgesetzt, sie bleiben innerhalb der Teilmenge von APIs).

@davidfowl Ja, ich habe den Kommentar von @shanselman gelesen, wir verwenden einige Libs der Firma, einige dieser Libs verwenden WCF, alle diese Libs sind stabil, sie zielen auf .NET 3.5 ab, und wir können sie nicht anfassen.

Dies wird eine sehr häufige Situation sein. Ich würde gerne wissen, ob Informationen (Telemetrie?) darüber gesammelt wurden, wie viele Benutzer von ASP.NET Core bisher .NET Core im Vergleich zu .NET Framework verwenden.

Ich persönlich bin darüber nicht emotional, aber einige Beobachtungen:

• Die meisten Kunden, die ich heute habe, verwenden die Kombination asp.net core 1.x/full framework, weil sie Angst davor haben, all-in auf die neuen Sachen zu gehen
• Wie aus den Download-Zahlen des Nuget-Pakets hervorgeht, ist die Akzeptanz des asp.net-Kerns nicht großartig. Mit diesem Schritt wird es noch ein bisschen schwieriger, etwas zu verkaufen, das sich derzeit nicht gut verkauft.
• Es ist großartig, dass Sie das LDAP-Zeug als Lücke identifiziert haben (ich glaube, ich habe in den letzten 10 Jahren nie jemanden gesehen, der diese Bibliotheken verwendet, aber vielleicht bin ich das nur). Das größere Problem werden Bibliotheken von Drittanbietern sein. Dies werden die wahren Gründe sein, warum die Leute nicht zu .net Core wechseln werden

Diese ganze Situation ist wieder ein weiteres gutes Beispiel dafür, dass MS einfach eine Entscheidung ohne Vorankündigung trifft. Nur weil einige Leute den Check-Ins folgen, existiert dieser Thread hier.

Ich könnte mich irren, aber ich dachte, .NET Core steht jetzt unter der Verwaltung des DNF - diese Entscheidungen sind also nicht mehr rein MS-intern.

Das LDAP/AD-Zeug ist definitiv ein Grund, warum ich gerade jetzt bei net462 auf dem Laufenden bleiben muss. Ich würde gerne komplett gehen, BAM -> NetCore komplett, aber das ist ein Manko.

Ich verwende auch XML-RPC.net in einem meiner Projekte. Es verwendet ernsthaftes Reflection.Emit darin, und ich bin mir nicht sicher, ob NetCore 2 es vollständig unterstützen wird. Ich muss den Portability Analyzer ausprobieren, um es sicher zu sehen.

Ich finde diese ganze Situation ein bisschen entmutigend, wie schnell und einfach eine wichtige Entscheidung wie diese, die die Zukunft von .NET betrifft, ohne jegliche Transparenz in letzter Minute und wieder einmal getroffen werden kann. Es wurde viel Energie investiert, um das bestehende .NET-Ökosystem bei der Migration zu ASP.NET Core zu verkaufen, wobei (meines Wissens nach) die Botschaft lautet, dass .NET Standard 2.0 sich auf Kompatibilität konzentrieren und die Version sein wird, die die Lücke zu .NET schließt v4.x, um endlich eine solide, stabile .NET-Plattform zu produzieren, auf die sich das Ökosystem endlich verlassen kann. Ich persönlich glaube nicht, dass .NET Core wirklich durchstarten wird, bis .NET Standard 2.0 veröffentlicht wird, da ich davon ausgegangen bin, dass es das „versprochene stabile Land“ sein wird, auf das wir alle warten – jetzt habe ich keine Ahnung, was „.NET Standard 2.0" bedeutet, was genau es abdecken wird und welche Bibliotheken nur für .NET Core geplant sind.

Da es keine vorherige offizielle Ankündigung, Bitte um Feedback, Umfrage oder Begründung gegeben hat, „scheint“ diese Entscheidung ohne Beteiligung der Community oder Auswirkungsanalyse auf das bestehende .NET-Ökosystem getroffen worden zu sein und wird wahrscheinlich das gesamte Ökosystem für viele fragmentieren Jahre kommen. Durch das Entfernen der .NET v4.x-Unterstützung entfällt für viele Unternehmen ein reibungsloser Migrationspfad, um ihre vorhandenen Codebasen auf das neue Entwicklungsmodell von ASP.NET zu migrieren. Dies wird sie nicht ermutigen, schneller zu .NET Core zu springen, es hindert sie effektiv daran, dies auch nur zu versuchen, was zu einer massiven Fragmentierung führt, die das .NET-Ökosystem in zwei Teile zerbrechen wird. Ich sehe nicht, wie dies am Ende anders sein wird als Python 2/3, das durch die Fragmentierung irreparabel geschädigt wurde, von der es sich seit fast einem Jahrzehnt immer noch nicht erholen konnte.

Die meisten vorhandenen .NET-Codebasen sind Industriebrachen, die hinter den Kulissen von „dunklen Materie“-.NET-Entwicklern entwickelt werden, von denen die meisten keine Ahnung haben werden, dass diese Entscheidung getroffen wurde, da .NET Core 1.1 .NET v4.x unterstützt und das Messaging für .NET Standard 2.0 war das Versprechen einer verbesserten Kompatibilität. Ich erwarte eine massive Gegenreaktion, sobald die Nachricht und die Auswirkungen dieser Entscheidung endlich zu Hause eintreffen. Viele Entwickler, die die Einführung von .NET Core intern innerhalb ihrer Organisation verkauft haben, werden sich betrogen fühlen, da sie effektiv auf eine Sackgassenplattform migriert haben (wenn sie aus irgendeinem Grund nicht vollständig zu .NET Core migrieren können). ) eine harte Realität, der sie sich stellen müssen, nachdem sie die monumentale Entscheidung getroffen haben, Stakeholder in ihrer Organisation davon zu überzeugen, die für ihre aktuelle Migration erforderlichen Ressourcen zu genehmigen.

Die meisten Unternehmen müssen ihre vorhandenen Codebasen „in-flight“ migrieren, wo sie ihre vorhandenen Systeme kontinuierlich bereitstellen müssen, während sie ihre Codebasis „parallel“ migrieren, die dann zuerst auf .NET v4.x bereitgestellt werden soll Nachdem sich alles stabilisiert und alle Probleme behoben wurden, können sie von dort aus eine vollständige Migration zu .NET Core planen.

Diese Entscheidung wird auch im Zusammenhang mit jahrelangen bahnbrechenden Änderungen an ASP.NET getroffen, die meiner Meinung nach das Vertrauen erodiert haben, dass .NET eine stabile Plattform ist, auf die sich Unternehmen verlassen können. Ich liebe das neue Entwicklungsmodell von .NET Core, aber was wir unserer Meinung nach am meisten brauchen, ist eine stabile Plattform, auf die wir uns verlassen können und auf die der Rest des Ökosystems aufholen kann. .NET Core befindet sich immer noch im unheimlichen Tal, mit unausgereiften Tools, inkompatiblen Abhängigkeiten, Laufzeitproblemen, veralteter Dokumentation usw. - Ich habe .NET seit den frühen Tagen, als es zum ersten Mal veröffentlicht wurde, nicht mehr so ​​instabil gesehen.

Warum nicht eine Umfrage darüber durchführen, was .NET-Entwickler mehr wollen? dh eine solide, stabile und polierte Plattform oder eine „schnelllebige“ Plattform, die neue Funktionen schneller bereitstellt? Ich verstehe, dass es viel weniger Aufwand erfordern würde, sich keine Gedanken über die Rückportierung von Funktionen nach .NET v4.x machen zu müssen, aber es wäre von unschätzbarem Wert, eine Version von ASP.NET Core zu haben, die sich hauptsächlich auf die Bereitstellung einer stabilen, kompatiblen Plattform mit langer Lebensdauer konzentriert Laufzeitunterstützung, die entweder auf .NET v4.x oder .NET Core ausgeführt werden kann.

Ist dieses Schiff gesegelt oder gibt es eine Option, ASP.NET Core 2.0 so zu lassen, wie es ist? dh mit den meisten Bibliotheken und Abstraktionen, die von .NET Standard 2.0 abgedeckt werden, und dann in der nächsten Version von ASP.NET Core 3.0 ankündigen, dass die nächste Plattform nur .NET Core sein wird? Dies wird es Organisationen ermöglichen, weiter voranzukommen und ASP.NET Core 2.0 einzuführen und es dem Rest des Ökosystems zu ermöglichen, mit stabilen und gut unterstützten Tools und Bibliotheken aufzuholen, während eine saubere Trennung von der reinen .NET Core-Plattform/ Funktionen beginnen.

Es ist möglich, auf einige .NET Framework-Bibliotheken in .NET Core 2.0 zu verweisen (vorausgesetzt, sie bleiben innerhalb der Teilmenge von APIs).

Dies atmet Unsicherheit, nur sehr wenige Menschen werden ihren Ruf und die Gesundheit und Stabilität ihrer Systeme riskieren und eine vollständige Migration zu .NET Core versuchen, wenn Unsicherheit darüber besteht, welche ihrer Abhängigkeiten ausgeführt werden können und welche nicht .NET Core, was bedeutet, dass mehr Menschen auf absehbare Zeit bei .NET v4.x bleiben werden.

Ich weiß nicht wirklich, wie sich das letztendlich auswirken wird und welche wahren Auswirkungen diese Entscheidung auf das gesamte .NET-Ökosystem haben wird, aber die Tatsache, dass wichtige Entscheidungen wie diese mit weitreichender Wirkung ohne Beteiligung der externen Community getroffen werden können, ist besorgniserregend.

Ich wünschte, Sie wären etwas weniger versessen darauf, Ihre Benutzerbasis zu teilen.

Mein Standpunkt beim Erstellen einer Bibliothek ist es, sie so einfach wie möglich für so viele Menschen wie möglich an so vielen Orten wie möglich zu verwenden. Es ist ein Schmerz im Nacken (suchen Sie nach #if Compiler-Direktiven in Newtonsoft.Json und Sie erhalten mehr als 1300 Ergebnisse), aber "Es funktioniert einfach" ist ein starkes Verkaufsargument.

Warum nicht eine Umfrage darüber durchführen, was .NET-Entwickler mehr wollen? dh eine solide, stabile und polierte Plattform oder eine „schnelllebige“ Plattform, die neue Funktionen schneller bereitstellt? Ich verstehe, dass es viel weniger Aufwand erfordern würde, sich keine Gedanken über die Rückportierung von Funktionen nach .NET v4.x machen zu müssen, aber es wäre von unschätzbarem Wert, eine Version von ASP.NET Core zu haben, die sich hauptsächlich auf die Bereitstellung einer stabilen, kompatiblen Plattform mit langer Lebensdauer konzentriert Laufzeitunterstützung, die entweder auf .NET v4.x oder .NET Core ausgeführt werden kann.

Echte Frage, ASP.NET Core 1.x unterstützt derzeit .NET Framework und .NET Core. Nehmen wir an, es war die stabile Plattform, die Sie oben erwähnt haben, die wir auf beiden Laufzeiten behoben und unterstützt haben, aber keine weiteren Funktionen erhalten haben. Würde das reichen?

ASP.NET Core und .NET Core sind derzeit die sich schnell entwickelnden, funktionsreichen Plattformen für .NET. Es ist eine Version von .NET, die an kein Betriebssystem gebunden ist und uns die Agilität verleiht, die wir für schnelle Innovationen und schnellere Veröffentlichungen benötigen.

Ist dieses Schiff gesegelt oder gibt es eine Option, ASP.NET Core 2.0 so zu lassen, wie es ist? dh mit den meisten Bibliotheken und Abstraktionen, die von .NET Standard 2.0 abgedeckt werden, und dann in der nächsten Version von ASP.NET Core 3.0 ankündigen, dass die nächste Plattform nur .NET Core sein wird? Dies wird es Organisationen ermöglichen, weiter voranzukommen und ASP.NET Core 2.0 einzuführen und es dem Rest des Ökosystems zu ermöglichen, mit stabilen und gut unterstützten Tools und Bibliotheken aufzuholen, während eine saubere Trennung von der reinen .NET Core-Plattform/ Funktionen beginnen.

Wir sind immer offen für Feedback und ASP.NET Core 2.0 wurde noch nicht ausgeliefert. Wenn ASP.NET Core 3.0 die Version war, die .NET Framework fallen ließ, würde das die Dinge besser machen? Wenn Sie sich einige der Rückmeldungen von @gulbanana und @ikourfaln ansehen , gibt es Technologien, die wahrscheinlich nie portiert werden und daher niemals auf .NET Core funktionieren werden. Bedeutet das nicht, dass .NET Framework so ziemlich für immer unterstützt wird? Würden wir nicht genau diese Diskussion in einem Jahr führen? Vielleicht sind bis dahin das Ökosystem oder die Bibliotheken, die .NET Core unterstützen, größer, sodass es weniger Auswirkungen hat? Was ist mit den Unternehmensbibliotheken, die niemals aktualisiert werden (oder deren Quellcode verloren gegangen ist)? Werden sich die in einem Jahr ändern?

Mein Standpunkt beim Erstellen einer Bibliothek ist es, sie so einfach wie möglich für so viele Menschen wie möglich an so vielen Orten wie möglich zu verwenden. Es ist nervig (suchen Sie nach #if-Compiler-Direktiven in Newtonsoft.Json und Sie erhalten mehr als 1300 Ergebnisse), aber „es funktioniert einfach“ ist ein starkes Verkaufsargument.

Nichts für ungut @JamesNK , aber JSON.NET ist ein JSON-Parser und größtenteils ein einzelnes Paket (ich weiß, dass es noch ein paar mehr gibt). ASP.NET Core hat > ​​200 Pakete.

Nichts für ungut, aber ich bin ein Typ, der Teilzeit arbeitet. Ihr Problem ist schwieriger, aber Sie haben exponentiell mehr Ressourcen.

Nachdem ich dies gelesen und die Abhängigkeiten durchgesehen habe, bin ich weit weniger davon überzeugt, dass dies eine gute Idee ist.

Nach derzeitigem Stand können wir keine unserer Apps auf netstandard / netcoreapp portieren, bis System.DirectoryServices verfügbar ist ( CoreFX-Ausgabe Nr. 2089 hier ). Wir können also zwar auf ASP.NET Core 1.x portieren, aber nicht auf 2.0. Schauen wir uns die Anwendungen hier an: Opserver, Stack Overflow selbst, unsere internen Apps ... nichts wäre fertig, da 2.0 zu diesem Zeitpunkt geplant ist. Laut dem Standup dieser Woche würden kritische Dinge wie DirectoryServices noch in einer späteren Version von 2.x folgen.

Also zwischen 1.0 und 2.0 hat es sich von etwas geändert, zu dem ich mich bereit gemacht habe, zu etwas, zu dem ich nicht gehen kann. Also ja, ich würde sagen, es ist noch nicht fertig. ASP.NET ist eine Möglichkeit, die Bits, die ich benötige, über HTTP verfügbar zu machen. ASP.NET ist nicht das, was ich an sich brauche. Ich verwende .NET nicht nur für die Web-Bits, ich verwende es für die Plattform ... wie viele andere auch. Die Plattform ist nicht bereit für die Vielzahl von Anwendungsfällen, die Benutzer verlangen, daher verursacht das Zwingen von Benutzern auf diese Plattform Schmerzen und Blockaden.

Das Fazit ist, dass wir, wenn wir AD-Authentifizierung (ein großer Teil der Plattform) benötigen, gerade auf der 1.x-Linie aufgegeben wurden. Da wollte ich mit unseren Apps hin ... aber wenn das die Richtung ist, dann macht es keinen Sinn, sich hier anzustrengen, bis die Bits, die ich brauche, am Zielort verfügbar sind.

Wenn wir sagen können, dass diese kritischen Dinge wie System.DirectoryServices , System.Drawing und die anderen Top-Elemente, die die Leute brauchen, mit ASP.NET Core 2.0 bereit sein werden, ändert sich meine Meinung sehr. Wenn sie ein nachträglicher Einfall sind (wie die aktuellen Zeitpläne zeigen), unterstützen Sie das .NET Framework bitte weiter, bis sie es sind.

Sich schnell zu bewegen ist großartig. Ich liebe es. Ich führe gerade Alphas in der Produktion aus. Aber all das spielt keine Rolle, wenn es für Ihren Anwendungsfall überhaupt nicht funktioniert.

Eine Sache, mit der ich persönlich zu kämpfen habe, ist die Frage „stabile Plattform“ vs. „neue Funktionen“. Einerseits wollen wir, dass die Plattform stabil, zuverlässig und kompatibel ist, andererseits will niemand auf 1.x bleiben, weil es keine 2.x-Features hat. Gibt es in ASP.NET Core 2.x wirklich überzeugende Features, die die Leute in diese Richtung ziehen, oder liegt es einfach daran, dass wir mehr Features haben als in 1.x (weil es neu und glänzend ist)?

Wenn es letzteres ist, kümmern sich diese Leute dann um Stabilität? Wenn die Antwort ja lautet, warum ist dann ASP.NET Core 1.x nicht ausreichend?

Ich verwende .NET nicht nur für die Web-Bits, ich verwende es für die Plattform ... wie viele andere auch. Die Plattform ist nicht bereit für die Vielzahl von Anwendungsfällen, die Benutzer verlangen, daher verursacht das Zwingen von Benutzern auf diese Plattform Schmerzen und Blockaden.

Einverstanden, aber wie hängt das Ihrer Meinung nach damit zusammen, dass ASP.NET Core 2.x die .NET Framework-Unterstützung einstellt? Wenn mehr Abhängigkeiten online kommen, werden sie in gewisser Weise überall funktionieren, da die Plattform sich weiterentwickelt, die breite Palette von Laufzeiten wird davon profitieren. Alle Versionen von ASP.NET Core-Anwendungen könnten plötzlich diese Features nutzen.

Wenn es letzteres ist, kümmern sich diese Leute dann um Stabilität? Wenn die Antwort ja lautet, warum ist dann ASP.NET Core 1.x nicht ausreichend?

Jeder möchte immer neue Funktionen, die Möglichkeit neuer Funktionen oder zumindest wissen, dass er irgendwann später die Möglichkeit hat, weitere Goodies zu bekommen. Wenn Sie eine Plattform schließen und in den „stabilen“/„Wartungsmodus“ versetzen, sehen die Leute das als nicht mehr beachtet an.

Gibt es in ASP.NET Core 2.x wirklich überzeugende Features, die die Leute in diese Richtung ziehen, oder liegt es einfach daran, dass wir mehr Features haben als in 1.x (weil es neu und glänzend ist)?

Support – dafür bezahlen wir.

Wenn die Antwort ja lautet, warum ist dann ASP.NET Core 1.x nicht ausreichend?

Denn der Support endet knapp ein Jahr nach Release (laut Scott oben). Und bis dahin bin ich vielleicht kaum mit der Portierung von Stack Overflow fertig.

Wie hängt das damit zusammen, dass ASP.NET Core 2.x die .NET Framework-Unterstützung einstellt?

Weil Bibliotheken, die ich haben muss, nicht da sind. Und ich weiß nicht, wann sie sein werden. Ich würde also auf 1.x stecken bleiben und habe eine Zeitbombe, bis der Support endet. Habe ich genug Zeit, um von 1.0 auf 2.x (oder 3.x) zu portieren, bevor der Support endet? Wahrscheinlich nicht.

Große Codebasen können nicht einfach anhalten und portieren, sie brauchen Zeit, es muss in Etappen geschehen. Als Zwischenschritt war eine .NET 4.6.x-Portierung auf ASP.NET Core machbar. Sofort zum Kern zu gehen ist viel schwieriger, dauert viel länger und erfordert langlebigere Äste und mehr Schmerzen. Wenn wir dies nicht schrittweise tun können, kann ich mir ehrlich gesagt einfach nicht vorstellen, dass wir jemals den Schritt von der jetzt aufgegebenen ASP.NET 5-Linie machen werden. Ich kann den Zeitaufwand, die Kosten und die Auswirkungen auf die Entwicklung auf keinen Fall rechtfertigen.

Ich denke, viele OSS-Autoren sind wie ich – es ist eine Verlängerung unserer täglichen Arbeit. Wenn wir die Plattform nicht nutzen oder dogfooden, sind die Bibliotheken viel schlechter dran oder werden nicht erstellt. Und wir können die Zeit, um sie zu warten, nicht mit Firmenstunden rechtfertigen, die wir heute aufwenden. Und jede Bibliothek, die wir erstellen, stammt aus einem Bedarf, den wir in der Produktion erfüllen. Die Anwendungsfälle, die das Ökosystem fallen lassen, haben viele nachgelagerte Auswirkungen, die nicht plötzlich sind, sich aber dennoch summieren.

Derzeit ist meine Ansicht die folgende: Es gibt eine neue Plattform, die bis etwa Juli 2018 funktioniert. Danach: Ich weiß nichts, ich hoffe nur, dass das, was ich brauche, bis dahin auf netstandard / netcoreapp verfügbar ist. Und ich hoffe, ich habe genug Zeit zum Portieren, bevor der Support endet. Ich werde jedoch nicht dafür bezahlt, zu hoffen, ich werde dafür bezahlt, Plattformentscheidungen für unser Unternehmen zu treffen, und ASP.NET Core ist mit dieser Änderung und ohne Datum für eine funktionierende Version eine schlechte Wette (für uns).

Lassen Sie mich eine einzeilige Zusammenfassung anbieten: Ohne .NET Full Framework-Unterstützung bietet ASP.NET Core in den nächsten 2 Jahren keine unterstützte Plattform für unsere Anwendungsfälle.

Als Kurzversion ist es das:

Priorität 1: Dies muss auf net461 funktionieren, egal welche ifdefs, perf es gibt.
Priorität 2. Wenn Sie es mit .NET Core 2.0 10x schneller machen können, dann ist das großartig. Es ist ein guter Grund für Leute, sich für die Plattform zu entscheiden und/oder zu migrieren, wenn sie können.

Das Wichtigste hier ist, dass es für eine langfristige Unterstützung immer noch auf dem gesamten Framework funktionieren muss, auch wenn es dort langsamer ist.

Priorität 1: Dies muss auf net461 funktionieren

Und wenn .NET Core vollständig mit net461 kompatibel wäre (im Rahmen des Zumutbaren); also funktionierte alles, was für net461 geschrieben wurde, auf Core; wäre das dann ok?

Grundsätzlich haben Sie an diesem Punkt eine stabilere Plattform als net4x, da Sie nebeneinander und eigenständig arbeiten können (auch ein Hauch von X-Plat). Während net461 ganze Maschinenänderungen auf 4.6.1, 4.6.2, 4.7 usw. hat

Offensichtlich wird etwas nie funktionieren; wie partielles Vertrauen - aber das hat sowieso nie funktioniert.

Echte Frage, ASP.NET Core 1.x unterstützt derzeit .NET Framework und .NET Core. Nehmen wir an, es war die stabile Plattform, die Sie oben erwähnt haben, die wir auf beiden Laufzeiten behoben und unterstützt haben, aber keine weiteren Funktionen erhalten haben. Würde das reichen?

Ich würde gerne eine LTS-Version von ASP.NET Core 2.0 sehen, wie Ubuntu / Redhat es mit ihren LTS-Versionen tut, die sie seit mehr als 5 Jahren unterstützen. Es würde ein solides kompatibles Ziel bieten, zu dessen Annahme sich der Rest des Ökosystems vertrauensvoll verpflichten kann.

Ich persönlich interessiere mich mehr für einen stabilen .NET Standard 2.0 als für zukünftige reine .NET Core-Funktionen, da ich gerne zur .NET-Entwicklung zurückkehren würde, wo alles einfach wieder funktioniert, die Tools nicht kaputt sind, die beliebte . NET-Pakete bieten alle Unterstützung, die umgebenden Bereitstellungs- und Hostinglösungen sind ausgefeilt und es gibt zahlreiche Dokumente, Posts, Videos und Wissensdatenbanken für einen stabilen ASP.NET Core, auf dem wir mit der Entwicklung von Lösungen beginnen können.

Würden wir nicht genau diese Diskussion in einem Jahr führen? Vielleicht sind bis dahin das Ökosystem oder die Bibliotheken, die .NET Core unterstützen, größer, sodass es weniger Auswirkungen hat? Was ist mit den Unternehmensbibliotheken, die niemals aktualisiert werden (oder deren Quellcode verloren gegangen ist)? Werden sich die in einem Jahr ändern?

In einer idealen Welt würden sowohl .NET v4.x als auch .NET Core in absehbarer Zeit ASP.NET Core unterstützen, und es sind nur neue .NET Core-only-Features, die nur in .NET Core-only-Paketen verfügbar sein werden. Aber wenn MS dazu bestimmt ist, .NET 4.x hinter sich zu lassen, dann wäre eine ASP.NET 2.0 LTS-Version, bevor Sie sich offiziell trennen, das Nächstbeste. Per Definition ist niemand auf neue Funktionen angewiesen, die es noch nicht gibt, sodass niemand gezwungen sein wird, auf eine reine .NET Core v3.0 zu aktualisieren.

Mit der Freiheit, nur eine Plattform unterstützen zu müssen, könnten Sie möglicherweise neue Funktionen bereitstellen, die Entwickler dazu verleiten würden, die nächstneueste und beste Version mit ständig neuen Funktionen zu übernehmen. Ich persönlich bin mit der Funktionalität von ASP.NET jetzt und so zufrieden Ich bin mehr an einer stabilen Version interessiert, in der alles aufpoliert ist, damit ich wieder produktiv sein und mich darauf konzentrieren kann, Lösungen darauf zu entwickeln, anstatt einer sich ständig bewegenden Plattform hinterherzujagen.

Zunächst einmal vielen Dank an @davidfowl , dass Sie in den Thread gesprungen sind und aufgestanden sind/Fragen gestellt haben usw. Wenn es eine hitzige Community gibt, die haufenweise Fragen stellt, ist es einfach, nicht einzugreifen und zu vermeiden, „ein Ziel“ zu sein. Also danke, dass Sie sich konstruktiv einbringen. /me grüßt dich.

Ich sehe zwei Hauptpunkte/Threads, die sich aus diesem Gespräch ergeben:

1. Anfrage zur Unterstützung von .NET-Desktop in vnext. (das sind 99% der Antworten hier drin)
2. Fehlende Konsultation der Gemeinschaft über eine so wichtige Entscheidung. (die 2 oder 3 Antworten hier drin).

TL;DR;

• Können wir bitte offener mit großen wichtigen vnext-Änderungen umgehen?
• Planen Sie etwas Zeit für RFCs von der Community zu diesen vnext-Änderungen ein.

@mythz hat es schön in seinem Eröffnungssatz zu seinem (zu diesem Zeitpunkt) ~neuesten~ zweitjüngsten Kommentar formuliert:

Ich finde diese ganze Situation ein bisschen entmutigend, wie schnell und einfach eine wichtige Entscheidung wie diese, die die Zukunft von .NET betrifft, ohne jegliche Transparenz in letzter Minute und wieder einmal getroffen werden kann.

Das hat mich persönlich wirklich getroffen, und ich würde mich über einige offizielle Antworten/Kommentare von den zuständigen Leuten bei MS freuen, die diese Anrufe tätigen, bitte. "Wir" sind schon seit verdammt langer Zeit in dieser Community - bekannte Gesichter, bekannte Namen und es ist ziemlich fair zu sagen - alle verfolgen die gleichen positiven Ziele. Ich würde sogar sagen, „wir“ sind eine ziemlich große Großfamilie, Warzen und so.

Ich habe also das Gefühl, dass MS mit der neuen Richtung, die MS eingeschlagen hat (OSS-all-the-things usw.), und mit einigen kürzlich erschienenen Mega-uber-.NET-Threads in den letzten 12/18 Monaten (sprich: Lernen aus diesen Community-Diskussionserfahrungen ) ... dass "wir" alle zusammen darin stecken und dass einige dieser wirklich großen Dinge ™️ weit im Voraus offen diskutiert würden.

Also – können wir bitte einige dieser großen Entscheidungen vorher offen besprechen? Erhalten Sie eine positive Community-Beratung und Diskussion?

Hinweis: Ich akzeptiere, dass dieses Projekt/diese Projekte keine Demokratie sind und dass die _Entscheidungen_ von MS getroffen werden. Kein Problem. Ich kritisiere _das_ nicht. Ich spreche von den Schritten davor. Außerdem verlange ich nicht, dass _alles_ für RFC usw. aufgegeben wird. Nur das eine oder andere wichtige Ticket-Element - wie das, was dieser Thread gestartet hat.

Aber wenn MS dazu bestimmt ist, .NET 4.x hinter sich zu lassen, dann wäre eine ASP.NET 2.0 LTS-Version, bevor Sie sich offiziell trennen, das Nächstbeste. Per Definition ist niemand auf neue Funktionen angewiesen, die es noch nicht gibt, sodass niemand gezwungen sein wird, auf eine reine .NET Core v3.0 zu aktualisieren.

Ich verstehe nicht. Auch ist noch niemand auf Funktionen in ASP.NET 2.0 angewiesen, da sie in einer Version nicht vorhanden sind. Ist ASP.NET Core 1.x also nicht diese Version? Es läuft auf Full Framework, Core 1.0 und Core 2.0 und kann als Sprungbrett für ASP.NET Core 2.x dienen?

@onovotny

Jeder möchte immer neue Funktionen, die Möglichkeit neuer Funktionen oder zumindest wissen, dass er irgendwann später die Möglichkeit hat, weitere Goodies zu bekommen. Wenn Sie eine Plattform schließen und in den „stabilen“/„Wartungsmodus“ versetzen, sehen die Leute das als nicht mehr beachtet an.

Ja, aber es ist wirklich schwierig, das gleiche Qualitätsniveau zu garantieren, wenn .NET Framework die große stabile Unterstützung ist, die an die Betriebssystemkomponente gebunden ist. Wie @terrajobst sagte, einige Dinge werden definitiv irgendwann portiert, andere müssen noch geklärt werden. Tatsache ist, dass ASP.NET Core am besten auf .NET Core läuft, da wir die Möglichkeit haben, den gesamten Stack auf einmal zu überarbeiten. Bisher gibt es große Leistungsunterschiede zwischen den beiden Laufzeiten, und wir müssen aufgrund der .NET Framework-Unterstützung noch Abhängigkeiten von neuen APIs eingehen. Im weiteren Verlauf werden wir neue APIs hinzufügen, die irgendwann in .NET Framework erscheinen können oder auch nicht, und wir wollen nicht im Tempo der stabilsten und langsamsten Laufzeitumgebung (.NET Framework) drehen.

@ Nick Craver

Denn der Support endet knapp ein Jahr nach Release (laut Scott oben). Und bis dahin bin ich vielleicht kaum mit der Portierung von Stack Overflow fertig.

Ich bin mir nicht sicher, ob das ganz richtig ist. Wenn 2.0 verfügbar ist, wird 1.1 weiterhin unterstützt. Also, was ist diese "Unterstützung", von der Sie sprechen? Meinst du bezahlten Support oder meinst du, dass wir Probleme beheben, wenn sie auftreten?

Weil Bibliotheken, die ich haben muss, nicht da sind. Und ich weiß nicht, wann sie sein werden. Ich würde also auf 1.x stecken bleiben und habe eine Zeitbombe, bis der Support endet. Habe ich genug Zeit, um von 1.0 auf 2.x (oder 3.x) zu portieren, bevor der Support endet? Wahrscheinlich nicht.

Wie ich bereits sagte, werden diese Bibliotheken unabhängig von der .NET Core-Version aufleuchten. Ich denke, was Sie sagen, ist, dass Sie die neueste Version von ASP.NET Core (was auch immer das ist) verwenden möchten und dass sie von .NET Framework unterstützt werden soll, bis genügend Bibliotheken auf .NET Core vorhanden sind, sodass der Port ist einfach für Sie spezifisches Szenario.

Große Codebasen können nicht einfach anhalten und portieren, sie brauchen Zeit, es muss in Etappen geschehen. Als Zwischenschritt war eine .NET 4.6.x-Portierung auf ASP.NET Core machbar. Sofort zum Kern zu gehen ist viel schwieriger, dauert viel länger und erfordert langlebigere Äste und mehr Schmerzen. Wenn wir dies nicht schrittweise tun können, kann ich mir ehrlich gesagt einfach nicht vorstellen, dass wir jemals den Schritt von der jetzt aufgegebenen ASP.NET 5-Linie machen werden. Ich kann den Zeitaufwand, die Kosten und die Auswirkungen auf die Entwicklung auf keinen Fall rechtfertigen.

Wie wirkt sich das Revving von ASP.NET Core-Versionen darauf aus? Wenn wir die .NET Framework-Unterstützung in 3.0 einstellen würden (wie sich die Leute in diesem Thread zu entziehen scheinen), würden Sie sich dann nicht trotzdem in derselben Sackgasse befinden? Sie würden Ihre ASP.NET Core 2.0-Anwendung portiert und ein Jahr lang auf Framework ausführen lassen, und wenn 3.0 herauskommt, könnten Sie kein Upgrade durchführen. Sie könnten dies sowieso mit ASP.NET Core 1.1.x tun, das auf .NET Framework ausgeführt wird und auch dann unterstützt wird, wenn ASP.NET Core 2.0 nicht verfügbar ist.

Derzeit ist meine Ansicht: Es gibt eine neue Plattform, die bis etwa Juli 2018 funktioniert. Danach: Ich weiß nichts, ich hoffe nur, dass das, was ich brauche, bis dahin auf netstandard/netcoreapp verfügbar ist. Und ich hoffe, ich habe genug Zeit zum Portieren, bevor der Support endet. Ich werde jedoch nicht dafür bezahlt, zu hoffen, ich werde dafür bezahlt, Plattformentscheidungen für unser Unternehmen zu treffen, und ASP.NET Core ist mit dieser Änderung und ohne Datum für eine funktionierende Version eine schlechte Wette (für uns).

Ein weiteres Jahr ist also genug Zeit für alle? Das ist nicht das Gefühl, das ich aus diesem Thread bekomme.

Priorität 1: Dies muss auf net461 funktionieren, egal welche ifdefs, perf es gibt.
Priorität 2. Wenn Sie es mit .NET Core 2.0 10x schneller machen können, dann ist das großartig. Es ist ein guter Grund für Leute, sich für die Plattform zu entscheiden und/oder zu migrieren, wenn sie können.

Das Wichtigste hier ist, dass es für eine langfristige Unterstützung immer noch auf dem gesamten Framework funktionieren muss, auch wenn es dort langsamer ist.

Der einzige Grund, warum .NET Framework so gut funktioniert wie heute, liegt darin, dass wir es absichtlich unterstützen wollten. Es kam nicht umsonst, es ist nicht "nur schneller im Kern", wir mussten das System absichtlich so entwerfen, dass es möglich war, es auf .NET Framework zum Laufen zu bringen. Auch wenn Sie es noch nicht sehen, wird die Funktionslücke zwischen den beiden größer, sobald wir uns entscheiden (und wir entschieden haben), Abhängigkeiten von APIs zu übernehmen, die noch nicht in .NET Framework vorhanden sind. Wir können tun, was @PinpointTownes sagt, und anfangen, NotSupportedException zu werfen, wenn diese Funktionslücken auftreten, aber meiner Meinung nach ist das eine ziemlich schlechte Erfahrung.

Wir haben ein großes Entwicklungsbudget für die Portierung unserer ASP.net MVC5-App auf das ASP.net Core Full Framework ausgegeben, damit sie gut mit Azure Service Fabric funktioniert. Das gesamte Projekt erstreckte sich über mehrere Monate, in denen mehrere Wochen der Portierung unserer Webanwendung gewidmet waren (und ehrlich gesagt, dem Ringen mit den umständlichen VS2015-Tools).

Der einzige Grund, der funktionierte, war, dass das vollständige Framework unterstützt wurde, da wir derzeit SignalR auf ASP.net Core ausführen (zur Entmutigung von @davidfowl ). Soweit ich das beurteilen kann, wird SignalR von Asp.net Core immer noch nicht unterstützt?

Dann haben wir ungefähr eine Woche damit verbracht, auf die neuen VS2017-Tools zu migrieren. Bußgeld.

_Beachten Sie, dass es bis zu diesem Zeitpunkt überhaupt keine Verbesserungen am Produkt gibt, es handelt sich lediglich um eine Anpassung der Codeform, um sie an die Plattform- und Toolanforderungen von Microsoft anzupassen._

Jetzt sagen Sie mir, dass ich innerhalb von 12 Monaten mehr funktionslose Entwicklungsanstrengungen durchführen muss, ohne Garantie, dass ich es überhaupt schaffen werde, abhängig von einem Haufen Handbewegungen und sollte dazu in der Lage sein? Nein Danke.

Holen Sie sich zunächst alles, was von Microsoft gebrandet ist und das heute im vollständigen ASP.net-Core-Framework verwendet wird, das nur auf ASP.net-Core arbeitet. Zweitens, finden Sie heraus, was (wenn überhaupt) das Ökosystem sonst daran hindern würde, den ASP.net-Kern wie gewünscht zu übernehmen. Dann, und nur dann, stellen Sie die Unterstützung für Netfx ein, wie dies diskutiert wird.

Wir können tun, was @PinpointTownes sagt, und NotSupportedException auslösen, wenn diese Funktionslücken auftreten, aber meiner Meinung nach ist das eine ziemlich schlechte Erfahrung.

Das ist nicht genau das, was ich gesagt habe: Wenn Sie mit Cross-Kompilierung arbeiten, sollte ifdefs definitiv die bevorzugte Option sein, um APIs auszuschließen, die auf einer bestimmten Plattform nicht verfügbar sind, aber wenn Sie aus irgendeinem Grund diese API-Signatur unbedingt öffentlich haben MÜSSEN Vertrag, dann können Sie mit NotSupportedException gehen.

Ich verstehe nicht. Auch ist noch niemand auf Features in ASP.NET 2.0 angewiesen

Ich gehe davon aus, dass die meisten Entwickler auf einen stabilen und hochkompatiblen .NET Standard 2.0 warten, den ihre Abhängigkeiten unterstützen, bevor sie sich zur Migration zu ASP.NET Core verpflichten. Sie werden .NET Core 1.1 jetzt nicht übernehmen wollen, da sie wissen, dass es EOL-ed ist, und MS hat keine gute Geschichte in der Bereitstellung von langfristigem Support für alte DNX/.NET Core-Versionen. Wenn es eine hochkompatible stabile LTS-Version gäbe, die der Rest des Ökosystems sicher übernehmen kann, sollten Unternehmen alles haben, was sie brauchen, um ihre Systeme darauf auszuführen, und sie fühlen sich nicht verpflichtet, auf .NET Core vNext zu aktualisieren, da sie alles haben, was sie haben auf v2.0 benötigen, und wenn die Zeit kommt, wird es viel einfacher sein, ihre Migration von ASP.NET Core 2.0/.NET v4.6 auf eine zukünftige reine .NET Core-Version zu planen.

@Mythos

Ich persönlich interessiere mich mehr für einen stabilen .NET Standard 2.0 als für zukünftige reine .NET Core-Funktionen, da ich gerne zur .NET-Entwicklung zurückkehren würde, wo alles einfach wieder funktioniert, die Tools nicht kaputt sind, die beliebte . NET-Pakete bieten alle Unterstützung, die umgebenden Bereitstellungs- und Hostinglösungen sind ausgefeilt und es gibt zahlreiche Dokumente, Posts, Videos und Wissensdatenbanken für einen stabilen ASP.NET Core, auf dem wir mit der Entwicklung von Lösungen beginnen können.

Ich bin mit allem einverstanden, aber ich sehe nicht, wie sich diese Entscheidung auf das auswirkt, was Sie gesagt haben. Ich will all die gleichen Dinge 👍 .

Mit der Freiheit, nur eine Plattform unterstützen zu müssen, könnten Sie möglicherweise neue Funktionen bereitstellen, die Entwickler dazu verleiten würden, die nächstneueste und beste Version mit ständig neuen Funktionen zu übernehmen. Ich persönlich bin mit der Funktionalität von ASP.NET jetzt und so zufrieden Ich bin mehr an einer stabilen Version interessiert, in der alles aufpoliert ist, damit ich wieder produktiv sein und mich darauf konzentrieren kann, Lösungen darauf zu entwickeln, anstatt einer sich ständig bewegenden Plattform hinterherzujagen.

Richtig, ist das nicht ASP.NET Core 1.x? Wenn die Unterstützung auf 1.x erweitert würde, wäre das nicht genug? Wir könnten einfach sicherstellen, dass ASP.NET Core 1., das Netstandard 1.x ist, auf .NET Core 2.0 ausgeführt wird (was es bereits tut) und dies für ein weiteres Jahr oder so unterstützen.

Das ist nicht genau das, was ich gesagt habe: Wenn Sie mit Cross-Kompilierung arbeiten, sollte ifdefs definitiv die bevorzugte Option sein, um APIs auszuschließen, die auf einer bestimmten Plattform nicht verfügbar sind, aber wenn Sie aus irgendeinem Grund diese API-Signatur im öffentlichen Vertrag haben müssen, dann können Sie das Gehen Sie mit NotSupportedException.

Ich spreche nicht einmal davon, öffentliche APIs offenzulegen. Ich spreche von APIs, die wir aufrufen müssen, die in netstandard nicht vorhanden sind. #ifdefs helfen hier nicht. Wir würden einfach werfen, wenn die Lücken größer werden.

@davidfowl Völlig gültige Fragen - Antworten:

Meinst du bezahlten Support oder meinst du, dass wir Probleme beheben, wenn sie auftreten?

Aktive Fixes für Probleme – Wird 1.x Fixes für alle Dinge erhalten, die wir kaputt machen, oder werden wir in einigen Fällen aufgefordert, ein Upgrade für einen Fix durchzuführen? (Hinweis: Das ist ein Upgrade, das wir nicht durchführen können, bis unsere Bibliotheken wie DirectoryServices da sind ... und selbst wenn wir es können , ist es bei weitem nicht kostenlos oder sogar billig, es dauert wahrscheinlich mindestens Monate). Wir sind groß, wir sind schnell, wir finden Brüche im Rahmen. Wir haben seit Jahren für jedes Major- und Minor-Release. Unterstützung ist für uns entscheidend.

Ich denke, Sie sagen, dass Sie die neueste Version von ASP.NET Core verwenden möchten

Nein, ich möchte eine funktionierende Version und einen Weg nach vorne. Bei 1.x haben wir nur die erste Hälfte. Bis zu dieser Ausgabe wurde die zweite Art angenommen.

Wie wirkt sich das Revving von ASP.NET Core-Versionen darauf aus?

Denn wenn Sie den Support für das vollständige Framework einstellen, müssen wir eine größere Änderung vornehmen, um den Support aufrechtzuerhalten.

Wenn wir die .NET Framework-Unterstützung in 3.0 einstellen würden (wie sich die Leute in diesem Thread zu entziehen scheinen), würden Sie sich dann nicht trotzdem in derselben Sackgasse befinden?

Vielleicht? Der Punkt ist, Parität in Anwendungsfällen zu haben, bevor man den Tauchgang macht. Es ist meine Karriere, ich kann unserem Unternehmen nicht sagen, dass es abspringen soll, wenn die andere Seite uns möglicherweise nicht unterstützt. Das wäre einfach unverantwortlich von mir. Wenn unsere Anwendungsfälle im 2.x-Zeitrahmen unterstützt wurden, gibt es einen klaren Weg nach vorne, und es ist viel sicherer, auf ASP.NET Core zu setzen.

Ein weiteres Jahr ist also genug Zeit für alle?

Die absolute Zeitdauer spielt keine Rolle - es muss Anwendungsfallkompatibilität + Zeit (IMO) sein. Wenn unsere Anwendungsfälle heute funktioniert haben (z. B. AD-Authentifizierung), dann reichen 2 Jahre, ja. Aber aktuell ist das nicht der Fall, daher ist es bestenfalls verfrüht, sich darauf zu einigen, dass ein beliebiger Zeitpunkt ab jetzt in Ordnung ist.

Es kam nicht umsonst, es ist nicht "nur schneller im Kern", wir mussten das System absichtlich so entwerfen, dass es möglich war, es auf .NET Framework zum Laufen zu bringen. Auch wenn Sie es noch nicht sehen, wird die Funktionslücke zwischen den beiden größer, sobald wir uns entscheiden (und wir entschieden haben), Abhängigkeiten von APIs zu übernehmen, die noch nicht in .NET Framework vorhanden sind.

Dann nichts für ungut, aber warum sagst du das nicht einfach und schließt das Thema? Diese Aussage scheint, als gäbe es nichts mehr zu diskutieren, und unsere Zeit ist besser woanders verbracht. Wenn das nicht der Fall ist, bitte klären?

Das Hauptproblem besteht darin, dass wir unsere Workloads heute oder, wie derzeit vorgeschlagen, beim Start nicht nach netstandard portieren können. Wenn das, was wir bereits haben , nicht funktioniert, warum sollten wir uns dann um neue Funktionen kümmern? Das Team spricht ständig über Leistung (und das ist wirklich großartig), aber etwas, das ich nicht gebrauchen kann, ist wirklich nicht wichtig, um schnell zu laufen.

Als Architektur-/Plattformleiter muss ich entscheiden, welche Wetten wir eingehen. Derzeit ist dies eine schlechte Wette. Wenn Version 1 Sie unterstützt, Version 2 jedoch nicht, aber hoffentlich eines Tages , dann ist das ein wirklich schlechtes Spiel mit der Zeit und dem Geld anderer Leute. Zumindest für uns haben wir uns aufgrund der Funktionen, des Ökosystems und des Supports für .NET entschieden. Derzeit sind wir im neuen Wort von allen 3 zu 1 übergegangen. Das Ökosystem ist noch nicht da (API-Oberfläche, Bibliotheken) und der Support ist viel kürzer als wir es gewohnt sind, ohne garantierten Upgrade-Pfad und eine unbekannte Zeit dafür.

@jahmai

Der einzige Grund, der funktionierte, war, dass das vollständige Framework unterstützt wurde, da wir derzeit SignalR auf ASP.net Core ausführen (zur Entmutigung von @davidfowl ). Soweit ich das beurteilen kann, wird SignalR von Asp.net Core immer noch nicht unterstützt?

Selbst SignalR 2 wird von ASP.NET Core nicht unterstützt (obwohl die Leute es gehackt haben, damit es funktioniert). SignalR befindet sich noch in der Entwicklung und wird noch nicht einmal mit ASP.NET Core 2.0 herauskommen, es kommt später.

Jetzt sagen Sie mir, dass ich innerhalb von 12 Monaten mehr funktionslose Entwicklungsanstrengungen durchführen muss, ohne Garantie, dass ich es überhaupt schaffen werde, abhängig von einem Haufen Handbewegungen und sollte dazu in der Lage sein? Nein Danke.

Gibt es Funktionen, die Sie in ASP.NET Core 2.0 benötigen? Oder spekulieren Sie nur, dass Sie irgendwann auf den nächsten ASP.NET Core upgraden müssen und zu diesem Zeitpunkt die Dinge auf .NET Framework nicht funktionieren?

Holen Sie sich zunächst alles, was von Microsoft gebrandet ist und das heute im vollständigen ASP.net-Core-Framework verwendet wird, das nur auf ASP.net-Core arbeitet. Zweitens, finden Sie heraus, was (wenn überhaupt) das Ökosystem sonst daran hindern würde, den ASP.net-Kern wie gewünscht zu übernehmen. Dann, und nur dann, stellen Sie die Unterstützung für Netfx ein, wie dies diskutiert wird.

Als Teil von netstandard 2.0 wurde viel Arbeit geleistet, um wichtige APIs zu identifizieren, die zurückgebracht werden sollten, damit Bibliotheken, die auf .NET Framework abzielten, größtenteils binärkompatibel damit waren. Natürlich gibt es Bereiche, die einfach nicht funktionieren, wie WCF, WPF usw., aber es wird helfen, da wir einige Nachforschungen angestellt haben und ~ 60 % der Bibliotheken API-kompatibel mit Netstandard 2.0 sind (korrigieren Sie mich, wenn ich mich bei dieser Zahl irre @terrajobst) und funktioniert möglicherweise nur auf .NET Core 2.0.

Richtig, ist das nicht ASP.NET Core 1.x? Wenn die Unterstützung auf 1.x erweitert würde, wäre das nicht genug?

Ich hatte erwartet, dass .NET Standard 2.0 die stabile Plattform sein würde, die die Kompatibilität mit .NET 4.x überbrückt, daher ist es sinnvoller, LTS-Unterstützung in der Nähe zu haben. Niemand erwartet, dass 1.1/.NET v4.x in der Mitte der Veröffentlichung EOL ist, also wäre es respektvoll, LTS für die neueste Version anzukündigen, wenn sie veröffentlicht wird, und nicht die .NET 4.x-Unterstützung vor der Veröffentlichung einzustellen, nein- LTS macht man rückwirkend zu alten Versionen so.

Ich weiß, dass wir unsere .NET Core-Pakete in separaten *.Core -Paketen verwalten, damit wir in einem separaten Veröffentlichungsrhythmus bleiben können, der der neuesten .NET Core-Version folgt, sobald wir sie mit den Haupt-NuGet-Paketen zusammenführen Wir verpflichten uns zu einer stabilen Version, die wir offiziell unterstützen werden, daher müssen wir sehr zuversichtlich sein, dass wir eine Version haben, die wir auf absehbare Zeit unterstützen können, was ich von .NET Standard 2.0 erwartet habe, nicht vom aktuellen .NET Standard 1,1/1,3/1,6 Mischung. Ich erinnere mich, dass es auch eine Zeit gab, in der es ein 1.7/8-Stopp-Gap-Release geben sollte, das mit 2.0 nicht kompatibel sein würde, wodurch die .NET Standard-Versionierungserwartung gebrochen wurde, was keine Signale für eine stabile Plattform sind.

Ich habe sehnsüchtig erwartet, dass .NET Standard 2.0 dazu bestimmt ist, die begehrte hochgradig kompatible Oberfläche und die dringend benötigte Stabilität bereitzustellen.

Selbst SignalR 2 wird von ASP.NET Core nicht unterstützt (obwohl die Leute es gehackt haben, damit es funktioniert). SignalR befindet sich noch in der Entwicklung und wird noch nicht einmal mit ASP.NET Core 2.0 herauskommen, es kommt später.

Ich bin mir nicht sicher, wie Sie diese Aussage gemeint haben, aber ich glaube, sie verstärkt nur meine Bedenken.

Gibt es Funktionen, die Sie in ASP.NET Core 2.0 benötigen? Oder spekulieren Sie nur, dass Sie irgendwann auf den nächsten ASP.NET Core upgraden müssen und zu diesem Zeitpunkt die Dinge auf .NET Framework nicht funktionieren?

Ich möchte aus Gründen irgendwann zu netstandard2 wechseln. Ich muss umziehen, um meine Web-App dafür auf asp.net Core 2 zu verschieben, richtig?

Als Teil von netstandard 2.0 wurde viel Arbeit geleistet, um wichtige APIs zu identifizieren, die zurückgebracht werden sollten, damit Bibliotheken, die auf .NET Framework abzielten, größtenteils binärkompatibel damit waren. <...>

Sicher, und ich mag, was mit netstandard gemacht wird, aber wenn etwas in netstandard fehlt, können Sie es umgehen, weil Sie das vollständige Framework in Anwendungen verwenden können, die es benötigen. Wir haben jetzt eine Handvoll reiner netstandard 1.3-Bibliotheken (unsere Quelle), die gemeinsam genutzt werden: Xamarin.iOS, Xamarin.Android, net46, Asp.net Core 1.1 - weil wir fehlende Funktionalität in netstandard mit spezifischen Framework-Zielbibliotheken, einschließlich net46-Sachen, ergänzen können in unserer asp.net-Core-Web-App.

Der _ einzige _ Grund, warum wir diese Netstandard-Bibliotheken haben, ist, dass wir unsere riesige Webanwendung portieren mussten (wie ich bereits erwähnt habe). Ich würde _gerne_ unsere plattformspezifische Codebasis für andere Plattformen nicht erweitern müssen und stattdessen die Netstandard-Kette weiter nach oben bewegen. Ich möchte wirklich nicht auf Netstandard 1.3 stecken bleiben, da es keinen Pfad gibt, um zu asp.net Core 2 zu wechseln.

Aktive Fixes für Probleme – Wird 1.x Fixes für alle Dinge erhalten, die wir kaputt machen, oder werden wir in einigen Fällen aufgefordert, ein Upgrade für einen Fix durchzuführen? (Hinweis: Das ist ein Upgrade, das wir nicht durchführen können, bis unsere Bibliotheken wie DirectoryServices da sind ... und selbst wenn wir es können, ist es bei weitem nicht kostenlos oder sogar billig, es dauert wahrscheinlich mindestens Monate). Wir sind groß, wir sind schnell, wir finden Brüche im Rahmen. Wir haben seit Jahren für jedes Major- und Minor-Release. Unterstützung ist für uns entscheidend.

Ich glaube nicht, dass es ein Problem mit dem Support gibt. Ich denke eigentlich nicht, dass dies ein großes Problem wäre, und wenn es die Leute dazu gebracht hat, sich sicherer zu fühlen, eine Wette anzunehmen, dann lohnt es sich vielleicht, die Unterstützung für 1.x auf einen längeren Zeitraum auszudehnen.

Nein, ich möchte eine funktionierende Version und einen Weg nach vorne. Bei 1.x haben wir nur die erste Hälfte. Bis zu dieser Ausgabe wurde die zweite Art angenommen.

Es bedeutet nur, dass Sie auf 1.x bleiben müssen, bis alle Ihre Abhängigkeiten portiert sind, nein?

@NickCraver Alle Ihre Beschwerden beziehen sich auf Dinge, die in .NET Core und nicht in ASP.NET Core fehlen. In .NET Core 1.x und ASP.NET Core 1.x werden diese beiden Entitäten zusammen ausgeliefert, sind aber vollständig entkoppelt. Ich habe keinen einzigen Grund dafür gehört, ASP.NET Core 2.0 speziell zu verwenden, außer berechtigten Bedenken, dass v1 etwas unterstützt und v2 es nicht unterstützt. Ich denke, wir würden in einem Jahr genau dieselbe Diskussion führen, wenn es einen anderen Grund gäbe, warum Sie nicht nur auf .NET Core portieren könnten (vielleicht haben Sie während der Entwicklung von ASP.NET Core auf dem vollständigen Framework einige neue Abhängigkeiten aufgenommen, die wird nie als Beispiel portiert).

Dann nichts für ungut, aber warum sagst du das nicht einfach und schließt das Thema? Diese Aussage scheint, als gäbe es nichts mehr zu diskutieren, und unsere Zeit ist besser woanders verbracht. Wenn das nicht der Fall ist, bitte klären?

Ich antworte und antworte hier, weil ich versuche herauszufinden, warum wir .NET Framework unterstützen müssen, wenn ja, wie lange. Ich bekomme immer noch eine gemischte Stimmung in diesem Thread über diese Zeitrahmen. Außerdem gibt es eine allgemeine Befürchtung, die ich verstehen kann, wenn es darum geht, „zu ASP.NET Core 1.x verbannt zu werden“, aber nichts Konkretes in Bezug auf bestimmte Funktionen, die in 2.x benötigt werden.

Eines der wichtigsten Dinge, die ich an der Kopplung von .NET Core und ASP.NET Core mag, ist, dass es einen Teil des Versionierungs- und Benennungswahnsinns löst. Viele Leute wissen nicht einmal, dass ASP.NET Core auf .NET Framework ausgeführt wird (es verwirrt sogar Neueinsteiger in den Stack). Allerdings haben wir viele Kunden mit vielen unterschiedlichen Bedürfnissen und wir hören auf ihr Feedback.

@Mythos

Ich habe sehnsüchtig erwartet, dass .NET Standard 2.0 dazu bestimmt ist, die begehrte hochgradig kompatible Oberfläche und die dringend benötigte Stabilität bereitzustellen.

Sicher, aber wie gesagt, ASP.NET Core, .NET Core und .NET Standard in 1.x sind komplett entkoppelt. Sie können jede .NET Standard-Bibliothek in jeder Version von .NET Core verwenden, die sie unterstützt. Wenn also .NET Core 2.0 ein neues LTS ist, könnten wir immer noch erklären, dass ASP.NET Core 1.x darauf unterstützt wird.

@jahmai

Ich möchte aus Gründen irgendwann zu netstandard2 wechseln. Ich muss umziehen, um meine Web-App dafür auf asp.net Core 2 zu verschieben, richtig?

Nein, das ist nicht richtig. Sie können jederzeit zu netstandard 2 wechseln, ohne Ihre Web-App auf ASP.NET Core 2.0 zu verschieben.

Der einzige Grund, warum wir diese Netstandard-Bibliotheken haben, ist, dass wir unsere riesige Webanwendung portieren mussten (wie ich bereits erwähnt habe). Ich möchte unsere plattformspezifische Codebasis nicht für andere Plattformen erweitern müssen und stattdessen die Netstandard-Kette weiter nach oben bewegen. Ich möchte wirklich nicht auf Netstandard 1.3 stecken bleiben, da es keinen Pfad gibt, um zu asp.net Core 2 zu wechseln.

Sie müssen nicht an netstandard 1.3 festhalten. Die 2 Dinge haben nichts miteinander zu tun.

Wenn Version 1 Sie unterstützt, aber Version 2 nicht, aber _hoffentlich eines Tages_, dann ist das ein wirklich schlechtes Spiel ....

Das ist meiner Meinung nach der Kern des Problems. Wir haben Kommentare erhalten, dass _einige_ der Lücken ( DirectoryService , et. al.) bekannt sind und behoben werden. Da brauchen wir etwas Konkreteres.

Ich bin damit einverstanden, dass ASP.NET Core auf .NET Core abzielt und dass wir das 2.0-Boot verpassen, wenn die Roadmap klar ist, wann wir erwarten können, dass diese Lücken (und welche Lücken) geschlossen werden (wieder unter der Annahme, dass genügend Zeit zum Portieren vorhanden ist). 1.X wird nicht mehr unterstützt).

Aus heutiger Sicht stagniert das Problem, für das wir für WCF blockiert sind, seit Mai 2015 und wird möglicherweise nie angegangen. Dadurch sind wir effektiv gestrandet.

@davidfowl

Nein, das ist nicht richtig. Sie können jederzeit zu netstandard 2 wechseln, ohne Ihre Web-App auf ASP.NET Core 2.0 zu verschieben.

Exzellent. In diesem Fall, solange Microsoft sicherstellt, dass 1.x unterstützt wird (alle Arten von Fehlerbehebungen und Betriebsunterstützung), bis es Kunden einen geeigneten 2.x-Migrationspfad (z. B. SignalR) bietet, kann ich meine Zeit bis zu uns abwarten Benötige asp.net Core 2.

Es bedeutet nur, dass Sie auf 1.x bleiben müssen, bis alle Ihre Abhängigkeiten portiert sind, nein?

Richtig, aber das muss ein bekannter Zeitrahmen sein. Wir haben keine Daten, das einzige, was uns bisher gesagt wurde, war "nicht in 2.0" ... also ist das nicht gut. Zum Beispiel wird System.DirectoryServices seit Mitte 2015 angefordert und fehlt immer noch, wird aber oft als das meistgesuchte von Benutzern wiederholt (gefolgt von System.Drawing ). Zu sagen, dass wir .NET Standard 2.0 auf ~60 % API-Parität bringen, aber die Bits fehlen, um die Benutzer gebeten haben, sendet mit Sicherheit gemischte Signale darüber, was wichtig ist.

Alle Ihre Beschwerden beziehen sich auf Dinge, die in .NET Core und nicht in ASP.NET Core fehlen.

Das ist falsch. Ich brauche die Bits, die wir benötigen , um auf einer unterstützten Plattform ausgeführt zu werden (z. B. AD-Authentifizierung). Was fehlt, ist die Unterstützung durch letztere. Die Unterstützung für 1.x ist sicherlich mein Hauptanliegen. Wir haben keinen unterstützten Weg nach vorne oder irgendwelche Zeitpläne, wann wir einen erwarten können.

Ich denke, wir würden in einem Jahr genau die gleiche Diskussion führen

Ich glaube nicht, dass das der Fall ist. Das Problem ist, dass wir heute nicht portieren konnten. Die APIs sind nicht da. Solange es keinen einzigen Zeitpunkt gibt, zu dem wir überhaupt portieren könnten, sind Diskussionen über die Zukunft ein bisschen hinfällig. Ich würde erwarten, dass die vollständige .NET-Framework-Unterstützung in ASP.NET Core veraltet ist, sobald Parität vorhanden ist und die meisten Benutzer wechseln können. Und ich würde erwarten, dass diese Version einen langen Supportzeitraum hat, in den die Leute wechseln können.

Wenn DirectoryServices, Drawing usw. in 2.x kommen, dann großartig. Diese Version sollte .NET Framework unterstützen und eine LTS-Version sein. Und 3.x sollte die volle Framework-Unterstützung fallen lassen.

Eines der wichtigsten Dinge, die ich an der Kopplung von .NET Core und ASP.NET Core mag, ist, dass es einen Teil des Versionierungs- und Benennungswahnsinns löst. Viele Leute wissen nicht einmal, dass ASP.NET Core auf .NET Framework ausgeführt wird (es verwirrt sogar Neueinsteiger in den Stack). Allerdings haben wir viele Kunden mit vielen unterschiedlichen Bedürfnissen und wir hören auf ihr Feedback.

Fair genug, aber all der Wahnsinn dort ist zweitrangig zu "funktioniert es überhaupt?". Derzeit ist das ein festes Nein. ASP.NET und .NET Core/Standard/was auch immer sind zwei verschiedene Dinge innerhalb von Microsoft (und das verstehe ich total), aber für Entwickler ist es immer noch eine Plattform. Die ASP.NET-Seite benötigt die APIs, um für viele nützlich zu sein, und sie sind noch nicht da. Dieser Schritt reduziert die verfügbaren APIs weiter. Das ASP.NET-Team bekommt vielleicht die, die es will, aber es geht auf Kosten derer, die wir brauchen.

@ctolkien @NickCraver

Das ist meiner Meinung nach der Kern des Problems. Wir haben Kommentare erhalten, dass einige der Lücken (DirectoryService usw.) bekannt sind und behoben werden. Da brauchen wir etwas Konkreteres.

Richtig, aber das muss ein bekannter Zeitrahmen sein. Wir haben keine Daten, das einzige, was uns bisher gesagt wurde, war "nicht in 2.0" ... also ist das nicht gut. Beispielsweise wird System.DirectoryServices seit Mitte 2015 angefordert und fehlt immer noch, wird aber häufig als das von Benutzern am meisten gewünschte wiederholt (gefolgt von System.Drawing).

Diese Lücken hängen jedoch mit .NET Core selbst zusammen, und ich kann die Angst verstehen, nicht zu wissen, wann diese Abhängigkeiten verfügbar sein werden, und deshalb wäre es gut, uns bei der Priorisierung dieser Abhängigkeiten zu helfen. Die gute Nachricht ist, dass netstandard 2.0 und netcoreapp2.0 die Gruppenarbeit dahingehend verlegt haben, andere Bibliotheken leichter portierbar zu machen. Ich gehe davon aus, dass es nach der Veröffentlichung von 2.0 viel einfacher sein wird, andere Abhängigkeiten hervorzubringen, indem wir Codeschwaden auf unsere sehr kompatible Basis portieren.

Wird CSOM in netcore 2 laufen? Das wäre ein großer Blocker für uns und ein Bereich, von dem ich noch nichts gehört habe.

@davidfowl Ich hoffe aufrichtig, dass das auch der Fall ist, aber ich setze unser Unternehmen nicht darauf. Das Abbrechen der Unterstützung, bevor das passiert, und nicht danach, dem stimme ich absolut nicht zu. Ich denke, dass dies im 3.x-Zeitrahmen passiert, nachdem diese kritischen APIs für viele Verbraucher vorhanden sind, ist absolut gültig. Wenn sie dies tun, bevor sie bereit sind, wird unsere Adoption nur gestoppt.

Ich war auf dem Weg, 1.0 zu übernehmen, in der Annahme, dass 2.x (oder was auch immer aktiv entwickelt/gefixt wird) das vollständige Framework unterstützen würde, bis diese kritischen APIs fertig sind (ich meine es ernst – Sie wissen, wie viel Arbeit ich bereits in Bibliotheken gesteckt habe ). Aber zu diesem Zeitpunkt kann ich das bei Stack nicht tun ... es war eine schlechte Annahme. Ich kann unseren Teams nicht guten Gewissens raten, .NET Core zu verwenden, während die Zukunft eines jeden Ports so ungewiss ist. Ich wünschte wirklich, ich könnte, aber es ist das Risiko und die Schmerzen im Moment nicht wert.

@ Nick Craver

Ich würde erwarten, dass die vollständige .NET-Framework-Unterstützung in ASP.NET Core veraltet ist, sobald Parität vorhanden ist und die meisten Benutzer wechseln können. Und ich würde erwarten, dass diese Version einen langen Supportzeitraum hat, in den die Leute wechseln können.

Was ist hier das Maß für "die meisten Benutzer"? Wie lautet die Liste der Abhängigkeiten, die abgedeckt werden müssen, bis wir den Support einstellen können? Ihre Liste unterscheidet sich von anderen Benutzern auf dieser Liste. Ich gehe auch davon aus, dass einige Leute sagen werden, für immer oder bis .NET Core die .NET Framework-Parität erreicht (was einfach unrealistisch ist). Ich werde immer noch behaupten, dass ASP.NET Core 1.x für diesen Zweck gut genug ist, und wir sollten versuchen, die Unterstützung dafür bis zu diesem Zeitpunkt zu verlängern.

Das ist falsch. Ich brauche die Bits, die wir benötigen, um auf einer unterstützten Plattform ausgeführt zu werden (z. B. AD-Authentifizierung). Was fehlt, ist die Unterstützung durch letztere. Die Unterstützung für 1.x ist sicherlich mein Hauptanliegen. Wir haben keinen unterstützten Weg nach vorne oder irgendwelche Zeitpläne, wann wir einen erwarten können.

Welche ASP.NET-Komponente fehlt für dieses Szenario? Wenn Sie 1.x vs. 2.x sagen, wäre es hilfreich, wenn Sie ASP.NET Core vs. .NET Core erwähnen.

Wenn DirectoryServices, Drawing usw. in 2.x kommen, dann großartig. Diese Version sollte .NET Framework unterstützen und eine LTS-Version sein. Und 3.x sollte die volle Framework-Unterstützung fallen lassen.

Ich habe das bereits erwähnt, welche ASP.NET Core-Funktionen benötigen Sie, dass ASP.NET Core 1.x dafür nicht ausreicht?

ASP.NET und .NET Core/Standard/was auch immer sind zwei verschiedene Dinge innerhalb von Microsoft (und das verstehe ich total), aber für Entwickler ist es immer noch eine Plattform

Einverstanden, aber wir müssen die FUD zu dieser Diskussion klären, damit wir die Auswirkungen richtig bewerten können. ASP.NET Core 1.x zielt auf .NET Standard 1.x (1.0–1.6) und .NET Framework 4.5.1 ab. Das bedeutet, dass es auf jeder Plattform ausgeführt werden kann, die diese Versionen von netstandard und .NET Framework unterstützt. Das bedeutet, dass ASP.NET Core 1.x auf .NET Core 2.0 ausgeführt wird.

@schmbecker

Wird CSOM in netcore 2 laufen? Das wäre ein großer Blocker für uns und ein Bereich, von dem ich noch nichts gehört habe.

Ich habe keine Ahnung, was das ist. Ist es das https://msdn.microsoft.com/en-us/library/ff798388.aspx? Wenn dies der Fall ist, wurde keine Arbeit geleistet, um dies explizit zu unterstützen. Es könnte nur basierend auf der .NET Framework-Kompatibilität in .NET Core 2.0 funktionieren, aber ich vermute, dass es niemals auf .NET Core portiert wird (nur basierend auf meinen 5 Minuten, in denen ich es mir angesehen habe), aber ich könnte mich irren.

Was ist hier das Maß für "die meisten Benutzer"? Wie lautet die Liste der Abhängigkeiten, die abgedeckt werden müssen, bis wir den Support einstellen können? Ihre Liste unterscheidet sich von anderen Benutzern auf dieser Liste. Ich gehe auch davon aus, dass einige Leute sagen werden, für immer oder bis .NET Core die .NET Framework-Parität erreicht (was einfach unrealistisch ist). Ich werde immer noch behaupten, dass ASP.NET Core 1.x für diesen Zweck gut genug ist, und wir sollten versuchen, die Unterstützung dafür bis zu diesem Zeitpunkt zu verlängern.

Beginnen wir mit den am häufigsten fehlenden APIs – diese verursachen bei den meisten Menschen Blockaden. Für uns ist das DiretoryServices, das ist die Nummer 1. Wenn das nicht einmal da ist, ist das ein wirklich schlechtes Zeichen für die Community. Ich stimme zu, dass Listen unterschiedlich sind, aber wenn wir nicht einmal Nummer 1 enthalten ...

Welche ASP.NET-Komponente fehlt für dieses Szenario? Wenn Sie 1.x vs. 2.x sagen, wäre es hilfreich, wenn Sie ASP.NET Core vs. .NET Core erwähnen.

Ich habe das bereits erwähnt, welche ASP.NET Core-Funktionen benötigen Sie, dass ASP.NET Core 1.x dafür nicht ausreicht?

Ich meine Unterstützung für den neuesten ASP.NET Core, der Full Framework unterstützt (und daher die Bibliotheken, die ich benötige). Ich hoffe , das ist 2.x, da wir Module, Rasierseiten usw. wollen. Wir haben viele 2.x-Features verwendet. Aber es hört sich so an, als ob unsere einzige Option zu diesem Zeitpunkt 1.x ist. Wir können den Sprung von ASP.NET 5 zu ASP.NET Core und vom vollständigen Framework mit all unseren Arbeitsbibliotheken zu netcoreapp nicht in einem Zug schaffen. Es ist zu viel. Es ist zu teuer. Es ist zu riskant. Und jetzt sind wir uns nicht sicher, ob wir diesen teuren, riskanten Schritt innerhalb eines Support-Fensters machen können. Das ist eine schlechte Situation - so schlimm, dass es besser ist, sich nicht zu bewegen (wie die Dinge heute stehen). Das finde ich wirklich schade.

Welche ASP.NET-Komponente fehlt für dieses Szenario? Wenn Sie 1.x vs. 2.x sagen, wäre es hilfreich, wenn Sie ASP.NET Core vs. .NET Core erwähnen.

• Es sei denn, es gibt eine Möglichkeit, AD-Authentifizierung/-Abfragen über ein Microsoft.Authentication.* NuGet-Paket zu verarbeiten, dann ist das eine große Sache. Ich bin derzeit im selben Boot, aber da ich .NET Core 1.1 auf .NET 462 ausführe, werde ich in der Lage sein, das durchzuziehen. Abgesehen davon, wie könnte ich AD-Gruppen und Metadaten über unterstützte Mittel abfragen? Ich habe im Corefx-Repo gesehen, dass eine Menge Arbeit an System.DirectoryServices passiert, also freue ich mich zumindest darüber.

• System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter . Derzeit kann ich darauf nur zugreifen, wenn ich .NET Core zusätzlich zum vollständigen .NET Framework ausführe. Ich denke, es ist eher eine Bequemlichkeitssache, da ich immer noch die DbDataReader / SqlDataReader verwenden kann.

Grundsätzlich muss ich wissen, dass es eine Garantie für EINIGE unterstützte Methode zur Handhabung der AD-Authentifizierung bei der Verwendung von ASP.NET Core 2.x gibt, ohne dass das vollständige .NET Framework erforderlich ist.

Ich habe heute viel darüber nachgedacht und stelle fest, dass meine Bedenken anders sind als die der meisten hier (nicht, dass diese Bedenken nicht genauso wichtig, wenn nicht sogar wichtiger wären).

Ich hänge immer noch an dem Anwendungsfall fest, ASP.NET Core-Pakete auf netstandard zu verbrauchen. Bis zu dieser Ausgabe war ich (vielleicht zu Unrecht) davon ausgegangen, dass netstandard das De-facto-Ziel für Bibliotheken war. Mit anderen Worten, das beabsichtigte Verhalten von Bibliotheksautoren wäre, auf netstandard abzuzielen, es sei denn, es gäbe einen zwingenden und zwingenden Grund, dies nicht zu tun. Dies gewährleistet nicht nur die Kompatibilität mit Framework, sondern auch mit anderen Plattformen wie Xamarin und UWP. Die Arbeit an .NET Standard 2.0 schien dies zu unterstützen, indem versucht wurde, die API-Oberfläche der verschiedenen Laufzeiten zu einem gemeinsamen Ziel zu vereinheitlichen, an das man nicht denken muss.

Für mich signalisiert diese Änderung etwas anderes. Zugegeben, am Ende des Tages ist ASP.NET Core nur eine Bibliothek und hat vielleicht „notwendige und zwingende Gründe“, die gemeinsame netstandard -Oberfläche nicht zu unterstützen. Aber es ist auch eine der sichtbarsten von Microsoft entwickelten .NET-Bibliotheken, und indem es sagt: „Wir wollen das Neueste und Beste, also werden wir die Unterstützung netstandard “, signalisiert es allen anderen Bibliotheksentwicklern (oder at zumindest für mich), dass sie vielleicht aufhören sollten, sich so sehr zu bemühen, netstandard zu unterstützen, und einfach anfangen sollten, die Core-Laufzeit ins Visier zu nehmen. Warum sich mit all dem Kompatibilitätskram herumschlagen, wenn Microsoft sich nicht einmal so sehr darum kümmert? .NET Core 4-Lyfe. Und vielleicht ist das das Beste – es ist sicherlich anders als ich dachte, dass wir mit mehreren Laufzeiten und einer größtenteils einheitlichen API-Oberfläche gehen würden.

Diese Besorgnis wird noch größer, wenn man bedenkt, dass ASP.NET Core viele, viele Bibliotheken enthält, die außerhalb des Kontexts von ASP.NET direkt nützlich sind. Vielleicht war es falsch anzunehmen, dass diese jemals isoliert verwendet werden sollten, aber es wäre eine schreckliche Schande, sie zu verlieren. Bibliotheksautoren, die sie verwenden möchten, müssen sich entscheiden, ihr eigenes Targeting ebenfalls auf .NET Core umzustellen oder auf netstandard zu bleiben und den Zugriff auf sie zu verlieren. Ich vermute, dass viele die frühere, weiter zersplitternde Bibliotheksunterstützung für alternative Plattformen wählen werden. Zumindest wenn ich die Kommentare hier verstanden habe, dass es zu schwierig ist, verschiedene Plattformen für die unterstützenden Bibliotheken anzusprechen.

Schließlich bin ich etwas (wenn auch etwas weniger) besorgt über die Kommentare hier, dass, sobald es möglich ist, neue APIs zu Core hinzugefügt werden, um in Verbindung mit ASP.NET zu revisieren. Insbesondere, dass diese neuen APIs es möglicherweise nie in netstandard oder .NET Framework schaffen. Ich verstehe sicherlich, dass es einige aufregende Dinge geben kann, die getan werden können, wenn die Legacy- und Kompatibilitätsbedenken fallen gelassen oder gelockert werden. Aber um ehrlich zu sein, ich habe den Eindruck gewonnen, dass das ASP.NET Core-Team oft da draußen vorprescht. Das ist nicht unbedingt eine schlechte Sache, aber es hat auch zu einer Reihe umfassenderer Entscheidungen geführt, die zurückgenommen werden mussten. Ich kann nicht umhin, mich zu fragen, ob dies und die anschließende schnelle Entwicklung der Core-Laufzeit dazu führen wird, dass die Menge der Laufzeiten im Laufe der Zeit stark gebrochen wird (und noch einmal, es ist nicht nur Windows/Framework, das zurückgelassen wird - es gibt auch Xamarin, Mono, UWP usw.).

Dieser ganze Thread hat mich veranlasst, mein Verständnis der Zukunft von .NET um .NET Core statt um netstandard herum zu orientieren. Vielleicht bin ich extrem und das wird in den kommenden Wochen nachlassen, oder vielleicht ist das sogar die beabsichtigte Position und es ist alles das Beste – so oder so, ich bin derzeit versucht, einfach loszugehen und .NET Core für mich selbst ins Visier zu nehmen Sachen und konzentriere dich nur darauf, nach allem, was ich hier gelesen habe.

@ Nick Craver

Ich meine Unterstützung für den neuesten ASP.NET Core, der Full Framework unterstützt (und daher die Bibliotheken, die ich benötige). Ich hoffe, das ist 2.x, da wir Module, Rasierseiten usw. wollen. Wir haben viele 2.x-Features verwendet.

Im Moment ist es 1.1.1 (es gibt keine Module in 2.0), Razor Pages ist gut, ein anderes ist SignalR. Das sind die 2 Dinge, die ich als Teil davon am schmerzhaftesten sehe.

Wir können den Sprung von ASP.NET 5 zu ASP.NET Core und vom vollständigen Framework mit all unseren Arbeitsbibliotheken zu netcoreapp nicht in einem Zug schaffen. Es ist zu viel. Es ist zu teuer. Es ist zu riskant. Und jetzt sind wir uns nicht sicher, ob wir diesen teuren, riskanten Schritt innerhalb eines Support-Fensters machen können. Das ist eine schlechte Situation - so schlimm, dass es besser ist, sich nicht zu bewegen (wie die Dinge heute stehen). Das finde ich wirklich schade.

Ist es trotzdem? Der Wechsel von ASP.NET Core 1.x zu 2.x oder 3.x wäre trivial, vorausgesetzt, Ihre Abhängigkeiten wurden portiert. Wenn Sie im Allgemeinen planen, zu ASP.NET Core zu wechseln, ist die Umstellung auf 1.1 ein guter erster Schritt, und Sie sparen keine Arbeit, wenn Sie dies vermeiden.

@schnickler

Grundsätzlich muss ich wissen, dass es eine Garantie für EINIGE unterstützte Methode zur Handhabung der AD-Authentifizierung bei der Verwendung von ASP.NET Core 2.x gibt, ohne dass das vollständige .NET Framework erforderlich ist.

Bis System.DirectoryServices auf .NET Core unterstützt wird, gibt es dann einen Grund, warum Sie ASP.NET Core 1.x nicht auf .NET Framework verwenden können?

Bis System.DirectoryServices auf .NET Core unterstützt wird, gibt es dann einen Grund, warum Sie ASP.NET Core 1.x nicht auf .NET Framework verwenden können?

Das mache ich gerade. Ich freue mich nur in der Hoffnung, dass ich mich nicht um das .NET Framework kümmern muss, wenn ich es nicht muss. Derzeit beschränkt es mich auf meinen Windows-Rechner, da der Namespace System.DirectoryServices.AccountManagement in Mono nicht existiert. Wird in dieser Hinsicht System.DirectoryServices.AccountManagement außerhalb der Beschränkungen von Windows verfügbar sein? Dieses eine kleine Stück zwingt mich, zwischen Computern zu wechseln, während ich mein MVC-Projekt und meine Xamarin.iOS-App lokal debugge.

Wenn Sie im Allgemeinen planen, zu ASP.NET Core zu wechseln, ist die Umstellung auf 1.1 ein guter erster Schritt, und Sie sparen keine Arbeit, wenn Sie dies vermeiden.

Ich stimme voll und ganz zu, wenn wir wüssten, dass Support da ist, bis wir auf eine andere Plattform aktualisiert haben, die funktioniert hat . Im Moment wissen wir nicht, wann die erforderlichen Bits in der .NET Core-Welt verfügbar sein werden. Wenn ich also jetzt eine zeitliche Obergrenze festlege und nicht weiß, wann diese Bits später kommen, setze ich auf ein Versprechen. Das ist das Kernproblem. Wenn wir eine unterstützte, sich überschneidende Version haben, die eine Portierung erlaubt, wäre ich bereit und würde gerne investieren. Wenn die Unterstützung eingestellt wird, bevor die APIs da sind, überspringen wir eine Glaubenslücke mit einer unbekannten Menge an Landebahn.

Ich verweise immer wieder auf DirectoryServices, weil ich weiß , dass das heute auf netcoreapp2.0 nicht funktioniert. Es wird natürlich andere Dinge geben, die wir finden, die in dasselbe Boot fallen. Wir brauchen ASP.NET Core + vollständiges Framework + Unterstützung für mehrere Jahre auf einigen Plattformen. Mit 1.x bekommen wir nicht viele Gewinne, wir bekommen eigentlich sehr wenig. Leistung ist kein großartiges Argument, da wir Seiten bereits in ~18 ms rendern und sie durch die Transportzeit in den Schatten gestellt wird. 2.0 bietet jedoch einige gute Punkte. Razor-Seiten und die Aussicht auf Plugins machen die Portierung sehr attraktiv. Soweit vertretbar.

Im Moment ist die einzige Version mit Support (1.1.x mit längerer Unterstützung, das erwarte ich nach dem Lesen dieses Threads) nicht den Umstieg wert. Es wäre im Grunde eine Menge Zeit und Mühe, dorthin zu gelangen, wo wir heute sind. 2.x bietet zumindest einige anständige Verbesserungen und Bits, die wir nutzen möchten. Sie helfen, die Umzugskosten zu rechtfertigen.

Leistung ist kein großartiges Argument, da wir Seiten bereits in ~18 ms rendern

Bei einem kleinen OT-Rant würde ich gerne wissen, wie Sie Seiten in ~ 18 ms @NickCraver rendern können . Das ist großartig

@daveaglick

Ich hänge immer noch an dem Anwendungsfall, ASP.NET Core-Pakete auf Netstandard zu konsumieren. Bis zu dieser Ausgabe war ich (vielleicht zu Unrecht) davon ausgegangen, dass netstandard das De-facto-Ziel für Bibliotheken ist. Mit anderen Worten, das beabsichtigte Verhalten von Bibliotheksautoren wäre es, auf Netstandard abzuzielen, es sei denn, es gäbe einen zwingenden und zwingenden Grund, dies nicht zu tun. Dies gewährleistet nicht nur die Kompatibilität mit Framework, sondern auch mit anderen Plattformen wie Xamarin und UWP. Die Arbeit an .NET Standard 2.0 schien dies zu unterstützen, indem versucht wurde, die API-Oberfläche der verschiedenen Laufzeiten zu einem gemeinsamen Ziel zu vereinheitlichen, an das man nicht denken muss.

Hier hat sich nichts geändert. Tatsächlich sind einige unserer Bibliotheken, die wir auf anderen Plattformen ausführen möchten, immer noch Netzstandard. Wenn Sie einige der oben genannten Punkte noch einmal lesen:

• Microsoft.Extensions.* (Protokollierung, DI, Konfiguration, Dateianbieter usw.)
• EntityFramework
• SignalR-Clients (sie müssen auf .NET Framework, Xamarin, UWP usw. ausgeführt werden).

.NET Standard ist die Defacto-Methode zum Schreiben von Bibliotheken, die überall ausgeführt werden. Bibliotheksautoren sollten darauf abzielen, wenn möglich auf Netstandard abzuzielen, um die größtmögliche Plattformreichweite zu erzielen. Bibliotheksautoren müssen entscheiden, ob sie Reichweite haben wollen oder nicht. Aus diesem Grund unterstützen Bibliotheken wie JSON.NET netstandard1.x und .NET Framework 2.0. Sie gehen noch einen Schritt weiter, damit die Dinge „einfach funktionieren“, wie @JamesNK oben erwähnt hat.

Dass sich ASP.NET Core an einigen Stellen vom Netstandard entfernt, ist eher eine Aussage, dass diese APIs nicht für UWP-Anwendungen gedacht sind und wir sie dort sicherlich nicht testen (als Beispiel). Es versucht auch zu verdeutlichen, dass .NET Core und ASP.NET Core ein einzelnes Produkt sind, das zusammen versioniert wird (da es Core im Namen hat). Da ASP.NET Core 1.x sowohl .NET Core als auch .NET Framework unterstützt, war diese Nachricht ein wenig verschwommen und führte bei vielen Menschen (insbesondere neuen Entwicklern) zu Verwirrung. Wir haben dies getan, um das Bibliothekslückenproblem zu lösen.

Diese Besorgnis wird noch größer, wenn man bedenkt, dass ASP.NET Core viele, viele Bibliotheken enthält, die außerhalb des Kontexts von ASP.NET direkt nützlich sind. Vielleicht war es falsch anzunehmen, dass diese jemals isoliert verwendet werden sollten, aber es wäre eine schreckliche Schande, sie zu verlieren. Bibliotheksautoren, die sie verwenden möchten, müssen sich entscheiden, ihr eigenes Targeting ebenfalls auf .NET Core umzustellen oder auf Netstandard zu bleiben und den Zugriff darauf zu verlieren. Ich vermute, dass viele die frühere, weiter zersplitternde Bibliotheksunterstützung für alternative Plattformen wählen werden. Zumindest wenn ich die Kommentare hier verstanden habe, dass es zu schwierig ist, verschiedene Plattformen für die unterstützenden Bibliotheken anzusprechen.

Ich vermute, das sind immer noch netstandard. Welche nicht?

Ich kann nicht umhin, mich zu fragen, ob dies und die anschließende schnelle Entwicklung der Core-Laufzeit dazu führen wird, dass die Menge der Laufzeiten im Laufe der Zeit stark gebrochen wird (und noch einmal, es ist nicht nur Windows/Framework, das zurückgelassen wird - es gibt auch Xamarin, Mono, UWP usw.).

Ich denke, Netstandard wird sich weiterentwickeln, aber .NET Framework wird immer das letzte sein, das neue APIs erhält (Xamarin und Mono sind ziemlich schnell, um Dinge hinzuzufügen).

@schnickler

Das mache ich gerade. Ich freue mich nur in der Hoffnung, dass ich mich nicht um das .NET Framework kümmern muss, wenn ich es nicht muss. Derzeit beschränkt es mich auf meinen Windows-Computer, da der System.DirectoryServices.AccountManagement-Namespace in Mono nicht vorhanden ist. Wird in dieser Hinsicht System.DirectoryServices.AccountManagement außerhalb der Beschränkungen von Windows verfügbar sein? Dieses eine kleine Stück zwingt mich, zwischen Computern zu wechseln, während ich mein MVC-Projekt und meine Xamarin.iOS-App lokal debugge.

Stellen Sie sicher, dass Sie solche Probleme auf dotnet/corefx melden. Anzunehmen, dass Ihre Abhängigkeiten portiert werden (es sei denn, es ist sehr beliebt), ist das Falsche.

@davidfowl Frage: Ich möchte Datei -> Neues Projekt mit ASP.NET Core 2.0 und mich gegen AD authentifizieren. Wird dies möglich sein? Ich kann mir einfach nicht vorstellen, dass eine Microsoft-Plattform ohne diese Möglichkeit ausgeliefert wird.

Ich bin mit allem einverstanden, aber ich sehe nicht, wie sich diese Entscheidung auf das auswirkt, was Sie gesagt haben. Ich will all die gleichen Dinge

Durch das Einstellen der Unterstützung für .NET v4.x wird ein beliebter Migrationspfad beendet und das .NET-Ökosystem noch weiter fragmentiert und viele Entwickler und Organisationen daran gehindert, es zu übernehmen, was den breiteren Community-Pool an Wissen und Investitionen in ASP verringern wird. NET Core, da viele .NET-Entwickler ihre bestehenden ASP.NET v4.x-Codebasen auf unbestimmte Zeit unterstützen müssen (für deren Arbeit sie in Vollzeit bezahlt werden).

Je kleiner der Marktanteil von .NET Core ist, desto geringer ist die Priorität für Bibliotheksbetreuer, es zu unterstützen, und einige werden es wahrscheinlich nie tun, wenn sie für eine Organisation arbeiten, die aus diesem Grund nicht mehr in der Lage sein wird, eine Migration zu ASP.NET Core in Betracht zu ziehen dies, was sich wiederum auf alle anderen auswirkt, abhängig von ihren Paketen, und so weiter. Dies sind alles Nebeneffekte der zunehmenden Belastung bei der Einführung von ASP.NET Core, da keine stabile Plattform und keine langfristigen Supportgarantien vorhanden sind und jetzt ein beliebter Migrationspfad beendet wird.

Ich glaube, jeder hier möchte, dass das .NET-Ökosystem gedeiht, aber es scheint, dass wir uns mit dem MS-Team darüber uneins sind, wie wir dies am besten erreichen können, da ich fest davon überzeugt bin, .NET v4.x so früh vor einer bekannten Menge fallen zu lassen, hochkompatibel, stabiles LTS-Release verfügbar ist, ist ein Fehler, der sich über Jahre nachteilig auswirken wird.

@davidfowl Danke - dein Kommentar hilft sehr. Ich hatte (anscheinend falsch) festgestellt, dass die meisten/alle unterstützenden Bibliotheken im Rahmen dieser Änderung von netstandard abgezogen wurden. Ich benutze ziemlich viele und kenne andere, die das auch tun, also ist es eine willkommene Nachricht zu hören, dass sie es nicht sind.

@NickCraver , welche Art von Authentifizierung verwenden Sie heute gegen AD? OpenIdConnect, WsFed, NTLM, andere?

@Tratcher AD-Authentifizierung über DirectoryServices (wir müssen die Gruppenmitgliedschaft usw. abfragen - die Standardbits)

@mythz Ich denke, das ist vernünftig, und ich denke, die Verlängerung der Support-Lebensdauer von ASP.NET Core 1.x würde ausreichen, um die meisten Fälle abzudecken.

Ich verstehe, warum Sie diese Entscheidung irgendwann treffen müssen, aber auch ich glaube, dass es verfrüht ist und wäre am glücklichsten mit:

• ASP.NET Core 2.x ist LTS und das letzte, das Full Framework unterstützt (da wir uns bereits in der Vorschau befanden, sind Sie sicherlich nicht allzu weit entfernt), und SignalR folgt später im Jahr und unterstützt es, sodass es das Zielframework für den Sprung ist von ASP.NET zu ASP.NET Core
• 3.x stellt die Unterstützung für Full Framework ein und wird freigegeben, wenn die wichtigsten Abhängigkeiten migriert werden

Die einfache Erweiterung der Unterstützung für ASP.NET Core 1.1 wäre meiner Ansicht nach nicht ausreichend, da diese Plattform nicht ausgereift/akzeptiert genug ist, um ein Ziel für viele ASP.NET-Migrationen zu sein (in meinem Fall ist SignalR der Blocker).

Nur zum Spaß habe ich versucht, EntityFramework 6 zu verwenden – das ich in ASP.NET Core 1.0-Apps, an denen ich gearbeitet habe, massiv verwendet habe – mit den neuesten nächtlichen Builds von preview2 .NET Core. Erraten Sie, was...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

Hören Sie auf, so zu tun, als würden Assemblys, die für das vollständige Framework entworfen und kompiliert wurden, unter .NET Core einwandfrei funktionieren: Triviale Fälle (Lesen Sie Hallo-Welt-Apps) werden wahrscheinlich funktionieren, aber in vielen Fällen werden Sie am Ende durch fehlende APIs oder nicht funktionierende APIs blockiert .

Was absolut schrecklich ist, ist, dass Sie erst zur Laufzeit feststellen werden, dass es nicht funktioniert. In einigen Fällen wird es überhaupt nicht offensichtlich sein. Beispielsweise unterstützt SqlClient .NET Core weder die Eintragung von Umgebungstransaktionen noch verteilte Transaktionen mit TransactionScope : selbst wenn Sie einen Weg finden, EF 6 zum Laufen zu bringen, Ihre TransactionScope s wird überhaupt nicht effektiv sein und Ihre DB-Aufrufe werden nicht die Isolationsstufe verwenden, die Sie benötigen.

Ich halte es für notwendig, hier meinen Senf dazuzugeben, was meine Bedenken bezüglich dieses Schrittes anbelangt. Wir haben eine Desktop-Anwendung, die hauptsächlich Windows Forms mit einigen der neueren Bereiche ist, die in WPF entwickelt wurden. In diese Anwendung wurden über 15 Jahre investiert, und es wird Jahre dauern, sich vollständig von WinForms zu entfernen. Ich wünschte, das wäre nicht der Fall, aber es ist so. Wir haben daran gearbeitet, mehr Modularität in die Codebasis einzubauen, damit wir die Geschäfts- und Datenzugriffsebenen über eine neuere Webschnittstelle und die vorhandene WinForms-Anwendung nutzen können. Ich hatte vor, für unsere neuere Webanwendung sehr bald zu ASP.NET Core zu wechseln, aber wie ich gerade gesagt habe, muss ich einen Großteil unserer vorhandenen Codebasis verbrauchen, die auf .NET v4.6.x abzielt. Ich weiß sicher, dass wir System.Drawing und System.Security.Cryptography verwenden. Wir nutzen TransactionScope auch auf die oben erwähnte Weise intensiv.

Ich habe mich sehr darauf gefreut, einige der Vorteile von ASP.NET Core zu nutzen, wie z. B. die Möglichkeit, Bereiche unserer Webanwendung in separate Assemblys zu kapseln, ohne mich auf MEF verlassen zu müssen, um alles zusammenzuführen. Es gibt viele zusätzliche Gründe, aber das ist es, was es wirklich schön macht. Wenn ich unsere Anwendung jedoch auf ASP.NET Core umstelle, bleibe ich wahrscheinlich auf absehbare Zeit bei 1.x hängen, da wir die Portabilität unseres Back-End-Codes mit WinForms aufrechterhalten müssen. Ich habe mich hauptsächlich auf das Webprodukt konzentriert, daher kann ich Ihnen nicht sagen, wo wir uns in Dinge wie WMI usw. einklinken und ob dies die Frage der Portabilität beeinflusst, aber ich weiß, dass wir uns innerhalb unserer Codebasis befinden. Wir befinden uns gerade in einer wirklich interessanten Phase, und das Letzte, was ich tun möchte, ist, alle Webversionen unserer Funktionen auf ASP.NET MVC 5 zu entwickeln und eine Menge neuen Legacy-Codes zu sammeln, der irgendwann portiert werden muss zukünftiges Unterfangen.

Ich bin mir sicher, dass wir viele Verwendungen haben werden, die uns davon abhalten, auf .NET Standard abzuzielen, selbst wenn/wenn wir WinForms nicht mehr verwenden. Wir sind ein Microsoft-Partner und arbeiten für unser Produkt auf verschiedene Weise direkt mit Microsoft zusammen, daher möchte ich nicht zu sehr ins Detail gehen, was wir hier tun, aber ich würde mich über eine privatere Diskussion mit @ freuen. @davidfowl , wenn Sie weitere Einzelheiten zu unserer Arbeit benötigen. Ich werde auch auf der MS Build sein und könnte mich dort mit jedem von Ihnen treffen und mit ihm sprechen, wenn Sie anwesend sind.

Ich denke, Sie haben noch nicht in Betracht gezogen, dass Unternehmen Ihren Stack mit dieser Art von Herausforderungen verwenden. Vollständiger Haftungsausschluss: Ich beabsichtige, den zuvor erwähnten Portabilitätsanalysator auszuführen, um zu sehen, wo wir tatsächlich feststecken, weil wir diese Portabilität innerhalb unserer Codebasis aufrechterhalten müssen. Ich stelle Ihnen gerne eine Liste aller .NET Framework-APIs zur Verfügung, die diese Prüfung nicht bestehen.

Mouahaha. Ich bin mir nicht sicher ob ich lachen oder weinen soll...

Hier ist der vom ApiPort-Analysetool generierte Bericht für meine triviale 23-zeilige EF 6-App, die nicht funktioniert:

Cross-Compiling ist ein Mehraufwand, der mit den Kunden- und Produktanforderungen in Einklang gebracht werden muss. Aus diesem Grund möchten wir dieses Feedback erhalten, damit wir konkreter definieren können, wie die Landschaft sowohl für unsere Kunden als auch für uns aussieht, während wir ASP.NET Core weiterentwickeln.

Gab es vor der Eröffnung dieser Ausgabe einen Feedback-Prozess?

Wir sprechen alle über Zeitrahmen und Unterstützung für 1.1, aber die Tatsache, dass ASP.NET Core das vollständige Framework überhaupt fallen lässt, hat mich sehr überrascht.

Mein Verständnis war, dass das Kernframework ein plattformübergreifendes Spiel war, ein neues Framework, das aus einer Teilmenge des vollständigen Frameworks besteht, das nicht an Windows gekoppelt ist. Die Version 2.0 war die, auf die wir alle gewartet haben, wo wir die meisten APIs zurückbekommen.

ASP.NET Core war das Hundefutter für dieses neue Framework, ein neues Webframework, das von einer so kleinen Oberfläche von Framework-APIs abhängig war, dass es überall ausgeführt werden konnte.

Ich hatte erwartet, dass, sobald das Kern-Framework eine enge Parität mit dem vollständigen Framework erreicht hat, alle neuen APIs zu Netstandard hinzugefügt werden und es schließlich in beide Frameworks schaffen würden. Wir würden alle auf Netstandard abzielen und alles wäre ein Regenbogen und ein Einhorn.

Jetzt zu finden, dass ASP.NET nicht einmal den Netstandard dogfood und Framework-spezifisch wird, eh :/

@rohatsu

Die einfache Erweiterung der Unterstützung für ASP.NET Core 1.1 wäre meiner Ansicht nach nicht ausreichend, da diese Plattform nicht ausgereift/akzeptiert genug ist, um ein Ziel für viele ASP.NET-Migrationen zu sein (in meinem Fall ist SignalR der Blocker).

Was wäre, wenn SignalR auf ASP.NET Core 1.x funktionieren würde? Was ist noch unausgereift an der Plattform, die Sie benötigen?

@millman82 Danke, dass du das geteilt hast. Es hört sich so an, als würden Sie bei der Version hängen bleiben, bevor die .NET Framework-Unterstützung für eine Weile eingestellt wurde. Einige der Vorschläge hier, bei denen wir 2.x-kompatibel halten und 3.x fallen lassen, funktionieren möglicherweise nicht einmal für Sie. Warum bleiben Sie nicht einfach bei ASP.NET Core 1.x? Was fehlt noch, was Sie in Ihrem Hafen brauchen? Oder ist es nur die gleiche Sorge wie bei @NickCraver (dass 2.x es nicht unterstützt, macht Sie nervös, wenn Sie darauf wetten).

@jkells

Ich hatte erwartet, dass, sobald das Kern-Framework eine enge Parität mit dem vollständigen Framework erreicht hat, alle neuen APIs zu Netstandard hinzugefügt werden und es schließlich in beide Frameworks schaffen würden. Wir würden alle auf Netstandard abzielen und alles wäre ein Regenbogen und ein Einhorn.

Das ist nicht weit hergeholt, es fehlt nur die Zeitkomponente. Wird es schließlich in alle Rahmenbedingungen schaffen, die jeder nach seinem eigenen Zeitplan versendet.

Jetzt zu finden, dass ASP.NET nicht einmal den Netstandard dogfood und Framework-spezifisch wird, eh :/

Ein Teil davon zielt immer noch auf netstandard ab, wie mehrfach in diesem Thread erwähnt wurde.

Warum bleiben Sie nicht einfach bei ASP.NET Core 1.x?

Sie können nicht - es wird 1 Jahr nach der Veröffentlichung von 2.0 nicht mehr unterstützt (vorausgesetzt, 2.0 ist das nächste LTS).

@davidfowl Es ist definitiv ein großer Teil davon. Wir verwenden auch OData und SignalR in unserer aktuellen Webanwendung, und das muss in ASP.NET Core sein, bevor wir wechseln können. Was ich jedoch nicht möchte, ist, in der Schwebe zu bleiben, wenn die Unterstützung für ASP.NET Core 1.x eingestellt wird und es keinen Migrationspfad mit den von uns verwendeten Frameworkteilen gibt, die derzeit nicht unterstützt werden. Ich gehe davon aus, dass ASP.NET Core ASP.NET en gros ersetzen wird. Es mag irgendwo auf der Straße sein, aber es kommt. Da ich weiß, dass ich es hassen würde, unsere Benutzeroberfläche jetzt in ASP.NET MVC 5 neu zu schreiben (wir haben jetzt ein paar Dinge dort, aber es ist leicht zu verschieben, weil es klein ist), nur um es ein paar Jahre später erneut in ASP.NET Core neu zu schreiben sobald das Lebensende für ASP.NET erreicht ist.

Wir könnten uns möglicherweise darauf einstellen, schwer verbrannt zu werden, wenn dieser Migrationspfad nicht vorhanden ist, wenn EOL von ASP.NET Core 1.x eintrifft, wenn es in der Zwischenzeit erweitert wird, wenn wir jetzt auf Core 1.x abzielen. Wir könnten wahrscheinlich einiges davon mit Mikrodiensten umgehen, aber das hat natürlich seine eigenen Bedenken.

@ctolkien

Sie können nicht - es wird 1 Jahr nach der Veröffentlichung von 2.0 nicht mehr unterstützt (vorausgesetzt, 2.0 ist das nächste LTS).

Nehmen Sie für eine Sekunde an, dass es nicht aus dem Support ist, wenn 2.0 fällt. Ist das nicht genug?

Was ich jedoch nicht möchte, ist, in der Schwebe zu bleiben, wenn die Unterstützung für ASP.NET Core 1.x eingestellt wird und es keinen Migrationspfad mit den von uns verwendeten Frameworkteilen gibt, die derzeit nicht unterstützt werden

Ersetzen Sie in diesem Satz 1.x durch 2.x. Glauben Sie, dass in einem Jahr alle Ihre Abhängigkeiten portiert wären?

Ersetzen Sie in diesem Satz 1.x durch 2.x. Glauben Sie, dass in einem Jahr alle Ihre Abhängigkeiten portiert wären?

Überhaupt nicht, aber ich würde erwarten, dass sie es wären, wenn sie nicht mehr auf .NET Full abzielen könnten. Ich verstehe, warum Sie das vorantreiben möchten, aber ich glaube nicht, dass Sie erwarten können, dass Unternehmen etwas übernehmen, das aus dem Support fällt, ohne die Möglichkeit, auf eine neuere Version umzusteigen, weil die fehlenden Abhängigkeiten nicht portiert wurden.

Ich glaube nicht, dass Sie erwarten können, dass Unternehmen etwas übernehmen, das aus dem Support fällt, ohne die Möglichkeit, auf eine neuere Version umzusteigen, weil die fehlenden Abhängigkeiten nicht portiert wurden.

Warum sollte es aus der Unterstützung fallen? In meiner hypothetischen Welt würden wir ASP.NET Core 1.x auf .NET Framework länger unterstützen.

Warum sollte es aus der Unterstützung fallen? In meiner hypothetischen Welt würden wir ASP.NET Core 1.x auf .NET Framework länger unterstützen.

Meine Frage ist wie lange noch? Ist das Team außerdem groß genug, um die notwendigen Abhängigkeiten wie SignalR und OData auf ASP.NET Core 1.x zu bringen und den Support aufrechtzuerhalten, bis alle diese fehlenden Abhängigkeiten tatsächlich portiert wurden? Scheint, als würde es den zuvor vorgebrachten Argumenten widersprechen, warum Sie die vollständige Unterstützung von .NET jetzt einstellen möchten. Ehrliche Frage...

Meine Frage ist wie lange noch? Ist das Team außerdem groß genug, um die notwendigen Abhängigkeiten wie SignalR und OData auf ASP.NET Core 1.x zu bringen und den Support aufrechtzuerhalten, bis alle diese fehlenden Abhängigkeiten tatsächlich portiert wurden? Scheint, als würde es den Argumenten widersprechen, die früh vorgebracht wurden, warum Sie die vollständige Unterstützung von .NET jetzt einstellen möchten. Ehrliche Frage...

Ich werfe eine Zufallszahl raus, 3 Jahre. Das ASP.NET-Team besitzt die Odata-Integration nicht, das Odata-Team jedoch, daher kann ich nicht für sie antworten. Was SignalR betrifft, denke ich, dass es möglich wäre, auf ASP.NET Core 1.x abzuzielen.

Das Problem, das ich sehe, ist, dass jede Person einen anderen Satz von "fehlenden Abhängigkeiten" hat, was es unmöglich macht, darüber nachzudenken, wann es überhaupt "in Ordnung" ist, die .NET Framework-Unterstützung für alle einzustellen. Es ist auch wahrscheinlich, dass einige dieser Abhängigkeiten niemals portiert werden (wie CSOM).
Wenn Sie im 1.x-Zug sind, erhalten Sie natürlich Fehlerkorrekturen und kleinere Funktionen, aber der Großteil der Arbeit würde immer noch in der neuesten Version von ASP.NET Core stattfinden.

Außerdem hindert Sie nichts davon daran, .NET Core 2.0 oder .NET Standard 2.0 mit ASP.NET Core 1.x zu verwenden. Ich möchte nur sicherstellen, dass sich jeder dessen bewusst ist, da dieser Thread ständig ASP.NET Core mit .NET Core zusammenführt (was einer der Gründe ist, warum wir nur .NET Core anvisieren möchten).

Das Problem, das ich sehe, ist, dass jede Person einen anderen Satz von "fehlenden Abhängigkeiten" hat, was es unmöglich macht, darüber nachzudenken, wann es überhaupt "in Ordnung" ist, die .NET Framework-Unterstützung für alle einzustellen.

Wenden Sie sich an das Ökosystem, um herauszufinden, was die Liste ist (nein, diese Ausgabe ist nicht der richtige Ort dafür). Wenn es sich um eine Microsoft-eigene Abhängigkeit handelt, portieren Sie sie. Wenn dies nicht der Fall ist, wenden Sie sich an den Eigentümer, um ihn über die Pläne zu informieren und mit einem Migrationsleitfaden zu unterstützen (wenn er nichts unternimmt, ist Microsoft nicht schuld). Unterstützen Sie in der Zeit, die für diesen Prozess benötigt wird, ASP.net Core 1.x. Ich sehe keinen anderen Weg, um Ihre Ziele zu erreichen, ohne viele Leute zu verärgern. Dies ist eine große Sache, die vorgeschlagen wird, die ein hohes Maß an Sorgfalt und Aufmerksamkeit erfordert, um richtig zu handeln.

Ich persönlich denke, dass es viel mehr Verwirrung um .NET Framework vs. .NET Standard vs. .NET Core gibt. Als ich sah, dass ich auf .NET Framework abzielen könnte, habe ich nie gesagt: „Aber das ist ASP.NET Core, also warum kann ich .NET Framework verwenden?“. Die Unterschiede zwischen den oben genannten sind für die meisten Ihrer Kunden weitaus verwirrender. Ich liebe alles, was ASP.NET Core tut. Ich liebe auch die Richtung mit .NET in Bezug auf Plattformunabhängigkeit. Ich denke nur, dass der Bereich der Verwirrung falsch angegeben ist. Ich würde sagen, dass die Mehrheit Ihrer Benutzerbasis eine gewisse Menge an Code haben wird, der aufgrund der Art dessen, was er tut, und der APIs, auf die er innerhalb des Frameworks abzielt, nicht portierbar ist.

Ich bevorzuge es, innerhalb von .NET Core und .NET Standard und .NET Framework auf die API-Parität hinzuarbeiten. Finden Sie auch heraus, welches Ziel die Leute anstreben sollten. Wie ich, glaube ich, bereits gesagt habe, fühlt sich .NET Standard wie ein Pflaster an, vielleicht auf eine etwas andere Art und Weise. Irgendwann würde ich erwarten, dass .NET Core die einzige „Framework“-Option ist, und wenn das passiert, bleiben .NET Framework und .NET Standard auf der Strecke. Ich selbst, und ich denke, die meisten, die sich seit der Ankündigung zu Wort gemeldet haben, würden gerne weiterhin von der Arbeit profitieren, die Sie auf der ASP.NET Core-Seite leisten, ohne die Freiheit zu haben, was sie ihren Code obendrauf ausführen entfernt zu werden.

Ich denke, dass Fälle, die als außergewöhnlich betrachtet werden, wie meiner, wo ich von Dingen wie WMI abhängig bin, nicht so außergewöhnlich sind, wie das Team vielleicht denkt. Auch hier werde ich die Nachforschungen anstellen und sehen, was fehlt (obwohl mich der Beitrag mit falschen Portabilitätsergebnissen ein wenig besorgt über die Genauigkeit macht) und ich werde Ihnen das gerne in einem privateren Medium mitteilen.

Unterm Strich sind wir leidenschaftlich dabei, weil wir es nutzen wollen.

Ich persönlich denke, dass es viel mehr Verwirrung um .NET Framework vs. .NET Standard vs. .NET Core gibt. Als ich sah, dass ich auf .NET Framework abzielen könnte, habe ich nie gesagt: „Aber das ist ASP.NET Core, also warum kann ich .NET Framework verwenden?“. Die Unterschiede zwischen den oben genannten sind für die meisten Ihrer Kunden weitaus verwirrender. Ich liebe alles, was ASP.NET Core tut. Ich liebe auch die Richtung mit .NET in Bezug auf Plattformunabhängigkeit. Ich denke nur, dass der Bereich der Verwirrung falsch angegeben ist. Ich würde sagen, dass die Mehrheit Ihrer Benutzerbasis eine gewisse Menge an Code haben wird, der aufgrund der Art dessen, was er tut, und der APIs, auf die er innerhalb des Frameworks abzielt, nicht portierbar ist.

Wir haben viele Kunden und wir haben neue Entwickler, die .NET noch nie in ihrem Leben gesehen haben. Wir müssen allen gerecht werden, denn das versuchen wir als Microsoft zu tun. Leute, die auf .NET Framework laufen, wissen, lieben und verstehen, dass es funktioniert, also stellen Sie sicher, dass Sie verstehen, dass ASP.NET Core auf .NET Framework läuft, aber als neuer Entwickler, der sich der Plattform nähert, würde ich hoffen, das nie zu erwähnen, da es die Geschichte im Vergleich dazu trübt etwas wie go oder node (die zu diesem Zeitpunkt so ziemlich 0 Vermächtnisse haben).

Ich bevorzuge es, innerhalb von .NET Core und .NET Standard und .NET Framework auf die API-Parität hinzuarbeiten. Finden Sie auch heraus, welches Ziel die Leute anstreben sollten. Wie ich, glaube ich, bereits gesagt habe, fühlt sich .NET Standard wie ein Pflaster an, vielleicht auf eine etwas andere Art und Weise. Irgendwann würde ich erwarten, dass .NET Core die einzige „Framework“-Option ist, und wenn das passiert, bleiben .NET Framework und .NET Standard auf der Strecke. Ich selbst, und ich denke, die meisten, die sich seit der Ankündigung zu Wort gemeldet haben, würden gerne weiterhin von der Arbeit profitieren, die Sie auf der ASP.NET Core-Seite leisten, ohne die Freiheit zu haben, was sie ihren Code obendrauf ausführen entfernt zu werden.

Diese Dinge passieren alle parallel. ASP.NET Core hört nicht auf, an Features zu arbeiten, bis „alles“ von .NET Framework auf .NET Core portiert wurde. ASP.NET wird weiterhin innovativ sein und APIs nutzen, die auf .NET Core verfügbar sind, da wir sie als Teil derselben Box liefern.

Ich sehe ein paar Trendideen in diesem Thread von:

• Ich möchte, dass Sie .NET Framework für immer unterstützen.
• Ich möchte, dass Sie .NET Framework unterstützen, bis die Abhängigkeiten, die ich für meine Anwendung benötige, portiert sind.
• Ich brauche nur noch 1 Jahr, das reicht mir, um die .NET Framework-Unterstützung (ASP.NET Core 3.x) einzustellen.

Hinzu kommt, dass wir keine Ankündigung geschrieben haben (was unser Fehler ist), aber eine kommt (ich verspreche es, ich gebe dem Wochenende die Schuld).

Ich weiß auch nicht, wie die API-Parität für die meisten Leute hier aussieht, ich vermute, dass sie für verschiedene Leute unterschiedlich ist. .NET Framework ist eine über 15 Jahre alte solide, zuverlässige Unternehmenstechnologie, die an Windows gebunden ist.
.NET Core wurde entwickelt, um moderne, leichte, plattformübergreifende Mikrodienste zu schreiben, und hat sich langsam weiterentwickelt, um kompatibler zu sein, sodass das Portieren von Bibliotheken einfacher wurde. Allerdings weiß ich nicht, was es bedeutet, sich .NET Framework in Bezug auf Kompatibilität zu nähern, oder ob dies überhaupt ein Ziel ist (war es ursprünglich nicht). Irgendwann können Sie ASP.NET Core nicht mehr auf .NET Framework verwenden, und es gibt einige Abhängigkeiten, die nicht umgeschrieben werden können und nicht mit .NET Core kompatibel sind. Anwendungen müssen dies berücksichtigen, wenn sie (in naher Zukunft) unter Berücksichtigung von ASP.NET Core entwickelt werden.

In Bezug auf die Projekte, an denen ich arbeite, wäre ein viel längerer Zeitraum der Unterstützung für 1.1 eine anständige Milderung. Es ist unwahrscheinlich, dass wir Netfx-Abhängigkeiten in 1 Jahr fallen lassen können, aber viel wahrscheinlicher mit den +3 Jahren, die Sie als Strohmann vorgeschlagen haben. Es wäre wirklich schön, eine Veröffentlichung zu haben, bei der zuerst alles auf der 2.0-Ebene zusammenkommt - das ist der Punkt, an dem alles einfacher zu portieren sein sollte! Ich spreche nur für eine Organisation, aber "2.0 wird ein LTS-Release sein; 3.0 wird netfx fallen lassen" wäre für uns im Grunde ein normales Geschäft und kein Grund für FUD.

Ich möchte auch wiederholen, was @PureKrome über die Wertschätzung dieses Engagements gesagt hat, es war eine sehr informative Diskussion.

Zum Thema Parität – ich hatte zuvor angenommen, dass .net Core sich niemals den .net Framework-Kompatibilitätsebenen annähern würde, aber dass dies in Ordnung wäre, da asp .net Core weiterhin beide unterstützen würde.

Ich denke, dass wir als Community .net Core grundsätzlich verwenden, um asp.net Core zu verwenden, nicht für seine eigenen Verdienste. Wie Sie sagten, handelt es sich um ein Produkt, und ich dachte, der Kern von clr wäre ein optionaler Teil dieses Produkts mit Vor- und Nachteilen, falls ausgewählt.

Nachdem ich eine Nacht darüber geschlafen habe -

Ich persönlich halte es für eine gute Idee, das alte .net-Framework hinter sich zu lassen und das bestmögliche Web-Framework für die moderne Runtime zu schreiben.

Aber Sie wissen, dass es definitiv riskant ist und Sie vielleicht einige Ihrer Kunden hier auf dem Weg verlieren (ich hoffe nicht - aber ich berate viel - und .NET Core ist für viele Unternehmen derzeit unerreichbar - hoffen wir 2.0 ändert das).

..und ja - die Kommunikation drum herum war (wie immer) etwas, das man verbessern kann (höflichste Version dieses Satzes für einen Deutschen) ;)

+1

Ich persönlich halte es für eine gute Idee, das alte .net-Framework hinter sich zu lassen und das bestmögliche Web-Framework für die moderne Runtime zu schreiben.

Ich stimme stark zu. Meine Hoffnung war, dass dies eine allmähliche Änderung gewesen wäre, z. B. Kestrel würde die Unterstützung zuerst für perf einstellen (http.sys-basiertes Hosting bleibt), dann folgt mvc/* für API- und Funktionsverbesserungen, während Portierungs-/Kompatibilitätstestbemühungen für netstandard2.0 beginnen.

Exzellent. In diesem Fall, solange Microsoft sicherstellt, dass 1.x unterstützt wird (alle Arten von Fehlerkorrekturen und >Betriebsunterstützung), bis es Kunden einen geeigneten 2.x-Migrationspfad anbietet (z. B. SignalR), dann bin ich >wohl damit, meine Zeit abzuwarten bis wir asp.net core 2 brauchen.

+1

kann nur auf .NET Core portiert werden (vielleicht haben Sie während der Entwicklung von ASP.NET Core auf dem vollständigen Framework einige neue Abhängigkeiten als Beispiel genommen, die niemals portiert werden).

Völlig einverstanden.
Im Moment finde ich das eine gute Entscheidung. Ich denke, in idealen Szenarien brauchen wir mehr als 1 Jahr Support, ich weiß nicht, vielleicht 2-3 Jahre, und Informationen darüber, was portiert wird, um das Vertrauen der Community zu gewährleisten.
Keine .net 461-Unterstützung.

@dasMulli

Ich stimme stark zu. Meine Hoffnung war, dass dies eine allmähliche Änderung gewesen wäre, z. B. Kestrel würde die Unterstützung zuerst für perf einstellen (http.sys-basiertes Hosting bleibt), dann folgt mvc/* für API- und Funktionsverbesserungen, während Portierungs-/Kompatibilitätstestbemühungen für netstandard2.0 beginnen.

Wir führen nicht einmal Leistungstests auf .NET Framework durch ... Portierungstests und Verbesserungen auf .NET Core und .NET Standard werden sowieso stattfinden, das hat meiner Meinung nach keinen Einfluss darauf, ob die .NET Framework-Unterstützung eingestellt wird oder nicht. Wenn überhaupt, bringt es uns dazu, uns auf diese Szenarien zu konzentrieren, weil es das einzige Ziel ist.

@gulbanana

Es wäre wirklich schön, eine Veröffentlichung zu haben, bei der zuerst alles auf der 2.0-Ebene zusammenkommt - das ist der Punkt, an dem alles einfacher zu portieren sein sollte! Ich spreche nur für eine Organisation, aber "2.0 wird ein LTS-Release sein; 3.0 wird netfx fallen lassen" wäre für uns im Grunde ein normales Geschäft und kein Grund für FUD.

Warum brauchen Sie ASP.NET Core 2.0 (vergessen Sie .NET Standard und .NET Core 2.0)?

Wir brauchen die Funktionen in asp.net Core 2.0 nicht besonders. Ich hätte sehr gerne die einfacheren Build-Prozesse und Interop, die mit der 2.0-Welle geliefert werden. Würde das eher als „Standard“ und unterstütztes Szenario betrachtet werden als als etwas, das niemand testet oder beachtet?

Grundsätzlich mache ich mir Sorgen, wenn 1.1 zu LTS wurde, dass Probleme in achtzehn Monaten mit "Nun, Sie können dies mit der 2.0-API tun" geschlossen werden.

Wir brauchen die Funktionen in asp.net Core 2.0 nicht besonders. Ich hätte sehr gerne die einfacheren Build-Prozesse und Interop, die mit der 2.0-Welle geliefert werden. Würde das eher als „Standard“ und unterstütztes Szenario betrachtet werden als als etwas, das niemand testet oder beachtet?

Das würde natürlich funktionieren. Wie ich die ganze Zeit gesagt habe, sind die 3 Dinge heute vollständig entkoppelt. Hier ist ein Beispielprojekt, das ASP.NET Core 1.1 auf .NET Core 2.0 unter Verwendung einer Version von System.Configuration-APIs ausführt, die in ein .NET Standard 2.0-Paket portiert wurden:

https://github.com/davidfowl/AspNetCore1OnNetCore2

Ich würde dies gerne akzeptieren, wenn es eine automatische Interop-Schicht zwischen .NET Core und .NET Framework gäbe (nicht die aktuelle, die zur Laufzeit Ausnahmen auslösen kann, und keine selbst erstellten internen WebAPI-Aufrufe) – eine Art Wrapper ("WowNET"?), was uns zwingen würde, 4.6-abhängigen Code in separaten .dlls aufzubewahren, aber das Ausführen von Legacy-Versionen auf Kosten der Leistung zu ermöglichen (was im Fall von LOB-Apps nicht das Hauptanliegen ist). Meint ihr das wäre technisch möglich?

Ich frage mich auch, ob diese Änderung bedeutet, dass sich das vollständige Framework selbst dem Ende seiner Lebensdauer nähert und keine andere wichtige Rolle spielen wird, als eine Legacy-Komponente zu sein, sobald die meisten APIs auf .NET Standard umgestellt wurden.

Grundsätzlich mache ich mir Sorgen, wenn 1.1 zu LTS wurde, dass Probleme in achtzehn Monaten mit "Nun, Sie können dies mit der 2.0-API tun" geschlossen werden.

Das ist immer eine Sorge. Die Antwort ist immer "es kommt darauf an". Fehlerbehebungen werden entsprechend gewichtet, und große Funktionen fallen wahrscheinlich häufiger in diesen Eimer als nicht.

@rohatsu

Ich würde dies gerne akzeptieren, wenn es eine automatische Interop-Schicht zwischen .NET Core und .NET Framework gäbe (nicht die aktuelle, die zur Laufzeit Ausnahmen auslösen kann, und keine selbst erstellten internen WebAPI-Aufrufe) – eine Art Wrapper ("WowNET"?), was uns dazu zwingen würde, 4.6-abhängigen Code in separaten .dlls zu behalten, aber die Ausführung von Legacy auf Kosten der Leistung zu ermöglichen (was im Fall von LOB-Apps nicht das Hauptanliegen ist). Meint ihr das wäre technisch möglich?

So ähnlich https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root , aber für .NET Core und .NET Framework. Wir haben etwas sehr Ähnliches getan, als wir ASP.NET Helios unterstützten, ein .NET Framework-Shim, das zum Boostrap von Coreclr in IIS verwendet wurde. Die Hacks, um es zum Laufen zu bringen, waren ziemlich hässlich, obwohl es eine Mischung aus COM und der Übergabe von Strukturen an die Main-Methode über string[]-Argumente war. Alles technisch machbar. Ich bin mir nicht sicher, welche Art von Genauigkeit Sie erwarten würden, da es sich nicht um die gleiche Laufzeit handelt und Sie Objekte nicht hin und her übergeben können. Sie würden auch 2 GCs, 2 Jits Tonnen mehr DLLs im selben Prozess ausführen, und ich bin mir nicht sicher, was Sie gewinnen, wenn Sie etwas außerhalb von Proc tun.

Ich frage mich auch, ob diese Änderung bedeutet, dass sich das vollständige Framework selbst dem Ende seiner Lebensdauer nähert und keine andere wichtige Rolle spielen wird, als eine Legacy-Komponente zu sein, sobald die meisten APIs auf .NET Standard umgestellt wurden.

Weit entfernt von. .NET Framework entwickelt und wird mit der Geschwindigkeit von Windows ausgeliefert, da es eine Windows-Komponente ist. Wir haben gerade .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) mit einer Reihe neuer Funktionen veröffentlicht. Tatsache ist, dass .NET Core schneller ausgeliefert werden kann und wird, da es an nichts anderes gebunden ist, sodass APIs, Laufzeitfunktionen usw. dort zuerst angezeigt werden. Das bedeutet nicht, dass die Dinge nicht irgendwann ihren Weg zu .NET Standard und .NET Framework finden werden. Es dauert nur länger, um dorthin zu gelangen. Die Tatsache, dass .NET Framework-Updates vor Ort durchgeführt werden, ist der Grund, warum wir beim Portieren von Änderungen so vorsichtig sind. Jede Änderung kann jede Anwendung beschädigen, wenn ein Update automatisch auf eine Milliarde Computer übertragen wird 😉 . Bei .NET Core befindet sich das Framework nebeneinander, sodass sich Anwendungen für die neuere Version entscheiden müssen, um neuere Features oder Fixes zu erhalten. Da ist einfach viel mehr Freiheit.

Nur um mit den net4x-Bibliotheken abzuwägen, die wir derzeit in ASP.NET Core 1.x verwenden, das würde in 2.0 nicht funktionieren: EntityFramework 6. EFCore hat einfach zu viele fehlende Funktionen, die wir verwenden, die fehlen (z. B. Abfang-/Lebenszyklus-Hooks). Wir hängen also eine Weile an EF6 fest.

Und laut dem Beitrag von @PinpointTownes funktioniert EF6 nicht mit der aktuellen (in Entwicklung befindlichen) Version von ASP.NET Core 2.x.

@nphmuller dann würden Sie weiterhin ASP.NET Core 1.x verwenden, bis weitere Abhängigkeiten verschoben wurden (ich weiß nicht, wie viele Dinge Sie von EF Core benötigen und wie der Status ist).

@davidfowl Sicher, wenn das Supportfenster von ASP.NET Core 1.x während dieser Zeit nicht vergeht.
Das Hauptmerkmal ist das Abfangen (Lebenszyklus-Hooks). Andere fehlende Funktionen können für uns einfacher umgangen werden. Interception befindet sich in ihrem Backlog, ist aber nicht an eine Veröffentlichung gebunden. Und mein Bauchgefühl sagt mir, dass es noch eine Weile nicht umgesetzt wird.

@gulbanana : Ich denke, dass wir als Community .net Core grundsätzlich verwenden, um asp.net Core zu verwenden, nicht für seine eigenen Verdienste.

Sprich für dich. Es gibt eine Reihe von uns, für die der Hauptvorteil von .NET Core darin besteht, Windows auf dem Server zu verlassen.

Und, nehme ich an, all ihr dreckigen Mac-besitzenden Hippies. 😝

@bradwilson Und, nehme ich an, all ihr dreckigen Mac-besitzenden Hippies.

Sprich für dich selbst, einige von uns sind keine Hippies ;P

Aber ja, das Entkommen von Windows (oder wirklich IIS und http.sys) ist das, wofür ich .NET Core neben der xcopy-Bereitstellung, perf usw. möchte.

Das Isolieren von altem Code in separaten Diensten oder das Portieren auf ASP.NET Core zahlt sich aus anderen Gründen als neu und glänzend aus.

@PinpointTownes ist ein Referenzfehler. Was passiert, wenn Sie auf System.Configuration gemäß https://github.com/aspnet/Home/issues/2022#issuecomment -299810945 verweisen? EF6 gibt an, dass es keine Abhängigkeiten gibt, da alles im alten GAC/Full Framework-Bundle enthalten ist

@benaadams und @PinpointTownes der Grund für das Scheitern ist, dass System.Configuration.ConfigurationManager nicht der DLL-Name ist, den .NET Framework erwartet. Ich bin mir nicht sicher, ob der Port von System.Configuration gültig ist.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

Ja, in der Lage zu sein, Nicht-Windows-Server auszuführen, ist großartig und ein großer Vorteil ... aber ohne asp.net-Kern, was würden Sie darauf ausführen? Sogar Nancy für .net Core verlässt sich über Kestrel, UseOwin() usw. auf asp.net Core.

Ich habe mehrere Microservices erstellt, die ASP.NET Core nicht verwenden. Sie sind Dinge wie Worker-Prozesse, die eine Warteschlange abfragen, um ihre Arbeit zu erledigen.

Das ist nicht fair, wir folgen Roadmaps, und Sie haben vorher nichts darüber gesagt !!
Wie Sie bereits gesagt haben, werden wir ASP.NET Core in unserem Projekt nicht verwenden, da wir .NET 4.x-Bibliotheken benötigen.
Unsere Planung umfasst die Aktualisierung unserer Projekte auf ASP.NET Core 2, da neue Funktionen benötigt werden.
Wir brauchen ASP.NET Core 2, um auch auf .NET 4.x abzuzielen. Wenn dies nicht möglich ist, was ist mit der Unterstützung von ASP.NET Core 1.x, planen Sie, auch alle neuen Funktionen hinzuzufügen oder nur Fehler zu beheben.

Unsere Planung umfasst die Aktualisierung unserer Projekte auf ASP.NET Core 2, da neue Funktionen benötigt werden.

Welche?

@PinpointTownes ist ein Referenzfehler, was passiert, wenn Sie auf System.Configuration gemäß #2022 (Kommentar) verweisen?

Das Hinzufügen <Reference Include="System.Configuration" /> hat keine Auswirkung (d. h. es wird dieselbe Ausnahme ausgelöst), da es anscheinend nicht vom GAC gelöst werden kann (ich bin mir nicht sicher, ob es wirklich überraschend ist):

Ich bin mir nicht sicher, ob der Port von System.Configuration gültig ist.

Die offizielle Schlussfolgerung lautet also: Sie können eine für .NET Framework 4.x geschriebene Bibliothek nicht auf .NET Core verwenden, wenn sie System.Configuration verwendet?

@PinpointTownes Ich bin mir nicht einmal sicher, ob die Version von System.Configuration versendet wird (die im Paket). Vielleicht ist es das, vielleicht auch nicht (das ist eine Diskussion, die man auf Corefx beginnen sollte). Ich sage Ihnen nur, warum Ihre Probe so zerbrochen ist, wie sie es tat.

Hinzufügen hat keine Wirkung (dh die gleiche Ausnahme wird ausgelöst), da es scheint, dass es nicht vom GAC gelöst werden kann (nicht sicher, ob es wirklich überraschend ist, tho'):

AFAIK, es gibt keine Standardunterstützung für die GAC-Referenzen in SDK-Projekten. Unter https://github.com/dotnet/sdk/issues/987#issuecomment -286307697 erfahren Sie, wie Sie es aktivieren.

Die offizielle Schlussfolgerung lautet also … Sie können eine für .NET Framework 4.x geschriebene Bibliothek nicht auf .NET Core verwenden, wenn sie System.Configuration verwendet?

Meine Schlussfolgerung ist, dass Sie mit dem oben bereitgestellten Beispiel ein Problem auf CoreFX eröffnen sollten.

@davidfowl Danke für die Antwort
Einige benötigte Funktionen und Helfer in EF Core sind in 2.0 geplant, insbesondere für Mapping-Daten (Eigenständige Mappings)...
Wie auch immer, ich muss nur eine klare Vorstellung von der Roadmap von ASP.NET Core 1.x haben, unser Team ist verwirrt und besorgt.

Eine Sache, mit der ich persönlich zu kämpfen habe, ist die Frage „stabile Plattform“ vs. „neue Funktionen“. Einerseits wollen wir, dass die Plattform stabil, zuverlässig und kompatibel ist, andererseits will niemand auf 1.x bleiben, weil es keine 2.x-Features hat. Gibt es in ASP.NET Core 2.x wirklich überzeugende Features, die die Leute in diese Richtung ziehen, oder liegt es einfach daran, dass wir mehr Features haben als in 1.x (weil es neu und glänzend ist)?

@davidfowl Ich denke, signlarR ist eine solche Funktion, es wäre zumindest in meinem vorherigen Projekt gewesen. Ich denke jedoch, dass ein Großteil der Besorgnis auf die relativ kurzen Supportfenster für 1.1 (2018?) zurückzuführen ist, wenn den Leuten versichert würde, dass sie auf asp.net 1.1 laufen könnten, bis sie bereit sind, auf Core umzusteigen, was möglicherweise Jahre und mehr bedeutet auch für Patches abgedeckt werden, die die Leute ein wenig beruhigen würden.

Ich denke auch, dass die Unterstützung von asp.net core 1.1 auf .net core 2.0 noch mehr hervorgehoben werden sollte, es gibt den Leuten (meiner Meinung nach) einen guten Migrationspfad: asp.net 5 on 46 > asp.net core 1.x on 46 > asp.net Core 1.x auf .net Core 2.0 > asp.net Core 2 auf .net Core 2. Das wäre ein Weg, der das Risiko verringern würde, über das sich viele Leute Sorgen machen.

Ich verfolge das seit dem ersten Tag und selbst nach all diesen Diskussionen und Klarstellungen ( danke @davidfowl ) habe ich das Gefühl, dass viele von uns unter den Bus geworfen werden.

Ich verstehe die Gründe für die Loslösung vom Full/Desktop .NET-Framework. Verdammt, ich stimme sogar zu, dass dies der Weg ist, ASP.NET zu stärken, ABER ich sehe nicht, wie dies jetzt statt von Anfang an entschieden wird.

Natürlich würden wir Kunden in beiden Szenarien ernsthaft meckern, aber ich würde lieber auf das „Ich kann das neue glänzende Ding nicht gebrauchen“ setzen, als auf „Ich kann es gebrauchen, in langsam migrieren und wenn möglich ersetzen“ und einfach wetten herausfinden, dass das falsch ist.

Ich sehe nicht, wie dies jetzt statt von Anfang an entschieden wird.

Bei einer Vermutung:

Auf .NET Core 1.x konnten Sie keine vollständigen Framework-Bibliotheken ausführen, daher wäre dies ein vollständiger Bruch gewesen.

Auf .NET Core 2.x können Sie meistens Full Framework ausführen und können .NET Standard 1.x - 2.0-Bibliotheken ausführen, sodass dies keine große Unterbrechung darstellt.

Alle Probleme mit der Ausführung von Full-Framework-Bibliotheken auf .NET Core 2.0 sollten wahrscheinlich in dotnet/corefx abgelegt werden

Es ist klar, dass das Hauptszenario „moderne Web-Apps in der Cloud“ sind, die oft nicht viele Abhängigkeiten von Drittanbietern haben (oder „nur Code“-Abhängigkeiten sind).

Die meisten Diskussionen konzentrierten sich bisher auf die BCL-Verfügbarkeit, aber viele von uns sind auf Komponenten von Drittanbietern angewiesen (Low-Level-Integration mit komplexen Video-, Audio-Subsystemen zum Beispiel ...), die oft und fast immer in der .NET-Landschaft hinterherhinken sich auf niedrigere Technologien verlassen, die wahrscheinlich nicht unterstützt werden.

Mit ASP.NET Core 1 entwickeln wir unsere modernen Dienste, zielen auf den .NET-Standard für Bibliotheken ab und entscheiden uns für die Bereitstellung auf vollständigen .NET- oder .NET Core-Abhängigkeiten pro Dienst.

Ich könnte darauf wetten, denn wenn wir nicht unterstützte Funktionen/Komponenten finden, könnten wir leicht auf Full .NET abzielen. Und die Wette war auf die langfristige Plattform gerichtet, da der Verbleib bei Full .NET wie eine Entscheidung aussieht, die man in ein paar Jahren vermeiden sollte.

_Auf .NET Core 2.x können Sie meistens Full Framework ausführen und können .NET Standard 1.x - 2.0-Bibliotheken ausführen, also ist es kein großer Bruch._

@benaadams Es gibt einen großen Unterschied zwischen der Verwendung des größten Teils der BCL und der Verwendung von Bibliotheken, die für Full .NET erstellt wurden (und intern nicht unterstützte Funktionen in .NET Standard 2.0 / Typvereinheitlichung verwenden könnten).

Ich denke, diese Entscheidung hat keine Auswirkungen auf die Erleichterung der Migration zu ASP.NET Core 2.0 von ASP.NET 4?
Nicht wenige Anwendungen, die ich verwalte, könnten wirklich von einem Update auf ASP.NET Core 2.0 profitieren, aber da es keinen OWIN/Katana-Support für ASP.NET Core gibt, muss ich wohl manuell migrieren, und das ist zu viel Arbeit. @damianh schlug ähnliches in https://github.com/aspnet/AspNetKatana/issues/27 vor

Wir führen das vollständige Framework aus, da wir EF6 (für Spatial) und Verzeichnisdienste benötigen und wir auf das eigentliche SignalR warten (derzeit wird eine nicht unterstützte Version verwendet, aber es funktioniert). Ich habe seit einiger Zeit keine anderen Blocker mehr überprüft, aber wahrscheinlich gibt es noch mehr.

Wie ich es verstehe, werden wir jetzt daran gehindert, zu asp.net Core 2.0 zu wechseln und signalr zu bekommen, wenn es herauskommt.

Wir sind seit dnx, RC1 bis RC2 und project json bis csproj dabei und schließlich fühlte es sich an, als wären wir aus dem Gröbsten heraus ... jetzt nicht so sehr.

Ich kann verstehen, dass diese Änderung irgendwann kommen wird, aber ist dies wirklich die Zeit dafür, wenn der Kern von asp.net versucht, Fahrt aufzunehmen? Außerdem sagt mir mein Bauchgefühl, dass EF Core noch nicht ausgereift genug ist (und schon gar nicht für Spatial), und jeder, der auf Unterstützung im Core setzt, geht ein größeres Risiko in Bezug auf die Portierung von Bibliotheken ein ... es scheint, als würde man auf eine andere Version für diesen Übergang warten Es würde eine gewisse Stabilität und eine Chance für EF Core und andere Ports geben, aufzuholen, ganz zu schweigen von signal r im gesamten Framework.

Ich wette, dass die meisten Unternehmen asp.net core (was übrigens großartig ist) auf dem vollständigen Framework ausführen und sich in einer ähnlichen Position wie wir befinden könnten.

Bedeutet das angesichts dieser Umstellung auf den Schnellzug für ASP.NET Core, dass Sie eine LTS- und eine aktuelle Version einführen, und wie lange wird die Unterstützung für diese Instanzen dauern?

Ich glaube, ich bin in der glücklichen Situation, dass ich an einer Greenfield-Lösung arbeite, die keine Anforderungen hatte, um auf netfx zu laufen, _aber_ es war immer schön, wenn es möglich war. Das einzige, was für mich ein Blocker wäre, wären Windows-Dienste, auf die ich netfx abziele, aber dafür gibt es einen Plan.

Ich habe das Gefühl, dass diese Änderung in die falsche Richtung geht. Ich verstehe, dass einige Funktionen Kern-exklusiv sind, bis netstandard aufholt. Aber diese reine Kernroute zu gehen, ist ein rutschiger Abhang zur Schaffung eines zerbrochenen Ökosystems.

Diese Änderung macht eine Aussage, von der ich nicht sicher bin, ob sie mir gefällt: Es ist in Ordnung, nur auf netcoreapp abzuzielen.

Ich wollte auch meine Meinung schreiben.

Ich glaube, dass es noch zu früh ist, .net Framework fallen zu lassen. Ich weiß nicht, was das Problem der gemeinsamen Unterstützung von .net Framework und .net Core ist, aber ich glaube, dass diese Entscheidung die Migration zu AspNet Core etwas schwieriger machen wird. Weil einige Unternehmen denken: „Lasst uns AspNet Core mit .net Core starten. Aber jetzt wird das nicht mehr möglich sein und Unternehmen werden zögern, mit AspNet Core zu beginnen. Außerdem kann diese Entscheidung den Wert von .netstandard verringern.

@hikalkan

Weil einige Unternehmen denken: „Lasst uns AspNet Core mit .net Core starten.

Sie können aber immer ASP.NET Core 1.1 verwenden, richtig?

Außerdem kann diese Entscheidung den Wert von .netstandard verringern.

Ich verstehe nicht, warum das der Fall sein sollte. Wie ich bereits sagte, zielen unsere Cross-Cutting-Bibliotheken immer noch auf .NET Standard sowie APIs ab, die über alle .NET-Implementierungen hinweg funktionieren müssen.

Sicher, sie können asp.net Core 1.1 verwenden. Aber es ist nicht schön zu sagen: „Die neueste Version von ASP.NET Core ist 2.x, aber Sie sollten ASP.NET Core 1.x verwenden, wenn Sie auf das .net-Framework abzielen möchten“. Das ist nicht viel anders als zu sagen "MVC 5.x verwenden" :)

Ich glaube, dass .net Core die Zukunft ist (nicht Zukunft, sogar jetzt!), aber es ist früh, .net Framework fallen zu lassen (diese Entscheidung wird von der Community so verstanden werden, als wäre .net Framework veraltet).

Sie können aber immer ASP.NET Core 1.1 verwenden, richtig?

es gibt keinen eindeutigen Vorteil. Erstens ist es noch nicht ausgereift, also ist es eine Wette.
Zweitens wollen Entwickler in ASP.Net Core nicht in alte Tools schreiben und zurückbleiben.
Ich interessiere mich für einige Dinge.

1. Wir arbeiten bereits im Greenfield-Projekt vollständig in ASP.Net Core, Dapper usw.
   Aber in anderen Projekten befindet sich unsere Geschäftslogik in 4.6-Assemblys. Wie ich oben gelesen habe, sollten wir kein Problem haben, auf sie zu verweisen. Ich hoffe, ich habe das ungefähr verstanden.
2. SignalR . Verzeichnisdienste, MS Orleans, Azure.
3. Vielleicht irrelevant für das obige Gespräch, aber ich möchte unbedingt einen ASP.Net Core mit Kestrel oder einem anderen HttpListener als UWP-Desktopanwendung oder als Desktopbrücke in UWP lokal hosten.

Ich muss sagen, ich bin ziemlich enttäuscht von der Kommunikation zu diesem Thema. Ich denke, wir können mit der Entscheidung leben, aber sie kam aus dem Nichts.

Im Juli beginnt mein Team mit der Arbeit an einem 12- bis 18-monatigen Greenfield-Projekt, das auf ASP.NET Core 2.0 ausgeführt wird, mit all den coolen Dingen, über die wir seit Jahren in .NET Core lesen.

In der Zwischenzeit haben wir jedoch eine ASP.NET MVC Core 1.0-App, die das Zentrum unseres Legacy-Produkts ist, das im Wesentlichen als Wrapper zum Aufrufen von .NET Framework-Bibliotheken dient.

Ich habe mit dem Team bestätigt, dass ihr Plan darin besteht, die App auf ASP.NET MVC Core 2.0 zu aktualisieren und sie Teil der neuen App werden zu lassen, wenn wir die .NET Framework-Komponenten austauschen. Jetzt bleiben wir bei ASP.NET MVC Core 1.0 hängen, das EOL-fähig sein wird, bevor wir das Projekt abschließen.

Kurz bevor ich meine Meinung vertrete, möchte ich nur Klarheit über einen Teil.
Gehe ich mit der Annahme richtig, dass, wenn wir ASP.NET Core weiterhin verwenden wollen,
Wir können nicht auf DLLs verweisen, die auf .Net 4.5 oder höher abzielen, und sie so funktionieren lassen, wie sie es derzeit tun.

@louislewis2 Nein, das ist nicht richtig. Sie können net45 - net461 Bibliotheken verwenden, solange sie sich innerhalb des unterstützten API-Bereichs für netstandard2.0 . Sie müssen diese Bibliotheken nicht neu kompilieren.

@bradwilson Danke für die Klarstellung. Das wird mich heute Nacht sicherlich besser schlafen lassen.
Viele der Bibliotheken stehen nicht unter unserer Kontrolle, das wäre also ein großes Problem gewesen.

Bin jetzt sehr erleichtert :)

@shanselman @DamianEdwards @davidfowl Für Ihre Liste der Elemente, die wir verwenden und die noch nicht portiert wurden, wären Elemente in der system.management dll. Wir verwenden speziell die Hardwarekennungen, die für die automatische Linkgenerierung für Azure Service Bus und unser gesamtes Lizenzserver- und Clientpaket verwendet werden. Ich stelle mir vor, dass sie uns einige ernsthafte Probleme bereiten würden, wenn sie derzeit nicht die API sind?

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

Dies ist unser größter Fehler, der uns dazu bringt, einige unserer Apps auf dem vollständigen Framework auszuführen.

Das bringt uns in eine unangenehme Situation.

Ich bin gerade dabei, unsere Microservices von ASP.Net 4.5, selbstgehostetem In-Process auf Kestrel (Legacy-Kompatibilitätsgründe), auf vollständig selbstgehostetes ASP.Net Core 1.x zu portieren. Allerdings müssen wir diese Dinge vorerst im vollen Rahmen ausführen. Und dafür gibt es gute Gründe.

Wir haben eine Reihe harter Windows-Abhängigkeiten, die bereits Teil unserer Infrastruktur sind und nicht geändert werden können. Dazu gehören NTLM-Authentifizierung, Ereignisprotokollprotokollierung usw. Wenn ASP.Net Core 2.x aus der Netstandard-Unterstützung aussteigt, kann ich es genauso gut überhaupt nicht tun. Das Problem ist, dass es keine aktiv entwickelte vollständige Framework-Alternative gibt. Katana ist tot und langsam (im Vergleich).

Wenn mir jemand einen HTTP-Server zeigen könnte, der so schnell ist wie Kestrel für .Net Framework, dann sicher. Aber das gibt es nicht. Ich muss also akzeptieren, dass ASP.Net mit dieser Änderung tatsächliche Produktionskunden wie mich hinter sich lässt.

Wenn der Stack alle neuen Extras wie Pipelines und Span benötigt, sollten diese als Netstandard-Bibliotheken bereitgestellt werden. Welche APIs verwendet ASP.Net Core 2.x in netcoreapp2.0, die nicht in netstandard2.0 enthalten sind, und warum können diese APIs in der Zwischenzeit nicht zu netstandard2.0-Erweiterungsbibliotheken gemacht werden?

Wollen wir damit ernsthaft sagen, dass MS zwei Jahre lang an einem (Netto-)Standard für alle seine Frameworks gearbeitet hat, nur um dann umzukehren und ein Flaggschiff-Produkt herauszubringen, das diesen Standard nicht verwendet?

Ich denke, dass das GitHub-Team aufgrund dieses Problems die Paginierungsfunktion für den Abschnitt "Probleme" hinzufügen wird.

@mattnischan

Ich bin gerade dabei, unsere Microservices von ASP.Net 4.5, selbstgehostetem In-Process auf Kestrel (Legacy-Kompatibilitätsgründe), auf vollständig selbstgehostetes ASP.Net Core 1.x zu portieren. Allerdings müssen wir diese Dinge vorerst im vollen Rahmen ausführen. Und dafür gibt es gute Gründe.

Sie können weiterhin ASP.NET Core 1.x verwenden, richtig?

Wenn der Stack alle neuen Extras wie Pipelines und Span benötigt, sollten diese als Netstandard-Bibliotheken bereitgestellt werden. Welche APIs verwendet ASP.Net Core 2.x in netcoreapp2.0, die nicht in netstandard2.0 enthalten sind, und warum können diese APIs in der Zwischenzeit nicht zu netstandard2.0-Erweiterungsbibliotheken gemacht werden?

Wenn APIs in .NET Standard erscheinen, die nicht in .NET Framework enthalten sind, wie werden Sie sie verwenden?

@stefan2410

Sie können dafür ASP.NET Core 1.x verwenden, oder? Welche ASP.NET Core 2.0-Funktionen benötigen Sie? Ist es nur SignalR?

Belassen Sie die App für die nächsten zwei Jahre unverändert, aber tauschen Sie die .NET Framework-Bibliotheken gegen ihre .NET Core-Äquivalente aus, wenn Sie fertig sind. Dadurch würde unsere Geschäftslogik usw. zwischen den beiden Apps geteilt bleiben.
Dies ist nicht möglich, da Juli 2018 die Frist für die Unterstützung von ASP.NET MVC Core 1.0 ist.

Wieder einmal verlängern wir in meiner hypothetischen Welt die Lebensdauer von 1.x

Aktualisieren Sie die App auf ASP.NET MVC Core 2.0 und lassen Sie sie Teil der neuen App werden, wenn wir die .NET Framework-Komponenten austauschen.
Wir können dies auch nicht tun, da Core 2.0 das .NET Framework nicht unterstützt, also geht es um alles oder nichts.

Brauchen Sie eigentlich ASP.NET Core 2.0? Oder nur .NET Core 2.0?

Wenn APIs in .NET Standard erscheinen, die nicht in .NET Framework enthalten sind, wie werden Sie sie verwenden?

Unser Plan war: warten, bis sie drin sind . Du hast vorhin gesagt, das ist nur eine Frage der Zeit, oder? Aus Stabilitätsgründen wäre es in Ordnung gewesen, die Blutungskante um einen festen Betrag zu verzögern. Zumindest viel besser, als dauerhaft ins Hintertreffen zu geraten.

@davidfowl
Ich werde in ASP.Net Core 2.0 einziehen. Ich habe keine andere Lösung. Ich kann dem Team nicht sagen, hinter der Evolution zu bleiben, wir haben lange auf den ASP.Net Core gewartet.
Soweit wir keine Probleme mit unseren Business Logic 4.6 Assemblies Referenzen haben.
Ich brauche SignalR, DirectoryServices, keine Probleme mit Azure/Amazon-Bibliotheken, MS Orleans.
Vielleicht ist es auch irrelevant für die obige Konversation, aber ich möchte, dass eine Desktop-App lokal einen ASP.Net Core mit Kestrel / HttpListener als UWP-Desktop-Anwendung oder als Desktop-Bridge in UWP hostet.
Wir können den Code nicht für XAML umschreiben und ich möchte Electron nicht verwenden.

Sie können weiterhin ASP.NET Core 1.x verwenden, richtig?

Für welchen Zeitraum? Ich kann etwas wie das Ereignisprotokoll nicht sehen, das es zum Netzstandard schafft.

Wenn APIs in .NET Standard erscheinen, die nicht in .NET Framework enthalten sind, wie werden Sie sie verwenden?

Ist das ein Ding? netstandard20 scheint laut Dokumentation immer noch auf net461 zu laufen. Wollen Sie damit sagen, dass die API unter netstandard20 nicht vollständig genug ist, um die neuen Goodies zu implementieren? Oder gibt es einen Plan, den Netstandard über das Framework hinaus zu verschieben, das noch nicht bekannt gegeben wurde?

Unser Plan war: warten, bis sie drin sind. Du hast vorhin gesagt, das ist nur eine Frage der Zeit, oder? Aus Stabilitätsgründen wäre es in Ordnung gewesen, die Blutungskante um einen festen Betrag zu verzögern. Zumindest viel besser, als dauerhaft ins Hintertreffen zu geraten.

Bibliotheken können zusätzlich zum Standard geschrieben werden. Wenn Dinge im Standard selbst geändert werden müssen, dauert es viel länger, bis er in allen Implementierungen von .NET übernommen wird, und dazu gehört auch .NET Framework. Es kann ein paar Dinge bedeuten:

• .NET Standard wird sich mit der Geschwindigkeit der langsamsten Implementierung weiterentwickeln
• .NET Standard wird sich in einem anderen Tempo weiterentwickeln und .NET Framework wird als letztes aufholen.

Das bedeutet natürlich nicht, dass Bibliotheken nicht dagegen geschrieben werden können, es bedeutet lediglich, dass diese Vorbehalte berücksichtigt werden müssen, wenn Sie die Version von .NET Standard auswählen, die Sie unterstützen möchten.

Vielleicht ist es auch irrelevant für die obige Konversation, aber ich möchte, dass eine Desktop-App lokal einen ASP.Net Core mit Kestrel / HttpListener als UWP-Desktop-Anwendung oder als Desktop-Bridge in UWP hostet.

ASP.NET Core auf UWP befindet sich derzeit in keiner Roadmap, daher kann ich nicht wirklich sagen, was hier passieren wird. HttpListener ist jedoch Teil von .NET Standard 2.0, also besteht vielleicht die Möglichkeit, dass es funktioniert.

Ich möchte mir einen Moment Zeit nehmen, um allen für ihre Kommentare und Rückmeldungen hier zu danken. Wir wissen es wirklich zu schätzen, ebenso wie Ihre Geduld, während wir den Weg nach vorne finden. Bitte beachten Sie, dass wir nicht beabsichtigten, dass diese Änderung so hart, so spät und ohne Vorwarnung erfolgt. Rückblick ist 20/20 und wenn wir gewusst hätten, was wir jetzt wussten, hätten wir die Dinge früher kommuniziert. Wir werden uns mehr bemühen, voranzukommen.

Basierend auf dem Feedback, das wir hier erhalten haben, haben wir einen Plan, den ich mit Ihnen teilen möchte, bevor wir ihn später in dieser Woche mit der Version 2.0.0-preview1 als Ankündigung veröffentlichen. Wenn das passiert, werden wir ein neues Thema eröffnen, um die Diskussion über diesen Plan zu erleichtern, aber jetzt mach weiter und teile deine Gedanken und dein Feedback hier weiter:

• Die Unterstützung für ASP.NET Core 1.x auf .NET Framework wird um mindestens ein weiteres Jahr (bis Juli 2019) verlängert. Wir werden dies jährlich neu bewerten und uns dazu verpflichten, den Support für ASP.NET Core 1.x 12 Monate im Voraus zu beenden (also würden wir bis Juli 2018 bekannt geben, ob wir um weitere 12 Monate bis Juli 2020 verlängern) ( Randbemerkung: is Ist sonst noch jemand ausgeflippt, weil wir schon über 2020 reden? Nein? Ok, nur ich. )
• Das neue SignalR wird auf ASP.NET Core 1.x abzielen und vollständig unterstützt werden (kommt später in diesem Jahr)
• Wir werden ASP.NET Core 1.x weiterhin aktualisieren, um neue Sprachversionen usw. zu unterstützen, wie wir es für System.Web tun
• ASP.NET Core 1.x auf .NET Core 1.x wird bis Juli 2018 unterstützt (keine Änderung)
• ASP.NET Core 1.x, das auf .NET Core 2+ ausgeführt wird, wird unterstützt, solange ASP.NET Core 1.x auf .NET Framework unterstützt wird
  
  
  
  • Dadurch soll sichergestellt werden, dass es immer eine Überschneidung eines unterstützten ASP.NET Core auf einem unterstützten .NET Core gibt, während wir die Ausführung auf .NET Framework unterstützen, sodass Kunden im Laufe der Zeit portieren können, während sie auf unterstützten Bits bleiben
  
  
• Die .NET Core 1.x-Unterstützung (als Runtime) ändert sich nicht. Endet im Juli 2018. Kunden, die ASP.NET Core 1.x ausführen, müssen zu diesem Zeitpunkt zu .NET Core 2.0 wechseln oder .NET Framework verwenden (oder zu ASP.NET Core 2.0 auf .NET Core 2.0 wechseln).
• Wir werden dieses Jahr System.DirectoryServices und System.Drawing auf .NET Core portieren (vollständig unterstützt, plattformübergreifend, Vorschau für mindestens Windows im Sommer)
• Die Liste der Dinge, die danach auf .NET Core portiert werden müssen, umfasst derzeit ServiceBase (zur Unterstützung von .NET Core-Windows-Diensten). Noch keine Zeitleiste außer der nächsten (die Zeitleisten werden offensichtlich konkreter, wenn wir die Liste abarbeiten). Wir werden auf dieser Liste basierend auf Kundenfeedback aufbauen.
• Wir haben derzeit keine Pläne, System.ServiceModel (serverseitiges WCF) auf .NET Core zu portieren. Die WCF für .NET Core wird möglicherweise weiter verbessert und es können Funktionen basierend auf Feedback hinzugefügt werden, z. B. HTTP-Nachrichtenverschlüsselung.

@DamianEdwards @davidfowl Ein großer Teil des Problems besteht darin, dass es monatelange Planungs- und Entwicklungsanstrengungen erfordern kann, während enorme Opportunitätskosten geopfert werden, um sich für den Wechsel zu ASP.NET Core zu entscheiden, wo viele Organisationen normalerweise nicht in der Lage sind, von einem zu wechseln .NET 4.x, da es die einzige Plattform ist, von der sie sicher sein können, dass sie alle ihre Systemabhängigkeiten ausführen können.

Bis zu diesem Zeitpunkt hat MS .NET Core aggressiv als die Zukunft von ASP.NET vermarktet, wobei unklar ist, ob die Entwicklung von ASP.NET 4.x eingestellt wurde und ob alle zukünftigen Entwicklungsanstrengungen in ASP.NET Core investiert werden Es werden viele Migrationen durchgeführt, um ihre Systeme auf dem neuesten Stand zu halten. Viele Leute werden sich fühlen, als wären sie unter einen Bus geworfen worden, wenn sie am Ende all ihrer Bemühungen effektiv auf eine EOL-Plattform migriert sind. Dies wird sowohl Organisationen als auch den Entwicklern/Beratern schaden, die die größten Verfechter der Umstellung auf .NET Core waren. Sie brauchen jetzt vielleicht nichts von ASP.NET Core 2.0, aber sie wollen definitiv etwas Spielraum für ihre Systeme haben und in der Lage sein, für all ihre Bemühungen auf einige neue Funktionen zuzugreifen.

Ich verstehe auch nicht, warum vorhandener „Legacy“-Code als Belastung angesehen wird, wenn er meiner Meinung nach als einer der größten Vermögenswerte von .NET angesehen werden sollte, .NET Core wäre bei weitem nicht so attraktiv, wenn er nicht in der Lage wäre, vorhandene .NET-Bibliotheken auszuführen . Java ist aufgrund des massiven und stabilen Ökosystems von JVM immer noch so stark, was wichtiger ist als die inhärente Schwäche der Sprache selbst.

Ich glaube nicht, dass MS auch nur begonnen hat, die Gegenreaktion durch die Einstellung der .NET 4.x-Unterstützung zu spüren, die nicht allgemein bekannt sein wird, bis sie angekündigt wird. Ich würde erwarten, dass die meisten Entwickler hier, die die Entwicklung auf GitHub aktiv verfolgen, dann mehr daran interessiert sind, neue Funktionen zu sehen Sie sind interoperabel und stellen sicher, dass es einen reibungslosen Migrationspfad für vorhandene Codebasen gibt. Ich wäre sehr überrascht, aber wenn Sie von dieser Entscheidung nach der Bekanntgabe keine Wärme bekommen, dann könnte es die richtige sein, da vielleicht nicht so viele Menschen dadurch verletzt werden.

Wäre es zu viel Aufwand, sich auf eine stabile/kompatible Version von ASP.NET Core 2.0 zu konzentrieren und dann die reine .NET Core-Zukunft für nachfolgende Versionen anzukündigen? Es scheint nur so, als wäre es in dieser Situation fair, da es völlig unvorhergesehen war.

@DamianEdwards danke für das Update und einen klaren Plan. Ich stimme dem nicht zu, aber ich weiß es trotzdem zu schätzen, dass du es darlegst.

Hier klafft noch eine große fundamentale Lücke. Die Portierung auf 1.x ist fast ausschließlich eine laterale, für uns enthält sie nur wenige Funktionen. 2.x enthält einige lohnende Upgrades, und wir haben immer noch keine Garantie, dass wir diesen Schritt jemals machen werden. Es besteht eine große Chance, dass wir viel Zeit, Geld und Mühe in die Portierung auf 1.x investieren, nur um dort aufgrund vollständiger Framework-Abhängigkeiten festzusitzen. Ich werde dieses Spiel nicht mit unserer Firma eingehen. Möglicherweise haben wir am Ende weniger Unterstützung als jetzt für ASP.NET 4.x.

Wenn sich das nicht ändert, werden unsere Apps nicht zu ASP.NET Core wechseln, und alle unsere Bibliotheken werden weitaus schlechter dran sein, da es an Dogfooding mangelt.

Ich hoffe sehr, dass Sie diese Entscheidung noch einmal überdenken. Ich hoffe, dass wir Stack Overflow eines Tages dazu bringen können, die Tausende von persönlichen Stunden zu nutzen, die wir der Entwicklung der .NET Core-Plattform gewidmet haben.

@ Nick Craver

Es besteht eine große Chance, dass wir viel Zeit, Geld und Mühe in die Portierung auf 1.x investieren, nur um dort aufgrund vollständiger Framework-Abhängigkeiten festzusitzen.

In diesem Thread haben Sie System.DirectoryServices als eines der Kernelemente bezeichnet. Ich nehme an, Sie haben einige Abhängigkeiten, von denen Sie glauben, dass es lange dauern wird, bis sie portiert werden, oder solche, die niemals portiert werden. Wenn 2.0 .NET Framework unterstützt, würden sich diese Abhängigkeiten in einem Jahr verschieben?

2.x enthält einige lohnende Upgrades, und wir haben immer noch keine Garantie, dass wir diesen Schritt jemals machen werden.

Welche? Es wäre gut zu wissen, weil wir darüber diskutiert haben, einige wichtige Dinge zurück auf ASP.NET Core 1.1 zu portieren, um den Übergang zu erleichtern.

Wenn sich das nicht ändert, werden unsere Apps nicht zu ASP.NET Core wechseln, und alle unsere Bibliotheken werden weitaus schlechter dran sein, da es an Dogfooding mangelt.

Ich weiß nichts über stackoverflow.com, aber ist es möglich, Teile abzubrechen (ich möchte nicht "Mikrodienste" sagen), damit ASP.NET Core für einige Teile verwendet werden kann?

@Mythos

Dies wird sowohl Organisationen als auch den Entwicklern/Beratern schaden, die die größten Verfechter der Umstellung auf .NET Core waren

Meinten Sie ASP.NET Core? Oder .NET Core?

@davidfowl Ich meinte ASP.NET Core, aber es betrifft auch Entwickler, die eine schrittweise Migration von ASP.NET Core/.NET 4.x zuerst und später von .NET Core planen.

Apropos, mir ist aufgefallen, dass es in ASP.NET Core/.NET Core keine Bibliotheken für die Handhabung von SAML gibt. Ich muss SSO über einen Drittanbieter-IdP handhaben, aber ich weiß nicht, ob das möglich sein wird.

@davidfowl Ich meinte ASP.NET Core, aber es betrifft auch Entwickler, die eine schrittweise Migration von ASP.NET Core .NET 4.x zuerst und dann von .NET Core planen.

Ich verstehe nicht, warum das der Fall sein sollte.

Ich denke, dass dieser Plan für meine Organisation wahrscheinlich ausreichen würde, um zu vermeiden, die Plattform zu verlassen. Die Hauptsache ist, einen längeren Zeitraum mit Support (=Sicherheitspatches) zu haben, in dem verbleibende Netfx-Deps umgeschrieben oder anderweitig beseitigt werden können. Es ist jedoch alles immer noch etwas heikel und konzeptionell seltsam. Was passiert, wenn wir in drei Jahren eine Website bauen wollen, die Excel-Dokumente aufnehmen kann, oder einen Webserver in eine App einbetten wollen? Was passiert mit anderen Frameworks wie Orleans, die anstelle von netcoreapp auf dem Standard aufbauen?

Ich verstehe ernsthaft nicht, warum so viel Arbeit an netstandard2.0 geleistet wurde, wenn es für ASP.NET Core nie gut genug sein würde, um es tatsächlich zu verwenden.

Was passiert, wenn wir in drei Jahren eine Website bauen wollen, die Excel-Dokumente aufnehmen kann?

Schwer zu sagen. Ich kann nicht für die Teams sprechen, denen das gehört, aber vielleicht wird es auf .NET Core portiert und funktioniert plattformübergreifend.

oder einen Webserver in eine App einbetten?

HttpListener ist Teil des Netzstandards 2.0.

Was passiert mit anderen Frameworks wie Orleans, die anstelle von netcoreapp auf dem Standard aufbauen?

Es liegt an den Frameworks zu entscheiden, ob sie auf .NET Framework, UWP, .NET Core, Mono usw. laufen wollen. Es ist eine Wahl. Orleans wird nicht mit .NET Core ausgeliefert. ASP.NET Core tut es. Diese Produkte sind ein und dasselbe.

Was für uns (und unsere Kunden) eine schwierige Entscheidung sein wird, betrifft nicht die Bibliotheken, die ich heute habe, sondern die Bibliotheken, von denen ich nicht weiß, ob ich sie in 6 Monaten brauchen werde. Es gibt eine lange Reihe von Bibliotheken und Frameworks, die netstandard noch nicht unterstützen. Beispielsweise stellten wir einen Monat nach einem Projekt fest, dass wir einige Funktionen in NHibernate benötigten, die in EF6 nicht einmal annähernd vorhanden waren, geschweige denn in EF Core. Was wäre also meine Option - Ziel ASP.NET Core 1.x auf vollständigem .NET?

Sieht so aus, als hätte ich in meiner Zukunft einen ApiPort.

Was wäre also meine Option - Ziel ASP.NET Core 1.x auf vollständigem .NET?

Jawohl.

Schwer zu sagen. Ich kann nicht für die Teams sprechen, denen das gehört, aber vielleicht wird es auf .NET Core portiert und funktioniert plattformübergreifend.

Richtig, aber sicherlich liegt es im Zuständigkeitsbereich des asp.net-Teams zu entscheiden, ob es sich lohnt, Zugang zu diesem Ökosystem von vielleicht nicht portierten Bibliotheken zu gewähren.

Richtig, aber sicherlich liegt es im Zuständigkeitsbereich des asp.net-Teams zu entscheiden, ob es sich lohnt, Zugang zu diesem Ökosystem von vielleicht nicht portierten Bibliotheken zu gewähren.

.NET ist groß und alt, Sie können also nicht erwarten, dass das ASP.NET-Team mit dem Atem der Bibliotheken spricht, die im .NET-Ökosystem existieren. Es ist unrealistisch. Ich habe gerade erfahren, was CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) als Teil dieses Threads war, und ich bezweifle, dass es portiert wird, aber das kann ich nicht sagen sicher.

Die Erweiterung der Unterstützung für ASP.NET 1.1 auf .NET Framework hilft, dies ein wenig zu mildern, aber ich denke, es hilft auch, weil einige Abhängigkeiten isoliert werden müssen, um ordnungsgemäß zu ASP.NET Core auf .NET Core zu wechseln (was die beabsichtigte Zukunft ist).

Ich werde die Bibliotheken beiseite lassen, da dieser Punkt bereits ausführlich diskutiert wurde. In unserem Fall (amilia.com, E-Commerce SaaS) ist das Tooling von Drittanbietern bereits ein Showstopper, wir können ASP.NET Core derzeit nicht einmal auf dem vollständigen Framework ausführen. Ich gebe zu, dass dies nicht nach einem legitimen Grund klingt, aber es ist eine Einschränkung, mit der wir umgehen müssen.

Theoretisch könnten wir diese Tools (z. B. Profiler, Überwachung, Build-Server usw.) durch Alternativen ersetzen, die .NET Core unterstützen, aber das sind ein paar Monate Arbeit, die ich lieber für die Lösung dringenderer Probleme aufwenden würde. Wir werden die Migration schließlich zu ASP.NET Core/.NET Core durchführen, aber im Moment ist es ein ziemlich bewegliches Ziel.

Bis zu diesem Zeitpunkt wurde die Erwartung geweckt, dass ASP.NET Core in der Lage sein würde , auf dem Desktop-Framework weiterzulaufen und somit die Breite von usw. usw. zu berücksichtigen. Ich weiß nicht, welche Art von Teeblättern wir lesen sollten, um zu wissen dass das unrealistisch war :/

Um es klar zu sagen: Die Idee, dass ASP.NET Core möglicherweise nur auf .NET Core ausgeführt wird, ist an sich nicht verrückt, aber wir haben noch nie zuvor davon gehört. Alle öffentlichen Informationen waren, dass es auf .NET Framework gut lief, und es gab keinen Hinweis darauf, dass dies möglicherweise geändert werden müsste.

.NET ist groß und alt, Sie können auf keinen Fall erwarten, dass das ASP.NET-Team mit dem Atem der Bibliotheken spricht, die im .NET-Ökosystem existieren. Es ist unrealistisch

Ist das nicht ein guter Grund, .NET 4.x weiterhin zu unterstützen? Die Last der Kompatibilität/Interoperabilität kann auf die .NET 4.x-Plattform eingedämmt werden, die eine funktionierende Lösung sein kann, die .NET Core von der Notwendigkeit befreien könnte, mit älteren Bibliotheken zusammenzuarbeiten, und den Druck verringert, vorhandene beliebte .NET-Bibliotheken auf .NET Core zu portieren ( für MS und externe Autoren).

@Mythos

Ist das nicht ein guter Grund, .NET 4.x weiterhin zu unterstützen? Die Last der Kompatibilität/Interoperabilität kann auf die .NET 4.x-Plattform eingedämmt werden, die eine funktionierende Lösung sein kann, die .NET Core von der Notwendigkeit befreien könnte, mit älteren Bibliotheken zusammenzuarbeiten, und den Druck verringert, vorhandene beliebte .NET-Bibliotheken auf .NET Core zu portieren ( für MS und externe Autoren).

Aus diesem Grund wurde die Lebensdauer von ASP.NET Core auf 1.1 verlängert (wenn auch nicht dauerhaft). Wir werden sicherstellen, dass SignalR funktioniert, da dies als einer der Hauptgründe für die Verwendung von ASP.NET Core 2.0 angegeben wurde. Gleichzeitig ist es nicht das, wo ASP.NET Core langfristig sein möchte. Die Absicht war immer, als Teil einer einheitlichen .NET Core-Plattform zu liefern.

@gulbanana

Bis zu diesem Zeitpunkt wurde die Erwartung geweckt, dass ASP.NET Core in der Lage sein würde, auf dem Desktop-Framework weiterzulaufen und somit die Breite von usw. usw. zu berücksichtigen. Ich weiß nicht, welche Art von Teeblättern wir lesen sollten, um zu wissen dass das unrealistisch war :/

ASP.NET Core auf .NET Framework wurde leider nie als Notlösung kommuniziert, um die Portierung zu erleichtern (das haben wir sehr schlecht kommuniziert). Es war nie beabsichtigt, eine für immer unterstützte Plattform zu sein, was die logische Schlussfolgerung ist, wenn Sie davon ausgehen, dass einige Abhängigkeiten einfach nie portiert werden.

Aus diesem Grund wurde die Lebensdauer von ASP.NET Core auf 1.1 verlängert (wenn auch nicht dauerhaft).

Die Frage ist, ob das ausreicht oder nicht, die aktuelle Version wurde im Grunde EOL'ed, bevor überhaupt eine kompatible/stabile Version geliefert wurde.

Ich glaube nicht, dass der Wert bestehender Investitionen berücksichtigt wird, wer will schon den ganzen Aufwand betreiben, um auf eine EOL-Plattform zu migrieren? Entwickler werden auf unbestimmte Zeit an ihren vorhandenen Brownfield-Systemen arbeiten, ihnen wird im Grunde gesagt, dass ihre aktuellen ASP.NET v4.x-Kenntnisse veraltet sein werden, und sie können nicht auf das neue ASP.NET Core-Entwicklungsmodell migrieren, weil . NET 4.x-Support eingestellt wird und es unverantwortlich wäre, eine Migration auf eine Sackgassenplattform in Betracht zu ziehen oder zu empfehlen.

@davidfowl

ASP.NET Core auf .NET Framework wurde leider nie als Notlösung kommuniziert, um die Portierung zu erleichtern (das haben wir sehr schlecht kommuniziert). Es war nie beabsichtigt, eine für immer unterstützte Plattform zu sein, was die logische Schlussfolgerung ist, wenn Sie davon ausgehen, dass einige Abhängigkeiten einfach nie portiert werden.

Fehler passieren, das ist in Ordnung. Das Problem ist nun, dass viele Leute diese Annahme gemacht haben und deshalb nur ASP.NET Core wegen ihrer logischen, aber falschen Schlussfolgerung verwenden. Wir werden sehen, wie viele ich denke :/

Ich warte so lange auf asp.net core 2/ .net core 2, aber das Ergebnis ist so deprimierend.

@Mythos

Ich glaube nicht, dass der Wert bestehender Investitionen berücksichtigt wird, wer will schon den ganzen Aufwand betreiben, um auf eine EOL-Plattform zu migrieren?

Kann nicht dasselbe Argument dafür angeführt werden, dass ASP.NET Core 2.0 nächstes Jahr EOL für .NET Framework ist, wenn 3.0 herauskommt? Wenn Sie sagen, dass ein Jahr für ASP.NET Core 1.1 nicht ausreicht, warum würden Sie vorschlagen, dass ein Jahr für ASP.NET Core 2.0 in Ordnung ist?

Entwickler werden auf unbestimmte Zeit an ihren vorhandenen Brownfield-Systemen arbeiten, ihnen wird im Grunde gesagt, dass ihre aktuellen ASP.NET v4.x-Kenntnisse veraltet sein werden, und sie können nicht auf das neue ASP.NET Core-Entwicklungsmodell migrieren, weil . NET 4.x-Support eingestellt wird und es unverantwortlich wäre, eine Migration auf eine Sackgassenplattform in Betracht zu ziehen oder zu empfehlen.

Wem wurde gesagt, dass ASP.NET 4.x-Fähigkeiten veraltet sein werden? Wenn überhaupt, hoffen wir, dass sie es nicht sind. Insbesondere MVC wirbt mit einigen neuen Features für die Konzeptkompatibilität. ASP.NET Core sieht Katana sehr ähnlich (und das ist kein Versehen). Wenn Sie über Web Forms sprechen, was ist dann mit MVC?

Ich habe keine Beratungserfahrung, aber ich würde zustimmen, dass ich zustimmen würde, wenn die Abhängigkeiten nicht verfügbar sind. Entweder das, oder die Anwendung muss neu gestaltet werden, um dies zu berücksichtigen.

@xyting kannst du das klären?

@davidfowl

Kann nicht dasselbe Argument dafür angeführt werden, dass ASP.NET Core 2.0 nächstes Jahr EOL für .NET Framework ist, wenn 3.0 herauskommt? Wenn Sie sagen, dass ein Jahr für ASP.NET Core 1.1 nicht ausreicht, warum würden Sie vorschlagen, dass ein Jahr für ASP.NET Core 2.0 in Ordnung ist?

Ich war lange Zeit davon ausgegangen, dass ASP.NET Core 1.1 nur eine Notlösung für ASP.NET Core 2.0 und .NET Standard 2.0 war, die die kompatibilitätsorientierte und stabile LTS-Version sein würden, die die Lücke zu den meisten schließen würde die in .NET 4.x fehlende Kernfunktionalität - bis dieser Thread diese Annahme im Grunde zerstörte. Es ist nicht ideal, die .NET 4.x-Kompatibilität bis zu ASP.NET Core 2.0 aufrechtzuerhalten, aber es ist viel besser, als es mit der aktuellen Version zu beenden, was niemand erwartet hat.

Wem wurde gesagt, dass ASP.NET 4.x-Fähigkeiten veraltet sein werden? Wenn überhaupt, hoffen wir, dass sie es nicht sind.

MS macht all sein aggressives Marketing für .NET Core mit allen neuen Ankündigungen und Funktionen, die scheinbar auf ASP.NET Core ausgerichtet sind. Werden alte ASP.NET WebForms/MVC überhaupt offen entwickelt? Welcher Anteil des Entwicklungsaufwands wird in alte ASP.NET WebForms/MVC im Vergleich zu .NET Core investiert? Ich habe keine Ahnung, alles, was ich in letzter Zeit gesehen habe, alle wöchentlichen Standups, Video-Tutorials, scheint sich ausschließlich auf ASP.NET Core zu konzentrieren. Ich weiß, dass ich mich definitiv nicht wohl dabei fühlen würde, neue Greenfield-Projekte mit alter ASP.NET WebForms- oder MVC-Technologie zu starten.

Wenn Sie hoffen, dass dies nicht der Fall ist, sollte MS dies auf jeden Fall besser mit klaren Roadmaps kommunizieren. Angesichts der Volatilität von ASP.NET in den letzten Jahren (diese Ausgabe ist ein perfektes Beispiel) ist es unmöglich, die Zukunft ohne eine offizielle Verpflichtung und Ankündigung zu kennen.

Hat sonst noch jemand das Gefühl, dass es besser gewesen wäre, wenn Version 1 nie auf dem vollen Framework gelaufen wäre? Das hätte ich aufgrund der Namensgebung nicht erwartet. Jetzt, wo es funktioniert und ich einen Vorgeschmack hatte, bin ich enttäuscht, es zu verlieren.

Ich verstehe, woher Sie kommen, Sie möchten den gesamten Stapel so schnell wie möglich iterieren. Sie konkurrieren mit einer ganzen Reihe von Web-Frameworks auf der grünen Wiese, die den gesamten Stack kontrollieren und kein Gepäck mitschleppen müssen. Das Ablegen des Gepäcks von System.Web ist einer der Hauptgründe, warum ASP.NET Core so aufregend ist.

Nachdem ich darüber geschlafen habe, kann ich sagen, dass unsere Nutzung in Ordnung sein wird, die Abhängigkeiten, die wir brauchen, sollten alle auf 2.0 funktionieren.

Gleichzeitig ist es nicht das, wo ASP.NET Core langfristig sein möchte. Die Absicht war immer, als Teil einer einheitlichen .NET Core-Plattform zu liefern.

Man muss zwar kein Hellseher sein, um herauszufinden, dass .NET Core die Plattform der Zukunft von .NET ist … wenn die Absicht von Anfang an (oder wie Sie es ausdrücken „immer“) darin bestand, ASP.NET Core mit . NET Core, das wurde definitiv in keinem Medium kommuniziert, das ich je gesehen habe.

Ich habe buchstäblich jede einzelne Minute jedes einzelnen ASP.NET-Standups gesehen (einschließlich Hanselman und Glenn, die 3 Stunden lang Fehler bei Docker beheben ... weil ich kein Leben habe), ich lese die Blogs, ich bin immer auf Twitter, ich gehe zu Mehr als 2 Konferenzen pro Jahr, Teilnahme an Benutzergruppen usw., und ich habe noch nie gehört, dass dies als Absicht von ASP.NET Core kommuniziert wurde. Stattdessen habe ich immer und immer wieder gehört „es läuft auf beiden Plattformen“ und zu Recht haben die Leute das Gefühl, dass ihnen jemand den Stuhl unter den Füßen weggezogen hat. Ich habe sogar Vorträge über ASP.NET Core gehalten und selbst gesagt, „es läuft auf beiden Plattformen“, und jetzt fühle ich mich schuldig für jeden, den ich auf diesen Weg geführt habe. Ich würde sagen, dass die ITT-Leute wahrscheinlich auf dem neuesten Stand sind und diese Art von Nachrichten am meisten akzeptieren würden, und hier gibt es eine Menge Gegenreaktionen. Es scheint, als würde es nur noch schlimmer werden, da diese Nachricht zu den Entwicklern und ihren Managern durchsickert, die nicht so eingebunden und wahrscheinlich konservativer sind als diese ITT.

Abgesehen von der mangelnden Kommunikation und dem Mangel an Unterstützung für einige Szenarien, denke ich, dass ein Großteil der Gegenreaktion nur auf den Zeitpunkt dieser Ankündigung zurückzuführen ist. .NET Core 2 ist noch nicht einmal RTM-fähig und wird bereits als der einzige langfristige Weg nach vorne angesehen, und es wurde im Wesentlichen eine tickende Zeitbombe auf Full Framework für ASP.NET Core gesetzt. Ich denke, viele unserer Ängste könnten ausgeräumt werden, wenn wir neben Nachtwäsche etwas Greifbares haben, mit dem wir spielen können.

Ich denke wirklich, dass es ein besseres Tooling-Erlebnis geben muss als „Führen Sie es aus und sehen Sie, ob es funktioniert“, wenn Sie auf net461+-Bibliotheken von .NET Core 2+ in VS verweisen, da ich bereits diese Meldung sehen kann: „Wir können wahrscheinlich das meiste davon ausführen Ihre 461+ Versammlungen auch!" wird zu Tode vermarktet. Etwas, das fehlende APIs dessen, worauf wir verwiesen haben, analysieren könnte, Kompilierzeitfehler liefert und idealerweise sogar kompatible Nupkgs vorschlägt, falls vorhanden (wie System.Configuration im obigen EF6-Beispiel ... und es funktionieren lässt :smile:). Offensichtlich kann nicht alles zur Kompilierzeit analysiert werden (das oben erwähnte Szenario mit verteilten Transaktionen fällt mir als etwas ein, das im Voraus schwer zu analysieren ist), aber je mehr, desto besser. So etwas wie das, was Immo hier für PlatformNotSupportedException gemacht hat, und die fehlenden net461-APIs für netstandard2 wären nett.

Nur meine 2 Cent. Ich hoffe, ich übertreibe nur. Letztendlich sind viele von uns einfach enttäuscht, weil wir ASP.NET Core lieben und nicht wollen, dass uns irgendetwas daran hindert, es zu verwenden. ❤️

Wenn ich mich den bereits aufgeführten Bedenken anschließe, starten wir nächsten Monat ein neues ASP.NET MVC-Projekt und es wird ein einfaches .NET Framework mit ASP.NET MVC sein, weil der Kunde nicht darauf vertraut, dass Microsoft in dieser Hinsicht das Richtige tut Langzeitplanung.

Die Kundenorganisation verwendet immer noch Windows 7-Bereitstellungen, und dieses Projekt ist eine Ausnahme, da der Großteil ihrer Webprojekte tatsächlich auf UNIX mit Java durchgeführt wird, wobei .NET hauptsächlich für Desktop-Anwendungen verwendet wird.

Diese Art von Ungewissheit häuft sich nur zu der kaputten Geschichte, die Windows 8 .NET Stack und UWP waren, und erhöht das Interesse des CTO der Organisation, nach stabileren Alternativen zur Zukunft von .NET zu suchen.

Wenn Sie diese Art von Organisationen zwingen, Module von Grund auf neu zu schreiben, um auf ASP.NET Core zu arbeiten, kann ich unseren Kunden auch raten, etwas mit stabileren Roadmaps zu übernehmen, anstatt das Gesicht über Probleme zu verlieren, die ich nicht kontrollieren kann.

@davidfowl Es kann sein, dass diese Änderung für 99% der Projekte gut funktioniert. Aber es wurde verkauft als "es läuft auf beiden Plattformen" und "Sie können es mit vollem Framework verwenden, wenn Sie müssen". Jeder wusste, dass die vollständige Framework-Version von asp.net Core für die Projekte gedacht war, die nicht migriert werden konnten, und das war in Ordnung. Und die Leute planten mit diesem Hintergedanken.

Diese Änderung ist vielleicht nicht die schlechteste in Bezug auf den Code, aber sie wird höchstwahrscheinlich einen riesigen Shitstorm auslösen, wenn die regelmäßigeren Entwickler die Nachrichten sehen. Und es wird nicht um den Code gehen, sondern um das, was versprochen wurde. Und das Versprechen lautete: „Run net oder core und netstandard, um sie alle zu kombinieren“.

@DamianEdwards @davidfowl Danke, dass du den Plan geteilt hast.

SignalR auf 1.x ist eine große Erleichterung, unsere nicht unterstützte Version zu ersetzen, und auch die Nachricht, dass ServiceBase als nächstes auf der Liste steht, da wir das derzeit auch verwenden!

Wir sind jedoch stark auf EF6 und Spatial angewiesen, also bleiben wir bei 1.x hängen, bis das den Funktionsumfang hat, den wir brauchen ....

Als halb amüsante Randnotiz kann dies jedoch letztendlich eine weitere Bereitstellung von Microservices dafür erzwingen. Ich werde mich jedoch nicht darauf freuen zu erklären, warum unsere LOB-Kunden mehrere weitere APIs auf IIS installiert haben müssen, nur um unsere Produkte zum Laufen zu bringen ....

Ich wünschte wirklich, dies könnte zurückgehalten werden, da es einfach zu früh zu sein scheint und wie mehrere Leute erwähnt haben, wird dies eine erhebliche Gegenreaktion hervorrufen, wenn der Blog-Beitrag veröffentlicht wird.

Außerdem muss ich sagen, dass ich mich ein bisschen „solded-the-river“ fühle, wenn von Anfang an das Gefühl war, dass dies auf dem gesamten Framework laufen wird und Kollegen dasselbe gepredigt hat. Erklärt jedoch die verwirrende Namenswahl von asp.net core.

@shanselman @davidfowl Mein größter Schmerzpunkt ist NHibernate. Auch nach der Veröffentlichung von EF Core ist es immer noch der einzige fortschrittlichste O/R-Mapper mit vollem Funktionsumfang.

@shanselman @DamianEdwards Ich fange gerade an, darüber nachzudenken, eine Site von ASP.NET MVC 4 auf die neueste Version zu aktualisieren (ich bin verwirrt, ob es 5 oder eine ist). Ich muss immer noch das vollständige .net-Framework ausführen, da ich sowohl auf SyncFusion- als auch auf Telerik-Bibliotheken verweise. SyncFusion zum Anzeigen von PDF-Dateien und Telerik zum Generieren von Word-DOCX-Dateien. Wie andere darauf hingewiesen haben, ist es einfach nicht vernünftig, dass Microsofts Strategie für den Umgang damit lautet: "Probieren Sie es aus und sehen Sie, ob es funktioniert". Ich kann das nicht garantieren, und die Produktion wird alles funktionieren, weil es eine so große Codebasis von Code von Drittanbietern ist.

Während die SyncFusion-Unterstützung im Allgemeinen sehr gut ist, ist die Unterstützung von Telerik nicht so, und ich wäre überrascht, wenn sie es mit .net Core zum Laufen bringen könnten. Ich habe keine Ahnung, welche APIs sie möglicherweise verwenden, die in .net Core nicht unterstützt werden - und als Endbenutzer ist das der springende Punkt bei dem Produkt eines Drittanbieters. Ich schließe es einfach an und es tut, was es tun muss.

Ehrlich gesagt, für einen Kunden, der nicht sehr häufig mit dem Zeug handelt (ich mache meistens WPF), ist das alles außerordentlich verwirrend. Es gibt zu viele verschiedene Versionen mit verschiedenen Inkompatibilitäten. Wie jemand darauf hingewiesen hat, ist es ein bisschen wie UWP XAML - ähnlich, aber völlig inkompatibel mit WPF XAML.

Nicht gut für Entwickler und nur eine weitere Sache, die dazu führt, dass Entwickler das Vertrauen in Microsoft verlieren (eine von vielen in den letzten Jahren). Es scheint mir, dass ASP.NET definitiv auf dem vollständigen .net-Framework laufen sollte, weil es eine so große Bibliothek von Tools gibt, die Benutzer möglicherweise auf ihrem Server verwenden müssen. In meinem Fall kann ich bei Bedarf problemlos auf eine neuere Version des .net-Frameworks aktualisieren, um die neuesten ASP.net-Inhalte zu verwenden, wenn ein Update für die neue ASP.net-Funktionalität erforderlich war.

Was auch immer an die Entwickler gesendet wird, muss viel klarer sein, bevor die Leute einfach komplett abspringen.

...Stefan

ASP.NET Core auf .NET Framework wurde leider nie als Notlösung kommuniziert, um die Portierung zu erleichtern (das haben wir sehr schlecht kommuniziert). Es war nie beabsichtigt, eine für immer unterstützte Plattform zu sein, was die logische Schlussfolgerung ist, wenn Sie davon ausgehen, dass einige Abhängigkeiten einfach nie portiert werden.

Ich persönlich habe kein Problem mit den in dieser Ausgabe aufgeführten Änderungen, ich verstehe die Begründung und sie machen Sinn, jetzt, wo ich viele Antworten hier durchgelesen habe. Was Sie gerade gesagt haben, hebt jedoch hervor, was letztendlich der Kern des Problems ist - schlechte Kommunikation von Microsoft als Ganzes (was ich zu schätzen weiß, ist nicht Ihre Schuld oder die Schuld einer _spezifischen_ Einzelperson).

Vielleicht übersehe ich etwas, aber „im Freien entwickeln“ bedeutet mehr, als nur den Code auf Github zu haben, den jeder durchstöbern und damit spielen kann. Genau dieses Problem wurde erstellt, weil eines Tages eine Änderung im Code auftauchte, die die Leute überraschte, aber offensichtlich wussten Sie und alle im .net-Team davon und verstanden es – also ließ es lange auf sich warten. Das Problem ist, dass der Rest von uns Normalsterblichen davon völlig blind war.

Schlimmer noch, ich vermute, dass die Mehrheit der Entwickler github nicht allzu viel Aufmerksamkeit schenken, um ihr Wissen und ihre Informationen zu erhalten - also wird diese Änderung viel mehr Leute überraschen, als sie hier bereits kommentieren. Ich habe dieses Problem nur selbst entdeckt, weil es in meinem RSS-Feed von hackernews auftauchte – was nicht das ist, was ich als meine Top-Quelle für Nachrichten und Informationen bezeichnen würde.

Jeder, der die Blogbeiträge auf MSDN verfolgt, wird wissen, dass 2.0 kommt, und sie werden es als den heiligen Gral sehen, der die Lücke zwischen dem asp.net-Kern und allem, was ihm vorher „fehlte“, überbrückt, aber sie sind sich dessen überhaupt nicht bewusst was im Wesentlichen eine bahnbrechende Änderung für bestimmte Workflows ist. Es gab nur sehr wenige Details darüber, was wirklich mit dem Design von asp.net Core 2.0 passiert. Ich vermute, weitere Details werden später in dieser Woche bei Build kommen? Man kann nur hoffen.

Der .net-Slack ist eine weitere Informationsquelle, aber es ist ein bisschen laut, auf dem Laufenden zu bleiben, was wirklich vor sich geht. Es ist großartig, um Entwickler einzubeziehen und Fragen zu stellen, aber es ist kaum eine Nachrichtenquelle.

Twitter und soziale Medien sind weitere Informationsquellen, aber ähnlich wie diese Github-Ausgabe, wenn sie dort erscheint, liegt es normalerweise daran, dass jemand Bedenken hinsichtlich einer bereits getroffenen Entscheidung geäußert und die Leute überrascht hat.

Genau dieses Problem haben wir auch nicht zum ersten Mal. Erinnern Sie sich an das Fiasko, das durch den Wechsel zurück zu csproj verursacht wurde? Ich möchte nicht in die Debatten über diese Änderung einsteigen, aber es ist ein weiteres Beispiel für eine Änderung, die zur Überraschung der Leute geschah, die so schlecht kommuniziert wurde, dass bis heute viele Leute einfach nicht erkennen, dass es nicht dasselbe csproj ist aus der "schlechten alten Zeit".

Ich bin mir nicht ganz sicher, was ich hier vorzuschlagen versuche, aber bei der offenen Entwicklung von .net „fehlt“ definitiv etwas. Microsoft leistet großartige Arbeit bei der Bereitstellung von Ressourcen und Dokumentation für Entwickler, aber nur für fertige Produkte und ausgelieferte Dinge. Die Roadmap, die Planungsmeetings, alles, was über das Design und die Richtung der Frameworks entscheidet, scheint hinter verschlossenen Türen gemacht zu werden, mit der gelegentlichen Erwähnung von „ausgewählten Partnern“ und dergleichen. Ich sage nicht, dass jedes Meeting weltweit gestreamt und ausgestrahlt werden sollte, aber es könnte definitiv einen besseren Mittelweg geben, bei dem getroffene Entscheidungen und die Gründe dafür der Community so früh wie möglich auf einfache Weise mitgeteilt werden für diejenigen von uns, die wirklich mitmachen _wollen_, um zu verdauen und auf dem Laufenden zu bleiben. Vielleicht ein spezieller Blog auf MSDN (oder anderswo), der regelmäßig aktualisiert wird, wenn diese Entscheidungen getroffen werden.

Eines meiner größten Probleme dabei ist, dass Sie auf fast jeder Konferenz im letzten Jahr, auf der ASP.NET Core vorgestellt wurde, eine Folie präsentiert haben, die zeigt, dass asp.net Core sowohl auf .net Framework als auch auf .net Core ausgeführt wird Schauen Sie sich das an: Erkunden Sie die Webentwicklung mit Microsoft ASP.NET Core 1.0 von Ignite im letzten Jahr. Um etwa 7.50 Uhr sehen Sie die Folie.

Die größten Showstopper für mich sind System.DirectoryServices, ServiceBase, EF6 (EF Core ist nicht bereit), ClosedXML (zum Erstellen von Excel-Tabellen).

Die Unterstützung für ASP.NET Core 1.x auf .NET Framework wird um mindestens ein weiteres Jahr (bis Juli 2019) verlängert. Wir werden dies jährlich neu bewerten und uns dazu verpflichten, den Support für ASP.NET Core 1.x 12 Monate im Voraus zu beenden (also würden wir bis Juli 2018 bekannt geben, ob wir um weitere 12 Monate bis Juli 2020 verlängern) (Randbemerkung: is Ist sonst noch jemand ausgeflippt, weil wir schon über 2020 reden? Nein? Ok, nur ich.)

@DamianEdwards Vielen Dank für die Ankündigung.

Derzeit entwickelt unser Unternehmen Unternehmensanwendungen für mehrere Kunden mit ASP.NET Core 1.1 auf .NET Framework 4.6.2. Zu hören, dass die Unterstützung für diese Framework-Kombination mindestens bis 2019 und möglicherweise bis 2020 verlängert wird, ist eine große Erleichterung.

Wir werden dieses Jahr System.DirectoryServices und System.Drawing auf .NET Core portieren (vollständig unterstützt, plattformübergreifend, Vorschau für mindestens Windows im Sommer)

Dies sind die beiden einzigen Gründe , warum wir derzeit auf .NET Framework abzielen. Wenn diese vollständig auf .NET Core 2 portiert sind, bin ich sicher, dass wir unsere Anwendungen nächstes Jahr sicher auf ASP.NET Core 2 portieren können.

Scheint, als hätten viele Leute die Kardinalregel, ein MS-Entwickler zu sein, gebrochen – verpflichten Sie sich nicht zu einem Produkt/Fork bis mindestens V2.

Aber ja, sprechen Sie darüber, Ihre Unternehmenskunden zu entfremden! Der einzige Grund, warum sie MS verwenden, ist die Abwärtskompatibilität.

Die Mehrheit der Leute, die ASP.NET ausführen, KÜMMERT SICH NICHT, wenn es unter Linux läuft. Und wenn sie einen Blogbeitrag mit einem Geschwindigkeitsvergleich mit ASPNET Core sehen würden, würden sie beide nicht einmal plattformübergreifend lesen, wenn sie sehen würden, dass er Legacy .NET nicht unterstützt.

lolkatzen.

Ich denke, es ist sinnvoll, ASP.NET Core 2.0 vollständig auf net46x auszuführen, um vielen Leuten einen reibungslosen Migrationspfad in die neue Welt zu ermöglichen. Ich denke, viele Leute haben auf ASP.NET Core 2.0 und .NET Core 2.0 gewartet in der Hoffnung, dass es viele der heutigen Lücken schließen und eine Migration ermöglichen wird. Wenn ASP.NET Core 2.0 erfordert, dass alles auf netcoreapp2.0 portiert wird, dann wird dies eine massive Verlangsamung für Teams sein und vielleicht sogar die Machbarkeit gefährden.

Das bedeutet jedoch nicht, dass es nicht kurz darauf einen ASP.NET Core 3.0 geben kann, der nur auf netcoreapp2.0 für all die Leute abzielt, die an all dem neuen glänzenden Greenfield-Zeug arbeiten und auf der Überholspur sein wollen.

Zwei Versionen von ASP.NET Core (2.0 und 3.0) nebeneinander zu haben, könnte wirklich eine gute Sache sein (zumindest für eine Weile). Dadurch könnte MSFT den aktuellen MVC 5-Stack schneller auslaufen lassen, da die neue Version von MVC im Wesentlichen ASP.NET Core MVC 2.0 wäre, das auch auf vollständigem .NET laufen würde.

Ich denke, es ist sinnvoll, ASP.NET Core 2.0 vollständig auf net46x auszuführen, um vielen Leuten einen reibungslosen Migrationspfad in die neue Welt zu ermöglichen

Was würde es reibungsloser machen als die Portierung von ASP.NET Core 1.x?

Ich denke, viele Leute haben auf ASP.NET Core 2.0 und .NET Core 2.0 gewartet in der Hoffnung, dass es viele der heutigen Lücken schließen und eine Migration ermöglichen wird.

Der Großteil der Arbeit zur Kompatibilität wurde in .NET Core 2.0 und .NET Standard 2.0 geleistet. ASP.NET Core 2.0 hat ehrlich gesagt nicht so viele neue Funktionen. Uns wird gesagt, dass wir SignalR auf ASP.NET Core 1.x zurückportieren werden (was sowieso Post 2.0 ist). Ist es nur eine Wahrnehmungssache?

Zwei Versionen von ASP.NET Core (2.0 und 3.0) nebeneinander zu haben, könnte wirklich eine gute Sache sein.

Das machen wir mit 1.1 und 2.0 (einfach die Zahlen umdrehen).

Dadurch könnte MSFT den aktuellen MVC 5-Stack schneller auslaufen lassen, da die neue Version von MVC im Wesentlichen ASP.NET Core MVC 2.0 wäre, das auch auf vollständigem .NET laufen würde.

MVC 5 wird nie verschwinden, wir verwerfen nichts. Es wird unterstützt, solange .NET Framework existiert. Sie können immer noch keine ASP.NET Core-Projekte innerhalb der integrierten IIS-Pipeline (auf System.Web) ausführen, und es macht nicht alle die gleichen Dinge wie MVC 5 auf System.Web, also ist es wirklich kein Ersatz für bestimmte Szenarien .

@davidfowl Werde ich in der Lage sein, eine ASP.NET Core 1.x-App zu erstellen, die vollständig auf .NET und netcoreapp2.0 abzielt, sodass ich eine aktuelle Legacy-App zuerst auf ASP.NET Core migrieren kann, wobei alle Abhängigkeiten net46x sind, und langsam migrieren eine Abhängigkeit nach der anderen, um auf netstandard2.0 abzuzielen, bis alles auf netstandard2.0 ist, was es mir dann ermöglichen würde, die ASP.NET Core 1.x-App auf 2.x zu aktualisieren (und das Ziel für net46x als Teil davon zu löschen)?

Wenn ja, dann glaube ich, dass ich den Thread falsch verstanden habe. Ich denke, das ist wirklich das, wonach die meisten Leute hier suchen.

@dustinmoris ja das kannst du machen. Die Hauptsorge der Leute ist, was passiert, wenn sie nicht zu ASP.NET Core 2.x migriert werden, bevor der Support für ASP.NET Core 1.x endet, wenn es ihnen überhaupt möglich ist, zu migrieren.

@alexwiese ah ok na das ist ja super, was diskutieren wir denn jetzt hier eigentlich? Anstatt zu diskutieren, auf welches Framework wir abzielen, sollten wir den Supportzeitraum von ASP.NET Core 1.x diskutieren, was MSFT leicht ändern könnte, wenn sie es wollten :)

BEARBEITEN:
@DamianEdwards schrieb dies etwas weiter oben im Thread:

Die Unterstützung für ASP.NET Core 1.x auf .NET Framework wird um mindestens ein weiteres Jahr (bis Juli 2019) verlängert. Wir werden dies jährlich neu bewerten und uns dazu verpflichten, den Support für ASP.NET Core 1.x 12 Monate im Voraus zu beenden (also würden wir bis Juli 2018 bekannt geben, ob wir um weitere 12 Monate bis Juli 2020 verlängern) (Randbemerkung: is Ist sonst noch jemand ausgeflippt, weil wir schon über 2020 reden? Nein? Ok, nur ich.)

Klingt gut für mich. Verpflichten Sie sich zu einem weiteren Jahr Support und führen Sie dann regelmäßige Neubewertungen durch. Macht für mich total Sinn.

Ich habe jeden Beitrag in diesem Thread gelesen. Eine Frage ist noch offen: Warum wird diese Entscheidung getroffen? Ich kann nur zu dem Schluss kommen, dass es aufgrund eines technischen Problems erforderlich war. Wenn „Verwirrung“ bei der Benennung das Problem ist, sollte Microsoft einen besseren PR-Mitarbeiter einstellen und aufhören, die Scheiße zu rühren, wie es das Team in diesem Thread tut.

Was ist also das technische Problem, das ASP.NET Core 2.0 auf netstandard2.0 blockiert hat? Nichts ist unmöglich im Softwareland, also kann es nicht sein, dass Sie keine Lösung finden konnten, die auf .NET full nicht machbar ist (und daher nicht in netstandard20 aufgenommen werden kann). Ja, das kostet Zeit und Mühe, aber ich habe das Gefühl, dass Sie alle die Nebenwirkungen dieser Entscheidung für Ihre Benutzer nicht wirklich erkannt haben, wie viel Zeit / Mühe sie dafür investieren müssen.

Diese Entscheidung hat einen weiteren Nachteil: ASP.NET Core ist kein Konsument von netstandard und daher auch kein Treiber davon. Es macht den Netzstandard zu einem Nachfolger, und da der ASP.NET-Core nicht davon abhängt, zu einem Nachfolger mit geringer Bedeutung: Die API von .net Core 2.0+ ist die Zieloberfläche, da der ASP.NET-Core auf diese Oberfläche abzielt, nicht Netzstandard2.0.

Und, sorry @davidfowl , ich weiß, dass Sie es gut meinen, aber Menschen immer wieder ASP.NET Core 1.x vorzuschlagen, zeigt, dass Sie wirklich keine Ahnung haben, wie die Situation für die Menschen ist, denen Sie das vorschlagen: die Menschen können nicht migrieren auf ASP.NET Core 1.x, weil sie nicht wissen, ob es ohne feste Frist einen reibungslosen Weg davon gibt: Es könnte sein, dass sie länger auf dieser Plattform bleiben müssen, als sie derzeit denken (Abhängigkeiten mussten portiert werden etc.). Das allein macht die Entscheidung, zu ASP.NET Core 1.x zu wechseln, zu einer Entscheidung, die auf nichts anderem als einem „Versprechen“ von Microsoft basiert. Es ist eine API, die für internetorientierten Code gedacht ist. Sie müssen wissen, ob sie eine heute erstellte App auch innerhalb von 3 Jahren ausführen können, da Microsoft Sicherheitslücken darin beheben wird (um ein Beispiel zu nennen).

Ehrlich gesagt verspüre ich nicht den Drang, einen weiteren Chaos-Cluster innerhalb des .NET-Ökosystems zu starten: Wir brauchen Stabilität, Verlässlichkeit, Verlässlichkeit: "Mein heute geschriebener Code wird in 5 Jahren so laufen, wie er ist". Ja, ich weiß, das klingt für manche Leute albern, aber das ist die Realität: Es gibt bereits mehr Softwarepakete auf diesem Planeten als Entwickler, die sie warten, und die Kluft wird immer größer. Sie können nicht einfach davon ausgehen, dass sich eine Organisation für die Verwendung von ASP.NET Core als Webstack entscheidet und hoffen, dass der damit geschriebene Code innerhalb von 5 Jahren ausgeführt wird. Organisationen tun dies nicht mehr: Sie wissen, dass es Stacks gibt, die es gibt zuverlässig und geben Sie ihnen das: Sie wissen, dass sie möglicherweise nicht in der Lage sind, die gesamte App innerhalb dieses Zeitrahmens neu zu schreiben, also brauchen sie diese Gewissheit.

Microsoft hat mit diesem Thread und, Entschuldigung, ihrer schrecklichen PR zu diesem Thema gezeigt, dass sie diese Zusicherung nicht geben können. Und ganz gleich, wie sehr Sie versuchen, dem in den kommenden Tagen bei \build einen Schub zu geben, wir auf der anderen Seite des Zauns haben gelernt, dass die Dinge mit Microsoft Marketing != Assurance morgen funktionieren werden.

@FransBouma Ich glaube nicht, dass es ein technisches Problem gab, es hört sich so an, als ob die Motivation, nur auf netcoreapp2.0 abzuzielen, darin besteht, dass dies die einzige Strecke ist, auf der sich MSFT so schnell bewegen kann, wie sie möchten, was für uns danach gut ist alles, weil es bedeutet, dass ASP.NET Core 2.x sich viel schneller bewegen kann als alle anderen Webstacks in der .NET-Welt zuvor. Wenn Sie sich nicht auf diesen Schnellzug festlegen können, können Sie länger auf ASP.NET Core 1.x bleiben (wird derzeit bis 2019 unterstützt).

@FransBouma , wie @davidfowl und @shanselman erwähnt haben, dass in .NET Core schnell neue APIs hinzugefügt werden, und ASP.NET Core 2.x wird einige davon verwenden, daher der Wunsch, netcoreapp20 ins Visier zu nehmen. Wenn sie diese APIs zu netstandard2x hinzufügen würden, müssten .NET Framework und andere Plattformen aufholen, und sie bewegen sich notorisch langsam.

Ich werde meine Stimme auf der Seite „Das ist eine gute Sache“ der Debatte hinzufügen. Hier ist der Grund:

• Das Team macht das nicht nur zum Spaß. Es gibt eine ganze Reihe neuer Features und Optimierungen, die bereit (oder fast bereit) sind, in .NET Core eingeführt zu werden, die unglaublich nützlich für Leute sind, die moderne Webanwendungen, APIs und Microservices erstellen und darauf warten, dass diese Features im vollständigen Windows .NET Framework landen würde die Veröffentlichung um viele Monate verzögern.
• Viele der Beschwerden, die ich in diesem Thread sehe, sind Variationen von „Ich kann X in .NET Core 2.0 nicht ausführen“, wenn der Autor eigentlich meint: „Ich muss die Art und Weise ändern, wie ich X in .NET Core 2.0 mache.“ _. Ja, du musst dich ändern. Nein, das ist nichts Schlimmes. Wenn Sie eine kleine diskrete Funktionalität in Ihrer ASP.NET MVC-Anwendung haben, die etwas mit PDFs oder DOCX-Dateien macht, und Sie _wirklich_ keinen besseren Weg finden können, was auch immer das ist (haben Sie es versucht?), dann brechen Sie das Funktionalität in einen Microservice aus, der auf vollständigem .NET auf Windows Server ausgeführt wird, und rufen Sie ihn als HTTP-API von Ihrer .NET Core-Anwendung auf. Das Zerlegen von Anwendungen und das Verschieben bestimmter Funktionen in kleine, eigenständige Dienste ist nicht einmal eine Problemumgehung, _es ist eine bewährte Methode für allgemeine Zwecke_.
  
  
  
  • NB: Soweit ich das beurteilen kann, unterstützen die OpenXML-Pakete jetzt .NET Standard, sodass das Arbeiten mit Word/Excel/was auch immer nicht unmöglich sein sollte.
  
  
• .NET Core 2.0 befindet sich noch nicht einmal in der richtigen öffentlichen Vorschau, daher scheint es verfrüht zu sein, sich darüber zu beschweren, dass es keine Unterstützung für LDAP oder was auch immer hat. Wenn RTM in Q3 kommt und es immer noch keine Möglichkeit gibt, mit AD oder Kerberos oder was auch immer zu interagieren, dann beschweren Sie sich (obwohl Sie auch über die Migration zu modernen Token-basierten Authentifizierungssystemen nachdenken, weil wir nicht mehr 2008 sind).
• Es _gibt_ eine reibungslose Migration von ASP.NET MVC 4.5 zu ASP.NET Core 2.0. Es heißt ASP.NET Core 1.0 (und ich stimme zu, dass es unter den gegebenen Umständen ein gewisses Versprechen auf langfristige Unterstützung für 1.0 geben sollte). Sie können Apps mit 1.0 erstellen und sie auf Full .NET in einer integrierten Pipeline unter IIS 8.5 auf Windows Server 2012 R2 bis ausführen
  
  
  
  • Full .NET holt auf und Sie können ASP.NET Core 2.x darauf ausführen, oder
  
  
  • Unabhängig davon, auf welche Technologie von Drittanbietern Sie sich verlassen, unterstützt sie .NET Core (oder kann durch eine gleichwertige Technologie ersetzt werden, die .NET Core unterstützt).
  
  
• Denken Sie daran, dass – während Ihr Team möglicherweise durch externe Abhängigkeiten oder interne Unternehmensrichtlinien oder -politik oder einfach nur Trägheit behindert wird – es Hunderttausende, wenn nicht Millionen von Entwicklern auf der Welt gibt, die versuchen, Anwendungen, Dienste und APIs mit modernen zu erstellen Architekturmuster und neue Technologieplattformen (Cloud/Edge/IoT/etc), für die ASP.NET Core 2.0 hervorragend geeignet ist. Sie wollen, dass es schnell, skalierbar und plattformübergreifend ist; Diese Dinge sind vielen Menschen wichtig. Von Microsoft zu verlangen, diesen schnell wachsenden Markt zu ignorieren, nur weil Ihr Drittanbieter von Steuerungen oder ein Open-Source-Projekt seinen Code noch nicht portiert hat, ist dumm.

@dustinmoris , das darauf hindeutet, dass netstandard die APIs fehlen, um einen schnellen Webstack zu erstellen. Wenn ja, haben wir alle größere Probleme.

@alexwiese wie gesagt, ich habe den kompletten Thread gelesen und somit auch die Beiträge auf die du dich beziehst. Ich weiß, was sie sagen und kann ihren Standpunkt verstehen, aber die getroffene Entscheidung zeigt, dass sie keine Ahnung haben, was ihre Benutzer mit ihren Sachen machen. Ich baue selbst seit vielen Jahren ein Produkt und weiß, dass man nach einer Weile an einem Punkt ankommt, an dem man Dinge herausschneiden und schneller vorankommen möchte, ohne den alten Kram, der veraltet ist. Aber das hat Konsequenzen, und eine Sache, die ich in den letzten 14 Jahren gelernt habe, ist, dass Abwärtskompatibilität eines der größten Merkmale ist, die ein Softwareprodukt haben kann: Es zu verwenden und „es funktioniert einfach“ ist ein entscheidender Punkt dafür viele viele Menschen sich für Ihre Plattform entscheiden. Sie denken vielleicht, dass es nicht so wichtig ist, und das ist in Ordnung, aber es gibt viele, viele Menschen da draußen, die das nicht so sehen können, da ihre Realität anders ist.

Es ist nicht so, dass das asp.net-Kernteam nicht schnell handeln sollte, es ist so, dass sie es auf eine Weise tun, die mit den Annahmen vieler Leute bricht, als sie zu asp.net Core 1.x wechselten.

@FransBouma Warum denkst du, hast du eine bessere Vorstellung davon, was die Benutzer von Microsoft mit den Sachen von Microsoft tun, als Microsoft?

@markrendle

Das Team macht das nicht nur zum Spaß. Es gibt eine ganze Reihe neuer Features und Optimierungen, die bereit (oder fast bereit) sind, in .NET Core eingeführt zu werden, die unglaublich nützlich für Leute sind, die moderne Webanwendungen, APIs und Microservices erstellen und darauf warten, dass diese Features im vollständigen Windows .NET Framework landen würde die Veröffentlichung um viele Monate verzögern.

Sagen Sie mir also, warum erstellen Sie diese Super-Duper-APIs nicht als .net-Standard-2.0-Pakete und veröffentlichen sie auf nuget?

Warum denken Sie, dass Sie eine bessere Vorstellung davon haben, was die Benutzer von Microsoft mit den Sachen von Microsoft machen, als Microsoft?

Oh, ich weiß nicht, nachdem ich die Beiträge in diesem Thread gelesen habe?

@FransBouma

Das deutet darauf hin, dass Netstandard die APIs fehlen, um einen schnellen Webstack zu erstellen. Wenn ja, haben wir alle größere Probleme.

Ich denke nicht, dass netstandard etwas fehlt, denn netstandard ist nichts anderes als eine Liste von Funktionen, die von einer Plattform implementiert werden müssen, die diesen Standard unterstützen möchte. Theoretisch können wir Netstandard so schnell verschieben, wie wir wollen, einfach mehr zur Spezifikation hinzufügen, aber realistischerweise ist es nicht für alle Plattformen möglich, diese neuen Spezifikationen einzuholen.

Die Frage ist also, will sich ASP.NET Core 2.x auf netstandard2.0 (der derzeit höchste) festlegen und dann wissen, dass es bei allem bleibt, was dort definiert wurde, oder nur ASP.NET Core 2.x verpflichten Sie sich zu netcoreapp2.x, das viel mehr sein kann als nur netstandard2.0. Ich bin mir sicher, dass es nach einer Weile wieder einen neueren Netzstandard geben wird (3.x?), der die neuen glänzenden Dinge von netcoreapp einholt, aber das wird viel mehr Zeit in Anspruch nehmen, und warum sollten ALLE asp.net-Frameworks an einem langsamen Fortschritt gehindert werden . Es ist irgendwie nett, einen wirklich schnellen ASP.NET Core-Stack zu haben, solange es auch einen zweiten gibt, der den Leuten eine langfristigere Unterstützung bietet, die sich an netstandard hält.

@FransBouma Oh, tut mir leid, ich wusste nicht, dass Ihre Stichprobengröße so groß ist. 257 Kommentare mit einer starken Tendenz zu Leuten, die die Entscheidung nicht mögen? Dagegen lässt sich schwer argumentieren.

HAFTUNGSAUSSCHLUSS: Ich bin kein Experte für Big Data.

@davidfowl :

In diesem Thread haben Sie System.DirectoryServices als eines der Kernelemente bezeichnet. Ich nehme an, Sie haben einige Abhängigkeiten, von denen Sie glauben, dass es lange dauern wird, bis sie portiert werden, oder solche, die niemals portiert werden. Wenn 2.0 .NET Framework unterstützt, würden sich diese Abhängigkeiten in einem Jahr verschieben?

Ja, wir haben andere Sachen. Ich weise auf System.Directory-Dienste hin, da selbst der oberste angeforderte Namespace noch nicht bereit ist. Alle anderen sind schlechter dran. Der API-Portabilitätsanalysator wird nicht einmal für VS 2017 aktualisiert, wo wir ihn ausführen können. Der Analysator, um zu sehen, ob Sie überhaupt portieren können, wurde nicht investiert, und wir stellen den Support bereits ein.

Welche?

Razor Pages ist riesig, ich habe es mehrmals erwähnt.

Ich weiß nichts über stackoverflow.com, aber ist es möglich, Teile abzubrechen (ich möchte nicht "Mikrodienste" sagen), damit ASP.NET Core für einige Teile verwendet werden kann?

Nein, das ist nicht wirklich möglich. Wir rendern nicht in 18 ms, indem wir API-Aufrufe tätigen und Overhead zwischen den Dingen hinzufügen. Ich gehe jederzeit gerne auf Architektur ein, Sie werden sehen, dass das kein wirklich vernünftiger Weg ist.

Ich dachte, ich hätte das schon früher erklärt, aber hier ist es noch einmal:

Jede API, die Teil von netstandard ist und weiterentwickelt werden muss, wird sich langsam weiterentwickeln. Dinge können auf netstandard aufgebaut werden und überall laufen, und das ist in Ordnung. In dem Moment, in dem Sie eine neue API für beispielsweise einen HTTP-Client oder SSL-Stream oder Int oder String oder Array oder LINQ oder eines der in NET Standard vorhandenen Primitive benötigen, muss eine neue .NET Standard-Version erstellt und implementiert werden zuzustimmen, dass sie es umsetzen werden. Nun, das ist nicht das Ende der Welt, denn wir besitzen jetzt die meisten von ihnen, Mono, .NET Core, .NET Framework, UWP, aber es gibt andere wie Unity (und wahrscheinlich noch andere). Jede .NET-Vertikale hat ihren eigenen Zeitrahmen und Auslieferungszyklus, sie sind jeweils ihre eigenen separaten Produkte und das kann nicht ignoriert werden.

Aber jetzt kommen Sie auf die Idee, eine neue Netstandard-Version wird erstellt, wenn neue APIs online gehen. Wenn Bibliotheken diese neuen APIs verwenden möchten, verliert man sofort den Atem an Unterstützung für alle Plattformen. Sie können über Kreuz kompilieren und versuchen, Polyfill zu erstellen, aber das skaliert nicht für alle Änderungen.

Hoffentlich gibt Ihnen das eine Vorstellung davon, wie der Prozess aussehen könnte, APIs zu netstandard zu bringen. @terrajobst hätte eine bessere Vorstellung davon, was der Plan ist.

@DamianEdwards und @shanselman Was ist mit Service Fabric und Komponententests?

In unserem Fall haben wir ein großes Mikrodienstprojekt mit vielen SF-Anwendungen, die Core-Projekte sind, aber .Net Framework 4.5 bis 4.6 (etwas) verwenden. SF unterstützt derzeit netcoreapp nicht, daher mussten wir .Net Framework verwenden, aber da wir nicht ins Hintertreffen geraten wollten, haben wir das .Net Core-Projekt verwendet.

(Ein weiteres Problem ist) Da unsere Dienste .Net Framework sind und MS Fakes für netcoreapp nicht verfügbar sind, sind alle unsere Komponententests normale (oder sollte ich sagen ältere) .Net Framework-Projekte. Fast alle unsere Bibliotheken sind auf Netzstandard 1.0 bis 1.6.

Auch hier verwenden unsere Client-Apps Xamarin Forms + UWP, und wir haben es geschafft , netstandard zu verwenden, damit unsere Bibliotheken kompatibel sind.

Bedeutet dies, dass wir feststecken und nicht auf .Net Core 2.0 und netcoreapp2.0 und netstandard 2.0 upgraden können?

@ Nick Craver

Razor Pages ist riesig, ich habe es mehrmals erwähnt.

Ich verstehe das, aber ich kann nicht glauben, dass Sie den gesamten Stapelüberlauf nur in Rasiermesserseiten konvertieren werden. Wenn Sie MVC bereits heute verwenden, warum portieren Sie nicht einfach auf normale Ansichten und wenn mehr Abhängigkeiten online gehen, portieren Sie auf Razor Pages. Die Art und Weise, wie Razor Pages gestaltet sind, macht es trivial, von einer Controller-Aktion zu einer Razor Page zu wechseln.

Ja, wir haben andere Sachen. Ich weise auf System.Directory-Dienste hin, da selbst der oberste angeforderte Namespace noch nicht bereit ist. Alle anderen sind schlechter dran. Der API-Portabilitätsanalysator wird nicht einmal für VS 2017 aktualisiert, wo wir ihn ausführen können. Der Analysator, um zu sehen, ob Sie überhaupt portieren können, wurde nicht investiert, und wir stellen den Support bereits ein.

Stellen Sie einfach sicher, dass Sie diese Liste der Abhängigkeiten eskalieren, damit wir wissen, was wichtig ist.

@abo

Bedeutet dies, dass wir feststecken und nicht auf .Net Core 2.0 und netcoreapp2.0 und netstandard 2.0 upgraden können?

Sie meinten ASP.NET Core 2.0 und? .NET Core 2.0 und .NET Standard 2.0 kommen hier nicht wirklich zur Anwendung.

Ja, Sie müssen auf ASP.NET Core 1.x bleiben.

Der Großteil der Arbeit zur Kompatibilität wurde in .NET Core 2.0 und .NET Standard 2.0 geleistet. ASP.NET Core 2.0 hat ehrlich gesagt nicht so viele neue Funktionen. Uns wird gesagt, dass wir SignalR auf ASP.NET Core 1.x zurückportieren werden (was sowieso Post 2.0 ist). Ist es nur eine Wahrnehmungssache?

@davidfowl Ich denke, Sie unterschätzen massiv die Angst, die das Herz eines Windows-Entwicklers trifft, wenn Ihnen gesagt wird, dass Sie Dinge migrieren müssen. _Besonders_ wenn der neue Stack die Feature-Parität mit dem alten Stack nicht erreicht hat und es nicht bekannt ist, ob und wann das passieren wird. Dies kündigt im Grunde das EOL von ASP.NET Core für das vollständige .NET Framework an. Und obwohl das wahrscheinlich nicht der langfristige Plan war, wurde es als Feature angekündigt, und die Leute dachten, es könnte noch eine Weile so bleiben. Die Roadmaps verschieben sich, während wir hier sprechen. Besprechungen werden stattfinden.

Wir haben ein paar ekelhaft alte Sachen, die wir wegen nominell gewarteter Datenbankkonnektoren und SDKs unterstützen müssen. Einige dieser Anbieter werden viel wahrscheinlicher eine neue, abgeschlachtete API mit 30 % bestehender Funktionalität, einer HTML5-Oberfläche und einer neuen Reihe von Fehlern veröffentlichen, als ihre bestehenden Produkte zu warten. Oder sie übernehmen einfach einen Konkurrenten, bringen das Produkt auf den Markt und beenden es schnell. Einige dieser Anbieter sind groß genug, um erkennbar zu sein. Wir haben eine Menge netten Code, aber ein Teil dieses Codes lebt trotz unserer Bemühungen auch in den Windows-Slums, weil er nicht immer unter unserer Kontrolle ist. Alte Technologie geht nicht einfach elegant in den Ruhestand. Es lauert unter Ihrem Bett, in unserem Schrank und unter Ihrer Tastatur.

Ich mache mir mehr Sorgen über diesen Schritt, der das mögliche Ausscheiden von .NET Standard signalisiert, als über den Rest. .NET Standard schien zunächst etwas zu sein, das die verschiedenen Implementierungen näher und näher an die Feature-Parität bringen würde, während es den Verbrauchern ermöglichte, auf die sich entwickelnde, wachsende Plattform zu migrieren. Jetzt klingt es wie nichts weiter als ein Meilenstein der .NET Core-Features. Sie können (oder wollen) keine ausführbaren Dateien auf .NET Standard ausrichten – nur Bibliotheken. Und es hört sich so an, als würde .NET Standard deutlich weniger Planung erfordern und stattdessen einfach mit dem abgesegnet werden, was in ASP.NET verwendet wurde, weil es für eine Änderung bereits zu spät ist. Es wird schließlich bereits in Produktion sein.

Andere Entwickler müssen den Code mit Compiler-Direktiven bestreuen, den Code in plattformspezifische Bibliotheken aufteilen und mit mehreren Zielen kompilieren. Der unhöfliche Teil von mir möchte, dass das ASP.NET Core-Team das dogfoodt, damit Sie an besserer Laufzeit- und Toolunterstützung für Multi-Targeting- und Multi-Plattform-Szenarien interessiert sind. Und wenn Ihr Team es möchte, bekommen wir es vielleicht. Der praktische Teil von mir sagt, dass Sie mindestens regelmäßige Versionen von ASP.NET Core haben sollten, die auf .NET Standard abzielen. Sie müssen sowieso aktuelle _stable_ Releases machen. Niemand wird einfach den Master-Branch aus Git kompilieren und in der Produktion bereitstellen. Warum nicht kleinere Iterationen des .NET-Standards erstellen und sie mit einer getaggten ASP.NET-Version abgleichen?

Wird es außerdem ein neues ASP.NET für den Desktop geben? All die Fanfare ließ es so klingen, als wäre ASP.NET Core das einzige ASP.NET. Jetzt hört es sich so an, als würden Sie auf ASP.NET nichts Neues erhalten, es sei denn, Sie sind auf .NET Core. Und das wird viele Geschäftsstrategien verändern. Bei Roadmaps herrscht eine Menge Verwirrung.

MVC 5 wird nie verschwinden, wir verwerfen nichts. Es wird unterstützt, solange .NET Framework existiert.

Ja, wir sind uns ziemlich bewusst, dass das alte Zeug dort bleiben wird. Das tut es normalerweise, und wir wissen das zu schätzen. Aber ob neue Dinge auf den "vollen" Rahmen kommen, ist sehr wichtig. Wir müssen wissen, wohin die Dinge gehen. Wir wollen nicht bis zum Ende mit dem Zug fahren und erst dann darüber nachdenken, wie es weitergeht. Wir haben auch unsere Passagiere, um die wir uns Sorgen machen müssen. Und die Diskrepanz zwischen .NET Core und .NET Framework lässt viele Menschen im Hinblick auf die Zukunft ungewiss zurück. Ich habe vor anderthalb Jahren eine Frage dazu gestellt, wann ein bestimmter Teil der Funktionalität in .NET Core unterstützt wird. Ich fragte sogar, ob es akzeptiert würde, wenn ich persönlich daran arbeiten würde. Die Kommunikation war spärlich. Ich habe noch keine Ahnung, was damit passieren wird. Diese Art von Ungewissheit über unterstützte Szenarien und Zeitpläne macht einen großen Unterschied in dem Code, den wir schreiben. Selbst wenn man weiß, welche Abschnitte des Desktop-Frameworks eine niedrige Priorität haben, könnte man ausreichend Zeit für die Migration haben, anstatt auf Statusaktualisierungen warten zu müssen.

Kurz gesagt, ich unterstütze, was Sie tun und die Ziele dahinter. Und ich weiß, es ist hart, wenn wir hier weiterkommen und uns über Entscheidungen beschweren, die Sie aus einem sehr guten Grund getroffen haben. Aber viele Leute werden nicht auf den Pionierzug aufspringen, weil sie es nicht können, und andere nicht, weil sie nicht wissen, wohin er führt.

@davidfowl denke ich. Wie nennt man ein Kernprojekt (neu) mit .Net Framework? Was auch immer das ist, ich verstehe aus dem Beitrag, dass der Netzstandard vNext dies nicht unterstützt.

@markrendle Wir sind echte Kunden. Wir sagen den Leuten, dass die Dinge nicht funktionieren werden. Ich kenne meine Architektur besser als Sie, also helfen die arroganten Kommentare nicht. Zu deinen Punkten:

Das Team macht das nicht nur zum Spaß. Es gibt eine ganze Reihe neuer Features und Optimierungen, die bereit (oder fast bereit) sind, in .NET Core eingeführt zu werden, die unglaublich nützlich für Leute sind, die moderne Webanwendungen, APIs und Microservices erstellen und darauf warten, dass diese Features im vollständigen Windows .NET Framework landen würde die Veröffentlichung um viele Monate verzögern.

Niemand ist dagegen, dass sie diese Dinge auch unterstützen. Unsere Beschwerden beziehen sich allgemein darauf, den Support einzustellen und nicht bedingt neue Funktionen hinzuzufügen.

Viele der Beschwerden, die ich in diesem Thread sehe, sind Variationen von „Ich kann X in .NET Core 2.0 nicht ausführen“, wenn der Autor eigentlich meint: „Ich muss die Art und Weise ändern, wie ich X in .NET Core 2.0 mache“. Ja, du musst dich ändern. Nein, das ist nichts Schlimmes. Wenn Sie eine kleine diskrete Funktionalität in Ihrer ASP.NET MVC-Anwendung haben, die etwas mit PDFs oder DOCX-Dateien macht, und Sie wirklich keinen besseren Weg finden können, was auch immer das ist (haben Sie es versucht?), dann brechen Sie das Funktionalität in einen Microservice aus, der auf vollständigem .NET auf Windows Server ausgeführt wird, und rufen Sie ihn als HTTP-API von Ihrer .NET Core-Anwendung auf. Das Zerlegen von Anwendungen und das Verschieben bestimmter Funktionen in kleine, eigenständige Dienste ist nicht einmal eine Problemumgehung, sondern eine allgemeine Best Practice.

Das ist einfach so weit weg von der Basis, dass ich nicht weiß, wo ich anfangen soll. Unsere Seiten wären in "Micro-Services" viel langsamer und teurer. Wir würden mit einem solchen Setup deutlich mehr Zeit in GC fressen als in Seitenrenderern. Dies macht auch die Annahme, dass die vollständige Framework-Abhängigkeit kein kritischer Teil jeder Seitenwiedergabe ist. Schlechte Annahme.

.NET Core 2.0 befindet sich noch nicht einmal in der richtigen öffentlichen Vorschau, daher scheint es verfrüht zu sein, sich darüber zu beschweren, dass es keine Unterstützung für LDAP oder was auch immer hat. Wenn RTM in Q3 kommt und es immer noch keine Möglichkeit gibt, mit AD oder Kerberos oder was auch immer zu interagieren, dann beschweren Sie sich (obwohl Sie auch über die Migration zu modernen Token-basierten Authentifizierungssystemen nachdenken, weil wir nicht mehr 2008 sind).

Uns wurde gesagt , dass sie nicht da sein werden. Beobachte den Aufstand. Oder schauen Sie sich GitHub an, wo es mit "Future" beschriftet ist. Wir beschweren uns jetzt, weil diese schlechte Entscheidung in Q3 ausgeliefert wird.

Es gibt eine reibungslose Migration von ASP.NET MVC 4.5 zu ASP.NET Core 2.0. Es heißt ASP.NET Core 1.0 (und ich stimme zu, dass es unter den gegebenen Umständen ein gewisses Versprechen auf langfristige Unterstützung für 1.0 geben sollte).

Langfristige Unterstützung bedeutet nicht, dass es keine Sackgasse ist. Wir können immer noch leicht auf 1.x festsitzen, wenn es das Ende seiner Lebensdauer erreicht. In diesem Fall hätten wir längere Unterstützung für das vollständige Framework gehabt.

Das vollständige .NET holt auf und Sie können ASP.NET Core 2.x darauf ausführen

Es zielt auf netcoreapp ab, das wird nicht passieren.

... oder welche Technologie von Drittanbietern Sie verwenden, um .NET Core zu unterstützen (oder durch eine gleichwertige Technologie ersetzt werden kann, die .NET Core unterstützt).

Diese Bibliotheken liegen oft außerhalb der Kontrolle und des Zeitbudgets der Menschen. Auch Bibliotheken von Microsoft werden nicht aktualisiert . Ich kämpfe gerade mit dem SQL-Team, um ihre Pakete zu aktualisieren, damit sie auf dem neuen Projektsystem funktionieren, weil install.ps1 funktioniert. Wenn wir nicht einmal diese einfachen Korrekturen einbauen können, sind wir mit netstandard Ports am Arsch.

Denken Sie daran, dass – während Ihr Team möglicherweise durch externe Abhängigkeiten oder interne Unternehmensrichtlinien oder -politik oder einfach nur Trägheit behindert wird – es Hunderttausende, wenn nicht Millionen von Entwicklern auf der Welt gibt, die versuchen, Anwendungen, Dienste und APIs mit modernen zu erstellen Architekturmuster und neue Technologieplattformen (Cloud/Edge/IoT/etc), für die ASP.NET Core 2.0 hervorragend geeignet ist. Sie wollen, dass es schnell, skalierbar und plattformübergreifend ist; Diese Dinge sind vielen Menschen wichtig. Von Microsoft zu verlangen, diesen schnell wachsenden Markt zu ignorieren, nur weil Ihr Drittanbieter von Steuerungen oder ein Open-Source-Projekt seinen Code noch nicht portiert hat, ist dumm.

Es dumm zu nennen, ist herabsetzend, unhöflich und unangebracht. Das ist unser Leben. Das sind unsere Apps. Das sind die Dinge, an denen wir Jahre oder Jahrzehnte gearbeitet haben, um sie zu erschaffen, und plötzlich stellen wir vor der Veröffentlichung fest, dass die Aussicht für uns zeitlich begrenzt ist, hart. Eine Menge Unsicherheit wird eingeführt, um es gelinde auszudrücken. Das ist nicht wirklich etwas, was Sie in Ihrer Karriere wollen.

Jeder Punkt macht Sinn, aber denken Sie daran, dass in diesem Universum alles in den Zustand gehen wird, der weniger Energie erfordert, dann stellen Sie sicher, dass dieser Zustand der ist, in den Sie gehen möchten, denn wir werden auf die eine oder andere Weise dorthin gelangen.
Wenn Sie also einen bestimmten Zustand erreichen möchten, stellen Sie sicher, dass er weniger Energie benötigt als der, der erforderlich ist, um dort zu bleiben, wo wir jetzt sind.

Ich habe gerade diesen ganzen Thread durchgelesen, nachdem jemand dies als Nebenbemerkung im IRC erwähnt hatte - ich habe noch keine offizielle Ankündigung dazu gesehen - und ich bin gründlich enttäuscht.

Ich habe .NET Core beobachtet, mitgemacht und kleine Projekte von .NET Framework auf .NET Standard / .NET Core umgestellt, um Erfahrungen mit dem neuen SDK und der Runtime zu sammeln und diese Projekte unter macOS und Linux auszuführen .

Mein großes Ziel ist ein großer Unternehmenswebdienst, der eine Menge Komponenten verwendet, die [noch] nicht in .NET Core 1.0 oder 1.1 verfügbar sind. Dazu gehören, nur aus der Spitze meines Kopfes:

• Active Directory ( System.DirectoryServices ), wird für die Authentifizierung und Benutzerverwaltung verwendet
• Entity Framework 6 ( EntityFramework ), da EF Core viele der von uns verwendeten Funktionen noch nicht unterstützt.
• OData ( Microsoft.Data.Services / System.Data.Services ) v1-3, die von uns verwendete Client-JavaScript-Bibliothek unterstützt v4 (noch) nicht, und WebAPI-OData ist viel komplexer einzurichten.
• IIS-Verwaltung ( System.Web.Management ) und .NET Remoting ( System.Runtime.Remoting ) für die Fähigkeit des Webdienstes, sich selbst zu aktualisieren – obwohl dies in eine eigenständige Anwendung extrahiert werden könnte.
• SignalR
• Benutzerdefinierte IHttpHandler s und IHttpModule s, die an das Äquivalent von ASP.NET Core angepasst werden müssten, wahrscheinlich eine Art Middleware
• Eine ganze Reihe von benutzerdefinierten Dingen, die die Erweiterbarkeit von ASP.NET WebAPI verwenden.
• Ich denke, wir könnten sogar Microsoft.TeamFoundationServer.ExtendedClient auf dem Server verwenden, der nur net46 unterstützt, einige native Assemblys hat und eine Chance von etwa 0 % hat, an .NET Core 2.0 zu arbeiten.
• usw.

Aufgrund der Größe und Komplexität dieses Dienstes müsste jede Migration zu .NET Core schrittweise erfolgen, und aller Wahrscheinlichkeit nach müssen wir möglicherweise einige neue APIs in ASP.NET-Core-2.0 verwenden, ich weiß es nicht doch so weit sind wir noch nicht gekommen.

Das Entfernen der Möglichkeit, ASP.NET Core auf dem .NET Framework auszuführen, bedeutet, dass Migrationen im Big-Bang-Stil durchgeführt werden müssen, wenn ASP.NET Core 1.x kein praktikables Sprungbrett ist. Wir verlieren sofort die Phase „Neues Framework auf alter Laufzeit ausführen“ vor „Neues Framework auf neuer Laufzeit ausführen“. Dies ist eine schreckliche Change-Management-Strategie für jedes große System.

Ich hätte nichts dagegen, wenn die .NET Framework-Unterstützung eingestellt würde, sobald .NET Core auf oder nahe der Parität war, aber es ist immer noch ziemlich weit zurück für jede ausreichend fortgeschrittene Anwendung, und ich denke nicht, dass 2.0 der richtige Ort ist, um eine solche zu erstellen eine bahnbrechende Veränderung.

@davidfowl

Ich verstehe das, aber ich kann nicht glauben, dass Sie den gesamten Stapelüberlauf nur in Rasiermesserseiten konvertieren werden. Wenn Sie MVC bereits heute verwenden, warum portieren Sie nicht einfach auf normale Ansichten und wenn mehr Abhängigkeiten online gehen, portieren Sie auf Razor Pages. Die Art und Weise, wie Razor Pages gestaltet sind, macht es trivial, von einer Controller-Aktion zu einer Razor Page zu wechseln.

Viele Bibliotheken usw., die von Apps gemeinsam genutzt werden, sind hier im Spiel. Stack Overflow besteht aus vielen Anwendungen (die Hauptwebsite ist fast ausschließlich eine einzige App, aber als Unternehmen: Wir haben viele verwandte, kommunizierende Dinge.

Stellen Sie einfach sicher, dass Sie diese Liste der Abhängigkeiten eskalieren, damit wir wissen, was wichtig ist.

Ja, das mache ich. Aber das wird nicht die letzte Abhängigkeit sein, nur der größte Blocker, da wir uns ohne sie nicht einmal bei einigen Apps anmelden können. Es ist ein First-Screen-Breaker. Ich werde diese Woche versuchen, die vollständige Portabilitätsanalyse für unsere Apps durchzuführen (nach einem Start heute Morgen), aber ich fürchte, es wird nur deprimierender. Es wäre hilfreich, wenn der Analysator sogar für aktuelle Werkzeuge aktualisiert würde, bevor solche Bewegungen überhaupt in Betracht gezogen würden.

Daten helfen, ich werde versuchen, mehr Daten von Ihnen zu bekommen - es sei denn, es besteht keine Chance, dass sich diese Entscheidung ändert. Wenn dies der Fall ist, teilen Sie uns dies bitte mit, damit ich nicht mehr Zeit dafür investiere.

Nur fürs Protokoll: OData ist eine weitere Bibliothek, die netcoreapp noch nicht unterstützt.

Eigentlich basiert es sogar noch auf System.Web (man muss es über OWIN-Middleware in ASP.NET Core verwenden) und sie haben Unterstützung versprochen (siehe https://github.com/OData/WebApi/issues/939).

Trotzdem erwähnenswert. Zumal es von Microsoft ist.

EDIT: @yaakov-h war 2 min schneller, also +1 für seine Erwähnung von OData

Ich bin immer noch hier, um aus ein paar Gründen zu antworten

• ich kümmre mich
• Schlaf ist für die Schwachen 😆
• Ich muss die FUD anrufen, weil jemand im Internet falsch liegt

@ Nick Craver

Viele Bibliotheken usw., die von Apps gemeinsam genutzt werden, sind hier im Spiel. Stack Overflow besteht aus vielen Anwendungen (die Hauptwebsite ist fast ausschließlich eine einzige App, aber als Unternehmen: Wir haben viele verwandte, kommunizierende Dinge.

Es bedeutet nur, dass Sie keine Razor-Seiten verwenden können, ASP.NET Core 2.0 hat viele kleine Dinge, aber es gibt keine großen Funktionen oder Korrekturen, die nicht auch auf 1.x zurückportiert werden. Die EOL-Sache ist sehr real, und ich persönlich glaube nicht, dass ASP.NET Core 2.0, das .NET Framework für ein weiteres Jahr unterstützt, helfen würde. Wir diskutieren hier wirklich über einen Richtungswechsel, entweder wir unterstützen .NET Framework für immer oder nicht, es gibt wirklich kein Dazwischen.

@dustinmoris ist nicht nur das. ist auch ein Erwartungsproblem. Ihr Anwendungsfall ist möglicherweise nicht derselbe wie bei allen anderen.

Ich entwickle aspnetcore 1.*-Apps und verwende den .NET-Desktop als Laufzeitumgebung (LOB für Unternehmen).

Und ich verstehe, was der Unterschied zwischen .net Core Runtime, Netstandard usw. ist (nur um sicherzugehen, dass dies kein Kommentar zu einem Missverständnis darüber ist)

Meine Migration war zuerst auf Aspnet Core (Ziel .net Desktop), weil der Flow/Vision/etc, konsolidieren und NACH dem Verschieben auf .net Core (falls möglich) das entscheidende Szenario bei der Aspnetcore-Wahl war.

Dieses Problem ist nur ein bisschen unerwartet, da aspnetcore 1. * immer als "auf beiden Frameworks ausgeführt" vermarktet wurde, ohne afaik Warnungen darüber, dass es als nächstes gelöscht wird (Version oder Jahr).
Ich hatte zumindest einen veralteten -> veralteten Zyklus erwartet oder nur nicht unterstützte Funktionen (das ist in Ordnung).

Das Gute an .net (und aspnet als Wahl für Webstack) ist, dass ich vorhandene Codebasis und Bibliotheken nutzen kann.
Einige sind intern, es lohnt sich nicht, diese zu migrieren, wenn das Ziel (.net core/netstandard) zu fließend ist.
Einige sind extern und schwer zu ändern, wenn diese in der netcoreapp2-Closure nicht funktionieren, kann ich diese nicht verwenden.

Außerdem war meine Idee zu netstandard2 zu konsolidieren, nicht zu netcoreapp2 .
Wie kann ich anfangen, die Migration von Libs auf netstandard2 einfach zu evaluieren, wenn es noch nicht da ist? Es ist schwierig, die Migration auf der Grundlage von Vorschaubits und -versprechen zu bewerten (und die letzten Jahre haben mein Vertrauen in die Stabilität von Versprechen verringert).

Ich verstehe, dass es ein anderes Szenario ist als vollständig auf der grünen Wiese, aber auch wenn ich auf der grünen Wiese einige Bibliotheken wiederverwenden möchte, weil ich mit dem vorhandenen System (Excel/PDF/etc) interagieren muss und nicht alles von Grund auf neu schreiben muss.
Oder fügen Sie Microservices als rpc hinzu, nur weil es der neueste Trend ist, weil es die Dinge komplizierter macht (das ist eine bewusste Entscheidung, die ich evaluieren und tun möchte, nicht gezwungen zu sein, vorhandene Bibliotheken zu umschließen). Ich muss Wert liefern (Aspnetcore-Entwicklungsfluss ist nett und produktiv), nicht nur die Architektur ändern.

In meiner persönlichen Bewertung des Ökosystems ist für meinen Anwendungsfall die Verfügbarkeit von .net Core und/oder netstandard lib atm zu gering (nicht jeder verwendet nur kostenlose nuget.org oss-Pakete). Wenn ich also hart auf einen neuen Stack migrieren muss, muss ich auch andere Stacks bewerten (Kosten/Nutzen/Zukunft/Vertrauen/usw.)

Ich schreibe nicht nur eine TODO-Web-App, ich verwende .NET, weil ich viele Jahre an Sachen fertig habe, damit ich eine Sache ändern kann (in diesem Fall Aspnetcore und den Rest für diese Iteration so lassen wie er ist).
Einfach alles zu ändern ist in meinem Szenario ein Rezept für eine Katastrophe, und wenn ich das tun muss, muss ich wirklich anfangen zu bewerten, ob es sinnvoller ist, auf einen anderen Stack (als Java/Knoten) zu migrieren, auf dem lib existiert.

Eine reibungslose Migration braucht Zeit, ich mag die Vision für den zukünftigen Aspnet-Kern. Aber wenn ich keinen klaren Weg habe (oder daran zweifle), ist es schwierig, intern zu verkaufen.

Lassen Sie den .net-Desktop jedoch hinter sich. Dies kann ein gutes Spiel für das Aspnet-Team sein, um schneller voranzukommen und mehr neue Benutzer auszuwählen (oder keine Strömungen an Node/Java zu verlieren).
Aber sicher wird das Leben für Entwickler auf langsamerem Ring schwieriger, und dies ist Aspnet Team Call (ihr Produkt).
Mein Feedback ist, das nicht zu tun und hart daran zu arbeiten, fw zu unterstützen, denn als Entwickler brauche ich Vertrauen und Stabilität, und die letzten Jahre waren im .net-Ökosystem etwas zu flüssig (nicht nur netcore/project.json, sondern davor auch, und Marketing/Evangelist hat nicht dazu beigetragen, das Vertrauen zu verringern)

@yaakov-h

Wenn Sie sich für eine Portierung auf ASP.NET Core (entweder 1.x oder 2.x) entscheiden, benötigen Sie einen anderen Prozess. ASP.NET Core wird nicht auf System.Web ausgeführt, sodass Sie keinen schrittweisen Port im selben Projekt durchführen können.

Ich hätte nichts dagegen, wenn die .NET Framework-Unterstützung eingestellt würde, sobald .NET Core auf oder nahe der Parität war, aber es ist immer noch ziemlich weit zurück für jede ausreichend fortgeschrittene Anwendung, und ich denke nicht, dass 2.0 der richtige Ort ist, um eine solche zu erstellen eine bahnbrechende Veränderung.

Es gibt keinen richtigen Zeitpunkt, um es fallen zu lassen. Es war nie dazu gedacht, die Parität mit .NET Framework zu erreichen, und es ist durchaus möglich, dass Sie Abhängigkeiten haben, die niemals portiert werden. Angesichts dessen wäre meine Frage, entwerfen Sie die Anwendung neu oder müssen Sie realistischerweise für immer auf .NET Framework bleiben?

@davidfowl , das hängt ganz von unseren Upstream-Abhängigkeiten ab. Zu diesem Zeitpunkt würden wir für immer auf .NET Framework bleiben.

Interessanterweise sind bei den meisten Drittanbietern bereits netstandard -Releases verfügbar. Es sind größtenteils die Microsoft-Abhängigkeiten, die uns auf .NET Framework halten, und einige davon scheinen halb aufgegeben zu sein (z. B. OData).

@NickCraver Ich möchte nicht herabsetzen oder beleidigend sein. Ich weiß zu schätzen, dass dies eine späte Änderung ist, und das ist frustrierend für jeden Teil der Community, der davon betroffen ist, und wenn ich davon betroffen wäre, würde ich wahrscheinlich auch Aufhebens machen. Ich bin es nicht (wo ich arbeite, arbeiten wir immer noch mit ASP.NET WebAPI 5.2.3), daher ist meine Einschätzung der Situation weniger emotional.

Betrachten Sie es so: Wenn Sie heute ganz von vorn anfangen würden, den nächsten Stack Exchange (was auch immer das sein mag) zu erstellen, würden nicht die Dinge in netcoreapp20 , die das ASP.NET Core-Team verwenden möchte ( wie UTF8Strings und Pipelines und niedrige Allokation, asynchrone, _schnelle_ Primitive (ich vermute da ein bisschen)) machen es für Sie attraktiver als volles .NET? Wäre .NET Core 2.0 im Allgemeinen nicht sinnvoller als das vollständige .NET 4.7.1? Wenn Sie zwischen Web-Stacks, die sich schnell weiterentwickeln und an Veränderungen anpassen können, und Web-Stacks wählen müssten, die unwiderruflich an eine sich langsam entwickelnde zugrunde liegende Technologie mit fast zwei Jahrzehnten an Legacy-Code gebunden sind, um deren Unterstützung Sie sich Sorgen machen müssen, was würden Sie wählen?

@ZigMeowNyan

Ich mache mir mehr Sorgen über diesen Schritt, der das mögliche Ausscheiden von .NET Standard signalisiert, als über den Rest. .NET Standard schien zunächst etwas zu sein, das die verschiedenen Implementierungen näher und näher an die Feature-Parität bringen würde, während es den Verbrauchern ermöglichte, auf die sich entwickelnde, wachsende Plattform zu migrieren. Jetzt klingt es wie nichts weiter als ein Meilenstein der .NET Core-Features. Sie können (oder wollen) keine ausführbaren Dateien auf .NET Standard ausrichten – nur Bibliotheken. Und es hört sich so an, als würde .NET Standard deutlich weniger Planung erfordern und stattdessen einfach mit dem abgesegnet werden, was in ASP.NET verwendet wurde, weil es für eine Änderung bereits zu spät ist. Es wird schließlich bereits in Produktion sein.

Das sind eigentlich wirklich gute Punkte und eine Überlegung wert. Sie müssen verstehen, dass es nichts damit zu tun hat, dass .NET Standard an den Rand gedrängt wird, es ist nur Physik. Wenn sich jede .NET-Plattform in ihrem eigenen Tempo bewegt, bedeutet die Verwendung des neuesten .NET-Standards, dass die langsameren Frameworks seltener Probleme bekommen. Das sollte jeder verinnerlichen. Das macht es nicht weniger nützlich, es liegt einfach in der Natur des Tieres. Die einzige Möglichkeit, diese Last zu beseitigen, besteht darin, eine einzige Implementierung und einen einzigen Auslieferungsplan zu haben, was die Orte, an denen .NET ausgeführt werden kann, stark einschränkt.

Andere Entwickler müssen den Code mit Compiler-Direktiven bestreuen, den Code in plattformspezifische Bibliotheken aufteilen und mit mehreren Zielen kompilieren. Der unhöfliche Teil von mir möchte, dass das ASP.NET Core-Team das dogfoodt, damit Sie an besserer Laufzeit- und Toolunterstützung für Multi-Targeting- und Multi-Plattform-Szenarien interessiert sind. Und wenn Ihr Team es möchte, bekommen wir es vielleicht. Der praktische Teil von mir sagt, dass Sie mindestens regelmäßige Versionen von ASP.NET Core haben sollten, die auf .NET Standard abzielen. Sie müssen sowieso tatsächliche stabile Releases erstellen. Niemand wird einfach den Master-Branch aus Git kompilieren und in der Produktion bereitstellen. Warum nicht kleinere Iterationen des .NET-Standards erstellen und sie mit einer getaggten ASP.NET-Version abgleichen?

Wir machen dasselbe, denken Sie daran, wir zielen immer noch auf Netstandard für eine Reihe unserer Bibliotheken ab, und diese enthalten ifdefs. Andere hingegen zielen auf netstandard ab, um uns für die Nutzung neuer APIs im 2.x-Zeitrahmen vorzubereiten.

Kurz gesagt, ich unterstütze, was Sie tun und die Ziele dahinter. Und ich weiß, es ist hart, wenn wir hier weiterkommen und uns über Entscheidungen beschweren, die Sie aus einem sehr guten Grund getroffen haben. Aber viele Leute werden nicht auf den Pionierzug aufspringen, weil sie es nicht können, und andere nicht, weil sie nicht wissen, wohin er führt.

Ehrliche Frage (das frage ich, nicht Microsoft): Bevorzugen Sie Kompatibilität gegenüber neuen Funktionen? Wenn ja, warum sollten Sie sich für ASP.NET Core entscheiden?

Nur noch ein kurzer Gedanke: Für jeden Thread wie diesen gibt es einen gleichwertigen, aber entgegengesetzten Thread, bei dem eine andere – aber genauso große – Gruppe von Leuten genauso verärgert war, weil ein Zugeständnis an die Unterstützung des „alten“ .NET gemacht wurde.

Interessanterweise haben die meisten Drittanbieter bereits Netstandard-Versionen verfügbar. Es sind größtenteils die Microsoft-Abhängigkeiten, die uns auf .NET Framework halten, und einige davon scheinen halb aufgegeben zu sein (z. B. OData).

😞

@markrendle

• Viele der Beschwerden, die ich in diesem Thread sehe, sind Variationen von „Ich kann X in .NET Core 2.0 nicht ausführen“, wenn der Autor eigentlich meint: „Ich muss die Art und Weise ändern, wie ich X in .NET Core 2.0 mache.“ . Ja, du musst dich ändern. Nein, das ist nichts Schlimmes. Wenn Sie eine kleine diskrete Funktionalität in Ihrer ASP.NET MVC-Anwendung haben, die etwas mit PDFs oder DOCX-Dateien macht, und Sie wirklich keinen besseren Weg finden können, was auch immer das ist (haben Sie es versucht?), dann brechen Sie das Funktionalität in einen Microservice aus, der auf vollständigem .NET auf Windows Server ausgeführt wird, und rufen Sie ihn als HTTP-API von Ihrer .NET Core-Anwendung auf. Das Zerlegen von Anwendungen und das Verschieben bestimmter Funktionen in kleine, eigenständige Dienste ist nicht einmal eine Problemumgehung, sondern eine allgemeine Best Practice.
NB Soweit ich das beurteilen kann, unterstützen die OpenXML-Pakete jetzt den .NET-Standard, sodass das Arbeiten mit Word/Excel/was auch immer nicht unmöglich sein sollte.<<

Wie andere bereits gesagt haben, ist es kein guter Plan, die Architektur unseres schönen Designs zu ändern. In unserem Fall teilen wir Code zwischen unserem WPF-Anwendungstest und dem Server. Je mehr Unterschiede wir zwischen diesen schaffen, desto komplizierter ist es, sie aufrechtzuerhalten.

Ich kann Ihnen versichern, dass ich viel Zeit damit verbracht habe, die besten Tools zu untersuchen, die wir für die PDF- und DocX-Generierung verwenden können, und es ist bei weitem nicht so einfach wie mit Open XML. Wir verwenden eine Bibliothek eines Drittanbieters, weil es Zehntausende von Codezeilen gibt, die sie entwickelt haben, und wir sie nicht entwickeln/warten/testen müssen. Das ist der springende Punkt.

Die .net-Versionierung ist sehr kompliziert geworden. Mir ist nicht klar, ob ASP.net irgendwann in der Zukunft auf dem vollständigen .net-Framework verwendet werden kann? Da ich Code zwischen dem Server und meinen Desktopanwendungen freigeben muss, bedeutet das, dass ich nie die neueste Version von ASP.Net haben kann? Kurzfristig ist dies kein Problem, aber langfristig mit Sicherheitsverbesserungen usw. möchte ich nicht zu weit von der neuesten Version entfernt sein. Ich bin mir sicher, dass es viele andere in meinem Boot gibt, bei denen Sie eine Form der Kompatibilität mit dem vollständigen Framework benötigen.

Um zu verdeutlichen, was ich tue, habe ich drei meiner eigenen Bibliotheken, die von verschiedenen WPF-Apps und meinem Server gemeinsam genutzt werden. Ich hätte zu diesem Zeitpunkt absolut keine Ahnung, welche APIs ich verwende und ob sie im.net-Kern verfügbar sind oder nicht. Und dann verwende ich in diesen Bibliotheken vollständige Desktop-Versionen der WPF-Tools von Telerik und SyncFusion zum Generieren von docx und pdf. Einige oder alle Funktionen, die diese Tools verwenden, sind möglicherweise in .net Core verfügbar oder nicht. Der Versuch, Anwendungen auf der Grundlage von may or may not zu entwickeln, ist äußerst schwierig. Microsoft hat ein brillantes Basis-Framework in .net, und obwohl ich die Argumentation hinter .net Core verstehe. Microsoft scheint die Bedeutung der Abwärtskompatibilität vergessen zu haben.

Stefan

@markrendle

Oh, Entschuldigung, ich wusste nicht, dass Ihre Stichprobengröße so groß ist. 257 Kommentare mit einer starken Tendenz zu Leuten, die die Entscheidung nicht mögen? Dagegen lässt sich schwer argumentieren. HAFTUNGSAUSSCHLUSS: Ich bin kein Experte für Big Data.

Keine Ahnung, was ich dir angetan habe, aber es gibt keinen Grund, so zu schnüffeln oder so leise zu jammern. Sie wissen genau, dass dieser Thread nur ein Beispiel ist.

@stefanson

Die .net-Versionierung ist sehr kompliziert geworden

Ich denke, das ist eines der wenigen Dinge, auf die wir uns alle einigen können.

Wir suchen nach einer Portierung auf .Net Core x.
Unsere größten Probleme sind:
NewRelic (kein .Net Core-Plan, also müssen wir eine Alternative finden)
NH (wobei EF Core nicht über die Funktionen verfügt).
ServiceBase (klingt, als würde es im Sommer zu .Net Core 2 kommen)

Es klingt sicherlich so, als müssten wir in der Zwischenzeit auf Core 1.0 abzielen und auf NH-, EF-Upgrades warten oder kreativ werden.

Es bedeutet nur, dass Sie keine Razor-Seiten verwenden können, ASP.NET Core 2.0 hat viele kleine Dinge, aber es gibt keine großen Funktionen oder Korrekturen, die nicht auch auf 1.x zurückportiert werden. Die EOL-Sache ist sehr real, und ich persönlich glaube nicht, dass ASP.NET Core 2.0, das .NET Framework für ein weiteres Jahr unterstützt, helfen würde. Wir diskutieren hier wirklich über einen Richtungswechsel, entweder wir unterstützen .NET Framework für immer oder nicht, es gibt wirklich kein Dazwischen.

Es ist etwas größer als Razor-Seiten, das heißt, es gibt keinen Grund, sich zu bewegen . Es gibt einfach kein (aktuelles) Szenario, in dem beides existiert:

1. Wir werden die ganze Zeit unterstützt
2. Auf der anderen Seite gibt es ein echtes Upgrade

Tatsache ist, dass ASP.NET Core ohne das Ökosystem nicht wirklich nützlich ist. Einen Controller zu haben, der Text wiedergibt, ist großartig, aber für so viele Szenarien nicht nützlich. Wir brauchen die APIs. Wir brauchen die Bibliotheken. Wir brauchen das Ökosystem, deshalb haben wir uns in erster Linie für .NET entschieden .

Diese Änderung geht von einem Framework, das unsere heutigen Anwendungsfälle vollständig unterstützt, zu einem Framework über, das eindeutig noch nicht bereit ist. Es ist noch lange nicht fertig. Und eine Vorschau, um zu testen, ob es fertig ist, ist nicht einmal allgemein verfügbar. Eine Migration, um die Versprechungen dessen, was fertig sein wird, herauszufinden, ist nicht verfügbar. Wir setzen auf eine ganze Reihe von Versprechungen und viele werden verbrannt. Das ist die denkbar schlechteste Art, diese Dinge zu vermarkten: zu viel versprechen und zu viel liefern (das Gesamterlebnis).

Ich finde ASP.NET Core großartig. Ihr macht tolle Sachen. Ich hatte das Glück, bei einigen davon helfen zu können. Aber dieser Schalter zu diesem Zeitpunkt ist schlecht. Wenn all die Dinge, von denen wir glauben, dass sie portiert werden, tatsächlich in den 2.x-Zeitrahmen portiert werden, dann großartig. Nehmen Sie dann die Änderung in 3.x vor. Es ist schlecht, zu portieren, bevor eine Alternative fertig ist, und eine Frist festzulegen, wann die EOL-Lebenslinie beendet werden soll. Leuten zu sagen, sie sollten auf eine Wartungsversion -> EOL-Version portieren, ist schlecht.

Bitte nehmen Sie diese Änderung jetzt nicht vor. .NET ist besser als das. Zeigen Sie, dass Sie sich genauso um Ihre Benutzer kümmern, wie sich alle hier um Sie kümmern. Wir wären nicht hier, wenn wir nicht helfen wollten.

@FransBouma Sie (sollten) genau wissen, dass Microsoft über riesige Datenbanken mit Telemetrie, Feedback und anderen Daten darüber verfügt, was die Leute mit ihrer Technologie tun, die ein viel klareres Bild vermitteln als jede Anzahl von GitHub-Issues-Threads, und ich glaube nicht, dass meine Darauf hinzuweisen, war noch bissiger als

Oh, ich weiß nicht, nachdem ich die Beiträge in diesem Thread gelesen habe?

Die .net-Versionierung ist sehr kompliziert geworden. Mir ist nicht klar, ob ASP.net irgendwann in der Zukunft auf dem vollständigen .net-Framework verwendet werden kann? Da ich Code zwischen dem Server und meinen Desktopanwendungen freigeben muss, bedeutet das, dass ich nie die neueste Version von ASP.Net haben kann? Kurzfristig ist dies kein Problem, aber langfristig mit Sicherheitsverbesserungen usw. möchte ich nicht zu weit von der neuesten Version entfernt sein. Ich bin mir sicher, dass es viele andere in meinem Boot gibt, bei denen Sie eine Form der Kompatibilität mit dem vollständigen Framework benötigen.

Die Code-Sharing-Story über verschiedene .NET-Laufzeiten hinweg ist .NET Standard. Ihre Bibliotheken sollten versuchen, dies auf Code abzuzielen, der von .NET Core und .NET Framework gemeinsam genutzt wird.

Microsoft scheint die Bedeutung der Abwärtskompatibilität vergessen zu haben.

Das Problem ist, dass ASP.NET Core nie abwärtskompatibel sein sollte ... Deshalb gab es einen so großen Paradigmenwechsel von ASP.NET 4.x. Scheint so, als ob die Abwärtskompatibilität das wichtigste Bit für Sie wäre, ASP.NET 4.x auf .NET Framework zu verwenden. Das wird auf absehbare Zeit unterstützt und wird mit Sicherheitspatches versehen, solange Windows am Leben ist.

Auch wenn es nicht sein sollte , war 1.0 sehr abwärtskompatibel! Es unterstützte das gesamte riesige Erbe des Ökosystems, und wir schätzten es. Es schien damals, als müsste niemand seinen Kuchen verschenken oder auf den Verzehr verzichten.

@ Nick Craver

Es ist etwas größer als Razor-Seiten, das heißt, es gibt keinen Grund, sich zu bewegen. Es gibt einfach kein (aktuelles) Szenario, in dem beides existiert:

Können Sie das näher erläutern?

Tatsache ist, dass ASP.NET Core ohne das Ökosystem nicht wirklich nützlich ist. Einen Controller zu haben, der Text wiedergibt, ist großartig, aber für so viele Szenarien nicht nützlich.

Das geht auch ganz schnell 😉

Ich finde ASP.NET Core großartig. Ihr macht tolle Sachen. Ich hatte das Glück, bei einigen davon helfen zu können. Aber dieser Schalter zu diesem Zeitpunkt ist schlecht. Wenn all die Dinge, von denen wir glauben, dass sie portiert werden, tatsächlich in den 2.x-Zeitrahmen portiert werden, dann großartig. Nehmen Sie dann die Änderung in 3.x vor. Es ist schlecht, zu portieren, bevor eine Alternative fertig ist, und eine Frist festzulegen, wann die EOL-Lebenslinie beendet werden soll. Leuten zu sagen, sie sollten auf eine Wartungsversion -> EOL-Version portieren, ist schlecht.

Ich verstehe nicht, warum 2.x (Support) und 3.x (Drop) besser sind als 1.x (Support) und 2.x (Drop). Kannst du mir das bitte erklären? Wie macht das einen Unterschied?

Einige //BUILD 2017-Sitzungsempfehlungen für diejenigen, die sich Sorgen um die langfristige Unterstützung von ASP.NET-Varianten machen:

• T6009 ASP.NET Web Forms-Updates
  
  
  
  • dh sie entwickeln immer noch vollständige .NET-Webplattformen
  
  
• T6072 Unterstützung für ASP.NET Core: Was ist ein LTS?
  
  
  
  • Was ich vermute, wird gerade hektisch aktualisiert :grimacing:
  
  

@davidfowl :

Wie macht das einen Unterschied?

Weil Sie versprochen haben, dass einige der wichtigsten fehlenden APIs nach 2.0 ausgeliefert werden?

@yaakov-h

Weil Sie versprochen haben, dass einige der wichtigsten fehlenden APIs nach 2.0 ausgeliefert werden?

Sagen Sie mir, welche in ASP.NET Core?

@davidfowl System.DirectoryServices, System.Drawing wurden oben erwähnt.

Ehrliche Frage (das frage ich, nicht Microsoft): Bevorzugen Sie Stabilität und Kompatibilität gegenüber neuen Funktionen? Wenn ja, warum sollten Sie sich für ASP.NET Core entscheiden?

Ich denke, das ist eine sehr gute Frage. Wenn das vollständige .NET-Framework einem alles bietet, was man heute braucht, warum sollte man dann so scharf auf eine Migration zu einem komplett anderen Stack sein? Wenn .NET Core und ASP.NET Core anders benannt worden wären, ohne .NET im Namen, dann würden meiner Meinung nach viel weniger Leute über Migrationsprobleme streiten. Niemand beschwert sich darüber, dass er nicht auf einen schnelleren Go- oder Node.js-Webstack migrieren kann.

@davidfowl Abwärtskompatibilität mit ASP.NET MVC 5.x ist eine Sache, Abwärtskompatibilität mit .net Framework ist eine andere Sache. Das Löschen des .net-Frameworks ist eine große Sache ...

Ich verstehe nicht, warum 2.x (Support) und 3.x (Drop) besser sind als 1.x (Support) und 2.x (Drop).

Weil 2.x sehr bald kommt, wie wir verstehen.

@davidfowl System.DirectoryServices, System.Drawing wurden oben erwähnt.

Diese haben nichts mit ASP.NET Core 1.x oder 2.x zu tun und werden auf beiden ausgeführt, wenn sie online gehen.

Wie ich schon sagte, ich bin nur hier, um die FUD anzurufen, und das gehört dazu. Dieser Thread ist so groß geworden, dass niemand die Fakten in einigen der Antworten erkennen kann.

@FransBouma Sie (sollten) genau wissen, dass Microsoft über riesige Datenbanken mit Telemetrie, Feedback und anderen Daten darüber verfügt, was die Leute mit ihrer Technologie tun, die ein viel klareres Bild vermitteln als jede Anzahl von GitHub-Issues-Threads, und ich glaube nicht, dass meine Darauf hinzuweisen, war noch bissiger als

@markrendle Telemetrie ist keine Zauberei. Sie können nicht messen, warum Leute/Entwickler nicht wechseln oder warum sie auf einen anderen Stack umgestiegen sind, oder die Wichtigkeit ihres Projekts und wie sehr sie den Stack mögen (und anderen helfen, mit Beratung oder Oss) oder was sie tun.

Dieser Thread ist genau das, ein Feedback.

Ich verstehe nicht, warum 2.x (Support) und 3.x (Drop) besser sind als 1.x (Support) und 2.x (Drop). Kannst du mir das bitte erklären? Wie macht das einen Unterschied?

@davidfowl Zeit.
Zeit, sich ein wenig zu beruhigen. Zeit, Dinge zu bewerten. Zeit, eine Sache nach der anderen zu ändern. Zeit, netstandard2 -Pakete mit einem RTM-Ding zu verwenden. Zeit, unsere Bibliotheken auf netstandard2 (einfacher) statt auf netstandard1 (schwieriger) zu verschieben. Zeit, eine Sache nach der anderen zu ändern, für mich meistens.
Sie tun Aspnet, aber mein Produkt ist nicht nur Aspnet, es ist eine Kombination aus vielen Bibliotheken und Kompromissen und dem Ökosystem.

Weil 2.x sehr bald kommt, wie wir verstehen.

Was hat das damit zu tun? Was wäre, wenn 2.0 Ende des Jahres oder im Januar kommen würde? Würde es einen Unterschied machen? Was in 2.0 macht 1.x unwürdig?

@yaakov-h Sie wurden hier erwähnt, wo @shanselman sagte (Hervorhebung von mir)

AD – Insgesamt ist dies eine Lücke, wenn Sie LDAP direkt aufrufen möchten. Sie können sich sicherlich JETZT gegen Windows Auth authentifizieren. Wir planen, um den Sommer herum speziell den DirectoryServices-Namespace für Core 2.0 zu haben
Zeichnen – Das ist absolut eine Lücke. Wir planen, dies für Core 2.0 im Sommerzeitrahmen zu haben. Bis dahin existieren diese Netzstandard-Optionen auch ImageSharp, ImageResizer, Mono-Optionen usw

@davidfowl es geht nicht um die Version, sondern um das Datum und die Reife des .net-Kerns und seines Ökosystems.

@hikalkan

Es tut mir leid, ich verstehe das aus einem sehr hohen POV, aber nicht aus einem technischen. Vielleicht ist das keine technische Diskussion?

@Enricosada

Zeit, sich ein wenig zu beruhigen. Zeit, Dinge zu bewerten. Zeit, eine Sache nach der anderen zu ändern. Zeit, netstandard2-Pakete mit einem RTM-Ding zu verwenden. Zeit, unsere Bibliotheken auf netstandard2 (einfacher) statt auf netstandard1 (schwieriger) zu verschieben. Zeit, eine Sache nach der anderen zu ändern, für mich meistens.
Sie tun Aspnet, aber mein Produkt ist nicht nur Aspnet, es ist eine Kombination aus vielen Bibliotheken und Kompromissen und dem Ökosystem.

Warum unterscheidet sich das speziell von ASP.NET Core 2.0? Sie profitieren von diesem Vorteil der Plattform, unabhängig davon, was ASP.NET Core auswählt.

@markrendle besorge mir jemand einen Kalender, weil die Jahreszeiten ein ganzes Quartal umfassen (könnten 3 Monate von etwas anderem im selben Quartal entfernt sein) und für uns Menschen auf der Südhalbkugel besonders verwirrend sind.

@enricosada Sie können eine Menge nützlicher Informationen aus Telemetrie und anderen Datenquellen (Webanalysen, Suchdaten, direktes Kundenfeedback) erhalten. Weit mehr, als Sie von wütenden Mobs auf GitHub bekommen können (so berechtigt der Ärger jedes Einzelnen auch sein mag).

@yaakov-h Nun, die derzeit projizierte RTM für .NET Core 2.0 (und damit ASP.NET Core 2.0) ist das Kalenderquartal Q3, also Juli/August/September), und der Sommer auf der Nordhalbkugel ist hauptsächlich Juli/August/September , also ist es im Grunde dasselbe.

Sie können eine Menge nützlicher Informationen aus Telemetrie und anderen Datenquellen (Webanalysen, Suchdaten, direktes Kundenfeedback) erhalten.

Ich frage mich jedoch, wie zuverlässig diese Telemetrie – zumindest der automatisierte Teil – für Unternehmensbereitstellungen ist. (Denn von dort scheint der Großteil der Gegenreaktion zu kommen.)

Ich verstehe nicht, warum 2.x (Support) und 3.x (Drop) besser sind als 1.x (Support) und 2.x (Drop). Kannst du mir das bitte erklären? Wie macht das einen Unterschied?

@davidfowlZeit . Und eine ordentliche Ansage. Wenn die Botschaft klarer wäre, wären die Leute nicht so überrascht.

@davidfowlZeit . Und eine ordentliche Ansage. Wenn die Botschaft klarer wäre, wären die Leute nicht so überrascht.

Ich verstehe, aber ich glaube nicht, dass es einen Unterschied in Ihrer Fähigkeit machen würde, wirklich etwas zu portieren. Dieselbe EOL-Richtlinie existiert noch.

Ok, nachdem es mir schwer gefallen ist, dieses Problem zu verstehen, wollte ich einige Erkenntnisse für diejenigen bringen, die wie ich kämpfen und auch einige Fragen haben.

Wenn Sie also richtig verstanden haben, wird netstandard schließlich net framework ersetzen.

Nehmen wir also an, Netcore existiert nicht und Aspnet Core basiert auf Netstandard. Das bedeutet, dass Funktionen langsamer bereitgestellt werden.

Beispiel:
2017 asp.net will Feature A.
2018 netstandard implementiert Feature A. wir bekommen Feature A auf ns.

Was das Team sagt, ist, Netcore zu haben, das nicht auf Netstandard basiert, also:
2017 asp.net will Feature A
Das Aspnet-Team von 2017 implementiert Feature A. Asp.Net Core erhält Feature A auf Netcore.
2018 netstandard implementiert Feature A. wir bekommen Feature A auf ns.

Diese Entscheidung bringt also tatsächlich mehr "Flexibilität und Geschwindigkeit" in die Gleichung. Schnellere Veröffentlichung für diejenigen, die sie verwenden können, Feedback usw. Ich denke, es ist eine großartige Ergänzung zum langsamen Peace-of-Net-Framework. Das Feature wird wirklich ausgereift sein, wenn es NS erreicht.

Wenn Netcore auf Basis von Netstandard 2 zu haben bedeutet, dass Funktionen 1 Jahr (oder einen beliebigen Zeitrahmen) später veröffentlicht werden, werden die Leute immer noch argumentieren, dass sie dies wollen? Dies ist das Szenario, das wir von NET Framework gewohnt sind.

Dies ist ein Paradies für das Aspnet-Team, da es in der Lage ist, Sachen zu versenden, ohne von jemand anderem abhängig zu sein, und es sind auch großartige Neuigkeiten für Kunden, die diese Sachen schnell bekommen können. Wenn Sie mit den schnellen Sachen nicht weiterkommen, ist das Festhalten an der vorherigen Version ein vernünftiger Kompromiss (und eine Motivation für Sie/Abhängigkeiten, ein Upgrade durchzuführen).

Bibliotheksautoren sollten immer noch darauf abzielen, auf netstandard abzuzielen, und wenn Sie können, dann machen Sie sich überhaupt keine Sorgen.
Wenn Sie etwas brauchen, das nicht auf Netstandard ist (vielleicht Razor Pages (?)), dann müssen Sie auf Netcore abzielen, in Szenario 1 existieren Razor Pages möglicherweise nicht einmal. Ich verstehe nicht, wie das schlecht sein kann, ich würde sagen, es ist fair.

Die Frage ist also, welche Abhängigkeit Sie derzeit haben, die Sie davon abhält, NET Framework auf Net Core umzustellen?
Ich bin vielleicht der einzige hier, aber ich hätte nie erwartet, dass Aspnet Core für immer auf NET Framework funktioniert, es war mir klar, dass dies ein "Übergangsschritt" war. Meine gesamte Entwicklung, die derzeit NET Framework benötigt, ist splited . (und nein, das sind keine Microservices, es ist viel einfacher als das).

2.x-Unterstützung und 3.x-Drop unterscheiden sich nicht von 1.x-Unterstützung und 2.x-Drop. Ich werde hier raten und sagen, dass die Leute das Szenario nicht klar verstehen, also hoffe ich, dass dies zumindest einige klarstellt.

@NickCraver Sie sagten, Sie möchten, dass Microsoft diese Entscheidung rückgängig macht. Was wäre Ihr Vorschlag, keinen isolierten Netcore und langsamere Feature-Releases zu haben? (ehrliche Frage)

@davidfowl Ich denke, es gibt möglicherweise ein subtiles verstecktes Problem mit dem aktuellen Vorschlag, das Entwickler beunruhigt.
Wenn Sie Feature A für asp.net (mit Netcore) haben, können Sie vermarkten und versenden (und ein Kontrollkästchen für Management/PM aktivieren) und "faul" sein, um es auf Netstandard zu implementieren. Wenn ich mich nicht irre, ist dies das, was "Wetten" ist. auf unsicher wird hier verwiesen.
In meinem vorherigen Beispiel implementiert netstandard Feature A also möglicherweise 2019 oder 2020 oder nie anstelle von 2018. <-- das sieht nach einem möglichen Problem aus (?) habe ich recht? Kann sich Microsoft hier zu etwas verpflichten?

Obwohl wir uns alle darüber unterscheiden können, ob uns die Ankündigung gefällt, danke @davidfowl @DamianEdwards und @shanselman dafür, dass sie sich die Zeit für die Diskussion genommen haben. Es ist ein weiterer Beweis für gesteigertes Engagement und Offenheit.

Ich bin mir sicher, dass einige über das Timing usw. streiten werden, aber es ist ein Fortschritt.

Beispiel:
2017 asp.net will Feature A.
2018 netstandard implementiert Feature A. wir bekommen Feature A auf ns.

Was das Team sagt, ist, Netcore zu haben, das nicht auf Netstandard basiert, also:
2017 asp.net will Feature A
Das Aspnet-Team von 2017 implementiert Feature A. Asp.Net Core erhält Feature A auf Netcore.
2018 netstandard implementiert Feature A. wir bekommen Feature A auf ns.

Was sie hätten tun sollen, ist:
2017 Aspnet Team Builds Feature benötigt in lib X, das netstandard2.0 unterstützt. Auf diese Weise funktioniert aspnet auf allem, auf dem .netstandard ausgeführt wird, und Benutzer können es dann auf .net full ausführen, da lib X auch auf .NET full verwendbar ist (es ist nur eine Nuget-Installation entfernt).

Stattdessen tun sie dies nicht, sie zwingen lib X, nur .NET Core zu sein (ansonsten, warum dieser Thread/diese Entscheidung überhaupt). Wenn lib X so fortschrittlich ist, dass es CoreCLR-Funktionen benötigt, muss sich Microsoft fragen, warum diese erweiterten Funktionen nicht auf die vollständige .NET-CLR portiert werden.

Alles in allem fühlt es sich nach Politik an, wo MS einen schnelllebigen .NET-Core/Aspnet-Core benötigt, um Azure-Kunden einen Stack bereitzustellen, der in Azure-Containern verwendet werden kann, damit er mit JVM/NodeJS-basierten Containern auf AWS oder Google Cloud konkurriert. Aus ihrer Geschäftsperspektive kann ich das sogar verstehen. Aber es zeigt, dass MS bezüglich .NET full keine Priorität hat, um schneller voranzukommen, da es nicht genügend Ressourcen auf .NET full setzt, um mit .NET Core Schritt zu halten. Sehen Sie sich die Menge an APIs an, die in den letzten zwei Jahren vollständig zu .NET hinzugefügt wurden. Sagt Ihnen das, dass ein großes Team daran arbeitet?

Nein.

Microsoft verkauft ein großes Datenbanksystem, SQL Server Enterprise. Es kommt mit ausgefallenen Verschlüsselungsfunktionen. Wird auf .NET Core nicht unterstützt. Viel Spaß beim Verkauf von .NET Core 2.0 an Unternehmen, die potenzielle Kunden dieses teuren Datenbanksystems sind.

Vielleicht möchten Sie sich „schnell“ bewegen, aber wenn Sie das Ziel, auf das Sie sich bewegen, nicht vollständig verstehen, hilft es, sich ein oder zwei Minuten Zeit zu nehmen, um dies zuerst zu entscheiden.

Je mehr ich darüber nachdenke, desto mehr denke ich, dass das Problem, das die meisten Leute haben, darin besteht, dass sie das Gefühl haben, dass wir die Schnur zwischen .net und asp.net durchtrennen.
Derzeit haben wir asp.net, asp.net core (.net) und asp.net core (core). So konnte man wählen, ob man auf keinen, wenig oder vollen Kern gehen wollte.

Da die Versionierung schlecht kommuniziert wird, haben die Leute das Gefühl, dass nur der letzte Teil innovativ ist und weitergeht, während asp.net und asp.net core (.net) feststecken.
Da wir keine Möglichkeit haben zu validieren, ob eine Bibliothek in netstandard2.0 funktioniert, ohne es zu versuchen, wird es sehr riskant, mit vollem Kern in ein neues Projekt zu gehen. Sie landen also entweder bei asp.net (alt) oder asp.net core (ebenfalls alt).
Und da beide alt sind, ist es sinnvoll, einfach system.web und das alte asp.net zu verwenden. Da sie das wissen und asp.net Core sowieso EOL ist, warum sich die Mühe machen.

Am Ende haben wir also nur den Kern der mutigen Wahl, und der Rest geht mit dem alten, aber stabilen system.web. Und wir werden für immer in einem noch zerbrocheneren Ökosystem stecken bleiben.

PS: Ich formuliere das wie mit dem aktuellen Gefühl. Dieser asp.net-Kern 1.x ist "alt und veraltet" im Vergleich zu 2.x. Nicht, dass es eine Tatsache wäre, aber so denken die Leute.

@davidfowl

Wenn sich jede .NET-Plattform in ihrem eigenen Tempo bewegt, bedeutet die Verwendung des neuesten .NET-Standards, dass die langsameren Frameworks seltener Probleme bekommen.

Das passiert bereits, und wir sind damit einverstanden. Das Versionsdokument wird üblicherweise mit _vNext_ gefüllt. Und das ist in Ordnung. Anstatt zu warten, bis alle Plattformen gleich sind, bevor ich den Standard erhöhe, würde ich lieber sehen, wie der Standard ein paar Versionen im Voraus definiert wird, und beobachten, wie die Plattformen aufholen. Die Leute können sogar bei der Definition und Implementierung mithelfen. Und wenn ASP.NET Core den Standard für seine Releases anvisiert, wäre das Paket in dem Moment verfügbar, in dem eine Plattform und Architektur diesen neuen Standard implementiert. Neue Standardversionen könnten durch VS-Updates oder -Pakete eingeführt werden.

Die Art und Weise, wie es präsentiert wird, obwohl .NET Standard nicht so klingt, als wäre es eine von der Community geplante Anstrengung. Es ist eher eine Momentaufnahme der implementierten Verträge, die die Überprüfung bestanden haben. Und wenn große Projekte nicht darauf abzielen, wird es nicht annähernd so viel Planung für seine Veröffentlichungen geben.

Wir machen dasselbe

Oh gut. Geteiltes Elend ist bestes Elend. Csproj- und sln-Dateien mit dem Plattform-/Konfigurations-Zeug sind übrigens wirklich ärgerlich, weil die Build-Kombinationen nicht immer deklariert werden - sie werden abgeleitet. VS könnte also denken, dass ich mehr Build-Kombinationen habe, als tatsächlich vorhanden sind, weil es davon ausgeht, dass jede mögliche Kombination wichtig ist. Und ich muss zusätzliche Abschnitte in der Datei haben, die nicht benötigt würden, wenn ich nur die Plattform/Konfigurationskombinationen deklarieren könnte. Beispielsweise können Sie Funktionen wie Substring in den csproj PropertyGroup -Elementen verwenden, um benutzerdefinierte Eigenschaften zu vereinfachen, aber diese Bedingungen werden zum Bestimmen von Build-Konfigurationen verwendet, sodass Sie dort die vollständigen Zeichenfolgenwerte haben müssen. Diese Art von Sachen sollte nicht so viel Aufwand sein, wie es ist.

Ehrliche Frage (das frage ich, nicht Microsoft): Bevorzugen Sie Kompatibilität gegenüber neuen Funktionen? Wenn ja, warum sollten Sie sich für ASP.NET Core entscheiden?

Persönlich nein. Solange es eine Möglichkeit gibt, das zu tun, was ich tun muss, macht es mir nichts aus, den Code neu zu schreiben, solange es kein großes Unterfangen mit wenig Nutzen oder ein PITA zum Testen ist. Also würde ich das auswählen, was die meiste Dynamik und das größte Potenzial hat. Aber ich muss mit Projekten über mehrere Technologien hinweg arbeiten – Win32, COM, CORBA, ADO.NET, mehrere Reporting-Engines, verschiedene Web-APIs, eingebettete Browser wie CEF/Firefox/IE (natürlich ohne Edge, da es nicht unterstützt wird) und Mehrere herstellerspezifische Dinge, die ich vermeiden werde, zu beschämen. Ich implementiere, was ich kann, als Plugin, aber ich bin größtenteils mit dem kleinsten gemeinsamen Nenner der ausführbaren Hostdatei verheiratet. Der Umgang mit so vielen Technologien ist nervig, aber sie sind statisch. So ist eine Menge Desktop/Server-Zeug. Solange ich die Werkzeuge zum Interoperieren bekomme, kann ich damit auskommen. Aber je weniger veraltete Frameworks, an die ich mich erinnere, desto besser.

ASP.NET ist jedoch Teil des Webstacks, und der Webstack ist etwas, von dem ich glaube, dass es auf dem neuesten Stand bleiben muss. Es hat einen anderen Anwendungsfall, und es besteht die unglückliche Erwartung, die neuere Plattform für Webarbeiten zu verwenden, es sei denn, es gibt einen guten Grund dagegen oder eine signifikant inkompatible Codebasis. Ich versuche, dies auf dem neuesten Stand zu halten, da sich Webstandards schnell und erheblich ändern. Die meisten Leute, die mit dem Web Schritt halten, halten an neueren Technologien fest, und die Implementierung der neuen Dinge auf älteren Stacks kann ziemlich schmerzhaft sein. Besonders in der Situation, in der ASP.NET mit PHP und Node konkurriert, muss ich einen moderneren Stack beibehalten, um Talente und Interesse zu wecken. Ich würde gerne weniger Webarbeit machen, aber leider ist es die neue UI-Erwartung. Ich hatte gehofft, dass ich durch das Festhalten am Standard das Beste aus beiden Welten haben würde, aber das scheint ein zeitlich begrenztes Angebot zu sein.

Wenn Sie also richtig verstanden haben, wird netstandard schließlich net framework ersetzen.

Nicht das ist nicht richtig. Ich bin mir nicht sicher, wie Sie zu diesem Schluss gekommen sind. .NET Standard ist immer eine Teilmenge aller Laufzeiten, die es unterstützen.

Ich möchte hier ein paar verrückte Sachen rauswerfen, weil es ein paar Mal erwähnt wurde. Was ich gleich sagen werde, hat keinen Einfluss darauf, was passieren wird, es ist an dieser Stelle alles Spekulation. Mehrere Leute haben gefragt, warum wir auf .NET Core statt auf .NET Standard abzielen wollen.

• Wir haben Zeichenfolgen als eines der wichtigsten Dinge identifiziert, die wir in .NET Core angehen möchten. Es gibt unzählige Ideen, aber eine davon ist, dass Zeichenfolge standardmäßig utf8 ist (jede Menge Kompatibilitätsprobleme, aber folgen Sie mir hier).
• Eine andere Sache, die wir beheben möchten, ist die Möglichkeit, billige Segmente von Arrays/Strings, jedes Stück zusammenhängenden Speichers, zu nehmen. Wir haben Span<T> hinzugefügt und betrachten Buffer<T> , um dies darzustellen. Es könnte bedeuten, dass String und Array neue Schnittstellen implementieren, die es ermöglichen, einen Slice zu nehmen, der eine 0-Zuweisung erfordert.
• Dies führt zu neuen Methoden für String, die eine Aufteilung ermöglichen, bei der nicht jedes Mal ein Array zugewiesen wird.
• Dies führt zu Überladungen von Int, UInt usw. (TryParse), die Span<char> und Span<byte> verwenden.
• Dies führt zu neuen Codierungsroutinen, die Span<byte> .
• Buffer<T> und Span<T> können Sie Speicher auf einheitliche Weise darstellen, und wir möchten den Netzwerkstapel aktualisieren, um die Übergabe vorab festgelegter Puffer zu ermöglichen, die Span<T> oder Buffer<T> .
• Kestrel wird HTTP2 im 2.x-Zeitrahmen implementieren (derzeit auf 2.1 ausgerichtet) und das erfordert neue APIs im SSL-Stream, um ALPN auszuführen (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• Http-Client auf .NET Core unterstützt Duplex-Streaming, wodurch es möglich wird, Streaming-Endpunkte über http in Signalr über eine einzige HTTP-Anforderung ohne Websocket zu implementieren.
• Wir haben die Header-Parser-Implementierungen von HttpClient und System.Net.Http gegabelt und umbenannt (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers), damit wir sie verbessern konnten und lassen Sie sie sowohl .NET Framework als auch .NET Core unterstützen. .NET Core hat eine Kopie dieser Verbesserungen, die es nicht zurück geschafft hat, weil sie nicht verbessert werden mussten (wir konnten sie nicht nutzen).
• Es gibt eine Reihe neuer Threading-Primitive, die eine neue API erfordern, die neue Szenarien erhellen wird, wenn wir sie nutzen können (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl+label%3Aarea-System.Threading), das sind nur einige der Dinge, die ich persönlich eingereicht habe.

Ohne die Fähigkeit, die Kernprimitiven auf Touren zu bringen, werden wir ermutigt, sie zu forken und Dinge zu erschaffen, die wie sie aussehen, es aber nicht sind. Aus diesem Grund haben wir unsere eigene kleine BCL in ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Das war nur eine zufällige Auswahl von Dingen, die wir in naher Zukunft tun sehen und die sehr grundlegende Teile von .NET betreffen.

@FransBouma

NET voll, um schneller voranzukommen, da es nicht genügend Ressourcen für .NET voll bereitstellt, um mit .NET Core Schritt zu halten. Sehen Sie sich die Menge an APIs an, die in den letzten zwei Jahren vollständig zu .NET hinzugefügt wurden. Sagt Ihnen das, dass ein großes Team daran arbeitet?

Das stimmt einfach nicht. Dinge werden ständig auf .NET Framework portiert, aber wie wir alle wissen, ist das Risiko erheblich höher, als dieselben Änderungen in .NET Core vorzunehmen. Hassen Sie es nicht alle, wenn ein Update auf .NET Framework Ihre Anwendung beschädigt? Wir tun das auch, also erfinden wir alle Arten von Verfahren, um es zu mildern, Sie würden nicht glauben, welchen Würgegriff es auf die Technik ausübt, um es aufrechtzuerhalten. Wir schaffen es trotzdem, Features zu machen. Das heißt, es wird sich einfach nie so schnell bewegen wie .NET Core, es ist eine Windows-Komponente, die nach dem Windows-Zeitplan ausgeliefert wird.

Ich verstehe, aber ich glaube nicht, dass es einen Unterschied in Ihrer Fähigkeit machen würde, wirklich etwas zu portieren. Dieselbe EOL-Richtlinie existiert noch.

@davidfowl Richtig. Aber wie Sie es gestalten, bedeutet etwas. Ganz zu schweigen davon, wann es kommuniziert wird, wenn überhaupt. Es wird den Menschen nicht unbedingt mehr Zeit geben, die eigentliche Arbeit zu erledigen, aber es würde ihnen mehr Zeit geben, nachzudenken und die richtige Entscheidung (für sie) zu treffen.

Wenn Sie derzeit mit der Portierung zu/der Verwendung von ASP.NET Core auf .NET Framework begonnen haben, haben Sie anscheinend drei Möglichkeiten:

1. Portieren Sie Ihren gesamten Code und Ihre Abhängigkeiten nach .NET Core und wechseln Sie zu ASP.NET Core 2.x.
   
   
   
   • Dies wäre die optimale Lösung, aber es könnte eine Menge Arbeit erfordern, und für einige könnte es aufgrund von Bibliotheken von Drittanbietern sogar außerhalb ihrer Kontrolle liegen.
   
   
2. Bleiben Sie bei ASP.NET Core 1.x und .NET Framework und hoffen Sie, dass Sie 1. ausführen können, bevor es nicht mehr unterstützt wird.
   
   
   
   • Das ist ziemlich riskant. Innerhalb eines Jahres (oder zwei oder drei? wer weiß?) könnten Sie riskieren, auf einer nicht unterstützten Plattform zu laufen.
   
   
3. Wechseln Sie zurück zu ASP.NET 4.x
   
   
   
   • Während diese Alternative Sie unterstützt, werden Sie "zurückgehen" und Arbeit rückgängig machen, die Sie bereits begonnen haben. Und seien wir ehrlich; Diese Plattform wird in Zukunft nicht mehr viel Liebe bekommen.
   
   

Wenn man es vorher gewusst hätte und einplanen könnte, halte ich sowohl 1. als auch 2. für gute Alternativen. Das Problem ist, dass beide Alternativen ziemlich viele Unbekannte haben. Was ist mit Bibliothek A? Was ist mit Bibliothek B? Wird Bibliothek A jemals portiert?

Ich glaube, im Moment fühlen sich viele Menschen gezwungen, eine Wahl zu treffen, ohne ein klares Bild davon zu haben, was die Wahl tatsächlich mit sich bringt.

@khellang (in deiner hypothetischen Lösung)

1. Wechseln Sie zu ASP.NET Core 2.0 auf .NET Framework
   
   
   
   • Das ist ziemlich riskant. Innerhalb eines Jahres könnten Sie riskieren, auf einer nicht unterstützten Plattform zu laufen.
   
   

@davidfowl

Ehrliche Frage (das frage ich, nicht Microsoft): Bevorzugen Sie Stabilität und Kompatibilität gegenüber neuen Funktionen? Wenn ja, warum sollten Sie sich für ASP.NET Core entscheiden?

Ehrliche Antwort:
Favor: Stabilität und Kompatibilität stehen an erster Stelle. Neue Funktionen sind nett, aber wenn sie landen, dürfen sie einfach nicht das bestehende Ökosystem zerstören.
Warum ASP.NET Core: Ganz einfach, weil es auf OS X und Linux läuft.

Ein Ökosystem wie .NET (alt und/oder Core) oder auch Java wird von Unternehmen gewählt. Und wenn sie ihre Entscheidung treffen, investieren sie viel Mühe in die Entwicklung von Code für diese Plattform / dieses Ökosystem.

Nun hat zum Beispiel einer unserer Kunden bereits viel in ASP.NET Core investiert. Basierend auf den vorherigen Ankündigungen und verkauften Ideen von .NET Core wurde Code geschrieben. Dieser neue (ASP.)NET Core-Code, den wir (schmerzhaft) mit einem Team im Laufe der anfänglichen Entwicklung von (ASP.)NET Core geschrieben haben, beginnend mit seiner Einführung, besteht aus einer Reihe von Servern und Clientbibliotheken mit einer ganzen Menge der Geschäftslogik.
Und dieser Code läuft nicht nur auf einem Linux-Server und stellt Dienste bereit, sondern wird derzeit auch in einer Reihe sehr alter Anwendungen verwendet, die mit diesen Diensten kommunizieren, und diese sind eine verdammt gute Mischung aus WPF / Windows Forms / C++ / CLI und normal C++ (einschließlich DirectX-Sachen).

Und jetzt kürzen Sie unseren Kunden einfach die Investition einiger Mannjahre in den .NET Core-Code für die vorhandenen Anwendungen, da es unmöglich sein wird, den neuen .NET Core-Code in den eigentlichen Anwendungen wiederzuverwenden (Die neuen Server und Geschäftslogikbibliotheken wurden dafür erstellt).

Um auf die Frage zurückzukommen: Ein Unternehmen würde sich für .NET Core als „.NET, jetzt auch für XPlat“ entscheiden und dabei die gleiche Kompatibilität und Stabilität erwarten, die uns .NET in den letzten 17 Jahren gegeben hat. Und um ehrlich zu sein, das ist der einzige Grund für .NET Core. Wenn Sie das nicht wollten, würden Sie Node.js oder sogar Java verwenden. Beide sind jetzt viel ausgereifter und XPlat als .NET Core.

Und um es noch ein wenig näher auszuführen: .NET Core war in den frühen Phasen mit project.json und allem cool und schnelllebig. Und dann wurde uns aus Gründen der "Kompatibilität mit .NET" project.json zugunsten von Msbuild und .csproj wieder genommen. Und genau diese „Kompatibilität zu .NET“ wird nun auch noch weggenommen, zugunsten von … was genau?

@Ingwer

Erstmal super Antwort!

Warum ASP.NET Core: Ganz einfach, weil es auf OS X und Linux läuft.

Basierend darauf scheint es, als wäre MVC 5 auf Mono das, was Sie wirklich wollten, oder?

Um auf die Frage zurückzukommen: Ein Unternehmen würde sich für .NET Core als „.NET, jetzt auch für XPlat“ entscheiden und dabei die gleiche Kompatibilität und Stabilität erwarten, die uns .NET in den letzten 17 Jahren gegeben hat. Und um ehrlich zu sein, das ist der einzige Grund für .NET Core. Wenn Sie das nicht wollten, würden Sie Node.js oder sogar Java verwenden. Beide sind jetzt viel ausgereifter und XPlat als .NET Core.

Und um es noch ein wenig näher auszuführen: .NET Core war in den frühen Phasen mit project.json und allem cool und schnelllebig. Und dann wurde uns aus Gründen der "Kompatibilität mit .NET" project.json zugunsten von Msbuild und .csproj wieder genommen. Und genau diese „Kompatibilität zu .NET“ wird nun auch noch weggenommen, zugunsten von … was genau?

Dies ist im Grunde der Kern des Problems. Basierend auf Ihrer Einschätzung:

Diesen neuen (ASP.)NET Core-Code haben wir (schmerzhaft) mit einem Team im Laufe der anfänglichen Entwicklung von (ASP.)NET Core geschrieben.

Sie wollten wirklich nur das vorhandene .NET Framework unter Linux mit der guten alten ASP.NET 4.x-Kompatibilität. Ist das eine faire Zusammenfassung?

Favor: Stabilität und Kompatibilität stehen an erster Stelle. Neue Funktionen sind nett, aber wenn sie landen, dürfen sie einfach nicht das bestehende Ökosystem zerstören.

.NET Core ist tatsächlich eine stabilere Plattform als Desktop, da es eine parallele Ausführung ermöglicht, wo Desktop dies nicht tut.

Wenn Sie neuere Funktionen in der nächsten Version von Desktop verwenden möchten, müssen Sie den gesamten Computer auf diese neue Version aktualisieren, und das wirkt sich auf alles auf diesem Computer aus, nicht nur auf die App, die die neueren Funktionen verwenden möchte. Was in Ordnung ist, wenn Sie einen dedizierten Server für einen einzigen Zweck haben; aber nicht, wenn Sie viele Apps auf demselben Server ausführen, die mit unterschiedlichen Raten aktualisiert werden (oder überhaupt nie aktualisiert werden!)

@davidfowl schrieb:

Es liegt an den Frameworks zu entscheiden, ob sie auf .NET Framework, UWP, .NET Core, Mono usw. laufen wollen. Es ist eine Wahl. Orleans wird nicht mit .NET Core ausgeliefert. ASP.NET Core tut es. Diese Produkte sind ein und dasselbe.

Im Fall von Orleans unterstützen wir .NET Standard 1.5 in unseren „2.0 Technical Preview“-Builds, haben aber auf .NET Standard 2.0 gewartet, damit wir eine stabile Version erstellen können. Derzeit sehe ich keine Blockaden für uns - meine Sorge gilt nur der zukünftigen Divergenz. Irgendwann muss es aber zu dieser Abweichung kommen.

👍 Vielen Dank, dass Sie hier bleiben, um die Fragen aller zu beantworten, @davidfowl & co!

NET voll, um schneller voranzukommen, da es nicht genügend Ressourcen für .NET voll bereitstellt, um mit .NET Core Schritt zu halten. Sehen Sie sich die Menge an APIs an, die in den letzten zwei Jahren vollständig zu .NET hinzugefügt wurden. Sagt Ihnen das, dass ein großes Team daran arbeitet?

Das stimmt einfach nicht. Dinge werden ständig auf .NET Framework portiert, aber wie wir alle wissen, ist das Risiko erheblich höher, als dieselben Änderungen in .NET Core vorzunehmen. Hassen Sie es nicht alle, wenn ein Update auf .NET Framework Ihre Anwendung beschädigt? Wir tun das auch, also erfinden wir alle Arten von Verfahren, um es zu mildern, Sie würden nicht glauben, welchen Würgegriff es auf die Technik ausübt, um es aufrechtzuerhalten. Wir schaffen es trotzdem, Features zu machen. Das heißt, es wird sich einfach nie so schnell bewegen wie .NET Core, es ist eine Windows-Komponente, die nach dem Windows-Zeitplan ausgeliefert wird.

das ignoriert die Tatsache, dass Sie die Bibliotheken, von denen _Sie_ abhängen, als netstandard2.0-Pakete freigeben können, damit aspnet auch auf .net vollständig ausgeführt werden kann. Darüber hinaus ist das Vornehmen von Änderungen an .NET Full nicht ohne Risiko, aber lassen Sie es bitte nicht so klingen, als wäre es ein schrecklich organisierter Haufen von Code, bei dem eine Änderung alles zum Einsturz bringen kann.

Wir schaffen es trotzdem, Features zu machen.

Ja, jeder andere .NET-Entwickler auch ;) Sobald Sie etwas veröffentlichen, bleiben Sie bei dieser API hängen, wir alle haben das. Sie möchten jedoch eine Abkürzung nehmen (wie es das ASPNET-Team viele Male zuvor getan hat!) und sich ohne diese Belastung bewegen. Aber das wird am Ende nicht fliegen.

Das heißt, es wird sich einfach nie so schnell bewegen wie .NET Core, es ist eine Windows-Komponente, die nach dem Windows-Zeitplan ausgeliefert wird.

Ich denke, hier haben wir den Kern der Sache, oder? Das .NET-Kernteam kann tun, was es will, ohne mit dem Ungetüm „WinDiv“ zu kommunizieren. Warum löst Microsoft diesen internen Politik-Mist nicht intern und stellt sicher, dass .NET full + .NET Core ohne die Windows-Politik korrekt versioniert / bewegt werden?

Übrigens, immer noch daran interessiert, wie Sie die Verschlüsselungs-API von SQL Server Enterprise an .NET Core 2.0-Benutzer verkaufen würden.

Außerdem muss ich hinzufügen; Ich bin ziemlich beeindruckt, wie lange dieser Thread schon läuft, mit so vielen Beteiligten, und dabei immer noch höflich bleibt ❤️ Das sieht man nicht jeden Tag im Internetz 👏 Vielleicht wächst das .NET OSS-Ökosystem doch noch heran? 😉

das ignoriert die Tatsache, dass Sie die Bibliotheken, von denen Sie abhängen, als netstandard2.0-Pakete freigeben können, damit aspnet auch auf .net vollständig ausgeführt werden kann.

Darüber hinaus ist das Vornehmen von Änderungen an .NET Full nicht ohne Risiko, aber lassen Sie es bitte nicht so klingen, als wäre es ein schrecklich organisierter Haufen von Code, bei dem eine Änderung alles zum Einsturz bringen kann.

Es ist groß und existiert schon lange. Wie bei jedem Legacy-System sind einige Teile besser als andere. Es macht den Code nicht weniger zuverlässig, aber es macht es praktisch unmöglich, einige Teile zu ändern. Es gibt so viele lustige Geschichten, die Veteranen Ihnen erzählen können, wie Fehlerkorrekturen in einem Bereich obskure Szenarien in Anwendungen in anderen Teilen zerstörten. Es ist verworren, das passiert, wenn die Abhängigkeitsgrenzen nicht gut definiert sind. Sie müssen mir nicht einmal glauben, gehen Sie einfach und stöbern Sie auf referencesource.microsoft.com. In-Place-Updates sind der Grund, warum wir einen Konfigurationsschalter für jede einzelne potenziell bahnbrechende Änderung an .NET Framework hinzufügen müssen. Es ist Physik, es kann sich einfach nicht so schnell bewegen.

Ja, jeder andere .NET-Entwickler auch ;) Sobald Sie etwas veröffentlichen, bleiben Sie bei dieser API hängen, wir alle haben das. Sie möchten jedoch eine Abkürzung nehmen (wie es das ASPNET-Team viele Male zuvor getan hat!) und sich ohne diese Belastung bewegen. Aber das wird am Ende nicht fliegen.

Wir lieben Abkürzungen! Entwickler sind faul 😄 . Wir möchten auch unseren .NET Core wirklich verbessern, ohne das zu stören, was .NET Framework darstellt. Vielleicht hätten wir es in etwas anderes umbenennen sollen, wie Sparkle 😄 .

Ich denke, hier haben wir den Kern der Sache, oder? Das .NET-Kernteam kann tun, was es will, ohne mit dem Ungetüm „WinDiv“ zu kommunizieren. Warum löst Microsoft diesen internen Politik-Mist nicht intern und stellt sicher, dass .NET full + .NET Core ohne die Windows-Politik korrekt versioniert / bewegt werden?

Lesen Sie meine andere Antwort zur Physik.

Übrigens, immer noch daran interessiert, wie Sie die Verschlüsselungs-API von SQL Server Enterprise an .NET Core 2.0-Benutzer verkaufen würden.

Das ist nicht mein Fachgebiet, das lasse ich jemand anderen beantworten.

@khellang lol das liegt daran, dass GitHub-Probleme MS-hassende Trolle noch nicht angezogen haben. Derzeit ist Twitter ihr Medium dafür, wo es noch kein Downvote gibt :)

@davidfowl

Sie wollten wirklich nur das vorhandene .NET Framework unter Linux mit der guten alten ASP.NET 4.x-Kompatibilität. Ist das eine faire Zusammenfassung?

Nein nicht wirklich. Unser Kunde benötigte komplett neue / glänzende (Mikro-)Dienste, um seine bestehenden .NET 4.x (sie waren 3.5, als wir anfingen) Windows-Desktopanwendungen zu ergänzen.

Als Sie mit all dem glänzenden Core-Zeug in die Beta-Phase gingen, haben wir begonnen, den neuen Servercode für das brandneue MVC auf ASP.NET Core zusammen mit begleitendem DTO, Geschäftslogik und Client-Bibliotheken zu schreiben, die ebenfalls vorhanden sind parallel in den bestehenden 4.6-Desktop-Anwendungen verwendet, um mit den brandneuen Servern zu kommunizieren.

Außerdem laufen einige der brandneuen ASP.NET Core-Server nicht nur unter Linux, sondern auch als Windows-Dienste mit Topshelf (zusätzlich zum vollständigen 4.6-Framework).

Die Sache ist also, dass viel investiert wurde, und jetzt scheinen wir bei .NET Core 1 festzustecken, da ein Wechsel zu 2 (und der Verlust von netstandard) auch bedeuten würde, dass wir die Assemblys in nicht wiederverwenden können vorhandene Desktop-Anwendung (für die die Dienste und zugehörigen Bibliotheken erstellt wurden) nicht mehr.

Das Wichtigste für uns wäre also, die neuen (ASP).NET Core-Bibliotheken, die wir in .NET 4.6-Desktopanwendungen schreiben, weiterhin verwenden zu können (denn dafür wurden sie entwickelt), während wir in der Lage sind, auf einem unterstützten System zu bleiben .NET Core-Version, solange die Desktop-.NET-Version unterstützt wird, auf der der Code ausgeführt werden kann.

Solange also .NET Core 1. genauso unterstützt wird wie .NET 4.6 und es einen linearen Upgrade-Pfad auf .NET Core x gibt, wenn .NET 5 herauskommt, und .NET Core x-Code auf .NET ausgeführt werden kann. NET 5, dann geht es uns gut.

@gingters Verwenden Sie .net-Funktionen, die nicht in netstandard2.0 enthalten sind, für die asp.net-Dienste?

Wenn nicht, sollten die Bibliotheken einfach funktionieren. Aber ich vermute, Sie sprechen über Dinge, die nicht in netstandard2.0 enthalten sind.

@davidfowl Funktionieren c++/cli-DLLs auf netcoreapp 2.0? Wir haben alte C++/CLI-Assemblys von Drittanbietern, die nicht früher ersetzt werden.

@davidfowl schrieb:

ASP.NET Core 2.0 hat ehrlich gesagt nicht so viele neue Features

In welchem ​​Fall, warum diese hochgradig disruptive Änderung jetzt?

@qrli C++/CLI funktioniert nicht auf CoreCLR. Hier sind einige Hintergrundinformationen, warum es nicht unterstützt wird: https://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

Geben Sie 1x 4 Jahre Support (portieren Sie so viel wie möglich von 2x) und machen Sie mit 2x schnell weiter. Ein Stadtflitzer für den langsamen Stadtverkehr und ein Ferrari für die Autobahn. Wir haben viel Konkurrenz außerhalb der .net-Welt.
Wenn ASP.Net Core erfolgreich ist, bin ich sicher, dass MS die Ressourcen bereitstellen wird, um 1x für 4 Jahre zu unterstützen. Meistens ändert sich die Kultur.

@ idg10 Es ist wirklich nicht. 2.x ist so ziemlich 1.x mit Performance-Sachen, die nur im Kern verfügbar sind. Ich denke, das einzige Hauptmerkmal sind Razor Pages.

Auf Version 1.x zu sein bedeutet also nicht, dass Sie auf einer veralteten Version sind. Aber das wurde nicht sehr gut kommuniziert.

In welchem ​​Fall, warum diese hochgradig disruptive Änderung jetzt?

Ich denke, das fasst es ziemlich genau zusammen https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

@hallatore
Ich weiß, dass es funktioniert, wie es _jetzt_ tut. Wir können vorerst bei 1 bleiben. Das Problem geht voran. Wenn wir ein Upgrade auf (ASP).NET Core 2-Bibliotheken durchführen möchten (oder schlimmer noch: müssen) (dh wenn 1 außer Betrieb geht und eine kritische Sicherheitslücke behoben wird), stehen wir vor dem Problem, dass wir kein Upgrade durchführen können würde es unmöglich machen, unsere Bibliotheken zu verwenden, die die aktualisierten Pakete in den .NET-Desktop-Apps benötigen.

Bearbeiten / hinzufügen: Es sei denn, es wird ein neues vollständiges .NET-Framework geben, das in der Lage ist, die neuen, festen .NET Core-Bibliotheken auszuführen, die sich auf einem linearen Upgrade-Pfad für die vorhandene Legacy-Desktop-App befinden.

@gingters Ich bin mir nicht sicher, ob ich es verstehe.

Wenn Ihre Desktop-Bibliotheken mit netstandard2.0 funktionieren, sollten sie auch auf dem Kern laufen. (Wenn sie WPF-Sachen usw. aufrufen, werden sie das natürlich nicht tun)
Wenn dies der Fall ist, sollten Sie asp.net Core 2.0 verwenden können.

Wenn Ihre Desktop-Bibliotheken auf dem Kern abstürzen, weil sie Dinge verwenden, die nicht in netstandard2.0. Dann sehe ich, warum Sie auf 1.x bleiben müssen. Und ich verstehe, warum das kurze EOL ein Problem ist.

Wäre 1.x eine einfachere/bessere Wahl, wenn Sie wüssten, dass 2.x nur Kernleistungsmaterial enthält (was bedeutet, dass 1.x nicht veraltet ist gegenüber 2.x). Und dass 1.x Patches bekommt und für * Jahre unterstützt wird?

@hallatore Es ist umgekehrt. Alte Anwendung: Mix aus Windows Forms, WPF, C++/CLI, normalem C++, DirectX, Millionen Codezeilen etc. pp, läuft auf 4.6 full framework.

Auf .NET Core: Neue Geschäftslogikbibliotheken (die auch andere Bibliotheken verwenden, dh die .NET Core-Version von Serilog), Abstraktionsbibliotheken + Dienste + Clientbibliotheken für diese Dienste. Dienste müssen unter Linux und als Windows-Dienste ausgeführt werden (derzeit Topshelf auf dem vollständigen .NET 4.6-Framework, sobald die Unterstützung von Windows-Diensten in Core landet, könnte dies jedoch geändert werden).

Jetzt werden die neue Geschäftslogik und Abstraktionen sowie die Service-Client-Bibliotheken auch von den .NET 4.6-Anwendungen verwendet. Das bedeutet, dass wir nicht in der Lage sind, sie zu aktualisieren, da sie auf dem vollständigen .net-Framework laufen müssen, solange die Desktop-App dies tut (was wir davon ausgehen können, dass dies so lange dauern wird, wie ein Desktop leben kann, es sei denn, das vollständige Framework geht im Allgemeinen weg).

@gingters Sie können weiterhin die gemeinsam genutzten Bibliotheksprojekte in Ihrer Lösung haben, die auf netstandard _min(usable)_ abzielen, und diese Bibliotheken aus Ihrem ASP.NET Core 2.0-Code nutzen sowie sie für die Verwendung von WPF, Xamarin, UWP usw. packen.

Es ist wirklich traurig, dass ihr MS-Jungs immer noch nicht versteht, worauf es ankommt. Sie denken immer noch, dass es sich nur um ein Problem mit der API-Lücke handelt. Sie denken immer noch, dass die Leute ihren Code einfach ändern können und es auf Netcoreapp funktioniert ... Ich dachte, Sie verstehen Unternehmen viel besser als Google.

Basierend darauf scheint es, als wäre MVC 5 auf Mono das, was Sie wirklich wollten, oder?

@davidfowl Ich meine, komm schon. Das ist eine abweisende und ehrlich gesagt beleidigende Antwort. Kann irgendjemand bei MS bestätigen, dass ein einzelner Entwickler überhaupt noch Framework ASP zugewiesen ist? Ich versuche hier nicht, ein Idiot zu sein, aber es scheint, als würde die Community manchmal schlecht behandelt.

Es gibt keinen Grund unter der Sonne, dass ich .Net Core und ASP.Net Core als dasselbe Produkt betrachten sollte. Es gab überhaupt keine Nachrichten, die dies unterstützten. Vor allem, wenn man bedenkt, dass Mono _nach_ der Ankündigung von .Net Core unter die Fittiche von Microsoft kam. Es wurde immer als die kleinere, flinkere xplat-Version von .Net gemeldet. Nicht nur das, wir erinnern uns alle an die Tage, als ASP.Net Core eigentlich ASP.Net 5 war und überall funktionieren sollte. Verdammt, diese Änderung ist erst etwas mehr als anderthalb Jahre her.

Ist die selbst gehostete HTTP-Story in netstandard20 effektiv „Kestrel 1.x verwenden“? Ich bin mir nicht sicher, ob die Nancy-Leute sich sehr darum kümmern werden, und ich auch nicht. ASP.Net 2.x mag in Bezug auf die Funktionen inkrementell sein, aber Kestrel 2 hat einen ernsthaften Leistungsvorteil, den wir an dem Tag ernsthaft nutzen könnten kommt heraus.

@davidfowl

Es ist groß und existiert schon lange. Wie bei jedem Legacy-System sind einige Teile besser als andere. Es macht den Code nicht weniger zuverlässig, aber es macht es praktisch unmöglich, einige Teile zu ändern. Es gibt so viele lustige Geschichten, die Veteranen Ihnen erzählen können, wie Fehlerkorrekturen in einem Bereich obskure Szenarien in Anwendungen in anderen Teilen zerstörten. Es ist verworren, das passiert, wenn die Abhängigkeitsgrenzen nicht gut definiert sind.

Ich denke, das ist ein interessanter Kommentar. Ich erinnere mich, dass ich eine ältere Aufzeichnung einer NDC-Konferenzsitzung gesehen habe, bei der @davidfowl und @DamianEdwards den alten Cruft in ASP.NET 4 auseinander genommen haben, den Sie wirklich hinter sich lassen wollten – es war wirklich faszinierend, einen Blick in diese schwarze Codebox zu werfen.

Aber ich denke, dieser Kommentar spiegelt auch die Bedenken wider, die viele von uns mit unseren eigenen Codebasen haben. Wir unterhalten große Legacy-Systeme, die oft nicht gut konzipiert sind und schlechte Abhängigkeitsgrenzen aufweisen. Es ist praktisch unmöglich, einige dieser Systeme für .NET Core umzuschreiben. Das Geschäft lässt das Risiko einer so großen Veränderung einfach nicht zu.

Ich weiß nicht, was die richtige Antwort ist. Aber ich weiß, dass wir für unsere eigenen Anwendungen auf absehbare Zeit das vollständige Framework und ASP.NET4/MVC5 verwenden werden (wir haben immer noch einen Teil der WebForms, die für eine ganze Weile nicht neu geschrieben werden!). Ich hoffe, dass MVC5 jetzt, da es _endlich_ auf GitHub verschoben wurde, etwas Liebe bekommt – ich bin sogar bereit, meine eigene Zeit und Mühe zu investieren, um es besser zu machen (z. B. bessere asynchrone Unterstützung, Leistungsverbesserungen usw.).

@qrli Enterprises verfügen weiterhin über vollständiges .NET 4.5 zur Ausführung auf ihren Windows Server 2008 R2 IIS 7.5-Webfarmen. Das nimmt ihnen keiner weg.

@mattnischan

Ist die selbst gehostete HTTP-Story in netstandard20 effektiv „Kestrel 1.x verwenden“? Ich bin mir nicht sicher, ob die Nancy-Leute sich sehr darum kümmern werden, und ich auch nicht.

HttpListener ist Teil von netstandard20, daher wird auch netcore20 an dieser Front nichts weggenommen, wenn man netcore20 wird.

HttpListener ist Teil von netstandard20 also auch netcore20.

Und ich nehme an, ich kann die gleichen Anfragen pro Sekunde von HttpListener erwarten?

@markrendle Stimmt. Zur Zeit.

Aber was würden Sie vorschlagen, wenn eine andere Bibliothek, die von unserem gemeinsamen Material verwendet wird (z. B. serilog, newtonsoft, autofac usw.), die Unterstützung für netstandard_min (usable) einstellt (vielleicht nur, weil sie der Meinung ist, dass es zu viel Aufwand ist, beide Welten zu unterstützen) und Es wurde ein kritisches Sicherheitsproblem in der neuesten Version entdeckt, die immer noch das vollständige Framework unterstützt?

@mattnischan

HttpListener ist Teil von netstandard20 also auch netcore20.

Und ich nehme an, ich kann die gleichen Anfragen pro Sekunde von HttpListener erwarten?

Ok, Nancy ist .NETStandard 1.6, also können Sie es auf Core 2.0 und Kestrel 2.0 verwenden. Besser?

@gingters Ich würde vorschlagen, diese Brücke zu überqueren, wenn Sie dazu kommen.

Lassen Sie sich niemals von der Zukunft stören. Sie werden ihm notfalls mit denselben Waffen der Vernunft begegnen, die Sie heute gegen die Gegenwart wappnen.
_~ Marcus Aurelius_

Das ist kein so nützliches Mantra, wenn Software ausgeliefert wird, die kein Wartungsbudget hat und über Jahre weitgehend unverändert verwendet werden muss.

Wenn es für die kommenden Jahre weitgehend unverändert bleiben muss, warum spielt es dann eine Rolle, was mit den Bibliotheken passiert, von denen es in diesen kommenden Jahren abhängig ist?

@markrendle Angenommen , Sie sind gesetzlich verpflichtet (zumindest in einigen Ländern), Notfallprotokolle für genau diese Fälle bereitzustellen, bevor eine Version der Anwendung ausgeliefert wird, da sie in Umgebungen verwendet werden könnte, in denen das Leben von Menschen auf dem Spiel stehen könnte .

Sie möchten also einen Webserver, der so schnell wie Kestrel ist, und Ihre einzige spezifische Anforderung ist, dass es nicht Kestrel ist?

Ok, Nancy ist .NETStandard 1.6, also können Sie es auf Core 2.0 und Kestrel 2.0 verwenden. Besser?

@markrendle @benaadams Nein, ich glaube, Sie missverstehen das, und wieder versuchen Sie nicht, ein Idiot zu sein, sondern weisen nur darauf hin, dass es andere Kunden von Teilen von ASP.Net Core gibt, die nicht das Ganze sind. Ich würde unsere Produktionsplattform nur gerne auf Kestrel 2.0 hosten, wenn es herauskommt, und unsere Produktionsplattform könnte für eine Weile auf Framework laufen. Ich kann netcoreapp20 nicht anvisieren.

Nancy mag netstandard16 sein, aber das spielt keine Rolle, da ich Kestrel 2.0 nur auf Core 2.0 verwenden kann. Mir ist klar, dass dies spezifisch ist, und vielleicht lautet die Antwort wirklich: "Dann schreiben Sie Ihren eigenen Webserver, der auf einem Framework funktioniert, das so schnell ist wie Kestrel 2. Kestrel ist nur für ASP.Net." Aber ich würde es hassen, wenn das die Botschaft wäre.

@gingters @gulbanana Ich verstehe nicht, wie eine ausgelieferte Anwendung mit einem festen Satz von Abhängigkeiten kaputt gehen wird, weil ein Open-Source-Projekt zu einem mutmaßlichen zukünftigen Zeitpunkt keine beliebige Version des zugrunde liegenden Frameworks mehr unterstützt.

@mattnischan Ja, ich habe herausgefunden, was du meinst und diesen Kommentar gelöscht :)

@stefanson

Da ich Code zwischen dem Server und meinen Desktopanwendungen freigeben muss, bedeutet das, dass ich nie die neueste Version von ASP.Net haben kann?

Wenn Sie Ihre Bibliotheken auf .NET Standard ausrichten, können Sie sie sowohl in Desktop als auch in Core verwenden. Für Bibliotheken, die auf .NET Standard abzielen, haben Sie Unterstützung für universelle Plattformen: Desktop, Core, Mono, Unity, UWP, Tizen usw

Eine ASP.NET-Anwendung ist eine ausführbare Datei; der Endpunkt, es ist keine Bibliothek. Die endgültige Ausgabe, die ASP.NET-Anwendung/ausführbare Datei, muss auf einer Plattform ausgeführt werden. Irgendwann werden alle ihre Plattformbibliotheken von der ASP.NET-Anwendung verwendet, sodass es keinen Vorteil gibt, wenn sie nicht dasselbe Ziel wie die Plattform sind.

.NET Core ist eine gute Plattform, da sie eine breite plattformübergreifende Abdeckung bietet; kann Seite an Seite mit Desktop installiert und App für App unabhängig aktualisiert werden; anstatt ganze Maschine und jede App.

Einige Gegenstände werden außerhalb verwendet; Daher verwendet Wyam Razor für die Generierung statischer Websites. Razor ist derzeit .NET Standard 1.3, sodass die Verwendung außerhalb von Core derzeit kein Problem darstellt.

Es gibt einige Randfälle, die oben erwähnt wurden:

Verwendung von Bibliotheken, die den Funktionsumfang von .NET Standard 2.0 nicht unterstützen. Viele von ihnen sind hoffentlich Lücken, die geschlossen werden können – und zu Beginn dieser Ausgabe fragte MS, was diese Lücken seien, damit sie sie priorisieren könnten.

Ausführen einer WebApp, die beispielsweise in eine UWP-App eingebettet ist; Wenn Desktop jedoch weiterhin unterstützt, aber auf Version 4.7.1 geändert wurde, befinden Sie sich immer noch in der gleichen Situation, da UWP derzeit 4.7.1 nicht unterstützt und zu dem Zeitpunkt, als dies der Fall war, ASP.NET 4.7.2 und dann 4.7 erfordern würde. 3 usw. Es wäre eine Sisyphusaufgabe, da die anderen Plattformen es niemals verstehen würden; also wäre es nur fleißige arbeit ohne viel sinn?

Ja, ich habe herausgefunden, was du meinst, und diesen Kommentar gelöscht :)

Keine Sorge, guter Herr. 👍

@davidfowl

Wie wirkt sich das Revving von ASP.NET Core-Versionen darauf aus? Wenn wir die .NET Framework-Unterstützung in 3.0 einstellen würden (wie sich die Leute in diesem Thread zu entziehen scheinen), würden Sie sich dann nicht trotzdem in derselben Sackgasse befinden? Sie würden Ihre ASP.NET Core 2.0-Anwendung portiert und ein Jahr lang auf Framework ausführen lassen, und wenn 3.0 herauskommt, könnten Sie kein Upgrade durchführen. Sie könnten dies sowieso mit ASP.NET Core 1.1.x tun, das auf .NET Framework ausgeführt wird und auch dann unterstützt wird, wenn ASP.NET Core 2.0 nicht verfügbar ist.

Nur zu sagen (so wie ich es verstehe), dass "wir irgendwann mit dem vollständigen .net brechen mussten, warum nicht jetzt", fehlt ein wichtiger Punkt. Ich bin mir sicher, dass viele Leute auf die Veröffentlichung von Core 2.0 gewartet haben. Weil es öffentlich viele Verbesserungen in der Kompatibilität mit dem vollständigen .net versprochen hat. So viele Bibliotheksautoren warten auch darauf, mit der Migration zum Core zu beginnen. Ich schätze also, dass wir nach der Veröffentlichung von Core 2.0 viel mehr Bibliotheken auf Core migrieren werden. Und so wäre die Bindung von asp.net Core an Core 3.0 für das Ökosystem viel weniger frustrierend als jetzt. Denn im Moment von 3.0 sollten diese Dinge weniger daran hindern, auf den Kern zu migrieren.
Im Moment ist es eine Katastrophe.

Zuvor habe ich den Beginn der Migration unseres Frameworks (sehr ähnlich zu dem, was @benaadams beschrieben hat) auf core/asp.net Core in zwei Schritten bewertet: Webpart (das sich jetzt auf mvc/webapi befindet) auf asp.net Core migrieren und voll halten .net und migrieren Sie dann alle anderen Dinge auf den Kern, wenn alle Abhängigkeiten entsprechende Implementierungen für den Kern haben. Was uns derzeit blockiert, sind der Oracle ADO-Anbieter und der Postgres ADO-Anbieter (es könnte andere Inkompatibilitäten in Corefx geben, die wir noch nicht untersucht haben). Jetzt ist dieser Plan tot. Also müssen wir sitzen und auf die Migration von Abhängigkeiten warten, wobei wir alle neuen Dinge in der Core-Welt aufgeben. Und das alles nur, weil jemand bei MS entschieden hat, dass wir eine „Moving Fast“-Plattform brauchen.

@markrendle Die Anwendung wird nicht nur deswegen kaputt gehen. Das Problem ist ein anderes:
Da .NET Core 2 die Unterstützung für das vollständige Framework eingestellt hat (wo es in Version 1 gut lief, und es von Microsoft ist, wo Sie nicht erwarten, dass ein so grundlegendes, elementares Feature beim Aktualisieren auf eine neue Version gelöscht wird), auch Ihre Abhängigkeiten könnten die Unterstützung für dieses Szenario eher früher als später einstellen.
Jemand findet ein kritisches Sicherheitsproblem in einer der verwendeten Bibliotheken und es wird kein Update für die Version herausgegeben, auf der Sie festsitzen, da neuere Versionen Ihre Laufzeitumgebung nicht mehr unterstützen. Da Ihre Anwendung jetzt in einer stark regulierten Umgebung verwendet wird, müssen Sie einen Notfallplan bereitstellen, der erklärt, was genau Sie tun werden, wenn ein kritisches Sicherheitsproblem erkannt wird, und wie Sie diesen Fix einführen, um zu verhindern, dass Menschen verletzt oder schlimmer werden. Ein "Nun, wir können nichts tun" führt zum Widerruf Ihrer Erlaubnis, diesen Antrag zu versenden.

@gingters Sehen Sie, der Punkt ist, dass Sie Ihre technischen Entscheidungen auf der Grundlage der derzeit verfügbaren Informationen und der Art des Marktes treffen müssen, auf dem Ihr Unternehmen tätig ist. Sie können beim besten Willen nicht für alle Eventualitäten Rechenschaft ablegen, so sehr die Bürokraten und Regulierer dieser Welt Ihnen das auch vorgaukeln möchten. Was, wenn Microsoft durch eine feindliche Übernahme von Apple aufgekauft wird und .NET vollständig zugunsten von Swift eingestellt wird? Was ist, wenn starke Verschlüsselung in einem der Länder, in die Sie verkaufen, für illegal erklärt wird und alle Software-Stacks, die SHA256 enthalten, verboten sind? Was, wenn Nicolas oder James oder _insert-name-of-Autofac-maintainer-hier_ beschließen, zum Mars zu ziehen und Feuchtigkeitsfarmer zu werden? Was, wenn sich die Magnetpole umkehren und jedes einzelne Bit der digital aufgezeichneten Daten gelöscht wird?

Als eigentliche Antwort auf die Frage, was Sie als Unternehmen tun werden, wenn beispielsweise in JSON.NET ein kritisches Sicherheitsproblem gefunden wird, ohne dass ein offizielles Update verfügbar ist, das einzige Die mögliche Antwort lautet "We will fork-and-patch JSON.NET", was meiner Meinung nach bereits die Antwort auf die Frage ist, was Sie tun würden, wenn James Newton-King aus irgendeinem Grund krank werden würde. In meiner früheren Erfahrung in dieser Art von Märkten gab es Hinterlegungsvereinbarungen für den Quellcode zu proprietären Paketen für diese Art von Eventualitäten; Was mit Open-Source-Paketen zu tun ist, ist im Vergleich dazu trivial.

Und das alles nur, weil jemand bei MS entschieden hat, dass wir eine „Moving Fast“-Plattform brauchen.

„schnell vorankommen“ ist vielleicht übertrieben; Nach dem vorherigen Veröffentlichungszeitplan von Full Framework könnte es besser als "ohne zusätzliche Verzögerung von 1 - 2 Jahren" beim Versand angegeben werden. Das ist eine verrückte Zeit in der Web-Welt.

Die Dinge ändern sich schnell und die Plattform muss relevant bleiben.

@davidfowl und @DamianEdwards Ich denke, dass diese ganze Verwirrung von der Tatsache herrührt, dass ASP.NET Core 1.x auf .NET Framework ausgeführt werden kann. Dies führte zu der Annahme, dass ASP.NET Core die Weiterentwicklung von ASP.NET 4/MVC5 war; Menschen dazu bringen, darauf umzusteigen und zu glauben, dass sie alle Vorteile (Geschwindigkeit und neue Funktionen) erhalten und gleichzeitig die Abwärtskompatibilität beibehalten würden.

Vielleicht besteht die langfristige / dauerhafte Antwort auf dieses Problem darin , ASP.NET 4/MVC5 erneut als Antwort für Leute zu bewerben, die Abwärtskompatibilität mit langfristiger Unterstützung suchen (und vielleicht auch anbieten, kleine Verbesserungen vorzunehmen).

Dann kann sich ASP.NET Core darauf konzentrieren, eine neue Plattform zu sein, die sich von der Vergangenheit löst, um enorme Vorteile für diejenigen zu bieten, die den Sprung schaffen können.

Vor diesem Hintergrund werden (ASP).NET (Framework) und (ASP).NET Core zwei parallele und gleichermaßen gültige Wege sein, die Kunden wählen können. Und ich denke, so hätte es von Anfang an sein sollen.

@markrendle Ja, das ist hypothetisch, aber Bürokratie ist leider eine reale Sache. Und ja, Sie können (und müssen) nicht alle Eventualitäten berücksichtigen. Nur für diejenigen, die Sie vorhersehen können.

Und jetzt haben wir die Situation, dass a) das Weglassen einer vollständigen Plattform (.NET Full Framework), die in .NET Core 1 problemlos unterstützt wurde, nicht etwas war, das Sie vorhersehen konnten. Da es jedoch jetzt passiert ist, können Sie b) den Rückgang der Unterstützung für v1 in Ihren anderen Abhängigkeiten mit einem ziemlich sicheren "Ja, ich kann absolut sehen, dass das eher früher als später passieren wird" antizipieren.

Und ja, Forking und Backporting von Fixes ist eine der möglichen Lösungen, aber das ist etwas, das Sie so gut wie möglich vermeiden möchten. Wenn das .NET Core-Team so etwas gesagt hätte wie „Hey. Sehen Sie, wir beabsichtigen nicht, auf dem vollständigen Framework zu laufen, verlassen Sie sich nicht darauf“, oder noch besser, das hätte diese ganze Diskussion überhaupt nicht ermöglicht wäre nicht notwendig, da sich der Kunde einfach nicht dafür entschieden hätte, in neue Dinge zusätzlich zu .NET Core zu investieren.

@gingters Ich dachte, wir wären an dem Punkt angelangt, an dem Sie zufrieden waren, Ihre ASP.NET Core-Webbits auf .NET Core 2.x oder höher auszuführen und .NET Standard 2.x für die gemeinsame Nutzung von Bibliotheken zwischen Core und Full/UWP/was auch immer zu verwenden . Denn wenn diese Bibliotheken die Unterstützung für .NET Standard 2.x zugunsten von nur .NET Core 2.x einstellen würden, dann würden sie auch die Unterstützung für vollständiges .NET einstellen, und Sie wären so oder so im Stich gelassen.

@markrendle Bis zu dem Punkt, an dem wir ein kritisches Problem in einem der ASP.NET Core-Bits haben, die wir in den freigegebenen Dingen verwenden müssen, nachdem 1x nicht mehr unterstützt wird.

@gingters zum Glück ist es Open Source und Sie können sich bei Bedarf selbst unterstützen (oder einen Drittanbieter bezahlen)!

@markrendle nein. reine Legacy-Projekte sind tot. Unternehmensprojekte sind in der Regel eine große gemischte Codebasis, die Code/Bibliotheken von vor Jahrzehnten bis zu frischen neuen enthält. Netcoreapp zu sein bedeutet nur, dass Sie die Möglichkeit zum Mischen entfernt haben. Daher können wir nicht mehr auf Ihre schicke neue Version umsteigen, sondern auf die alte Version. und die Anti-MS-Arbeitskollegen sagen fröhlich zu mir: „Ich habe es dir gesagt …“ und drängen uns dann, zu Google-Lösungen zu migrieren.

ich plädiere nicht dafür, netfx für immer zu unterstützen. aber ich bin der festen Überzeugung, dass netfx von asp.net core für mindestens 2 Jahre unterstützt werden sollte. nicht nur 1.x sondern auch 2.x.

@qrli Diese "Unternehmensprojekte ... große Mix-Codebasis, die Code / Bibliotheken enthält, stammen von vor Jahrzehnten bis frisch neu." sind alles, was bei Unternehmensprojekten falsch läuft und aufhören muss. Sich darüber zu beschweren, dass eine neue Technologie Sie davon abhält, noch mehr Schlammklumpen in einen großen Ball der Verzweiflung zu werfen, der mit Unterlegscheiben, Draht und Leugnung zusammengehalten wird, ist wie sich darüber zu beschweren, dass eine neue industrielle Laserschneidmaschine mit Sicherheitsfunktionen ausgestattet ist, die Sie davon abhalten, sich hineinzulehnen und abzuschneiden wichtige Teile von dir.

@benaadams

„schnell vorankommen“ ist vielleicht übertrieben; Nach dem vorherigen Veröffentlichungszeitplan von Full Framework könnte es besser als "ohne zusätzliche Verzögerung von 1 - 2 Jahren" beim Versand angegeben werden. Das ist eine verrückte Zeit in der Web-Welt.

Die Dinge ändern sich schnell und die Plattform muss relevant bleiben.

Dies ist eine politische/organisatorische Einschränkung, keine technische. Schau dir an, wie sich die JVM/Java bewegt. Wenn sie sich überhaupt bewegen. Immer noch relevant, viel mehr als .NET heute ist. „Schnelles Handeln“ ist also nicht der Grund, warum sich Leute für Java/JVM entscheiden. Andererseits. Sie entscheiden sich für Java/JVM, weil ihr alle Nachteile fehlen, die mit „schnellem Handeln“ verbunden sind: Es ist eine stabile, zuverlässige Plattform, auf der Ihre Investition nicht in 1-2 Jahren verschwendet ist.

Ich weiß nicht, wenn MS .net ganz schnell bewegen will, wird es schnell gehen. Sie besitzen es, sie können entscheiden, was zu tun ist. Aber die Mächtigen geben nicht viel darüber her: .net full ist „gut genug“ für den jetzigen Stand.

MS hat viele Jahre am Steuer geschlafen und jetzt sind plötzlich Dinge wie Leistung und Speicherdruck wichtig (das sind sie zweifellos), während bei JVM viele Investitionen in diese speziellen Aspekte einer Laufzeit getätigt wurden Jahre und das zahlt sich aus.

Ich weiß nicht, was die kurzfristige Lösung ist, aber langfristig, wenn .NET auf zwei Hauptabteilungen aufgeteilt bleibt (.net voll mit Windows, .net Core mit devdiv), ohne andere Gemeinsamkeiten/Ziele als die gleichen Arbeitgeber verheißt nichts Gutes für uns Außenstehende.

Während hier viele Punkte angesprochen werden und jeder versucht sicherzustellen, dass er die Standpunkte anderer versteht, werden Lösungen wie „Große Unternehmen sollten nicht so sein“ nicht helfen. Selbst wenn Sie sie davon überzeugen könnten, würden sie 20 Jahre brauchen, um damit aufzuhören, weil sie große Unternehmen sind .

@kolectiv Das stimmt, aber zu akzeptieren, dass Unternehmen nicht plötzlich aufhören, Unternehmen zu sein, bedeutet nicht, dass Sie diese Art von Verhalten aktiv fördern/ermöglichen müssen.

Es sollte auch nicht bedeuten, dass _meine_ Anwendungen langsamer laufen und mehr Hosting-Kosten verursachen müssen.

Führen Sie eine Portabilitätsanalyse für unsere stark genutzten Bibliotheken durch, die immer noch auf .NET 4.x auf ASP.NET Core 1.x (EF6, NHibernate, NServiceBus) abzielen, und Mann, diese Bibliotheken sind nicht einmal annähernd in der Lage, auf netstandard20 abzuzielen

Bibliothek | Pkt
---------- | ---------
EF6 | 62.74
NHibernate | 67.39
NServiceBus | 65.68

Und immer noch große Lücken bei fehlenden APIs. EF Core hat immer noch eine große Lücke zu EF6, und wir verwenden immer noch NHibernate, wenn es dort wichtige Funktionen gibt, die in EF6 nicht vorhanden sind. NServiceBus verwenden wir für jedes Projekt, das Messaging durchführt.

Wütend.

@markrendle

Diese "Unternehmensprojekte ... große Mix-Codebasis, die Code / Bibliotheken enthält, stammen von vor Jahrzehnten bis frisch neu." sind alles, was bei Unternehmensprojekten falsch läuft und aufhören muss. Sich darüber zu beschweren, dass eine neue Technologie Sie davon abhält, noch mehr Schlammklumpen in einen großen Ball der Verzweiflung zu werfen, der mit Unterlegscheiben, Draht und Leugnung zusammengehalten wird, ist wie sich darüber zu beschweren, dass eine neue industrielle Laserschneidmaschine mit Sicherheitsfunktionen ausgestattet ist, die Sie davon abhalten, sich hineinzulehnen und abzuschneiden wichtige Teile von dir.

Ja, Mann, sagen wir diesen lästigen Unternehmen und großen Organisationen, dass sie die Dinge anders machen sollen, schneiden Sie den Draht ab! stoppen Sie die Schlammflut! Das wird sie dazu bringen, aufzuwachen und zuzuhören. Oh warte, das wird nicht helfen, da sie das bereits wissen, aber für deine eigene Argumentation mit vielen Dingen arbeiten müssen, die dir egal sind oder die du ignorierst.

Schauen Sie, niemand sagt 'neue Technologie: schlecht!'. Es geht darum, neue Technologien zu verfolgen, ohne sich der Konsequenzen bewusst zu sein, die sie mit sich bringen. Wir alle arbeiten gerne mit den neuesten Bits und müssen uns nicht um alten Kram kümmern, wer will das? Die Realität erzählt jedoch eine andere Geschichte. Wenn du nur mit den neusten Bits arbeiten musst und dich nicht um alten Scheiß kümmern musst, gut für dich! Leider müssen wir traurigen Arbeitsdrohnen in den Schützengräben mit einer anderen Realität leben. Es würde Ihnen passen, wenn Sie zumindest anerkennen, dass die Realität für VIELE Menschen einfach das ist, sie können es nicht ändern, sie können keine andere Zukunft gestalten, es ist das, womit sie arbeiten müssen.

@markrendle Ich bin mir nicht ganz sicher, was Sie vorschlagen? Unsere 15 Millionen Zeilen funktionierenden C#-Code aufgeben und alles neu schreiben? Wir wollten (langsam) auf Netstandard 2.0 umsteigen und hoffentlich Zugang zu Dingen wie Span usw. bekommen, wenn es dazu kommt, aber Probleme wie diese lassen mich bezweifeln, dass das klug ist.

Wir hätten gerne Linux-Unterstützung, aber das fühlt sich eher wie eine Abweichung an. Ich hatte angenommen, dass netstandard mit der fortschrittlichsten Implementierung vorankommen würde und dann Dinge wie das Framework aufholen würden, aber zumindest wüssten wir, dass es so wäre.

@FransBouma Also sollten wir alle leiden, weil Unternehmen dumme Dinge tun wollen? Ich sollte keine schönen Dinge bekommen, weil Multi-Millionen-Dollar-Projekte des öffentlichen Sektors noch nicht dafür bereit sind? Wie funktioniert das?

@markrendle Was ist so dumm daran, den funktionierenden Code behalten zu wollen?

Sie entscheiden sich für Java/JVM, weil ihr alle Nachteile fehlen, die mit „schnellem Handeln“ verbunden sind: Es ist eine stabile, zuverlässige Plattform, auf der Ihre Investition nicht in 1-2 Jahren verschwendet ist.

Und Sie können System.Web praktisch für immer verwenden; Es ist in Windows eingebrannt, was bedeutet, dass es wahrscheinlich nie verschwinden wird. Sie erhalten nicht viel stabiler und zuverlässiger als das.

ASP.NET Core 1.x -> ASP.NET Core 2.x; Alle APIs sind ziemlich gleich, die Hauptänderung besteht darin, die Unterstützung für .NET Framework einzustellen. Es ändert sich sogar für die Pause 😱

ASP.NET Core 1.x läuft auf .NET Core 2.x und .NET Framework, unterstützt .NET Standard 2.x (über .NET Core 2.x); und hat die gleichen APIs wie ASP.NET Core 2.x. Das ist also die Sprungbrettversion.

ASP.NET Core 2.x ist die Break-Release. Es unterstützt immer noch .NET Standard 2.x (über .NET Core 2.x) und nicht viel api-weise hat sich zwischen ASP.NET Core 1.x und ASP.NET Core 2.x geändert; aber löscht .NET Framework.

Könnte eine Alternative sein:

• ASP.NET Core gehen Sie voran und arbeiten Sie an etwas wie netstandard3.0 (könnte 2.x sein) und nur einer schnelleren Version von netstandard. Etwa einmal im Quartal.
• Die nächste Version von NetFx könnte erneut springen, um netstandard3.x zu unterstützen, wann immer die nächste Version verfügbar ist. Es müsste nicht einmal der neuste Standard sein.

Dies könnte eine schlechte Idee sein, da möglicherweise nicht alles, was verwendet wird, Teil von netstandard sein muss, aber zumindest ASP.NET Core 2.x würde auf einen Standard abzielen, den die anderen Frameworks schließlich verwenden werden.

Nur Spuckballing. Ich bin mir sicher, dass dies angesprochen wurde.

@bencyoung Ich schlage nur vor, dass es ein bisschen egoistisch ist, darauf zu bestehen, dass sich die ganze Welt um Ihre 15 Millionen Zeilen funktionierenden C # -Codes drehen sollte (der übrigens nicht aufhören wird zu funktionieren). Daher können Sie ASP.NET Core 2.0 nicht verwenden. Sie haben immer noch das vollständige Nur-Windows-Framework ASP.NET, das von Legacy-Unterstützung durchzogen wird wie Brighton through Rock. Es gibt also ein neues Spielzeug, mit dem Sie nicht spielen können, weil es für Sie wirtschaftlich nicht tragbar ist, Ihren Code zu portieren und Ihre Anwendung umzugestalten/umzugestalten. Das ist scheiße, aber viele Dinge tun es auch. Aber wenn Microsoft alles vermeidet, was für bereits zwei Jahrzehnte alte Legacy-Codebasen, die wahrscheinlich noch in VB 6.0 geschriebene COM-Komponenten enthalten, nicht funktioniert, dann werden sie in weiteren 20 Jahren Micro Focus sein.

@adamhathcock Dafür hatte ich angenommen, dass netstandard dafür gedacht ist - eher ein Vereinheitlichungsansatz als ein kleinster gemeinsamer Nenner. Es kann sich so schnell bewegen, wie es will, aber sie wären eine Verpflichtung, die das .NET-Framework schließlich einholen würde. Irgendwann würde es einen Netzstandard geben, der im Grunde das .NET-Framework abzüglich der plattformspezifischen Dinge war, und dann würde er vereinheitlicht

Die nächste Version von NetFx könnte erneut springen, um netstandard3.x zu unterstützen, wenn die nächste Version verfügbar ist.

Ein .NET Framework-Update ist ein erzwungenes Update für jeden Computer auf dem Planeten, auf dem (meistens) Windows ausgeführt wird.

Ein .NET Core-Update ist ein Update, das Sie für eine einzelne Anwendung auswählen .

Sie sind sehr unterschiedliche Tiere.

Nun, eine einfache Möglichkeit wäre, die Verknüpfung zu dieser Seite von der allerersten Seite der ASP.NET Core-Dokumentation an zu beenden.

(Oder fügen Sie einfach eine Zeile „Wählen Sie nicht .NET Framework aus, wenn Sie weiterhin ASP.NET Core verwenden möchten!“ hinzu.)

Sie wären eine Verpflichtung, die das .NET-Framework schließlich einholen würde.

Es gibt https://github.com/aspnet/Home/issues/2022#issuecomment -299609207

Unser Versprechen lautet im Allgemeinen: Wenn der Typ von .NET Framework und .NET Core gemeinsam genutzt wird, beabsichtigen wir, neu hinzugefügte Member nach .NET Framework zu portieren. In sehr seltenen Fällen ist dies möglicherweise nicht möglich, aber der Grundstein liegt darin, dass sie automatisch berücksichtigt werden.

Aber bis es aufholt, wird ASP.NET zur nächsten .NET Standard-Version übergegangen sein, und es wäre niemals die richtige Version von .NET Framework für ASP.NET; es würde immer hinterher sein.

@markrendle nein, sie sind kein großer Schlammball. Ein großer Mix bedeutet nicht, dass sie schlecht konstruiert sind. sie sind modular. Es ist so, dass viele Module kampferprobter Code sind, der vor langer Zeit von wirklich klugen Leuten geschrieben oder von Drittanbietern gekauft wurde. manches ist von c, manches ist in fortran, manches in c++/cli usw. Um zu migrieren oder neu zu schreiben, müssen wir sie verstehen, Papiere lesen, mehr echte Testdaten sammeln, die neue Version erneut testen. es kostet Mühe, aber solche Aufgaben sind nie budgetiert, sondern uns selbst überlassen. Geschäftsleuten ist es egal, ob wir .net Core verwenden oder nicht, aber sie möchten, dass die Funktionen ausgeführt werden. und für Dritte müssen wir sie drängen oder Ersatz suchen.
In der Praxis kann es also einige Jahre dauern.

@benaadams

Und Sie können System.Web praktisch für immer verwenden; Es ist in Windows eingebrannt, was bedeutet, dass es wahrscheinlich nie verschwinden wird. Sie erhalten nicht viel stabiler und zuverlässiger als das.

ASP.NET Core 1.x -> ASP.NET Core 2.x; Alle APIs sind ziemlich gleich, die Hauptänderung besteht darin, die Unterstützung für .NET Framework einzustellen. Es ändert sich sogar für die Pause 😱
ASP.NET Core 1.x läuft auf .NET Core 2.x und .NET Framework, unterstützt .NET Standard 2.x (über .NET Core 2.x); und hat die gleichen APIs wie ASP.NET Core 2.x. Das ist also die Sprungbrettversion.
ASP.NET Core 2.x ist die Break-Release. Es unterstützt immer noch .NET Standard 2.x (über .NET Core 2.x) und nicht viel api-weise hat sich zwischen ASP.NET Core 1.x und ASP.NET Core 2.x geändert; aber löscht .NET Framework.

Ja, und mal sehen, was die Optionen wirklich sind :) ASPNET Core 1.x ist eine Sackgasse: Sie können dorthin portieren, aber Ihr Code kann nicht auf .net Core verschoben werden, wenn Sie von Bibliotheken abhängen, die heute .net voll sind und möglicherweise nicht nach .net core /standard portiert, wenn der Support endet. Die Wahl von ASP.NET Core 1.x jetzt ist nur dann sinnvoll, wenn Ihre Abhängigkeiten bereits auf netstandard2.0/.netcore liegen, dann können Sie problemlos zu asp.net Core 2.x wechseln, da Sie wissen, dass Sie nicht in eine Sackgasse geraten.

Ihr Vorschlag, system.web als Alternative zu nginx und einem JVM-Stack zu wählen, wenn Sie Stabilität haben möchten, ist ein bisschen schwach, finden Sie nicht? :) Es geht um Optionen für eine große Organisation, was man als Plattform wählen kann. Wenn sie keine App erstellen, die völlig neu ist und nicht mit externen Abhängigkeiten arbeiten muss (selten), werden sie wahrscheinlich auf Nummer sicher gehen, und warum sollten sie nicht? Wenn es dann auf system.web oder JVM/nginx hinausläuft, ist die Wahl ziemlich einfach.

Es sind die kleinen Dinge. Ich habe schon einmal darauf gehämmert: Verschlüsselungsfunktionen von SQL Server-Unternehmen. Sie werden diese nicht auf .net Core verwenden, da sie dort nicht vorhanden sind. Orakel? Nö. Wenn Sie also asp.net core und diese Funktionen verwenden möchten, müssen Sie .net full und asp.net core 1.x verwenden. Aber was passiert, wenn diese Funktionen nicht portiert/verfügbar sind, wenn die Unterstützung für asp.net Core 1.x endet? (und wer will die Farm auf einer Plattform wetten, die sich bereits im 'QFE-Modus' befindet?) Zurück zu system.web?

Es scheint mir, dass ein Teil des Problems darin besteht, dass ASP.NET die Entwicklung von .NET Core direkt vorantreibt. Ich denke, das ist eine interne Sache in Microsoft, aber eigentlich sollten die Plattform und eine bestimmte Bibliothek nicht so eng gekoppelt sein.

Wenn etwas Neues zu einer Version von .NET hinzugefügt werden muss, sollte es allen über einen Netstandard-Bump (mit vNext) zur Verfügung gestellt und dann ASP.NET aktualisiert werden, um es zu verwenden, wenn es veröffentlicht wird. Ich denke, es ist die privilegierte Position von ASP.NET, die dieses Problem verursacht. Dies kann unvermeidlich sein, da die Entwicklergruppen innerhalb von Microsoft dieselben sind ...

Als Autor von HPC-Software, die .NET stark nutzt, haben wir auch unser eigenes Zero-Allocation-Parsing usw. ohne Änderungen an der zugrunde liegenden Plattform implementiert. Würden wir von Span usw. profitieren? Absolut! Können wir zu .NET Core wechseln? Nicht für eine lange Zeit. Wird Span usw. zu .NET Framework hinzugefügt? Scheint jetzt schwer zu sagen, ohne dass es sich um eine Netstandard-Verpflichtung handelt ...

@markrendle Sicher, aber wie sieht unser Übergangsplan aus? Ich kann keinen sehen, der nicht auf nicht unterstützte Pfade trifft. Wenn die Änderungen in netstandard waren und dann von ASP.NET Core verwendet wurden, dann wüssten wir zumindest, dass es irgendwann einen Weg gibt ....

@markrendle Ich bin mir nicht sicher, wer die beabsichtigten Benutzer von asp.net core sind. aber was ich gesehen habe, sind hauptsächlich .net-Benutzer, die viel in .net und eine große Legacy-Codebasis (nicht schlecht) investiert haben. Wenn wir nicht die beabsichtigten Benutzer sind, sehe ich nicht, dass node.js/python/go Jungs .net einen Scheiß geben, egal wie gut wir .net finden.
wenn es nicht für unternehmen, sondern für meine eigenen projekte ist, werde ich nicht asp verwenden, sondern stattdessen nancy verwenden. Unternehmen brauchen stabile Garantien und Unterstützung. und sie/wir zahlen viel Geld dafür.

Die einfache Lösung für dieses Problem wäre, wenn Microsoft eine reine Windows-Distribution von CoreCLR erstellen würde, die die gesamte Bandbreite der .NET Framework-Bibliotheken unterstützt.

Die persönliche Seite in mir ist cool, mit .NET Core auf dem PI auf Ubuntu zu spielen, aber die geschäftliche Seite hat .NET Core nicht einmal in Betracht gezogen, weil .NET Framework alles tut, was wir brauchen, und .NET Core im Vergleich nur Ärger macht. Die meisten dieser Probleme betrafen die Werkzeuge und die Einrichtung aller, sodass diese Probleme endlich verschwinden, aber es fehlen immer noch so viele Funktionen ... EF Core ist nicht einmal annähernd ausgereift genug, um EF6 oder NHibernate zu ersetzen, und sie haben gewonnen läuft auch nicht auf .NET Core 2. Das Fehlen von WCF (Host) für SOAP-Dienste ist eine ziemliche Belastung, da dies das ist, was wir den ganzen Tag in der Geschäftskommunikation tun, aber es könnte wahrscheinlich durch cleveres Design und die Verwendung von .NET Core und .NET Framework in mehreren Apps migriert werden. AppDomains sind auch nicht einfach zu ersetzen, obwohl das das geringste meiner Probleme ist. Der Sprung von ASP.NET MVC 5 zu MVC Core war für eine Neufassung unerwartet einfach, aber der Wechsel zu .NET Core führt dazu, dass VS die Zusammenarbeit einstellt und alle Fehler anzeigt.

Lustige Dinge wie das Hosten von ASP.NET Core in WPF werden ebenfalls unmöglich sein.

Es wäre nicht einmal wichtig, ob die Windows CoreCLR-Distribution Closed Source wäre, da sie sich nicht wesentlich von .NET Framework heute unterscheidet.

Entschuldigen Sie mich jetzt, während ich leise weine und meine experimentellen Zweige lösche, die zu ASP.NET Core migriert wurden.

Ihr Vorschlag, system.web als Alternative zu nginx und einem JVM-Stack zu wählen, wenn Sie Stabilität haben möchten, ist ein bisschen schwach, finden Sie nicht?

Es ist das extreme Ende ;)

Wenn es dann auf system.web oder JVM/nginx hinausläuft, ist die Wahl ziemlich einfach.

Ja, wenn Sie JVM verwenden können, verwenden Sie ASP.NET Core 2, da Sie keine Blocker haben und es eine nette Interop- und p/invoking-Funktion hat :)

Wenn die APIs "ziemlich gleich" sind, warum behalten Sie nicht eine Version mit der Nummerierung 2x für alle, haben aber die Möglichkeit, zwischen "Netstandard" oder "Netcore" zu wählen?

Weil es die Interna sind, die sich ändern; und Nutzung von Änderungen an Laufzeit-, JIT- und Standardbibliotheken. Für einen Benutzer erscheinen sie meistens gleich, da dort die Kompatibilität zwischen ASP.NET 1.x und 2.x besteht; auf der exponierten API-Oberfläche, nicht die Interna "hier ist, wie es gemacht wird".

Es scheint mir, dass ein Teil des Problems darin besteht, dass ASP.NET die Entwicklung von .NET Core direkt vorantreibt.

Genauso wie andere Menschen. Sie können eine API-Anfrage unter dotnet/corefx stellen, wie ich es zum Beispiel für ValueTask getan habe ; das sich dann zu Task-likes entwickelte und jetzt Teil von C # 7 ist.

Sobald Ihre API in .NET Core enthalten ist, können Sie sie verwenden (wenn Sie sich für Nightlies entscheiden und sicherstellen möchten, dass die API richtig ist); oder bei der nächsten Version von coreclr/corefx, wenn Sie 6 Monate durchhalten möchten.

und dann ASP.NET aktualisiert, um es zu verwenden, wenn es veröffentlicht wird.

Jetzt müssen Sie 2 Jahre warten. Das ist nicht wirklich praktisch; da die API durch Gebrauch verfeinert werden muss; und durch den Gebrauch wird mehr Entdeckung geschehen. Das ist so, als ob Sie Ihrem Entwicklungszyklus einen zweijährigen Kompilierschritt hinzufügen würden.

Als Autor von HPC-Software, die .NET stark nutzt, haben wir auch unser eigenes Zero-Allocation-Parsing usw. ohne Änderungen an der zugrunde liegenden Plattform implementiert. Würden wir von Span usw. profitieren? Absolut! Können wir zu .NET Core wechseln? Nicht für eine lange Zeit.

Hängt Ihre HPC-Software direkt an Webanfragen? Vermutlich hat es Warteschlangen, die von Webanfragen gesteuert werden, aber es läuft in einem separaten Prozess, also sollte es von dieser Änderung nicht betroffen sein?

Wird Span usw. zu .NET Framework hinzugefügt?

Jawohl

@benaadams

Aber bis es aufholt, wird ASP.NET zur nächsten .NET Standard-Version übergegangen sein, und es wäre niemals die richtige Version von .NET Framework für ASP.NET; es würde immer hinterher sein.

Was völlig in Ordnung und akzeptabel ist, wenn es mindestens eine Versionsüberschneidung gibt (dh wenn Sie auf dem neuesten vollständigen Framework bleiben, gibt es immer noch mindestens eine offiziell unterstützte (ASP).NET Core-Version, die darauf läuft).

Microsoft würde eine reine Windows-Distribution von CoreCLR erstellen, die die gesamte Bandbreite der .NET Framework-Bibliotheken unterstützt.

Oder eine Reihe von .NET Standard 2.0-Bibliotheken; damit sie auf .NET Core laufen können, das nur auf Windows läuft, das die API-Lücke abdeckt?

@benaadams ja, das ist die Idee, obwohl das nicht für etwas funktioniert, das PlatformNotSupportedException auslöst

@qrli Wenn es modular ist, können Sie die Module aktualisieren, die jetzt aktualisiert werden können, und den Rest für später aufheben.

Es sei denn, Sie meinen mit „modular“ „es ist eine massive monolithische System.Web ASP.NET IIS-Anwendung, die Dutzende verschiedener Bibliotheken umfasst, die über PInvoke und COM zusammenarbeiten“, in diesem Fall ist das ein großer Schlammball.

Gibt es eine abschließende Liste, welche Baugruppen betroffen sind und welche nicht? Es wurde erwähnt, dass Microsoft.Extensions.* sicher ist und Microsoft.AspNetCore.Razor.Runtime (angenommen) auch, weshalb Microsoft.AspNetCore.Html.Abstractions auch auf netstandard bleiben muss. Gibt es noch etwas in den Microsoft.AspNetCore.* , das auf netstandard bleibt?

@bencyoung Mein empfohlener Übergangsplan besteht darin, verschiedene Komponenten im Laufe der Zeit zu eigenständigen Diensten zu migrieren, die auf .NET Core 2.x abzielen (oder was auch immer aus dem gesamten Universum der Entwicklungstools für diese bestimmte Komponente am besten funktioniert), und diese Dienste aus Ihrem Legacy-Code zu verbrauchen eine Standard-API-Grenze mit HTTP oder einem Nachrichtenbus, bis Sie eine geeignete verteilte Systemarchitektur haben.

@markrendle Nicht alles gehört jedoch in ein verteiltes System. Als konkretes Beispiel: Ein großer Teil des Grundes, warum Stack Overflow Seiten so schnell rendert, ist, dass es nicht verteilt wird. Obwohl unsere Netzwerklatenz 0,017 ms beträgt, würde dies unserer Anwendung einiges an Netzwerk-, Serialisierungs-, Deserialisierungs- und GC-Kosten hinzufügen. Das Teilen eines Systems in viele Dienste ist keine universelle Antwort. Es ist eine komplizierte, eine kostspielige und für viele Szenarien auch ein Netto-Negativ. Es kann eine gute Sache sein, aber es kann auch eine überkomplizierte schlechte Sache sein.

@markrendle mein Problem ist nicht die Migration zu Diensten, sondern dass einige der grundlegenden Bausteine ​​der Dienstinfrastruktur APIs verwenden, die nicht auf der Roadmap für netstandard20 oder sogar netstandardbanana stehen. Bei .NET Core geht es uns nicht um Greenfield-Anwendungen, sondern um ganze Greenfield-Systeme. System.DirectoryServices ist ein Beispiel, aber für andere ist es WCF und für noch mehr andere System.Data und das SqlClient-Zeug und für uns System.Messaging .

Ich bin dafür, .NET Core zu verwenden, wenn ich kann. Bisher umfasste das Zero-Client-Projekte, Greenfield oder nicht, sie sind alle wegen irgendetwas blockiert.

@NickCraver Ich möchte nicht scherzhaft sein oder so, und ich weiß, dass der wahre Grund, warum SO-Seiten so schnell gerendert werden, darin besteht, dass Sie und die anderen Leute, die sie erstellen, fantastisch sind, aber die Google-Suchergebnisse, die Links zu Ihren Seiten enthalten werden genauso schnell gerendert wie Ihre Seiten, und Sie _wissen_, dass sie aus einem großen, komplizierten verteilten System stammen. Amazon-Seiten werden ziemlich schnell gerendert, gleicher Deal. Ich bin optimistisch, dass ASP.NET Core auf eine Zukunft zusteuert, in der es verwendet werden kann, um Systeme auf die gleiche Art und Weise zu erstellen, mit der gleichen Leistung, und ich denke, es hat eine bessere Chance, dorthin zu gelangen, wenn es sich davon befreit der Update-Zyklus der Vollversion von .NET, der sich in eine kleine Insel verwandelt.

@jbogard Ich sehe das ähnlich, aber das wird ganz anders sein, wenn .NET Core 2.0 herauskommt.

Seufzen.

@jbogard

netstandardbanane

Zitat aus dem Thread

Das Hauptproblem dabei ist für mich und mein Team, dass es keinen Hinweis darauf gab, dass dieser Weg die beabsichtigte Zukunft war. Ich verstehe, dass niemand die Zukunft kennt, aber höre, dass wir alles, was auf dem vollständigen .net-Framework (Komponentenanbieter-DLLs, Zahlungsdienst-SDKS, HSM-SDKs) beruht, in ihre eigenen Dienste ausbrechen und diesen neuen Hop STINGS einführen müssen. Es ist einfach nicht etwas, was diese Site braucht, und jetzt müssen wir entweder mehr Dev-Ops-Komplexität einführen oder den Web-App-Teil für MVC 5 neu erstellen.

Wir entschieden uns für asp.net core für die Geschwindigkeit von Kestrel und die schicke neue API. Es wäre schön gewesen, die Optionen angesichts unserer Abhängigkeiten genauer gegen das Fehlen eines einfachen Upgrade-Pfads abwägen zu können.

Hinzufügen zu @jabrown85
ASP.NET Core war bisher eine Achterbahn der Gefühle.
Nachdem csproj gelandet war, ging ich schließlich zu "es ist jetzt fertig" und hielt es für ein Kinderspiel, etwas Neues darin zu beginnen und zu prüfen, was aktualisiert werden kann. Nach dieser Ankündigung ist es eher so: „Unterstützt .NET Core das Szenario definitiv oder sollten wir auf Nummer sicher gehen und einfach bei MVC5 bleiben?“

Die Verluste sind bisher gering, nur eine in ASP.NET Core geschriebene Anwendung, die die Verwaltungsaufgaben der primären MVC 5-App verwaltet, aber sie wird für immer auf 1.x hängen bleiben, da die Haupt-App NHibernate verwendet.

@markrendle Computer sagt nein

Es wäre schön, wenn es eine Roadmap für vollständiges .NET -> Netstandard gäbe. Einige der grundlegenden Teile sagen nur "Nicht unterstützt" von ApiPort. Ich werde eine umfassendere Analyse der Clientprojekte auf ASP.NET Core 1.x durchführen, um zu sehen, was fehlt.

aber es wird für immer auf 1.x hängen bleiben, weil die Haupt-App NHibernate verwendet.

Sollte nicht sein, NHibernate ist nicht tot, oder?

@benaadams überraschend nein. Es gibt ein paar Dinge, für die EF6 wirklich kein Äquivalent hat. Wir verwenden standardmäßig EF6, aber es gibt Fälle, in denen wir die NH-Route wählen müssen.

@benaadams offiziell nein, es hat Pausen, in denen es fast tot zu sein scheint, aber normalerweise gibt es alle paar Tage einen Commit. ApiPort meldet 72,26 % Abdeckung für .NET Standard, aber ich bin nicht wirklich davon überzeugt, dass es portiert wird (zumindest in naher Zukunft).

Wenn ich die Kommentare lese, bin ich besorgt über die allgemeine Richtung, in die dieses Projekt geht. Lange Zeit war ASP.NET eine gute Wahl für eine stabile und solide Technologie. Allerdings habe ich jetzt nicht das gleiche Gefühl. Es gibt viele „Move Fast and Break Things“-Technologien, aber das ist eine ganz andere Kategorie.
Ich hoffe, dass Microsoft in der Lage sein wird, diese Bedenken auszuräumen und die Erwartungen aller in Einklang zu bringen.

Es geht nicht um Enterprise vs. Non-Enterprise-Software. Heutzutage werden viele Python 2.x-Anwendungen verwendet, und nicht alle sind "Enterprise". Außerdem verwenden nicht alle neuen Projekte Python 3 (fast 9 Jahre nach der Veröffentlichung von Python 3.0!).

Kann jemand den ganzen Thread in einem Blogbeitrag zusammenfassen?

Ich habe alle über 300 Kommentare während des Pendelns/Mittagessens durchgelesen und … ich scheine immer noch nicht ganz „verstanden“ zu haben.

Was ich bekomme ist:

• Das vollständige .NET Framework wird auf .NET Core 2 nicht unterstützt
• Jede Abhängigkeit hängt von netcoreapp2.0 statt von netstandard2.0 ab
• Wenn ich so etwas wie DirectoryServices oder Drawing möchte, muss ich Full Framework fallen lassen und zu 2.0 springen

Irgendwie habe ich den Rest vermisst... vollen Terminkalender und alles.

@ Maxim Rouiller

Wenn ich so etwas wie DirectoryServices oder Drawing möchte, muss ich Full Framework fallen lassen und zu 2.0 springen

Nein, wenn Sie eine Bibliothek verwenden möchten, die .net Core nicht unterstützt, können Sie AspNet Core 2.0+ überhaupt nicht verwenden.

@MaximRouiller , was sie gerade getan haben, ist, dass Asp.Net-Kernprojekte nicht in der Lage sein werden, auf vollständige Framework-Assemblys zu verweisen, was es für viele, wenn nicht die meisten, unbrauchbar macht. Sie sagen, dass Assemblys wie system.drawing und Directoryservices auf den neuen Netstandar portiert werden oder ich weiß nicht, aber alte Assemblies werden nicht funktionieren, es sei denn, jemand portiert sie, also ist es für viele ziemlich nutzlos, weil einige Assemblies veraltet sind und niemals portiert werden. Zusammenfassend ist festzuhalten, dass jeder, der .net Core mit der Vollversion des .NET-Frameworks verwendet hat, einfach aufgeschmissen wurde und zu MVC 5 zurückkehren muss.

@davidfowl Danke übrigens für diese Liste . Das ist das sehr wichtige "Also, was haben wir davon?" Stück, das die Leute brauchen, um Kosten/Nutzen in ihren Gedanken abzuwägen.

Wenn Sie es noch nicht getan haben, lesen Sie die Liste , damit Sie auf beiden Seiten informiert sind. Ich stehe immer noch zu dem Wunsch, dass 2.x eine Übergangsversion ist (mit berechtigten Vorteilen für das Unternehmen, um den Wechsel tatsächlich zu rechtfertigen) und dass 3.x die Gewinner sind. Auch wenn es 2 Tage später raus kam. Ich schätze die Einblicke auf allen Seiten sehr.

@davidfowl du sagtest:

Bibliotheken können zusätzlich zum Standard geschrieben werden. Wenn Dinge im Standard selbst geändert werden müssen, dauert es viel länger, bis er in allen Implementierungen von .NET übernommen wird, und dazu gehört auch .NET Framework. Es kann ein paar Dinge bedeuten:
.NET Standard wird sich mit der Geschwindigkeit der langsamsten Implementierung weiterentwickeln
.NET Standard wird sich in einem anderen Tempo weiterentwickeln und .NET Framework wird als letztes aufholen.

Aber warum ist das so? Können Sie nicht .NET Standard vNext veröffentlichen und .NET einige Zeit später (einige Monate bis ein Jahr später) nachholen lassen? Das bedeutet, dass Leute, die auf dem neuesten Stand sind und den neuesten ASP.NET Core wollen, in .NET Core hosten können, und Leute, die .NET für ihren Legacy-Code benötigen, können schließlich diese Version von ASP.NET Core verwenden, sobald .NET aufholt auf die verwendete .NET Standard-Version. Ich verstehe nicht, warum .NET Standard so schnell wie die niedrigste Implementierung auf Touren gebracht werden muss.
Auch hier sprechen wir über offizielle Implementierungen des Standards, aber es wird andere Implementierungen geben, die nicht zusammen mit dem Standard aktualisiert werden.
So lassen Sie keine Menschen zurück. Sicher, sie brauchen etwas länger, um von den neuesten Funktionen zu profitieren, wenn sie in .NET sind, aber sie bleiben nicht für immer hängen.

@jdom , weil ich die Geschwindigkeit kenne, mit der sich .NET Framework ändert und warum es langsam sein muss. Es ist eine andere Distribution und vielleicht gibt es dafür nicht genug Wertschätzung. Jede Änderung wird auf Milliarden von Maschinen übertragen. Die Schichtung ist auch völlig anders, also ist es nicht trivial, darüber nachzudenken.

Ich verstehe nicht, warum .NET Standard so schnell wie die niedrigste Implementierung auf Touren gebracht werden muss.

Wenn wir die niedrige Wassermarke für den .net-Standard in ASP.NET Core weiterhin erhöhen, verfehlt dies den Zweck und lässt Sie in der gleichen Situation zurück. Sicher fühlen Sie sich nicht zurückgelassen, weil es ein Versprechen gibt, dass diese APIs eines Tages in .NET Framework eingeführt werden, aber in welchem ​​Zeitraum? .NET 4.7 vervollständigt immer noch nicht die Funktionsparität mit .NET Standard 2.0.

@davidfowl , aber dies wird das gleiche Problem wie bei PCLs zurückbringen, es wird der kleinste gemeinsame Nenner und ein Schmerz in der Verwendung, die Tatsache, dass ASP.NET die Verwendung aufgibt, zeigt dies bereits.

@davidfowl , aber dies wird das gleiche Problem wie bei PCLs zurückbringen, es wird zum kleinsten gemeinsamen Nenner und zu einem Schmerz in der Verwendung.

@Suchiman wie ist das ein Problem? Das einzige Problem mit PCLs war, wie sie dynamisch berechnet und in NuGet dargestellt wurden, was es schwierig machte, vorherzusagen, was Sie bekommen würden. Wie sonst würde netstandard funktionieren, wenn es kein API-Set wäre, das von verschiedenen Implementierungen implementiert werden könnte?

Was die Verwendung von PCLs nervig machte, war die superduper kleine API-Oberfläche. .NET Standard 1.3-1.4 reicht aus, um die meisten grundlegenden Bibliotheken API-weise zu implementieren.

Bei .NET Standard ging es immer um Breite.

Bei ASP.NET Core und .NET Core ging es um einen wettbewerbsfähigen , plattformübergreifenden Server-Stack zum Erstellen leichter Mikrodienste. Der Atem in diesem Sinne war eine breitere Plattformunterstützung (Laufen auf Linux, OSX, Tizen, Pi usw.).

@davidfowl

Wir haben Zeichenfolgen als eines der wichtigsten Dinge identifiziert, die wir in .NET Core angehen möchten. Es gibt unzählige Ideen, aber eine davon ist, dass Zeichenfolge standardmäßig utf8 ist (jede Menge Kompatibilitätsprobleme, aber folgen Sie mir hier).

Eine andere Sache, die wir beheben möchten, ist die Möglichkeit, billige Segmente von Arrays/Strings, jedes Stück zusammenhängenden Speichers, zu nehmen. Wir haben Span hinzugefügtund sehen Buffer anum dies darzustellen. Es könnte bedeuten, dass String und Array neue Schnittstellen implementieren, die es ermöglichen, einen Slice zu nehmen, der eine 0-Zuweisung erfordert.

Es hört sich so an, als ob dies bedeutet, dass, wenn ich diese neuen Bits in einer Bibliothek verwenden möchte, die Bibliothek auch auf netcoreapp2.0 anstelle von netstandard2.0 abzielen muss. Ist das korrekt?

Es ist eine wirklich schlechte Idee, das alte 4.x-Framework nicht mehr zu unterstützen. Die Leute aktualisieren nicht, wenn es viel Arbeit verursacht. Sehen Sie sich den super alten Klassiker ASP an, der seit 2002 veraltet ist - ungefähr 15 Jahre. Und wir haben alte Anwendungen, die noch im klassischen ASP existieren! Möchte Microsoft etwas Ähnliches noch einmal sehen? Die Abschaffung des alten 4.x-Supports ist etwas, das zwingend getan werden muss - aber auf lange Sicht! Nicht jetzt. Dies kann in einigen Jahren eine Option sein, wenn .NET Core der De-facto-Standard ist und nur noch alte Anwendungen das Netz 4.x verwenden.

Die Idee hinter (ASP).NET Core ist wirklich großartig, das Beste, was Microsoft seit der Veröffentlichung von .NET gemacht hat. Aber so ein Chaos trübt dieses schöne Konzept. Außerdem ist es sehr traurig, dass Microsoft so massive Änderungen alleine beschließt, ohne darüber in der Community zu diskutieren! Scheint, als hätte dieses Unternehmen noch nicht vollständig gelernt, wie man mit Open-Source-Projekten umgeht.

@davidfowl

Bei .NET Standard ging es immer um Breite.

Breite an APIs oder Plattformen?

Was ist das Problem bei der Entwicklung .netstandard im gleichen Tempo wie .netcoreapp ?
Ist eine der BCL-Tunings spezifisch für .netcoreapp , weil sie niemals in den anderen Frameworks implementiert werden?

Die Veröffentlichung .netstandard2.1 zur gleichen Zeit wie .netcoreapp2.1 macht keinen Unterschied zur Veröffentlichung von zuerst .netcoreapp2.1 und ein Jahr später .netstandard2.1 zur gleichen Zeit wie .net50 , außer dass Pakete, die auf .netstandard2.1 abzielen, sofort auf .net50 funktionieren würden, aber blockiert werden, wenn sie auf .netcoreapp2.1 abzielen

ASP.NET Core ist ein High-Level-Webapp-Framework, das auf .NET Core aufbaut und in Zukunft auf .NET Core abzielt, _allerdings_ kann es auch ein High-Level-Webapp-Framework sein, das stattdessen auf .NET Standard aufbaut, sodass es darauf abzielt eher eine Referenz-API-Schnittstelle als eine spezifische Implementierung davon.

Die öffentliche Positionierung von .NET Standard ist ein einfaches Ziel, auf das man aufbauen kann, während man die Implementierungsdetails beiseite lässt – mit 2 offiziellen Frameworks direkt von Microsoft, um die meisten Anwendungsfälle abzudecken.

Warum diese Geschichte jetzt ändern? Wenn das .NET Framework nie aufholt, scheint das nebensächlich zu sein. Zumindest besteht die Möglichkeit, dass dies der Fall ist, oder ein anderes Drittanbieter-Framework kann dies tun. Was also, wenn es nur eine einzige Implementierung gibt, die realistischerweise Schritt hält? Genau aus diesem Grund haben wir Schnittstellen in unseren Anwendungen, auch wenn es nur eine einzige konkrete Implementierung gibt, damit wir die Flexibilität und die Vorteile haben, die das bringt.

Vielleicht den Bereich auf ASP.NET Core 2.0 inline mit .NET Standard 2.0 herunterfahren und dann .NET Standard 2.1 für neuere Features verwenden? Fügen Sie einige anständige Support-Zeitpläne hinzu und würde das nicht dieses ganze Dilemma lösen? Microsoft besitzt den .NET Standard und beide Frameworks, daher scheint diese Angst vor inkrementierenden Versionen völlig unbegründet zu sein ...

Ich denke, es sollte berücksichtigt werden, dass ASP.NET zu ASP.NET Core nicht der Migrationspfad für alle ist.

ASP.NET auf dem vollständigen Framework wird bleiben und Funktionen erhalten, aber nicht wie Core.

Die Migration wird im Laufe der Zeit einfacher, aber nie zu 100 % übereinstimmen.

Die Leute führen immer noch klassisches ASP aus. Das ist auch in Ordnung für sie.

@davidfowl Ich habe großen Respekt vor dem gesamten Team und den Fortschritten, die Sie alle machen. Also, bitte nehmen Sie das nicht als herablassend auf das, was passiert. Ihr seid Pioniere und wir alle betrachten euch als Vorbilder dafür, wie man die Dinge richtig macht. Aber ich sehe viele dieser Punkte nicht als unmittelbare Probleme bei der Zieländerung, besonders wenn es nicht kommuniziert wurde. Vielleicht bin ich falsch.

Ich möchte hier ein paar verrückte Sachen rauswerfen, weil es ein paar Mal erwähnt wurde. Was ich gleich sagen werde, hat keinen Einfluss darauf, was passieren wird, es ist an dieser Stelle alles Spekulation. Mehrere Leute haben gefragt, warum wir auf .NET Core statt auf .NET Standard abzielen wollen.

• Wir haben Zeichenfolgen als eines der wichtigsten Dinge identifiziert, die wir in .NET Core angehen möchten. Es gibt unzählige Ideen, aber eine davon ist, dass Zeichenfolge standardmäßig utf8 ist (jede Menge Kompatibilitätsprobleme, aber folgen Sie mir hier).

Dieser Punkt hier wäre definitiv ein Game Changer, aber meiner Meinung nach ist es der einzige, der absolut kein Targeting-Framework erfordert, und es ist sowieso nicht für netcoreapp20.

• Eine andere Sache, die wir beheben möchten, ist die Möglichkeit, billige Segmente von Arrays/Strings, jedes Stück zusammenhängenden Speichers, zu nehmen. Wir haben Span hinzugefügtund sehen Buffer anum dies darzustellen. Es könnte bedeuten, dass String und Array neue Schnittstellen implementieren, die es ermöglichen, einen Slice zu nehmen, der eine 0-Zuweisung erfordert.
• Dies führt zu neuen Methoden für String, die eine Aufteilung ermöglichen, bei der nicht jedes Mal ein Array zugewiesen wird.
• Dies führt zu Überladungen von Int, UInt usw. (TryParse), die Span einnehmenund Span.
• Dies führt zu neuen Codierungsroutinen, die Span nehmen.
• Pufferund SpanDamit können Sie Speicher auf einheitliche Weise darstellen, und wir möchten den Netzwerkstapel aktualisieren, um das Übergeben von vorab fixierten Puffern zu ermöglichen, die Span benötigenoder Puffer.

All dies ist immer noch als Pakete über dem aktuellen Netzstandard implementierbar. Dazu brauchen Sie nicht einmal netstandard20. Ich verstehe, dass ich dieses Gepäck nicht herumtragen möchte, aber der Rest von uns draußen in der Nicht-MS-Welt muss ständig benutzerdefinierte BCL-ähnliche Impls erstellen, wenn der Anwendungsfall oder die Leistung nicht passt. Ganz zu schweigen davon, dass die Span-API auch nicht für 2.0 vorgesehen ist (es sei denn, das wird wieder geändert).

Kestrel wird HTTP2 im 2.x-Zeitrahmen implementieren (derzeit auf 2.1 ausgerichtet) und das erfordert neue APIs im SSL-Stream, um ALPN auszuführen (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http-Client auf .NET Core unterstützt Duplex-Streaming, wodurch es möglich wird, Streaming-Endpunkte über http in Signalr über eine einzige HTTP-Anforderung ohne Websocket zu implementieren.

Ich habe das Gefühl, dass dieser etwas kniffliger ist, aber nicht allzu anders als Kestrel, der libuv herumträgt. Die CURL-Implementierung von .Net Core kann einfach in ein Netstandard-Erweiterungspaket gezogen werden, bis alle aufholen.

• Wir haben die Header-Parser-Implementierungen von HttpClient und System.Net.Http gegabelt und umbenannt (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers), damit wir sie verbessern konnten und lassen Sie sie sowohl .NET Framework als auch .NET Core unterstützen. .NET Core hat eine Kopie dieser Verbesserungen, die es nicht zurück geschafft hat, weil sie nicht verbessert werden mussten (wir konnten sie nicht nutzen).

Richtig, aber das ist in diesem Fall wohl der richtige Weg. Es ist frustrierend zu warten und an den Implementierungen festzuhalten, aber auch hier sehe ich keinen Unterschied zu dem, was andere tun, wenn sie ein Framework oder eine Bibliothek schreiben.

• Ohne die Fähigkeit, die Kernprimitiven auf Touren zu bringen, werden wir ermutigt, sie zu forken und Dinge zu erschaffen, die wie sie aussehen, es aber nicht sind. Aus diesem Grund haben wir unsere eigene kleine BCL in ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Nochmals, genau wie der Rest von uns.

Bei ASP.NET Core und .NET Core ging es um einen wettbewerbsfähigen, plattformübergreifenden Server-Stack zum Erstellen leichter Mikrodienste.

ASP.Net Core hatte solche Nachrichten. .Net Core wurde vom ersten Tag an als voll funktionsfähige xplat-serverseitige .Net-Framework-Teilmenge gemeldet. Ich habe noch nie jemanden sagen hören, dass .Net Core nur für Microservices ist. Ich habe gehört, dass Sie es mit ASP.Net Core verwenden können, wenn Sie möchten, aber auch Konsolen-Apps, Datenanalyse, DB-Dienste usw. Ist die Ausrichtung von .Net Core effektiv „das, was das ASP.Net Core-Team am meisten will“?

ASP.NET auf dem vollständigen Framework wird bleiben und Funktionen erhalten, aber nicht wie Core.

Wird es? Ich habe noch niemanden von MS gesehen, der bestätigt, dass noch daran gearbeitet wird. Mein Bauchgefühl sagt, dass es nicht so ist. Ich verstehe es. Das Team braucht einen Moment der Art „Move it or lose it“, um sich zu befreien. Ich glaube nur nicht, dass dies noch der Moment ist.

Angenommen, wir haben eine Business-Logik-4.6-Assembly, die den Oracle.Net-Treiber, NHibernate und RabbitMQ (alle in 4.6) verwendet. Die Schnittstelle mit ASP.Net besteht nur über unsere Geschäftsobjekte, Anforderungen und Antworten. Können wir auf diese Assembly in unserem ASP.Net Core 2 verweisen, ohne sie neu zu kompilieren?

Meine kurze Zusammenfassung

@ stefan2410 kurze Antwort, nein, Sie können nicht auf das vollständige Framewrok verweisen, Sie können auf diese Assemblys nur verweisen, wenn sie für Netstandar 2.0 erstellt wurden.

@mattnischan

All dies ist immer noch als Pakete über dem aktuellen Netzstandard implementierbar. Dazu brauchen Sie nicht einmal netstandard20. Ich verstehe, dass ich dieses Gepäck nicht herumtragen möchte, aber der Rest von uns draußen in der Nicht-MS-Welt muss ständig benutzerdefinierte BCL-ähnliche Impls erstellen, wenn der Anwendungsfall oder die Leistung nicht passt.

Es tut mir leid, aber das ist es wirklich nicht. Sie können Patch-Typen nicht affen. Es sei denn, Sie schlagen vor, dass wir neue Typen hinzufügen und die vorhandenen nicht ändern.

Ganz zu schweigen davon, dass die Span-API auch nicht für 2.0 vorgesehen ist (es sei denn, das wird wieder geändert).

Span existiert in 2.0 als Implementierung, aber nicht als öffentliche API. Wir nehmen Breaking Changes in neuen Majors vor, damit wir mehr Features in Minor-Versionen machen können. Wenn ASP.NET Core 2.1 auf .NET Standard 2.1 abzielt, wird die .NET Framework-Unterstützung wieder eingestellt.

Ich habe das Gefühl, dass dieser etwas kniffliger ist, aber nicht allzu anders als Kestrel, der libuv herumträgt. Die CURL-Implementierung von .Net Core kann einfach in ein Netstandard-Erweiterungspaket gezogen werden, bis alle aufholen.

Sie sagen also, wir sollten alle Klassen in der BCL umbenennen, damit wir sie auf beiden .NET-Standards verwenden können.

Ich habe noch nie jemanden sagen hören, dass .Net Core nur für Microservices ist. Ich habe gehört, dass Sie es mit ASP.Net Core verwenden können, wenn Sie möchten, aber auch Konsolen-Apps, Datenanalyse, DB-Dienste usw. Ist die Ausrichtung von .Net Core effektiv „das, was das ASP.Net Core-Team am meisten will“?

Nein, .NET Core ist ein Allzweck-Framework, das ursprünglich keine Branchen im Kern hatte. Es ist möglich, dass ASP.NET Core nur eine vertikale Stelle anstelle von Bibliotheken auf .NET Core sein sollte, es hätte möglicherweise einen Teil dieser Verwirrung vermieden.

Wird es? Ich habe noch niemanden von MS gesehen, der bestätigt, dass noch daran gearbeitet wird. Mein Bauchgefühl sagt, dass es nicht so ist. Ich verstehe es. Das Team braucht einen Moment der Art „Move it or lose it“, um sich zu befreien. Ich glaube nur nicht, dass dies noch der Moment ist.

Ja, die HTTP/2-Unterstützung wurde in der letzten Version hinzugefügt. Es gibt ein anderes Team, das an ASP.NET und IIS arbeitet und Verbesserungen vornimmt. Sie sind jedoch nicht in derselben Größenordnung wie ASP.NET Core.

Ich habe diesbezüglich keine sehr starken Gefühle, da ich es vermieden habe, meine ASP.NET Core-Dienste wie die Pest auf dem vollständigen Framework auszuführen. Abgesehen davon musste ich vermeiden, einige schöne und ausgereifte Bibliotheken zu verwenden, da sie .NET Standard nicht unterstützten, weil sie entweder auf netstandard2.0 warteten oder einfach nicht wollten.

Meine Befürchtung ist, dass das Entfernen der Möglichkeit, ASP.NET Core auf dem vollständigen Framework auszuführen, Benutzer davon abhalten wird, ihre aktuellen MVC 5/Web API 2-Apps auf ASP.NET Core zu portieren, was nur einen weiteren Grund für Bibliotheksautoren darstellt, die Portierung auf .NET zu vermeiden Standard. Warum sollten Sie sich die Mühe machen, ein Upgrade durchzuführen, wenn keiner Ihrer Benutzer davon profitiert? Es wird zu einem Henne-Ei-Problem und ich habe nur Angst, dass dies dem Ökosystem als Ganzes schaden wird, gerade als es anfing, etwas Zugkraft zu bekommen. Zuerst brauchen Sie ASP.NET Core-Benutzer, und ich bin nicht davon überzeugt, dass es so viele davon gibt, wie wir alle möchten. Hoffentlich liege ich falsch.

Wenn ASP.NET Core 2.1 auf .NET Standard 2.1 abzielt, wird die .NET Framework-Unterstützung wieder eingestellt.

Nein, es bedeutet nur, dass Net Framework ASP.NET Core 2.1 automatisch unterstützt, sobald es .NET Standard 2.1 unterstützt, wann immer das der Fall ist, selbst wenn es ein oder zwei Jahre dauert.

Dasselbe gilt für alle anderen .NET-Standard-kompatiblen Plattformen (Xamarin / Unity / ...).

Auf .NET Standard aufzubauen bedeutet, dass andere Plattformen _irgendwann_ aufleuchten werden, auf .NET Core aufbauen bedeutet, dass sie __nie__ aufleuchten werden.

Ich nehme an, dass nach wie vor geplant ist, dass full-fx netstandard einholt, wenn auch mit großer Verzögerung?
(und wenn von keiner anderen Plattform außer NET Core erwartet wird, dass sie .NET Standard 2.1 implementiert, warum sollte man dann überhaupt einen .NET Standard haben?)

Es tut mir leid, aber das ist es wirklich nicht. Sie können Patch-Typen nicht affen. Es sei denn, Sie schlagen vor, dass wir neue Typen hinzufügen und die vorhandenen nicht ändern.

Letzteres wurde in 1.x in den meisten Fällen bereits erledigt, oder? Ist das plötzlich nicht mehr haltbar?

Span existiert in 2.0 als Implementierung, aber nicht als öffentliche API. Wir nehmen Breaking Changes in neuen Majors vor, damit wir mehr Features in Minor-Versionen machen können. Wenn ASP.NET Core 2.1 auf .NET Standard 2.1 abzielt, wird die .NET Framework-Unterstützung wieder eingestellt.

Warum sollte es fallen gelassen werden? Wollen Sie damit sagen, dass Span auf Framework _nie_ existieren wird?

Sie sagen also, wir sollten alle Klassen in der BCL umbenennen, damit wir sie auf beiden .NET-Standards verwenden können.

Boah, nein. Ich sage, wenn ich ein Wörterbuch mit einer anderen API benötige, muss ich etwas anderes erstellen und es auch nicht System.Collections.Generic.Dictionary nennen, so wie Sie es bereits mit Microsoft.Net getan haben.*

Ja, die HTTP/2-Unterstützung wurde in der letzten Version hinzugefügt. Es gibt ein anderes Team, das an ASP.NET und IIS arbeitet und Verbesserungen vornimmt. Sie sind jedoch nicht in derselben Größenordnung wie ASP.NET Core.

Das ist fair. Das war mir nicht bewusst.

Letzteres wurde in 1.x in den meisten Fällen bereits erledigt, oder? Ist das plötzlich nicht mehr haltbar?

Es schafft ein Durcheinander. Sie haben versucht, das so wenig wie möglich zu tun. Das API-Design und die Bereitstellung sind so drastisch komplizierter, als die meisten Leute glauben, denke ich. Und es sind nicht die Microsoft-Leute, die es so machen, es ist die Realität, viele Plattformen und Zeitpläne zu unterstützen. Ich habe das erst gewürdigt, als ich mehrere Male mittendrin war und alles durchsprach. Ich wünschte wirklich, die Typweiterleitung wäre auf Methodenebene. Das hätte schon einige Fälle lösen können :(

Warum sollte es fallen gelassen werden? Wollen Sie damit sagen, dass Span niemals auf Framework existieren wird?

Es müsste aus ASP.NET Core 2.0 entfernt werden, da die Zeitachsen nicht mehr ausgerichtet würden, da das vollständige Framework es noch nicht hätte.

Es müsste aus ASP.NET Core 2.0 gelöscht werden, da die Zeitachsen nicht mehr ausgerichtet würden, da das vollständige Framework es noch nicht hätte.

AFAIK, Spans sind Teil eines netstandard1.x -Pakets, das auf .NET Desktop verwendet werden kann (es ist eine portable Implementierung, daher hat sie nicht den gleichen Leistungsschub, als ob sie in die CLR gesichert wäre, aber es ist wahrscheinlich gut genug).

Bearbeiten: Das System.Memory -Paket hat ein netstandard1.0 -TFM, sodass es sogar unter .NET 4.5 verwendet werden kann.

Letzteres wurde in 1.x in den meisten Fällen bereits erledigt, oder? Ist das plötzlich nicht mehr haltbar?

Aus diesem Grund stellen wir heute die Feature-Arbeit in bestimmte Richtungen ein. Es ist beabsichtigt und wir halten uns zurück und weigern uns, neue APIs zu verwenden, indem wir Dinge außerhalb von .NET Standard kopieren und neu implementieren, damit .NET Framework funktionieren kann. Das ist noch nicht alles, aber es gibt einige grundlegende Teile, die wir in Zukunft ansprechen möchten, schließlich kontrollieren wir (Microsoft) beide Seiten.

Warum sollte es fallen gelassen werden? Wollen Sie damit sagen, dass Span niemals auf Framework existieren wird?

Span selbst hat eine portable Version, die überall ausgeführt werden kann. Ich bin mir nicht sicher, ob die schnelle Implementierung jemals auf .NET Framework erfolgen wird. Die APIs, die zu .NET Framework hinzugefügt werden und Span nutzen, können viel länger dauern als Span selbst, es ist umfangreich. Wann haben wir das letzte Mal String und Array in .NET Framework geändert?

Boah, nein. Ich sage, wenn ich ein Wörterbuch mit einer anderen API benötige, muss ich etwas anderes erstellen und es auch nicht System.Collections.Generic.Dictionary nennen, so wie Sie es bereits mit Microsoft.Net getan haben.*

Genau das schlagen Sie vor. Wir möchten kein Microsoft.Extensions.Collections.Generic haben. Wir versuchen das Beste, um das zu vermeiden, und wir leben wo möglich mit den alten APIs und Polyfill (https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs). Dies ist nicht nachhaltig und bedeutet, dass .NET Core nicht von den Vorteilen profitiert, da wir die Verwendung aktiv vermeiden.

@PinpointTownes mit Spans ist nicht gut genug, sie müssen sie in Methodenaufrufen für vorhandene Typen verwenden. An diesem Punkt kommt die Weiterleitung auf Klassenebene ins Spiel und verursacht viele Probleme.

@ 0x53A

Das ist fair. Können Sie mir sagen, warum beliebte Bibliotheken auf NuGet die Unterstützung für ältere .NET Framework-Versionen, die eindeutig nicht mehr unterstützt werden, nicht einstellen? Die beliebtesten Bibliotheken zielen auf net20, net35, net40 usw. ab. Warum sollte es plötzlich in Ordnung sein, die höchste Version von .NET Framework zu verlangen, um weiterhin ASP.NET Core zu verwenden? Meint ihr das wäre sinnvoll?

Dies ist ein Show-Stopper. Ich muss erwägen, Migrationen von ASP.NET MVC 5/Web Api 2 zu Core abzubrechen. Viele stabile Frameworks sind noch nicht für Core verfügbar. Wir verwenden immer noch EF6.x , weil EF Core noch nicht ausgereift genug ist Funktionsvergleich .

@PinpointTownes mit Spans ist nicht gut genug, sie müssen sie in Methodenaufrufen für vorhandene Typen verwenden.

"brauchen" ist wohl etwas übertrieben. Spans werden hauptsächlich für die Leistung verwendet, daher hindert sie nichts daran, die vorhandenen not-super-perfy-Überladungen auf .NET Desktop mithilfe von ifdefs zu verwenden, bis .NET Desktop native Unterstützung für Spans erhält.

@davidfowl Ich denke, das große Problem ist emotional. Wenn Sie auf netstandard abzielen, weiß ich, dass ich irgendwann von 1.x auf 2.x upgraden kann (wenn auch mit einer Verzögerung). Meistens ist das Aktualisieren von netfx für eine Anwendung keine so große Sache (anders für eine Bibliothek).

Aber einige Apps werden nie in der Lage sein, den Sprung netfx -> netcore zu schaffen. Wenn Sie also auf netcore abzielen, wissen sie, dass sie mit 1.x in einer Sackgasse stecken.

In dieser Hinsicht wäre es besser gewesen, wenn der Asp.net-Kern nie auf netfx gelaufen wäre, so wie es aussieht, sie erwarteten, dass dies so bleibt, und fühlen sich jetzt (zu Recht, meiner Meinung nach) betrogen. Schließlich haben sie dafür vielleicht schon viel Zeit investiert.

Ich bin nicht persönlich daran beteiligt, weil ich kein asp.net-Benutzer bin, meine große Frage ist eigentlich nur

Ich nehme an, dass nach wie vor geplant ist, dass full-fx netstandard einholt, wenn auch mit großer Verzögerung?
(und wenn von keiner anderen Plattform außer NET Core erwartet wird, dass sie .NET Standard 2.1 implementiert, warum sollte man dann überhaupt einen .NET Standard haben?)

In Bezug auf andere Bibliotheken, die auf net20, net35 usw. abzielen, versuchen meiner Erfahrung nach die meisten Autoren, auf die niedrigste Version abzuzielen, die sie können, und schneiden nur Plattformen ab, auf denen sie keine andere Wahl haben.

Und __ja, ich denke, es ist vernünftig, die Unterstützung für ältere Versionen von .NET Framework__ einzustellen, weil es immer noch einen klaren Migrationspfad gibt. Aktualisieren Sie einfach Ihre Version. Meistens müssen Sie nicht einmal etwas ändern, sondern "nur" neu kompilieren und testen.

Ich denke, Sie unterschätzen ernsthaft die Anzahl der Apps, die niemals auf Netcore abzielen können - nur eine einzige Closed-Source-Abhängigkeit von Drittanbietern reicht aus, um dies zu blockieren.

Span selbst hat eine portable Version, die überall ausgeführt werden kann. Ich bin mir nicht sicher, ob die schnelle Implementierung jemals auf .NET Framework erfolgen wird. Die APIs, die zu .NET Framework hinzugefügt werden und Span nutzen, können viel länger dauern als Span selbst, es ist umfangreich. Wann haben wir das letzte Mal String und Array in .NET Framework geändert?

@davidfowl Ich denke, das ist vielleicht ein Teil des Problems. Ich habe hier ehrlich gesagt ein bisschen den Advokaten des Teufels gespielt, weil wir als Greenfield-App, die kurz vor der Einführung von .Net Core gestartet wurde, in der Mitte stecken, also spannen wir die Linie.

Unser Gedanke war schon immer, verwenden Sie die schicken neuen Bibliotheken (wie Kestrel), wenn es irgendwie möglich ist, aber warten Sie, bis sich .Net Core stabilisiert hat (und ich bin froh, dass wir das getan haben, wenn auch nur wegen der Werkzeugänderungen), _oder_ warten Sie auf die coole Core-Bits, um es zurück zum Framework zu schaffen. Ich denke, die meisten Leute sind davon ausgegangen, dass die meisten, wenn nicht alle Fortschritte, die Corefx gemacht hat, es in Framework vNext oder vNext+1 schaffen würden. Aber es sieht (aus unserer Sicht von 30.000 Fuß) aus dieser und anderen Änderungen so aus, dass Framework keine Plattform der Zukunft ist.

Ich denke, wenn es so ist, dann ist es so. Unser Projekt ist riesig, also vertrauen Sie mir, wenn ich sage, dass ich den Schmerz verstehe, einen Haufen benutzerdefinierter Impls von Dingen zu haben, die nahe, aber nicht ganz BCL-Typen oder Ifdef-Spaghetti sind. Also schlage ich nichts aus Unkenntnis der Komplikationen vor. Es gibt definitiv Kompromisse.

In der Tat eine gute Frage: Was bleibt von der Rückportierung von .net-Kernfunktionen auf .NET full? Wie ich hier gelesen habe, ist .NET full so spröde, dass das Verschieben von Code ewig dauert (es bewegt sich sehr langsam) und kann jeden Moment brechen (könnte sein, keine Ahnung, wie verflochten es ist), also schließe ich daraus, dass das nicht passieren wird sehr oft.

Es kann nicht beides sein: Entweder ist die Rückportierung auf .NET full in Ordnung, sie veröffentlichen nur seltener (z. B. alle 6 Monate bis zu einem Jahr) oder es ist sehr kompliziert und fehleranfällig. Wenn es ersteres ist, beschleunigen Sie einfach das Tempo und lassen Sie Ihre Benutzer nicht die Rechnung bezahlen und hören Sie auf, letzteres als Ausrede zu verwenden. Wenn letzteres der Fall ist, ist dann nicht die richtige Schlussfolgerung, dass netstandard ein Trugschluss ist, da für die Zukunft ohnehin nur die API von .netcore zählt?

Ich mache mir ernsthaft Sorgen um die Zukunft von .NET. Mein Unternehmen erstellt Tools für .NET Full und .NET Standard1.6. Das Letzte, was wir wollen, ist, dass die treibende Kraft der Richtung von .NET (die neuen Funktionen, die bald auf .NET full zurückportiert werden, wie in der .NET-Core-Ankündigung vor all diesen Monden gesagt wurde) die Dinge und das Ökosystem effektiv spaltet wird in zwei Hälften gespalten, da Fragmentierung tödlich ist.

Nichts in diesem Thread hat mich beruhigt, dass die Dinge für die Zukunft von _all_ .NET und dem Ökosystem, das benötigt wird, um es am Leben zu erhalten, in Ordnung sind: Ich sehe nur zwei Gruppen:

• Menschen, die befürchten, dass die Optionen kompliziert werden, und sie haben ein schwieriges Problem vor sich
• Microsoft, der einen Weg vor sich sieht: den .net-Core-Weg.

Diese beiden passen im Moment nicht zusammen. Kann jemand von Microsoft bitte eine kohärente Geschichte herausbringen, damit wir alle sehen können, was wirklich los ist, wie die Dinge wirklich sind, dh mit der Rückportierung von Funktionen nach .net full, was mit den fehlenden Myriaden von Dingen im .net-Kern getan wird (Sqlserver-Zeug, Transaktionsumfang, um nur einige zu nennen) und wie Microsoft glaubt, dass sie diese neue Richtung als solide, zuverlässige und verlässliche Plattform für die Zukunft verkaufen können, damit Unternehmen und große Teams sie ohne Bedenken wählen können.

Obwohl ich zustimme, dass all dies auf lange Sicht eine gute Sache ist, denke ich auch, dass es zu früh ist, die Unterstützung für das vollständige Framework mit 2.0 einzustellen.

Wir würden gerne so schnell wie möglich auf .NET Core umsteigen, aber leider sind unsere größten Blocker im Moment fast ausschließlich Microsoft-Bibliotheken (z. B. ist Entity Framework Core noch nicht gut genug, Azure Service Bus hat nur eine sehr frühe Vorschau).

Obwohl ich hoffe, dass die Azure-Bibliotheken in den nächsten Wochen/Monaten fertig sein werden, scheint es nicht so, als würde EF Core in absehbarer Zeit über genügend Funktionen verfügen.

Ich weiß nichts über die Interna von EF6, aber wäre es nicht mit vertretbarem Aufwand möglich, es auf netstandard abzuzielen? Dies würde einen großen Blocker entfernen ...

"Einfach auf 1.x zu bleiben" scheint keine gute Alternative zu sein, da es sicherlich viele Bibliotheken geben wird, die sich nicht darum kümmern (oder nicht über die Ressourcen/das Wissen verfügen, um beides zu unterstützen) und einfach ihre Abhängigkeit aktualisieren 2.0

PS: Ich bin sehr frustriert darüber, wie komplex das .NET-Ökosystem in den letzten Jahren geworden ist. Ich musste VIEL Zeit aufwenden, um all die neuen Dinge zu verstehen, und ich verstehe nicht, wie ein neuer Entwickler irgendetwas davon verstehen sollte. Aufgrund all dieser ziemlich extremen Breaking Changes gibt es jetzt sooo viele veraltete Informationen im Internet.
Auch die vielen unterschiedlichen Produktversionen (.net core, sdk, .net standard, ...) sind extrem unübersichtlich. Ich habe noch niemanden gesehen, der die .NET-Standardtabelle versteht, ohne eine 20-minütige Erklärung zu benötigen. 😞

Jeder, der .net Core mit der Vollversion des .NET-Frameworks verwendet hat, wurde einfach verarscht und muss zu MVC 5 zurückkehren

Ja. Ich verstehe die Argumentation, und ich nehme an, ich könnte sagen, ich hätte das kommen sehen sollen, aber es ist sehr frustrierend, dass dies ohne Vorwarnung über uns hereingebrochen ist.

Wir haben ein Anwendungsökosystem, wie viele andere, mit gemeinsam genutzten Bibliotheken, die ein Jahrzehnt und mehr zurückreichen, mehrere MVC 3-, 4-, 5-Apps, Konsolen-Apps, Windows-Dienste und Hunderttausende von Codezeilen. Wir sind nicht einmal in einer so schlechten Situation, um im Vergleich zu einigen anderen aufzurüsten.

Wir haben kürzlich ein paar neue Web-Apps mit ASP.Net Core 1.1 entwickelt, die notwendigerweise auf das vollständige 4.6.2-Framework abzielen. Diese Apps verwenden große Schwaden unserer bestehenden gemeinsam genutzten Bibliotheken. Wir haben eine peinliche Menge an Entwicklungszeit damit verbracht, uns mit project.json und dann mit der neuen .csproj-Datei zu beschäftigen und zu versuchen, alte und neue .csproj-Dateien in derselben Lösung zu mischen, und sind auf VS15 zurückgefallen, um Dinge mit alten .csproj-Typen zu erledigen, die kaputt sind System. Abhängigkeiten und eine Litanei von Assembly-Bindungsproblemen, Erstellungs- und Veröffentlichungsproblemen ... die Liste geht weiter und weiter.

Und jetzt hängen wir hoch und trocken in einer Sackgasse. Werfen wir ein paar Mannmonate der Entwicklung weg oder verbringen wir viele Male damit, zuerst nur festzustellen, was funktionieren könnte und was nicht, und dann herauszufinden, wie man ein Upgrade durchführen kann, und wenn das überhaupt möglich ist, tun wir es?

Ich kann nicht sagen, dass ich mit der Richtung und Notwendigkeit nicht einverstanden bin, aber eine frühere Kommunikation wäre wünschenswert gewesen.

Oh, und natürlich laufen die Azure Service Fabric-Bibliotheken auch nicht auf .NET Core – was für uns ein weiterer Blocker ist.

Ich würde sagen, Sie sollten das vollständige .NET-Framework unterstützen, bis Sie eine richtige .NET-Kerngeschichte innerhalb von Microsoft (und insbesondere Azure) liefern können.

@cwe1ss Diese Änderung wird jedoch einen Teil der Komplexität des .NET-Ökosystems verringern. Da Sie nicht zwei verschiedene Formate haben werden (ASP.NET Core + .NET Full und ASP.NET + .NET Core). Ich stimme den veralteten Informationen vollkommen zu, aber ich denke, das lässt sich nicht vermeiden, wenn Sie offen entwickeln, wie es Microsoft jetzt tut.

@davidfowl

Die Code-Sharing-Story über verschiedene .NET-Laufzeiten hinweg ist .NET Standard. Ihre Bibliotheken sollten versuchen, dies auf Code abzuzielen, der von .NET Core und .NET Framework gemeinsam genutzt wird.<

Aber das vollständige Framework, wie ich es verstehe, unterstützt nicht einmal den.net-Standard, also ist es wirklich kein nützlicher Standard.

Microsoft scheint die Wichtigkeit der Abwärtskompatibilität vergessen zu haben.<<

Das Problem ist, dass ASP.NET Core nie abwärtskompatibel sein sollte ... Deshalb gab es einen so großen Paradigmenwechsel von ASP.NET 4.x. Scheint so, als ob die Abwärtskompatibilität das wichtigste Bit für Sie wäre, ASP.NET 4.x auf .NET Framework zu verwenden. Das wird auf absehbare Zeit unterstützt und wird mit Sicherheitspatches versehen, solange Windows existiert.<

Sicherheitspatches sind nur ein Teil des Problems. Die Webstandards ändern sich so schnell, dass wir etwas haben müssen, mit dem wir die neuesten Standards verwenden können. So habe ich zum Beispiel irgendwo oben etwas über HTTPS v2 gesehen. Ich habe keine Ahnung, was das in der Praxis bedeutet, aber der Punkt ist, dass ich möchte, dass mein Framework diese Dinge unterstützen kann. Wenn ich gezwungen bin, bei einer älteren Version des Frameworks zu bleiben, egal ob es sich um v4 oder v1 handelt, werden die erforderlichen Dinge nicht unterstützt.

ASP .net Core wurde immer so vermarktet, dass es sowohl auf .net Core als auch auf dem Framework läuft. Wie andere gesagt haben, stört es mich nicht, wenn wir sechs Monate oder ein Jahr warten müssen, bis der Rahmen aufholt. Ich bin normalerweise sowieso ungefähr sechs Monate oder mehr im Rückstand. Was jedoch zu passieren scheint, ist, dass unsere bestehenden Investitionen vollständig aufgegeben werden, wie so viele andere Microsoft-Technologien, in die viele von uns Zeit investiert haben.

Stefan

@Rutix für „offenes Entwickeln“ wurde diese wichtige bahnbrechende Änderung überraschend leise ohne Ankündigung oder Umfrage durchgeführt (schließlich wurde dieses Problem von einem Community-Mitglied erstellt, das Pull-Anforderungen beobachtete).

Dinge im Stillen zu tun, hat Microsoft in der Vergangenheit gebissen, und sie scheinen nicht zu lernen. Und versuchen Sie nicht einmal, mir zu sagen, dass sie nicht sehen konnten, dass die Einstellung der vollständigen Framework-Unterstützung die Community stören und das Vertrauen und die Investition in die Plattform verletzen würde.

Der letzte Vorfall war https://github.com/dotnet/roslyn/issues/17054 , aber sie haben ihn schnell korrigiert, ich frage mich, wie das weitergehen wird.

Aber das vollständige Framework, wie ich es verstehe, unterstützt nicht einmal den.net-Standard, also ist es wirklich kein nützlicher Standard.

@stefanolson Das ist nicht richtig. Bibliotheken, die auf .Net Standard 1.x abzielen, können heute auf verschiedenen vollständigen Framework-Versionen ausgeführt werden. Bibliotheken, die auf .Net Standard 2.0 abzielen, sollen in der Lage sein, auf 4.6.1 ausgeführt zu werden, als ich zuletzt nachgesehen habe.

@Suchiman Da stimme ich dir voll und ganz zu. Ich bin ein bisschen enttäuscht, dass sie nicht zu lernen scheinen, wie man kommuniziert und Bomben auf die Community abwirft. Sie hätten damit besser umgehen können, wenn sie es zuerst angekündigt und eine Community-Diskussion geführt hätten.

Aber das vollständige Framework, wie ich es verstehe, unterstützt nicht einmal den.net-Standard, also ist es wirklich kein nützlicher Standard.

@stefanolson Das tut es. Unterschiedliche (vorhandene) Versionen von .NET Framework implementieren unterschiedliche Versionen des .NET-Standards. Siehe https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

Ich weiß, dass ich mit diesem Thread etwas spät dran bin, aber hier sind zwei unserer Anwendungsfälle für die Verwendung von ASP.NET Core auf NetFX unter Windows:

Verwenden von ASP.NET zum Hosten einer REST-API für Ihre Anwendung

Unsere Anwendung ist eine Art Anwendung, die von einer .NET-API in eine REST-API umgewandelt wurde. Es wurde zuerst als .NET-API ausgeliefert und hat Abhängigkeiten zu allen Arten von Windows-Zeug.

Als wir eine REST-API hinzugefügt haben, haben wir die ASP.NET-Web-API ausgewählt, um sie zu hosten. Als klar wurde, dass die Web-API in ASP.NET vNext/5/Core vereinheitlicht wird, __und__ wir herausgefunden haben, dass __ASP.NET Core auf NetFX__ laufen würde, war es sinnvoll, ASP.NET vNext/5/Core zu verwenden.

Während wir .NET Core nutzen, um (einen Teil) unserer Anwendung auf Linux und macOS zu portieren, gibt es immer noch Windows-Abhängigkeiten, die nicht auf .NET Core ausgeführt werden (um eine Liste der Abhängigkeiten zu erhalten, die wir portiert haben, überprüfen Sie die CoreCompat.* NuGet-Pakete).

Um es kurz zu machen, wir sind jetzt auf ASP.NET Core 1.x fixiert, das für einen begrenzten Zeitraum unterstützt wird. Und dann was? Zurück zu ASP.NET 4?

Ich verstehe all die Leistungsarbeit, die Sie in anderen Bereichen von .NET Core leisten und Grenzen überschreiten, aber in meinem Anwendungsfall hoste ich keine hochvolumige internetexponierte Website, ich hoste eine REST-API, die dies tut bekommen wie was, 10-20 RPS max?

Visual Studio-Unterstützung

Wirklich, meine Visual Studio 2017-Erfahrung auf NET 4.x ist immer noch viel besser als .NET Core – ein gutes Beispiel dafür ist die Zeit, die es dauert, ein Testprojekt neu zu kompilieren und die neuen Tests im Testfenster anzuzeigen . Es ist viel schneller auf NetFX.

Am Ende haben wir eine Situation, in der wir heute parallel ein NetFX- und ein .NET Core-Projekt haben, das im Wesentlichen dieselbe Codebasis kompiliert. Der einzige Grund, warum wir mit dieser doppelten Wartung Schritt halten, ist die Leistung von Visual Studio bei .NET Core-Projekten (_insbesondere_ Komponententests und der Debugger).

Was mir im Nachhinein wirklich auffällt, ist, dass diese Änderung jetzt vorgenommen wird, ein paar Tage vor der Vorschauversion. Es scheint nur darauf hinzudeuten, dass es noch keinen technischen Grund dafür gibt – warum also nicht die Änderung in ASP.NET Core v3 vornehmen?

@mattnischan

@stefanolson Das ist nicht richtig. Bibliotheken, die auf .Net Standard 1.x abzielen, können heute auf verschiedenen vollständigen Framework-Versionen ausgeführt werden. Bibliotheken, die auf .Net Standard 2.0 abzielen, sollen in der Lage sein, auf 4.6.1 zu laufen, wie ich zuletzt gesehen habe.<

Es scheint mir, als würde asp.net core .net core nicht .net standard ausführen? Ich bin mir also immer noch nicht sicher, was der Sinn des .net-Standards ist – wenn er praktisch sofort nach seiner Erstellung aufgegeben wird.

Es wäre absolut sinnvoll, wenn der asp.net-Core den .net-Standard 2.1 erfordern würde, da es Dinge gibt, die sie benötigen, die derzeit nicht im Framework enthalten sind. Wir mussten also warten, bis das vollständige .net-Framework diese zusätzlichen Funktionen unterstützte, bevor wir die neueste Version des Asp.net-Kerns verwenden konnten. Das würde funktionieren und Sinn machen.

Aber stattdessen geben sie den Standard einfach auf und machen den Standard unbrauchbar (wenn ich diese verwirrende Situation richtig verstehe).

Also ... sein Build 2017 beginnt morgen; Ich kann mir vorstellen, dass das Team sehr damit beschäftigt ist, sich darauf vorzubereiten. Vielleicht einige Ankündigungen, vielleicht auch nicht. Vielleicht gibst du ihnen etwas Raum zum Atmen und triffst dich in einer Woche wieder?

Sehen Sie sich vielleicht die Sendung https://build.microsoft.com/ an (Mi 8:00 PST, 15:00 GMT und Do ähnlich?)

Vielleicht wissen wir mehr; nicht dürfen. Die Dinge können klarer sein, müssen es nicht. Das ASP.NET-Team wird jedoch wahrscheinlich etwas besser reagieren und sich mehr auf die Anliegen aller konzentrieren können. Obwohl @davidfowl sich tapfer geschlagen hat!

@stefanolson Aber stattdessen geben sie einfach den Standard auf und machen den Standard unbrauchbar (wenn ich diese verwirrende Situation richtig verstehe)

Ich denke, der Sinn von .NET Standard ist die Kompatibilität. Bibliotheksautoren können .NET Standard als Ziel verwenden und jeder kann es verwenden, unabhängig davon, ob er .NET Framework, .NET Core oder etwas anderes verwendet, das .NET Standard unterstützt.

Ich denke, der Sinn von .NET Core ist eine Neuinterpretation von .NET Framework. .NET Core ist plattformübergreifend, leistungsstark, Open Source und entwickelt sich schnell weiter.

Das standardmäßige Ändern der Implementierung von string in utf8 ist massiv und etwas, das Sie niemals in .NET Framework erwarten würden.

Nachdem ich diesen Thread gelesen habe, fühle ich mich:
.NET Core -> .NET Framework ist wie ASP.NET MVC -> WebForms.

Ich möchte auch den Werkzeugaspekt anführen. Die aktuelle Wiederherstellungs-/Build-/Test- usw. Leistung ist sehr schlecht und ein königlicher Schmerz. Wenn wir „bei 1.0 bleiben“ müssten, könnten wir immer noch neuere SDKs mit (hoffentlich) besserer Leistung verwenden oder würden wir bei einem 1.x SDK stecken bleiben?

Die Geschichte von .NET Core ist eine wunderbare Tour voller Höhen und Tiefen. Wir haben erst vor kurzem mit der Arbeit an ASP.NET Core begonnen, wegen all der vorherigen „Fuck-Ups“ (Versionierung, Benennung, project.json - .csproj-Übergang) und ich war (und bin) gespannt auf .netstandard 2.0, weil ich denke dies wird die erste "echte" Veröffentlichung sein.

Ich verstehe, dass ASP.NET Core 1.1 immer noch unterstützt wird und die nächsten 10 Jahre laufen wird, aber Sie sind super mutig, __das__ schnell zu bewegen und eines der früheren Verkaufsargumente von ASP.NET Core zu streichen.

Falls Sie wissen wollen, was von unserer Seite ein Blocker (abgesehen von Verzeichnisdiensten) ist: Wir verwenden immer noch EF6 und warten immer noch auf ein offizielles Open XML SDK NuGet-Paket, das auf netstandardwhatever abzielt.
Das Migrieren von Code kann sehr lange dauern...

Wäre es möglich, eine Art Prozess zu formalisieren, um netstandardXX basierend auf Änderungen, die in Core auftreten, voranzutreiben, was beinhaltet, dass es als Teil einer Wartungsphase der Veröffentlichung der Asp.Net Core-Bibliothek ins Visier genommen wird?

So wie es aussieht, habe ich eine WebForms/MVC-App, für die wir gerade einen Trigger auslösen wollten, um eine ANC-Web-API für eine SPA (und letztendlich für die Legacy-App von WebForms) verfügbar zu machen und aufzurufen, aber wir können sie deswegen nicht auf der CoreCLR entwickeln eine Abhängigkeit von Sybase (jetzt SAP) Ase ADO.NET -Treiber (wenn jemand, der dies liest, irgendwo bei SAP auf einen Knopf drücken könnte ... ich scheine leider überhaupt nichts darüber oder über Fehler zu hören, von denen ich seit über bekannt bin 9 Jahre jetzt).

Beim Lesen dieser Ausgabe bin ich mir nicht mehr so ​​sicher, was mein Weg sein soll. Das einzige, von dem ich zuversichtlich bin, dass ich planen kann, ist, dass es weiterhin einen fehlerhaften Treiber für das Desktop-Framework geben wird. Sollte ich die Änderungen an ASP.NET in den letzten Jahren ignorieren, weil sie Zeitverschwendung waren und ich einfach auf WebApi2 abzielen sollte? Soll ich sagen, fahren Sie mit ANC 1.x fort, in dem Wissen, dass ich wahrscheinlich nie migrieren und die Vorteile von 2.x in einer Anwendung sehen werde, von der ich glaube, dass sie hier für die nächsten 10-15 Jahre unterstützt wird (die WebForms-App hat migriert und gewartet wurden, seit das 1.1-Framework veröffentlicht wurde)?

@davidfowl

Span selbst hat eine portable Version, die überall läuft, ich bin mir nicht sicher, ob die schnelle Implementierung jemals sein wird
auf .NET Framework. Die APIs, die zu .NET Framework hinzugefügt werden und Span nutzen, können viel länger dauern als Span selbst, es ist umfangreich. Wann haben wir das letzte Mal String und Array in .NET geändert
Rahmen?

Warte was?

Nicht alle von uns sind Webentwickler. Wir haben jahrelang sehnsüchtig auf eine bessere Saitenbehandlungsunterstützung gewartet und jetzt sagen Sie uns plötzlich, dass wir SOL sind? Dass das .NET Framework und die unzähligen darauf aufbauenden Nicht-Web-Anwendungen niemals Zugriff auf auf Span basierende String-Handling-Bibliotheken erhalten werden?

Dies ist nicht mehr nur ein ASP.NET-Problem. Es steht im Mittelpunkt von Microsofts langfristigem Engagement für .NET Framework und seine Basisklassenbibliothek.

Weißt du, ich muss Leuten wie @davidfowl wirklich dafür danken, dass sie weiterhin allen antworten und allen, die zu dieser Diskussion beigetragen haben. Ich muss einiges von früher heute nachholen, aber ich habe das Gefühl, dass ich durch jeden Kommentar viel darüber lerne, wofür jeder .NET verwendet/zu verwenden hofft.

Ich denke, wir werden mit der Hilfe aller irgendwann einen oder mehrere Wege ebnen, und ich hoffe, dass alle Seiten berücksichtigt werden.

Ich warte gespannt auf die offizielle Ankündigung

Wenn ich es richtig verstanden habe, wird net coreapp 2.0 einen Kompatibilitäts-Shim bereitstellen, der es unseren ASP.NET Core 2.0-Projekten ermöglicht, von unseren alten NetFx-Klassenbibliotheken (z. B. net461) abzuhängen.
Wo finde ich weitere Informationen zu den derzeit geplanten Möglichkeiten/Einschränkungen eines solchen Compat-Shims?

@dgaspar Das ist nicht wirklich genau, so funktioniert es: netcoreapp2.0 unterstützt die meisten APIs in net461 . Wenn Ihre Bibliothek für net461 erstellt wurde und nur die APIs aufruft, die innerhalb der von netcoreapp2.0 unterstützten Teilmenge vorhanden sind, können Sie die Bibliothek trotzdem importieren (stellen Sie sich das als Überschreiben vor, das Sie besser wissen). und lass es laufen, da alle Klassen und Methoden, die es aufruft, dort sein sollten.

Jetzt gibt es auch einen Nachteil: Wenn die Methoden nicht vorhanden sind oder auf irgendeine Weise nicht vollständig unterstützt werden, erhalten Sie Laufzeitfehler für fehlende Methoden usw. Daher sind Überprüfungen zur Kompilierzeit dort keine gute Garantie. Es ist ein zweischneidiges Schwert, dessen man sich bewusst sein muss, aber einige Bibliotheken, die nie aktualisiert werden, sind dennoch mit den von ihnen aufgerufenen APIs in Ordnung.

@NickCraver erinnert sich noch jemand ...

"imports": [ "dnxcore50", "portable-net45+win8" ]

Ein verwandter Kommentar, den ich im Dezember gemacht habe. 11 Daumen hoch nach vorne getragen:

Hier ist etwas aus dem Ruder gelaufen. Ich vertreibe seit 15 Jahren C#-Apps. Ironischerweise verbringe ich immer mehr Zeit damit, tief in Interna einzudringen, um die ich mich früher nie kümmern musste, da Microsoft Abstraktionen auf höherer Ebene ausliefert. DU MACHST ES FALSCH.

Wenn ich zur Laufzeit von zufälligen Bibliotheks- und Paketverwaltungsfehlern überrascht werden wollte, die der Compiler nicht abfing, würde ich meine Apps in Ruby schreiben.

sogar node.js erlaubt es uns, alle Netfx-Bibliotheken einfach aufzurufen.

Der MVC-Code ist wirklich der einfache Teil. Es kann ein paar Wochen dauern, in node.js oder nancy neu zu schreiben, aber es wird viel länger dauern, Geschäfts- und Algorithmuscode zu portieren und zu beweisen, dass er genauso solide funktioniert wie der alte. ganz zu schweigen von dem Fall, wenn wir die Quelle nicht haben.

Nehmen Sie das Beispiel RyuJit, selbst nach der Veröffentlichung in der Produktion wurden blockierende größere Fehler gefunden, und es dauerte ein weiteres Jahr, bis sie vollständig behoben waren. Das Gleiche gilt für unsere Software, die keine Tierhandlungen sind, sondern industrielle Werkzeuge, die helfen, Millionen Dollar pro Tag zu verdienen.

Das UI-Framework ändert sich schnell, von Winform zu Web. aber Kerngeschäftslogik/-algorithmus sind viel stabiler und langlebiger. Um also das neue glänzende UI-Framework zu verwenden, müssen wir unseren Geschäfts-/Algorithmus-Code neu schreiben/erneut testen oder aufgeben? Nein, wir wussten, dass der neue Glanz in 5 Jahren durch etwas Trendigeres ersetzt wird, aber unser Geschäfts-/Algorithmuscode wird weiterhin verwendet.

@qmfrederik

Was mir im Nachhinein wirklich auffällt, ist, dass diese Änderung jetzt vorgenommen wird, ein paar Tage vor der Vorschauversion. Es scheint nur darauf hinzudeuten, dass es noch keinen technischen Grund dafür gibt – warum also nicht die Änderung in ASP.NET Core v3 vornehmen?

Als nächstes führen wir HTTP2-Unterstützung durch und es erfordert neue APIs.

Ich möchte auch den Werkzeugaspekt anführen. Die aktuelle Wiederherstellungs-/Build-/Test- usw. Leistung ist sehr schlecht und ein königlicher Schmerz. Wenn wir „bei 1.0 bleiben“ müssten, könnten wir immer noch neuere SDKs mit (hoffentlich) besserer Leistung verwenden oder würden wir bei einem 1.x SDK stecken bleiben?

Ja, das wird funktionieren.

@davidfowl

Als nächstes führen wir HTTP2-Unterstützung durch und es erfordert neue APIs.<

Also wird die Art von HTTP2-Unterstützung, die in asp.net Core 2.0 verfügbar sein wird, in 1.x nicht verfügbar sein? Dies ist wirklich die Art von Problem, über das ich mir Sorgen mache, wenn wir keinen Zugriff auf die neueste Technologie haben, weil wir aus irgendeinem Grund an das vollständige .net-Framework gebunden sind. Wie ich oben gesagt habe, spielt es keine Rolle, ob es sechs Monate bis zu einem Jahr dauert, bis dieser Filter zu dem durchdringt, was ich verwende, aber letztendlich nicht zu weit zurückbleiben möchte. Aufgrund von Codesharing und Bibliotheksnutzung durch Drittanbieter benötige ich in diesem Stadium das vollständige .net-Framework.

Zum Schluss stelle ich ein paar Dinge klar:

• Wenn ich Legacy-Module sage, handelt es sich um DLLs, die von Netfx- oder C++/CLI-DLLs abhängen, die wiederum einige native DLLs hervorrufen können. sie sind für Geschäft/Algorithmus, kein COM, kein asp.net. sie sind nicht schlecht. Sie werden hauptsächlich deshalb veraltet, weil .net Core sie nicht ausführt.
• es ist möglich, langfristig auf net core zu migrieren, und wir wollen es wirklich. aber es ist wirklich schwer, das zu erreichen. Es wird ein paar Jahre dauern, bis wir und Dritte da sind.
• Die domänenspezifischen Bibliotheken sind viel langsamer als Mainstream-Bibliotheken für Tech-Stack-Änderungen. Wir alle kennen das Beispiel von Python 3. Diese domänenspezifischen Bibliotheken sind ein echtes Geschäft.

@danielcrabtree

Ich denke, der Sinn von .NET Core ist eine Neuinterpretation von .NET Framework. .NET Core ist plattformübergreifend, leistungsstark, Open Source und entwickelt sich schnell weiter.<

Was fantastisch ist. Die Herausforderung besteht darin, wie wir mit den vorhandenen Codebasen umgehen und wie wir diese mit .net Core nutzbar machen. Wenn WPF basierend auf .net Core verfügbar wäre, könnte ich .net Core überall verwenden. Da dies jedoch nicht der Fall ist und mein Code zwischen WPF und ASP.net geteilt wird, brauche ich eine Möglichkeit, sie zu teilen. Aber ich möchte nicht zu weit hinter den neuesten Webtechnologien und Sicherheitstechniken zurückbleiben, von denen sich die meisten (alle?) so anhören, als ob sie erst in 2.x und höher verfügbar sein werden

Einige Male in diesem Thread und in der Dokumentation an anderer Stelle wird .NET Core als plattformübergreifend beschrieben. Dies wurde als eines der wichtigsten Verkaufsargumente für den Wechsel zur Plattform beworben.

Dies scheint jedoch nicht der Fall zu sein, wie in diesem Gespräch auf Twitter klargestellt wird

https://twitter.com/James_M_South/status/861595907782987776

Und der obige Kommentar; Betonung von mir.

Die verbleibenden großen Lücken, die in .NET Core 2 fehlen, sind System.DirectoryServices und System.Drawing. Wir arbeiten an einem Windows-Kompatibilitätspaket, das beide in diesem Sommer auf .NET Core unter Windows ermöglichen würde.

Ich habe sehr hart mit .NET Core gearbeitet, seit ich sehr früh versucht habe, die Lücke zu füllen, die System.Drawing mit ImageSharp hinterlassen hat, und ich bin jetzt sowohl sehr verwirrt als auch mehr als ein wenig verärgert und frage:

Was ist .NET Core jetzt überhaupt?

Hier ist die Beschreibung aus den MS Docs .

.NET Core ist eine Allzweck-Entwicklungsplattform, die von Microsoft und der .NET-Community auf GitHub verwaltet wird. Es ist plattformübergreifend, unterstützt Windows, macOS und Linux und kann in Geräte-, Cloud- und eingebetteten/IoT-Szenarien verwendet werden.

Da ist wieder diese plattformübergreifende Aussage. Ist es oder nicht? Ich denke, der Versuch, dies festzunageln, führt zu viel Verwirrung in der Entwicklergemeinschaft.

Jede Beschreibung, die ich lese, scheint anders zu sein.

Können wir:

1. Bitte lassen Sie sich irgendwo eine anständige, konsistente Botschaft aufschreiben, damit wir tatsächlich ein Ziel haben, das wir anstreben, und ein besseres Gesamtverständnis.
2. Verschaffen Sie sich Klarheit über die aktuelle Roadmap für System.DirectoryServices und System.Drawing

Insbesondere System.Drawing ist sowohl verwirrend als auch besorgniserregend. Ich kann nicht nachvollziehen, warum Sie diese API jemals auf einer beliebigen Plattform auf .NET Core portieren möchten. Es ist schwierig damit zu arbeiten, wird auf dem Server nicht unterstützt und es fehlen viele kritische Funktionen, die für die moderne Entwicklung erforderlich sind (Multi-Threading, Pixelformate, ICC, EXIF, Quantisierung, indiziertes Png und so weiter).

Es gibt hier viele erkennbare Namen und Gesichter, und ich weiß, dass ich hier nur etwas Lärm hinzufüge, aber:

• Verzeichnisdienste
• Zeichnen (nicht dass ich es brauche)
• EF

Dies scheinen die drei wichtigsten Dinge zu sein, die man auf den neuesten Stand bringen muss, bevor man eine so große Pause einlegt. Persönlich arbeite ich fast ausschließlich wegen EF6 auf net4x, da EFCore ... na ja ... :trollface:

@stefanson
Ich denke, von Ihnen wird erwartet, dass Sie den gemeinsam genutzten Code in eine .NET Standard-Bibliothek aufteilen. Dann kann es von WPF und ASP.NET auf .NET Framework und von ASP.NET auf .NET Core und anderen .NET Core-Anwendungen verwendet werden.

@JimBobSquarePants
Ich glaube nicht, dass das Windows Compat Pack Teil von .NET Core ist. Es handelt sich um eine Windows-spezifische Bibliothek, die auf .NET Core aufgesetzt wird. Sie können sich vorstellen, dass es eine Linux-spezifische Bibliothek gibt, die nur Linux-Funktionen verfügbar macht.

Ich denke, das Windows Compat Pack soll es einfacher machen, vorhandene .NET Framework-Codebasen zu migrieren. Sobald jemand zu .NET Core gewechselt ist, sollte er sich natürlich überlegen, zu besseren Lösungen wie ImageSharp zu migrieren.

@stefanson
Es ist möglich, dass sie sogar ein WPF-Paket nur für Windows erstellen könnten, mit dem Sie WPF-Anwendungen in .NET Core erstellen können, das jedoch nur unter Windows ausgeführt werden würde.

Dieses GitHub-Problem wurde auf einer deutschen IT-Nachrichtenseite erwähnt:
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

Danke @danielcrabtree , das ist das erste, was ich von Kompatibilitätspaketen höre.

Übersetzung für den Link von @MJomaa : https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert- net-entwickler-mit-support-entscheidung-1705-127712.htm

Ich warte darauf, dass System.Xaml portiert wird.

@alexwiese nicht die Luft anhalten.

Ich warte darauf, dass System.Xaml portiert wird.

Mach weiter; Ich werde beißen. Wie verwenden Sie Xaml auf Ihrer Website?

Mach weiter; Ich werde beißen. Wie verwenden Sie Xmal auf Ihrer Website?

Plattformübergreifende Benutzeroberfläche (Bildschirmvorlagen, die von einer „Green Screen“-Konsolenanwendung, einer Xamarin-App und einer Angular-SPA gemeinsam genutzt werden), die auch für eine Geschäftsregel-Engine verwendet wird.

Wow, ok, Sie wandeln also das XML von XAML in irgendeiner Weise in HTML und Javascript um? In Ordnung 😄

Ich war mir nicht sicher, ob du nur trollst.

Ich mache dasselbe, aber realistisch gesehen sehe ich nicht, dass sie XAML portieren, wenn man bedenkt, dass es zu diesem Zeitpunkt nicht analysiert werden kann, ohne auch ausgeführt zu werden.

Wow, ok, Sie wandeln also das XML von XAML in irgendeiner Weise in HTML und Javascript um? In Ordnung 😄

Natürlich nicht; Ich konvertiere zuerst in JSON 😉

Ein weiterer Nachrichtenartikel zu diesem Thema, in dem viele von uns zitiert werden: https://www.infoq.com/news/2017/05/ASPNET-Core-2

@cwe1ss Der Autor ist @Grauenwolf

@alexwiese @yaakov-h Ich würde gerne einen Blogbeitrag darüber lesen; klingt ziemlich interessant und muss mit anderen Herausforderungen einhergehen, als ich es gewohnt bin.

Das ist wirklich schlimm. ASP.NET Core war ein vernünftiger Verkauf, wenn Sie bei Bedarf Legacy-Bibliotheken nutzen konnten. Falls dies mit den neuen Dingen möglich ist, optimieren Sie einige Dinge und zielen Sie auf .NET Core ab. Andernfalls zielen Sie einfach auf das gesamte Framework ab.

Mit dieser Änderung ist es ein Alles-oder-Nichts-Sprung. Und da Sie nicht immer alle Abhängigkeiten im Voraus verstehen, erhöht dies das Risiko.

Ich verstehe den Wunsch, sich schnell zu bewegen und sich dahin zu entwickeln, wohin die Dinge sowieso gehen müssen, aber Sie werden Ihre Benutzer zurücklassen. Menschen neigen dazu zu migrieren, nicht zu springen. Eine große Anzahl wird sich einfach nicht vom Strom lösen. Und wenn sie das tun, könnten sie durchaus auf eine ganz andere Plattform wechseln. Im Ernst, Sie unterschätzen dieses Risiko.

Dies ist ein Schritt, der irgendwann gemacht werden sollte, aber eher Ende 2019 oder frühestens 2020. Selbst dann möchten Sie immer noch ein langfristiges Modell, um diejenigen zu unterstützen, die sich entschieden haben, Dinge zu mischen.

Und nein, ASP.NET Core 1.x ist da einfach keine Antwort. Seine Unreife ist als Übergangsphase mit einem leichten Migrationspfad nach vorne in Ordnung, aber nicht geeignet, um langfristig damit zu leben. Es gibt einen großen Unterschied zwischen der Denkweise derjenigen, die eine solche Plattform entwickeln, und denen, die sie nutzen. Bitte überdenken Sie diese Richtung noch einmal.

@davidfowl Was ist mit so etwas wie edge.js für netcore? Es macht den API-Verbraucher für Plattformprüfungen verantwortlich, und eine stark typisierte Schnittstelle zwischen netfx und netcore ist für die meisten Szenarien ausreichend.

Wird diese Vorlage dann entfernt?

Es ist im Moment in VS2017 eingebacken.

Was für ein völlig inakzeptabler Blödsinn, wieder einmal beweist dies, dass es sich um eine Spielzeugtechnologie handelt, die noch nicht für die Hauptsendezeit und eine breite Akzeptanz bereit ist.

Ich weiß es wirklich zu schätzen, Jungs, ihr habt eine schöne Fahr- und Programmiererfahrung, ihr könnt in euren Blog-Einträgen und Twitter glänzen (hurra!), eure LinkedIn-Profile und Lebensläufe verbessern (hurra^2), alle Release-Partys vor euch, Mädels, Drinks und Das Zeug sieht vielversprechend aus, aber ... wer wird es verwenden? richten Sie sich an Unternehmen und möchten eine große Akzeptanz und eine solide Benutzerbasis? oder nur einige Startup-Hippies?!?

Dieser Kommentar zu "Full Span", das es möglicherweise nie in .NET Framework schafft, ist für mich ernsthaft besorgniserregend. Wenn Full Span nicht in .NET Framework enthalten ist, gehe ich davon aus, dass APIs, die es verwenden, es niemals in einen zukünftigen Netzstandard schaffen können, was es unmöglich macht, plattformübergreifende Bibliotheken zu schreiben, die Hochleistungs-Parsing verwenden oder verfügbar machen? Was bedeutet, dass wir mit unseren unsicheren benutzerdefinierten Implementierungen dauerhaft effektiv festsitzen ...

Sie erwähnen, dass Sie auf netstandard abzielen sollten, wenn Sie möchten, dass Ihre Bibliothek plattformübergreifend ist, aber was ist ASP.NET Core, wenn nicht eine weit verbreitete Bibliothek? Würden Sie anderen Bibliotheken empfehlen, die Unterstützung für netstandard einzustellen und zu .NET Core zu wechseln? Sollte die nächste Hauptversion von JSON.NET oder was auch immer netstandard fallen lassen? Es könnte sicherlich schnelles Parsing vertragen!

Hinweis Java hat es geschafft, Fast IO ohne Kopieren usw. auf abwärtskompatible Weise mit Netty (https://netty.io/) hinzuzufügen.

Abschließend möchte ich mich bei den Leuten bedanken, die bereit sind, herumzuhängen und diese zu beantworten. Wir freuen uns über die Antworten...

@shanselman Sich schnell zu bewegen ist ein edles Ziel, insbesondere für Teams, die größte Anstrengungen in die Kompatibilität stecken und Dinge auf kompatible Weise entwerfen, wie das ASP.Net-Team. Ich weiß, wie gerne sie ihre Problemdomäne vereinfachen würden, und ich unterstütze das, aber ...

Sich schnell und gleichzeitig „auch weg“ von Ihren Kunden zu bewegen, ist auch nicht gut. Wissen Sie, Ihre Kunden (mich eingeschlossen) haben eine Menge Legacy-Software und investieren viel Zeit in bestehende Apps und Bibliotheken. Sie können uns nicht einfach zurücklassen und an einen Ort gehen, wo wir nicht folgen wollen/können.

Sie sollten Ihre Kunden berücksichtigen, die nicht zu .Net Core wechseln können und von nun an mindestens noch einige Zeit Full Framework verwenden müssen. Wenn Sie sich von Full Framework entfernen, lassen Sie viele Menschen auf älteren Versionen festsitzen und schaffen eine große Spaltung in der .Net-Welt.

@JimBobSquarePants Ich unterstütze dich beim System.Drawing -Teil. Es gibt einige Diskussionen in den anderen Repos darüber, System.Drawing zurückzubringen. Basierend auf einigen Kommentaren in diesem Thread verstehe ich, dass es zuerst ein "Kompatibilitätspaket" für Windows und dann für alle Betriebssysteme für System.Drawing geben wird.

Ich frage mich, wie das aussehen wird und ob es auf Monos libgdiplus basieren wird oder nicht (was einige der Bedenken beseitigen würde, die Sie mit System.Drawing haben, aber das ist eine andere Geschichte).

Okay, so wie ich das sehe, gibt es ein paar Probleme:

1. Dies wurde eher schlecht kommuniziert.
2. Die Leute waren an der Entscheidung nicht beteiligt. Beachten Sie, dass es Microsoft natürlich freisteht, die gewünschte Richtung zu wählen, aber diese Art von großen Änderungen nicht mit der Community zu diskutieren, entspricht nicht dem Geist der Open-Source-Entwicklung.
3. Es gibt kein "großes Schema", das die Gemeinschaft verwenden könnte, um diese Art von Entscheidungen zu prüfen. Zunächst war .NET Core eine abgespeckte, plattformübergreifende Version des vollständigen Frameworks. Dann, mit .NET Standard 2.0, schien es vielen, dass .NET Core 2 wie ein Drop-In-Ersatz für das vollständige Framework wäre, natürlich innerhalb angemessener Grenzen (kein UWP, WinForms usw.).
4. .NET Core 2 wird einige wichtige Funktionalitäten verpassen, die im vollständigen Framework enthalten sind, wie System.DirectoryServices. Soweit ich das beurteilen kann, wurde dies anerkannt, aber vielleicht könnte der Weg zum Hinzufügen dieser Funktionen zu .NET Core deutlicher gemacht werden.
5. ASP.NET Core 2 wird nicht auf dem vollständigen Framework ausgeführt, da dem vollständigen Framework neuere Features fehlen. Ich bin damit eigentlich völlig einverstanden. Wenn das Hinzufügen der fehlenden Funktionen zum vollständigen Framework übermäßig schwierig ist, dann tun Sie es nicht. Dass ASP.NET Core 2 nur auf .NET Core 2 ausgeführt wird, macht eigentlich ziemlich viel Sinn, obwohl die Erwähnung als ein Produkt wahrscheinlich nicht die beste Art war, ihre Beziehung zu beschreiben.

Was die Leute meiner Meinung nach wirklich gerne sehen würden, ist eine Beschreibung der Vision der .NET-Plattform. In welche Richtung wird es gehen? Wird das vollständige Framework nur Bugfixes und dergleichen erhalten, aber keine neuen Funktionen? Was wird getan, um fehlende Features zu .NET Core hinzuzufügen, und wann können wir damit rechnen? Wenn dies erklärt würde, würde dies hoffentlich viel dazu beitragen, die Angst zu lindern, die die Menschen jetzt empfinden.

@davidfowl Ich denke, es geht nicht nur um HTTP 2.0; Wenn es wirklich um HTTP 2.0 geht, könnten Sie nicht ASP.NET Core 2.0 als Ziel NetFX mit Ausnahme der HTTP 2.0-Unterstützung haben? Vielleicht sogar ein steckbares Modell, damit die Community HTTP 2.0 auf NetFX machen könnte, wenn sie es wirklich wollte?

@cokkiy @popcatalin81 @xprzemekw Wenn Sie nichts Konstruktives zu sagen haben, sehen Sie bitte von Kommentaren ab, diese Art von Kommentaren helfen niemandem.

Es gibt legitime Gründe, warum Sie den von @davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134 beschriebenen Schritt machen sollten

Zu den Gründen, warum es verschoben wird, gehören (z. B. asp.net Core 3.0):

• EF Core ist noch nicht bereit, EF 6.0 zu ersetzen, da viele Funktionen fehlen
• keine Produktion bereit System.Drawing Ersatz
• nein System.DirectoryServices
• Es wurde office xml sdk erwähnt, aber das scheint bereits am 01.05.2017 auf netstandard verfügbar zu sein https://www.nuget.org/packages/DocumentFormat.OpenXml/
• andere Pakete außerhalb des MS-Bereichs sind auf .net Core nicht verfügbar (nhibernate, verschiedene DB-Anbieter, ikvm)

Zu den Gründen, warum Sie es nie tun sollten, gehören:

• Leute portierten Apps mit Legacy-Abhängigkeiten auf asp.net Core, ohne die Absicht, auf .net Core umzusteigen.
• Sorgen Sie sich darum, netstandard hinter sich zu lassen und sich nicht viel darum zu kümmern.
• Es ist unwahrscheinlich, dass einige Pakete von Drittanbietern jemals auf .net Core portiert werden (was sie wohl veraltet macht, aber das könnte nur meine Meinung sein)

Ein Beispiel für einen konstruktiven Kommentar wäre das Hinzufügen Ihres Grundes, warum Sie eines dieser drei Szenarien sehen möchten, oder das Vorschlagen einer alternativen Lösung. Wenn Sie nur Ihre Zustimmung/Ablehnung ausdrücken möchten, verwenden Sie die Schaltflächen "Reaktion".

@Kukkimonsuta

Leute portierten Apps mit Legacy-Abhängigkeiten auf asp.net Core, ohne die Absicht, auf .net Core umzusteigen.

Stimme voll und ganz zu. Denn Microsoft hatte angekündigt, dass ASP.NET Core sowohl auf .net Core als auch auf .net Frameworks funktionieren wird. Und es ist nicht fair, sie jetzt in AspNet Core 1.x zu belassen.

Die letzte Zusammenfassung ist ganz gut. Ich möchte nur ein oder zwei Dinge hinzufügen:

1.) Es sollte möglich sein, Windows-Dienste mit .NET Core zu schreiben (ich weiß, dass Daemons auf *NIX-Plattformen anders funktionieren). Die ServiceBase wäre also weiterhin nötig, und das hat zusammen mit EF hohe Priorität.

2.) Es sollte weiterhin möglich sein, eigenständige Dienste mit .NET Core zu schreiben und diese zusätzlich in Ihrer bestehenden, vollständig auf dem Framework basierenden .NET-Anwendung (dh einem kostenlosen Dienst aus Ihrer Windows Forms / WPF-App) zu hosten , um sie zu erweitern.

Letzteres ist wirklich für langsame Migrationsszenarien erforderlich, bei denen es nicht möglich ist, einen harten Schnitt zu machen und auf der grünen Wiese zu beginnen.

Stimme voll und ganz zu. Denn Microsoft hatte angekündigt, dass ASP.NET Core sowohl auf .net Core als auch auf .net Frameworks funktionieren wird. Und es ist nicht fair, sie jetzt in AspNet Core 1.x zu belassen.

Ich möchte auch noch einmal betonen, dass der große Wechsel zurück zu .csproj und msbuild hauptsächlich damit entschuldigt wurde, dass es nicht möglich wäre, (ASP).NET Core-Projekte aus Ihren bestehenden (Full Framework) .NET-Projekten zu referenzieren.

Diese Änderung macht letzteres unmöglich (zumindest für den größten Teil von ASP.NET). Warum also war Kompatibilität damals von größter Bedeutung (und verursachte viel Schmerz), ist es aber heute nicht (und verursacht wieder viel Schmerz)?

sorry ich muss auch betonen. Aber fast 500 Kommentare, ich glaube, wenn ich als Microsoft-Typ an diesem Problem beteiligt bin, hatte ich zwei Möglichkeiten:
1: Stummschalten des Problems
2: Denke über meine Entscheidung nach

@gingters Die csproj-Änderung galt jedoch hauptsächlich für _.net_ core, damit xamarin, asp.net, uwp und alle anderen Code gemeinsam nutzen und auch auf andere Projekttypen wie nativen Code verweisen können.

Außerdem ermöglicht es asp.net Core 2-Projekten, wieder auf vollständige Framework-Projekte über das Compat-Shim zu verweisen

@qmfrederik

Vielleicht sogar ein steckbares Modell, damit die Community HTTP 2.0 auf NetFX machen könnte, wenn sie es wirklich wollte?

Sie könnten es technisch. Aber anscheinend wollen sie das nicht. Ich habe das Gefühl, dass sie einfach nicht über die wirklichen Bedürfnisse von Unternehmen / großen Unternehmen nachdenken wollen, oder über Abwärtskompatibilität oder die Notwendigkeit, mit etwas anderem als Greenfield-Sachen fertig zu werden.

Und um ehrlich zu sein, zielte das Erwartungsmanagement in der Vergangenheit vollständig auf Unternehmen ab, die ihre Inhalte langsam plattformübergreifend erweitern/migrieren und gleichzeitig ihre bestehenden Apps langsam erweitern/migrieren möchten. Dieser Schritt ist also völlig unangepasst an das vorherige Erwartungsmanagement.

@ aL3891

damit xamarin, asp.net, uwp und alle anderen Code gemeinsam nutzen können

Jawohl. Exakt. Und dazu gehört auch die WPF/Windows Forms-App zur Verwendung von .NET Core-Bibliotheken, was jetzt unmöglich ist, wenn Sie zu .NET Core 2 wechseln möchten.

Könnte jemand genau erklären, warum zum Teufel diese Bibliotheken nicht auf netstandard2.0 abzielen können?

Bis jetzt habe ich netcoreapp als Spitznamen für eine plattformübergreifende ausführbare Datei betrachtet (nur in einem ausführbaren csproj-Projekt verwendet), aber ich habe es nie als Plattform betrachtet, jetzt sollte es als echte Plattform betrachtet werden? Warum warum warum und wie sind wir zu dieser absurden Option gekommen?