ASP.NET Core 2.0 nur noch mit .NET Core, nicht mehr mit .NET Framework (=>MS rudert zurück)

Das ist echt mal ein trauriges Durcheinander.
Insbesondere wenn man ein Backend, das teilweise noch COM-Komponenten verwendet, mit eine Core WebAPI anreichern will.
Jetzt ärgere ich mich nicht mehr, dass wir in einem Project noch auf "classic" WebApi gesetzt haben.

Never trust a 1.X version

Dass das .NET Framework ausläuft war lange ein Gerücht; aber das ist natürlich nicht so.
Das .NET Framework deckt aktuell ein ganz anderes Spektrum als .NET Core ab. Wird sich in den nächsten Jahren auch nicht ändern.
Das Framework ist an den Support Zyklus von Windows gekoppelt; und da sind wir aktuell mindestens bei 2025.

Leider ist das wirklich nicht so gut von Microsoft rüber gekommen, sodass hier vor allem in nicht-englischen Communities schnell falsche Infos kursiert sind.
Scott Hanselman hat es dann das erste Mal mit der .NET Innovation ( .NET Future Innovation: .NET Standard) anschaulich dargestellt.

ASP.NET war quasi der erste Stack, der die .NET Innovation mit dem eingeführt hat.
Im Prinzip ist aus diesem Requirement auch die neue Welt des gemeinsamen ".NET Standard" entstanden.
Ich betone auch in meinen Vorträgen zu .NET Core / .NET Standard / ASP.NET Core, dass hier ein enormes Umdenken von "Framework Version" auf "Standard Version" notwendig wird, da man ansonsten das Ziel seines Codes gar nicht kennen kann.

Wer sich mit ASP.NET beschäftigt - und das ist ja alles Open Source - da wusste man schon, dass das .NET Framework kein Dauerzustand für ASP.NET sein wird, sondern, dass das auf lange Frist schon .NET Core wird.
Dass das aber so schnell passiert; das ist schon eine Überraschung.

Denn in vielen Augen - siehe auch den GitHub Link - ist .NET Core aufgrund einiger fehlender Implementierungen noch nicht ready, sodass viele ASP.NET Core aktuell mit dem .NET Framework verwenden und sich natürlich nun vor den Kopf gestoßen fühlen.
Dazu kommt, dass Firmen natürlich auch bereits bestehende Entwicklungen haben und die Wirtschaftlichkeit durch die Wiederverwendung oft eine Rolle spielt.
Da werden leider nur selten Budgets für entsprechende Weiterentwicklung / Migration zur Verfügung gestellt.

Never trust a 1.x Version ist in meinen Augen Käse. Meine persönliche Meinung.
Denn Versionierung sagt in der Software-Welt nichts über den Inhalt oder die Roadmap aus; leider.
Gerade im JavaScript-Umfeld gibt es genug Open Source Bibliotheken, die alle über Jahre mit 0.x arbeiten.
Trotzdem erfreuen sie sich hoher Beliebtheit. Andere Produkte wechseln die Wechsel quasi im Wochentakt; heisst aber nicht, dass es dadurch besser ist.
Versionen ist leider heute oft einfach nur Marketing.

@mfe: welche Einschnitte sind es denn?
Die wichtigsten APIs sind eigentlich abgedeckt; außer im Enterprise-Umfeld, da fehlt System.Speech, System.DirectoryServices und natürlich System.Drawing.

SignalR ist quasi ein eigenes Produkt. Wird als Middleware in ASP.NET Core registriert (AddSignalR/UseSignalR).
Meines Wissens kommt SignalR gemeinsam mit ASP.NET Core 2; will hier aber nicht meine Hand für ins Feuer legen. Kann auch sein, dass sich das mittlerweile geändert hat.

OData verfolge ich aktuell nicht.
Aber ich hab gesehen, dass OData im GitHub issue referenziert wurde ( https://github.com/OData/WebApi/issues/939).
OData 7 hat wohl den Fokus von .NET Standard 2.0; aber ich kenn hier auch kein Datum.

Zu SignalR sei noch gesagt, dass SignalR quasi eine der Gründe ist, wieso so stark auf .NET Core gesetzt wird.
In .NET Core ist der Fokus ganz klar auf Performance vor Kompatibilität.

Das .NET Framework arbeitet mit UTF-16 strings. Netzwerkverkehr arbeitet aber mit UTF-8.
Ergo ist an jeder Stelle eine Konvertierung notwendig - was gerade bei Webanwendungen, wo einfach alles über das Netzwerk läuft - Performance kostet.
Hinzu kommt häufiges Kopieren von Streams/Arrays.

Daher hat das .NET Team die Idee von Channel<T> und Span<T> gehabt: die sogenannten Pushed Based Streams.
Mittlerweile wurde das ganze in Pipelines umbenannt und befindet sich im  Lab Repository von .NET.

Natürlich ist sowas nicht ohne weiteres zu implementieren, wenn ASP.NET mal mit .NET Core und mal mit .NET Framework verwendet wird. Denn die Pipelines können nicht teil des .NET Standards werden.
Es gibt also schon gute Gründe, wieso ASP.NET Core nur mit .NET Core läuft und der Austausch zu .NET Framework nur über den .NET Standard passiert.
Der Zeitpunkt ist aber... unschön. Vor allem unschön kommuniziert.

Naja, Du kannst ja auch EF Core verwenden, was mit .NET Core ja kompatibel ist, sofern Dir die aktuell nur sehr simplen Use Cases, die EF Core unterstützt (zB kein Group By!), ausreichen.
Ich mach eh schon länger nen Bogen um EF und nutze in Projekten Dapper oder NoSQL DBs.

Heise hat hierzu auch schon einen Artikel:  Microsoft will ASP.NET Core nicht mehr auf dem klassischen .NET anbieten

Wenn ich das dem  Kommentar vom Artikel  Build 2017: Microsoft stellt Version 2.0 der .NET-Core-Produkte vor richtig entnehme, wird die RTM Version 2.0 von ASP.NET Core auf .NET Standard 2.0 und so mit auch auf dem Framework .NET 4.x laufen. Die Einschränkung gab es wohl nur für die Preview Version.

Also viel Wind um Nichts?

Damit meinte ich, dass viele Newsseiten jetzt nicht die Meldung nachschieben, dass der Bruch doch nicht kommen wird, sondern lieber weiter dem Sturm der Entrüstung zuschauen, der bei der ersten Meldung losbrach. In diesen Bereichen ist es jetzt wirklich nur noch viel Wind um Nichts.

Etwas ganz anderes ist eine sachliche Diskussion auf den entsprechenden Seiten und Reporitories von MS, vor allem wenn letztere dabei auch zuhören und darauf eingehen. Ein sehr wünschenswertes Verhalten, das ich Seitens Microsoft enorm begrüße. Überhaupt scheint man bei MS seit ein paar Jahren auch deutlich mehr auf die Community einzugehen, siehe z.B. die teils starke Kritik an einigen Funktionen der XBox One, die dann eine teils größere Überarbeitung nach sich gezogen hat.

Mir fehlt also einfach an vielen Stellen im Netz gerade der Hinweis, dass die Leute wieder aufhören können, vor Wut an der Decke zu kreisen, weil die Faktenlage sich geändert hat.