Aspnetcore: Assemblys werden aus Microsoft.AspNetCore.App 3.0 entfernt

Ich denke, MVC-Pakete sollten auch zusätzliche NuGet-Pakete werden. MVC ist großartig, aber im Gegensatz zu Vanilla ASP.NET Core ist es äußerst eigenwillig, wie eine We-Anwendung aufgebaut sein sollte, was wirklich nicht jedermanns Sache ist, geschweige denn zum Paradigma aller .NET-Sprachen passt. Ich glaube wirklich, dass das freigegebene ASP.NET Core-Framework es verdient, MVC-frei zu sein oder eine zweite MVC-freie Version davon zu haben. Was denken Sie?

Was wäre der Nutzen? Wie würde dies das Leben der Menschen verbessern, die ASP.NET Core-Anwendungen erstellen?

Groß! Ich brauche nur das, was ich brauche, wenn ich asp.net Core verwende.

@davidfowl

Was wäre der Nutzen? Wie würde dies das Leben der Menschen verbessern, die ASP.NET Core-Anwendungen erstellen?

Aus den gleichen Gründen, warum Sie die oben in dieser Ausgabe aufgeführten Pakete nicht einschließen. Ich denke nur, dass es immer einfacher ist, dem Framework, das mit .NET Core 3.0 ausgeliefert wird, weitere Pakete hinzuzufügen, als später Pakete zu entfernen. Warum fangen Sie nicht an, den kleinsten gemeinsamen Nenner hinzuzufügen, um eine Vanilla-ASP.NET Core-App auszuführen, und bieten den Rest dann als NuGet-Pakete an. Wenn sich herausstellt, dass dies ein Problem für Entwickler ist, können Sie später immer noch weitere Dinge hinzufügen, aber Sie können Dinge später nicht mehr so ​​einfach entfernen.

Weil wir eine Balance finden müssen, indem wir auch standardmäßig nützlich sind.

Okay, ich denke, Vanilla ASP.NET Core ist bereits nützlich (und ich dachte, Sie denken auch so, warum haben Sie es sonst nicht nützlich gemacht?), aber wenn Sie sich bereits Gedanken darüber gemacht haben, was im Framework enthalten sein sollte und was dann nicht egal ;)

Wenn Sie ein Purist wären, hätten Sie die meisten Middleware oder MVC oder SignalR nicht in der Box, da sie nicht unbedingt erforderlich sind. Diese Grenze zwischen dem, was der Standardsatz von Dingen sein sollte und nicht sein sollte, zu ziehen, ist so ziemlich ein Bauchgefühl und eine unscharfe Sache (basierend auf Erfahrung, Blick auf andere Plattformen in Vergangenheit und Gegenwart und Tätigen eines Anrufs). Ab ASP.NET Core 3.0 haben wir keine Pläne, diese herauszunehmen (zumindest jetzt).

Ja, ich weiß, dass dies immer eine schwierige Entscheidung ist, aber ich bin mir manchmal nicht sicher, was die Rechtfertigung für die Tendenz (von Microsoft) ist, Dinge mehr als nötig aufzublähen. So positionieren Sie Ihre eigenen Produkte am Markt, wie sie wahrgenommen werden. ASP.NET Core soll das neue moderne zusammensetzbare und flexible Webframework sein, aber die Art und Weise, wie Sie alles positionieren, ist, dass ASP.NET Core nutzlos ist, es sei denn, Sie erzwingen MVC + SignalR + Identity + EF für alle. Meiner Meinung nach haben Sie bereits die Entscheidung getroffen, wo die Linien zu ziehen sind, deshalb sind MVC und SignalR nicht in ASP.NET Core eingebettet, sondern separate Frameworks, die auf Wunsch hinzugefügt werden können. Warum verwischen Sie diese Linien jetzt? Es fühlt sich inkonsistent an und ich kann mir keinen Wert vorstellen, den Sie daraus ziehen. Anstatt nur ASP.NET Core + ein florierendes Open-Source-Ökosystem zu fördern, fördern Sie ein sehr enges Weberlebnis. Alles, was es tut, ist Frustration bei denen zu erzeugen, die etwas anders sein wollen und mehr für sich selbst arbeiten wollen, während Sie am Ende Dinge auf die Leute drängen, die sie vielleicht nicht wollen.

Es ist nicht so, dass die Leute MVC nicht verwenden, wenn Sie es nicht in das Standard-Framework stopfen. Machen Sie es zu einem einzigen NuGet-Paket und niemand wird sich beschweren, dass er MVC von NuGet beziehen muss. Es ist wahrscheinlicher, dass mehr Leute kommen und fragen, warum Sie das Standard-Framework mit Dingen aufgebläht haben, die sie nicht wollen, wie ich.

Ich nehme an, dies ist eine Diskussion und immer noch etwas, das Sie in Betracht ziehen könnten. Wenn Sie also eine Frage stellen möchten, ist, diese Frage vielleicht noch einmal mit Ihrem Team zu besprechen und zu sehen, ob Sie alle wirklich darauf eingestellt sind oder ob Sie können meiner Idee gegenüber weicher werden :)

PS: Ich bin mir nicht sicher, ob das der Fall ist, aber ich hoffe, dass SignalR auch ein separates NuGet-Paket ist. Es ist, als ob Sie Bootstrap und Angular2 in Ihr Standard-Framework aufnehmen würden. Wenn diese beiden Produkte von Microsoft entwickelt wurden, würden Sie es wahrscheinlich tun, aber es würde keinen Sinn machen, und ich denke, nur weil sie von einem Drittanbieter entwickelt werden, sehen Sie, dass es keinen Sinn macht.

TBH Ich würde gerne sehen, dass mehr Dinge aus der Standardinstallation entfernt werden. Vor allem MVC. Dies macht alternative Frameworks zusätzlich zu ASP.NET Core noch attraktiver. Außerdem frage ich mich, warum Dinge wie ContentResult in MVC und nicht im Kern leben. Es wird viel in azurblauen Funktionen verwendet und jetzt muss ich immer auf das MVC-Zeug verweisen - nur für ContentResult.

Ich denke, der Punkt ist eher, dass es sich nicht wirklich negativ auf Sie auswirken sollte, das MVC-Zeug im ASPNET SDK zu haben. Die meisten Entwickler werden es verwenden, daher wird der Versand auf diese Weise gegenüber einer aufgeblähten Wiederherstellungslast bevorzugt. Wenn Sie es nicht wollen, können Sie es einfach nicht verwenden. Die meisten der oben aufgeführten Pakete bringen Abhängigkeiten von Drittanbietern (json) mit sich, haben einen schweren Aspekt (Razor) oder sind konzeptionell von ASPNET getrennt und werden oft außerhalb des SDK (EFCore) referenziert.

So sehr ich auch mit der Standardisierung von Mindestwerten einverstanden bin, um gleiche Wettbewerbsbedingungen für OSS-Frameworks zu fördern, muss dies ausgewogen sein. In den frühen Tagen von Core (Beta und sogar 1.0) waren die Dinge überall Pakete und das war VIEL verwirrender und die Wiederherstellung dauerte ewig.

@psibernetic Selbst wenn sich Sachen in getrennten Paketen befinden, kann der .net Core Installer diese Pakete bereits in lokale Caches legen.

@psibernetic Du bist die zweite Person, die erwähnt, dass es wichtig ist, das Gleichgewicht zu halten, aber was bedeutet das überhaupt? Die Balance zwischen was? Reden wir nicht über Extreme, denn das ist offensichtlich nicht gut, sprechen wir hier über realistische Vorschläge. Wenn MVC ein einzelnes NuGet-Paket ist, wie wirkt es sich auf die Benutzerfreundlichkeit aus? Es tut es wirklich nicht und das ist mein Punkt. Zu denken, dass Sie ein Extrem lösen werden, indem Sie das entgegengesetzte Extrem implementieren, ist engstirniges Denken. Dazwischen liegt vieles. Das Framework muss nicht aufgebläht werden und MVC und SignalR müssen auch nicht in 100 Pakete fragmentiert werden. Beides kann gleichzeitig vermieden werden.

Nennen Sie mir einen Fall aus der Praxis, in dem es verwirrend wäre, MVC als einzelnes NuGet-Paket zu haben, die Wiederherstellung ewig dauern würde, oder einer der anderen Nachteile, die Sie erwähnt haben?

Und wenn wir über die Wiederherstellungszeit sprechen...

IMHO ist es wichtiger, schnell startende Container oder eine serverlose Architektur zu haben (da dies einen realen Einfluss auf das Geschäft hat), als einen etwas schnelleren Build auf einem Entwicklercomputer zu haben. Ja, letzteres ist auch enorm wichtig und ich möchte, dass es blitzschnell ist, aber wenn ich die Bedeutung einstufen müsste, nehme ich lieber einen kleinen Schlag auf meine Entwicklungsmaschine als auf meine Produktionsinfrastruktur in der Cloud. Daher ist es nur (wenn nicht sogar wichtiger) wichtig, den Footprint so klein wie möglich zu halten, als die Wiederherstellungszeit gering zu halten.

Was wäre der Nutzen? Wie würde dies das Leben der Menschen verbessern, die ASP.NET Core-Anwendungen erstellen?

Ich denke, es ist unerwünschte Bloatware für alle anderen Benutzer, die MVC nicht verwenden, wie CandyCrush, das auf meinem Windows 10-PC vorinstalliert ist. Asp.net Core predigte, dass es mit vollständig konfigurierbarer Middleware usw. weniger eigensinnig wurde.

Es gibt viele andere Frameworks wie Nancy, ServiceStack und Giraffe, die alle ihre Vorzüge haben und nicht aufgebläht / Konflikte mit einer unerwünschten / unnötigen MVC-Force-Installation haben sollten. Es scheint nur inkonsistent, da Authentifizierung, Rasierer, EF usw. alle im Paket enthalten sind, aber MVC, das goldene Kind, wird Teil des Kernframeworks, wenn es nicht zum Kern gehört?

Wenn es daran liegt, dass MVC so eng mit dem Kern gekoppelt ist, dass eine Entkopplung eine Menge Arbeit bedeuten würde, kann ich das verstehen, aber auf der Grundlage davon, dass es einigen Entwicklern das Leben erleichtert, scheint es faul und dem alten asp.net sehr ähnlich MVC-Mentalität, von der ich gehofft hatte, dass wir wegsteuern.

.NET Core sollte der schlanke modulare Klon von node.js für .NET sein, aber es sieht nicht so aus, als hätte er die Absicht, die Eigenschaften zu replizieren, die sein florierendes, dynamisches Ökosystem fördern – ein kleiner, flexibler, uneinsichtiger Kern mit enthaltenen Funktionen im Kern von all dem profitiert, da es nicht mit einem meinungsstarken Web-Framework gebündelt ist, ist es reif für Experimente und genießt eine gesunde Anzahl beliebter Frameworks mit ihren eigenen unabhängigen Communities.

Ich meine, das ASP.NET-Team glaubt, dass es das bestmögliche Framework entwickelt, aber nicht alle sind mit allen ausgewählten Meinungen oder dem erforderlichen Komplexitätsgrad einverstanden, um etwas zu erledigen. Alles in .NET Core wurde im Nachhinein entwickelt, wobei vieles von Ansätzen inspiriert wurde, die auf anderen Plattformen erfolgreich waren Wenn das nächste Ding auf anderen Plattformen an Fahrt gewinnt, wird ASP.NET Core im Nachteil sein, seinen Erfolg zu wiederholen, da wir in Zukunft für immer die standardmäßige "MVC-Steuer" zahlen werden, bei der jeder sein Entwicklungsmodell für alle Web verwenden soll Apps bis ins Unendliche.

Die Leichtigkeit von Node macht es auch für die Entwicklung einer Reihe anderer Anwendungsfälle wie Electron, Native Mobile Apps, IOT, Shell-Skripte usw. geeignet. Je aufgeblähter die Standardinstallation wird, desto weniger nützlich ist sie für die Verwendung in anderen Szenarien.

IMO sollte die Standardeinstellung wieder die ursprüngliche Vision von .NET Core sein, einen schlanken, modularen Kern zu haben, wobei der Schwerpunkt darauf liegt, das Hinzufügen von Funktionen zu erleichtern (die jeder nutzen kann), dh nicht durch standardmäßiges Bündeln und Aufblähen der Standardeinstellung Installieren.

Danke für die Bewertung. Lassen Sie mich einige Gedanken teilen.

1. Wir beschneiden keine Baugruppen, weil wir einfach Lust dazu haben. Jede Baugruppe, die wir entfernen, ist eine bahnbrechende Änderung und erhöht die Kosten für das Upgrade von 2.x auf 3.0. Dies sind die Leitprinzipien, nach denen wir entscheiden, was in Microsoft.AspNetCore.App eingeht :

2. Das Entfernen von MVC aus Microsoft.AspNetCore.App ist nicht etwas, was wir in Betracht ziehen würden. Obwohl wir erkennen, dass nicht jeder Benutzer in seiner Anwendung auf MVC verweist, glauben wir, dass dies ein zentraler Bestandteil des Angebots von ASP.NET Core ist. Wir planen, dies in Microsoft.AspNetCore.App beizubehalten.

3. MVC ist seit 2.1 Teil von Microsoft.AspNetCore.App, aber wie Sie in 2.1 "Empty Web"-Vorlagen sehen werden , müssen Sie MVC nicht verwenden. Sein Vorhandensein im freigegebenen Framework zwingt Sie nicht, es in Ihrer Anwendung zu verwenden. Sie können weiterhin gerne Alternativen verwenden, Ihr eigenes View-Framework schreiben oder die "roheren" aspnetcore-APIs verwenden, um HTTP-Anforderungen und -Antworten direkt zu lesen und zu schreiben.

4. @dustinmoris : Ich denke nur, dass es immer einfacher ist, dem Framework, das mit .NET Core 3.0 ausgeliefert wird, weitere Pakete hinzuzufügen, als später Pakete zu entfernen. Warum fangen Sie nicht an, den kleinsten gemeinsamen Nenner hinzuzufügen, um eine Vanilla-ASP.NET Core-App auszuführen, und bieten den Rest dann als NuGet-Pakete an. Wenn sich herausstellt, dass dies ein Problem für Entwickler ist, können Sie später immer noch weitere Dinge hinzufügen, aber Sie können Dinge später nicht mehr so ​​einfach entfernen.

   Genau das versuchen wir. Es ist einfacher hinzuzufügen als zu entfernen. Wir haben in 2.0 zu viele Dinge hinzugefügt und stellen uns wieder auf das ein, was unserer Meinung nach für den absehbaren Weg wartbar ist. Die meisten Assemblys, die aus Microsoft.AspNetCore.App entfernt wurden, werden weiterhin als NuGet-Pakete angeboten. Wenn wir später feststellen sollten, dass 90 % aller Kunden auf dasselbe Paket verweisen, ist dies ein guter Kandidat für das gemeinsame Framework. Wie in der Anleitung erwähnt , ist die Nutzung einer API jedoch eine wichtige Kennzahl, aber nicht der einzige Faktor, den wir berücksichtigen.

5. "Vanille" ist subjektiv. Für viele unserer Benutzer sind MVC und SignalR "Vanille".

6. Einige Leute haben gesagt, dass .NET Core dies oder das oder etwas anderes sein sollte. Die Dinge ändern sich, wir sammeln Benutzerfeedback, wir beobachten, wie das Produkt verwendet wird, und wir versuchen, die Standardeinstellungen so anzupassen, dass sie unserer Meinung nach der größten Anzahl von Kunden zugutekommen. Die in dieser Ausgabe vorgeschlagenen Anpassungen spiegeln das Feedback wider, das wir zu .NET Core 2.x erhalten haben.

Abschließender Gedanke: Dieses Thema wird nicht alle glücklich machen. Wenn es so aussieht, als würden wir Ihr Feedback ignorieren, bitte ich um Entschuldigung. Bitte beachten Sie, dass wir Hunderttausende von Kunden haben und nur wenige von ihnen zu GitHub kommen, um Feedback zu geben. Wir erfassen auch Informationen aus persönlichen Besuchen, Telefonaten, E-Mails, sozialen Medien, Kundensupportanfragen, Blogs, Visual Studio-Telemetrie und mehr. All dies ist Teil dessen, was wir bei unseren Entscheidungen berücksichtigen und was Teil der Standarderfahrung ist und was nicht.

Wenn etwas über unsere Motivationen oder Gründe nicht klar ist, lassen Sie es mich bitte wissen und ich werde versuchen, es zu klären.

Wenn Sie so viel direkten Kundenkontakt haben, wann haben Sie das letzte Mal gefragt, wie viele von ihnen MVC und SignalR verwenden? Gibt es echte Nutzungsmetriken hinter dieser Haltung, sie definitiv beizubehalten, anstatt sie in einem einzigen NuGet-Paket zu haben, das bei Bedarf sehr einfach installiert werden kann?

@dustinmoris die Einbeziehung von MVC in die gemeinsame Laufzeit bedeutet, dass es vorkompiliert

All dies gesagt, und wohlgemerkt, ich habe keine Zugehörigkeit zum Microsoft- oder Aspnet-Team, KONNTE ICH eine separate Laufzeit mit Aspnetcore-Barebones ausgeliefert sehen, WENN die Community es wirklich aussprach und bewies, dass es ein großer Wunsch war. Die Mission besteht darin, so vielen Anwendungen und Entwicklern wie möglich ein großartiges Erlebnis zu bieten, und die Tatsache, dass derzeit ein unglaublich hoher Prozentsatz von denen von MVC in der gemeinsamen Laufzeit profitiert. @natemcmaster Gibt es eine bevorzugte Möglichkeit für die betroffenen Personen, für die Zukunft, GitHub-Problem, zu stimmen, und ist dies eine vernünftige Lösung?

@psibernetic Sie können gerne ein neues GitHub-Problem starten, um MVC aus dem freigegebenen Framework zu entfernen, aber wie ich oben erwähnt habe, würden wir das Entfernen von MVC aus Microsoft.AspNetCore.App nicht in Betracht ziehen, daher ist es unwahrscheinlich, dass dieses Problem innerhalb des Unternehmens an Bedeutung gewinnt unser Team.

@Bomret Fast jede reale Kunden-App, die wir inspiziert haben, verwendet MVC in irgendeiner Weise. Es hat viele Vorteile, es im gemeinsamen Framework zu belassen, und ich sehe keine klaren Gründe, warum wir es entfernen sollten.

@Natemcmaster : Ich telefoniere jetzt, aber danke für die Erklärung und ich bin einfach
gemerkt, dass es hier um das Metapaket geht, während ich über das sprach
gemeinsamen Rahmen.

@natemcmaster Ich denke, @forki , @dustinmorris , @gerardtoconnor und @mythz haben sehr

Es heißt "Microsoft.AspNetCore.App", warum nicht ein zweites "Microsoft.AspNetCoreMVC.App" erstellen?

Wie auch immer, ich verstehe, dass es sehr schwer ist, eine Grenze zu ziehen, aber ich denke, das allgemeine Feedback hier ist, dass es eine wachsende Anzahl von Leuten gibt, die mögen, was Sie mit Aspnet Core gemacht haben, aber die Dinge wie MVC, Rasiermesser nicht wirklich mögen , EF oder signalR.

In der Tat. Sie können sich darauf verlassen, dass die Community lebendig genug ist, um eine Menge Ideen für Bibliotheken und Frameworks zu liefern, die mit API, Web, Websockets, Vorlagen, DB-Zugriff usw. umgehen. Sie würden eine Option für diejenigen mit MVC, Razor, EF usw. anbieten, aber nicht die einzige oder Standardoption.

@natemcmaster Mein Fehler, ich habe hier in dieser Ausgabe tatsächlich über das gemeinsame Framework gesprochen. Ich denke, die gleichen Gründe gelten auch für das Meta-Paket, aber das stört mich ehrlich gesagt weniger, da ich bereits auf einzelne Pakete anstelle des Meta-Pakets verweisen kann, aber ein gemeinsames Framework nicht einfach kürzen kann, wenn ich es behalten möchte einen möglichst kleinen Container, daher macht dein Vorschlag, eine neue Ausgabe für das Shared Framework zu eröffnen, Sinn 👍

@natemcmaster Könnten Sie schnell bestätigen, ob ich die Dinge richtig verstanden habe:

• In die nächste .NET Core-Runtime (3.0) wird ein gemeinsames ASP.NET Core-Framework integriert, was bedeutet, dass ASP.NET Core als Teil der .NET Core-Installation in einer Umgebung ausgeliefert wird.

• Darüber hinaus gibt es ein Metapaket namens Microsoft.AspNetCore.App und Microsoft.AspNetCore.All die eine Sammlung von NuGet-Paketen für ASP.NET Core-Apps sind

• Das freigegebene ASP.NET Core-Framework < das Microsoft.AspNetCore.App Metapaket, das Dinge wie EF Core enthält?

• Ich kann eine ASP.NET Core-Web-App erstellen, ohne das Microsoft.AspNetCore.App -Metapaket einschließen zu müssen, das EF Core, SignalR, MVC usw. enthält, wenn ich nur eine extrem kleine API erstellen möchte?

• Was auch immer Sie tun, es wird möglich sein, einen Docker-Container mit nur minimalen Abhängigkeiten für ASP.NET Core zu erstellen, um eine winzige API auszuführen?

In die nächste .NET Core-Runtime (3.0) wird ein gemeinsames ASP.NET Core-Framework integriert, was bedeutet, dass ASP.NET Core als Teil der .NET Core-Installation in einer Umgebung ausgeliefert wird.

Jawohl

Darüber hinaus gibt es ein Metapaket namens Microsoft.AspNetCore.App und Microsoft.AspNetCore.All, bei dem es sich um eine Sammlung von NuGet-Paketen für ASP.NET Core-Apps handelt

Nein. Es gibt ein neues Konzept namens FrameworkReference und Microsoft.AspNetCore.App wird eines davon sein. Microsoft.AspNetCore.All wird in 3.0 nicht vorhanden sein.

Das freigegebene ASP.NET Core-Framework < das Microsoft.AspNetCore.App-Metapaket, das Dinge wie EF Core enthält?

Nein, EF ist nicht enthalten.

Was auch immer Sie tun, es wird möglich sein, einen Docker-Container mit nur minimalen Abhängigkeiten für ASP.NET Core zu erstellen, um eine winzige API auszuführen?

Mit dem Trimmen von Assemblys und dem Linker ja, nicht durch Entfernen von Paketen, da es keine für ASP.NET Core geben wird.

@natemcmaster

Wir beschneiden keine Baugruppen, weil wir einfach Lust dazu haben. Jede Baugruppe, die wir entfernen, ist eine bahnbrechende Änderung und erhöht die Kosten für das Upgrade von 2.x auf 3.0.

Der richtige Ort, um Korrekturen vorzunehmen, wäre das Fenster der Hauptversion von v3, das praktisch das einzige Mal ist, dass solche Änderungen auftreten können, dh gleichzeitig mit anderen Paketen entfernt werden.

Das Entfernen von MVC aus Microsoft.AspNetCore.App ist nicht etwas, was wir in Betracht ziehen würden. Wir erkennen zwar an, dass nicht jeder Benutzer in seiner Anwendung auf MVC verweist.

Es heißt "Microsoft.AspNetCore.App", was logisch als "auf dieses Paket verweisen" gelesen wird, wenn Sie eine "ASP.NET Core-App" erstellen.

Wir glauben, dass dies ein zentraler Bestandteil des Angebots von ASP.NET Core ist. Wir planen, dies in Microsoft.AspNetCore.App beizubehalten.

Dies nähert sich dem Kern des Problems, bei dem es den Anschein hat, dass die Ziele von ASP.NET Core sich von der Förderung eines schlanken, offenen Ökosystems im Stil von node.js entfernen. Ist es die Absicht des Teams, ASP.NET Core-Apps als Synonym für MVC-Apps zu kombinieren? Einige der Verkaufsargumente von ASP.NET Core waren "Pay to play" und entkoppeltes "Layering", aber dies deutet darauf hin, dass eine "ASP.NET Core-App" für immer als MVC-App gedacht ist.

Es wäre für alle Beteiligten klarer, wenn die Pakete expliziter wären, wo:

• Microsoft.AspNetCore.App => Basis für alle ASP.NET Core Apps
• Microsoft.AspNetCore.Mvc => ASP.NET Core MVC-App

Aber wenn "Microsoft.AspNetCore.App" unantastbar ist, könnten wir zumindest ein offizielles "Baseline"-Metapaket (oder FrameworkReference) mit nur den Kernserverfunktionen (dh ohne rechthaberische Libs) haben, einige mögliche Namen:

• Microsoft.AspNetCore.[Basis | Nackt | Lite | Basic]

("Core" wäre auch angemessen gewesen, aber es gibt bereits eine Überverwendung des Begriffs).

Ohne ein offizielles Metapaket/Namen ist es nicht so zugänglich wie die derzeit empfohlene "Microsoft.AspNetCore.App", die die empfohlene Basis für alle ASP.NET Core-Apps ist.

Einschränkungen führen zu Innovationen, wenn MVC nur auf dem gleichen Spielfeld wie alle anderen laufen könnte, könnten wir vielleicht alle Zugang zu einer Funktion haben, die es uns ermöglicht, einfach und explizit anzugeben, welche Produkte (auch bekannt als Paketpakete) Apps benötigen, z. B. könnte es etwas aussehen mögen:

• Microsoft.AspNetCore.Mvc+SignalR+EF

Wo jeder einfach deklarieren und nur installieren konnte, was er brauchte und die Tools hinter den Kulissen die Metapakete "Microsoft.AspNetCore.Mvc", "Microsoft.AspNetCore.SignalR" und "Microsoft.AspNetCore.EF" kombinieren könnten. (Oder alternativ überlegene Lösung, um die Absicht zu erfüllen).

Sein Vorhandensein im freigegebenen Framework zwingt Sie nicht, es in Ihrer Anwendung zu verwenden.

Klingt nach der Begründung für jeden Monolith, der jemals geschaffen wurde. "Sie müssen nicht alles verwenden, was wir bündeln, es ist nur für Ihre Bequemlichkeit da".

Sie können weiterhin gerne Alternativen verwenden, Ihr eigenes View-Framework schreiben,

Es ist nicht so einladend, wie Sie vielleicht denken. Während wir beispielsweise unsere eigene "View Framework"-Alternative zu MVC und Razor entwickelten, stießen wir in .NET Core auf ein magisches Verhalten, bei dem der Build beim Ausführen des Standardbefehls zum Veröffentlichen einer . NET Core-Projekt, dh:

 dotnet publish -c Release

Was würde scheitern an:

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

Überraschendes Verhalten angesichts der Tatsache, dass wir eine Alternative zu MVC entwickelten, die explizit nicht auf MVC, Razor oder .cshtml Seiten verweist, da ihr Zweck darin bestand, Apps zu erstellen, ohne sie zu verwenden.

Nachdem ich mehrere GitHub-Threads durchsucht hatte, um verschiedene Problemumgehungen auszuprobieren, stellte ich fest, dass andere das gleiche Problem hatten, bei dem die Lösung die MVC Razor-Kompilierung deaktivierte, die Builds bricht:

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

Dadurch konnte das Projekt veröffentlicht werden. Während des Testens verschiedener Switches zur Behebung des defekten Builds haben wir auch festgestellt, dass wir unseren veröffentlichten Footprint um die 150 .dlls in /refs/*.dll reduzieren konnten, indem wir die Metadaten, die unsere .NET Core 2.0 Web App unnötig aufblähten, abwählten Abmelden von Metadaten, die von Razor benötigt werden, mit:

<PreserveCompilationContext>false</PreserveCompilationContext>

Also im Grunde gezwungen, Whack-a-Mole zu spielen, um herauszufinden, welche Schalter wir benötigen, um den Tools mitzuteilen, dass wir MVC nicht verwenden, um zu verhindern, dass Projekt-Builds beschädigt werden und unnötige Metadaten ausgegeben werden, die nur MVC/Razor-Apps benötigen. Es wäre viel besser gewesen, mit einem "Basis"-Metadatenpaket zu beginnen, bei dem solche Probleme nicht möglich waren, da die Tools nicht davon ausgehen konnten, dass jede App MVC verwendet, da die MVC-Bits nicht vorhanden wären.

Obwohl es leicht zu sagen ist, dass ASP.NET Core immer noch eine einladende Plattform ist, die das Experimentieren, Erstellen und Verwenden alternativer "Ansichtsframeworks" fördert, ist die Bündelung vorgeschriebener meinungsorientierter Webframeworks wie MVC so ziemlich die feindseligste Maßnahme, um die Erstellung zu verhindern und Nutzung der genannten Alternativen. Sich einen Moment Zeit zu nehmen, um sich die Anzahl der beliebten Alternativen anzusehen, die auftauchen, ist ein guter Gradmesser, um zu sehen, wie einladend die Plattform für sie ist.

Wenn beabsichtigt ist, dass jede ASP.NET Core-App MVC enthalten soll als jedes andere alternative "Ansichtsframework" (einschließlich eines einzelnen .cs Datei-Drop-Ins von ext-Methoden) wird es "schwerer" erscheinen " und umständlicher als die Verwendung des gebündelten MVC, da alle damit gebündelt werden müssen + alles andere, was das View-Framework benötigt.

Zusammenfassend wäre es vorzuziehen, wenn "MVC" opt-in wäre und nicht im .App Paket enthalten wäre, aber wenn die Entscheidung irreversibel ist, könnten wir zumindest eine offizielle Basis-Metapaket-Basis haben, die dies tut nicht enthalten?

Bitte beachten Sie, dass wir Hunderttausende von Kunden haben und nur wenige von ihnen zu GitHub kommen, um Feedback zu geben.

IMO ist die Nachfrage nach nicht aufgeblähten Startpaketen unterrepräsentiert, Anekdote: Von allen C#/.NET-Projektvorlagen, die wir für VS 2012, VS 2013, VS 2015, VS 2017 und .NET Core erstellt haben, ist dies durchweg die beliebteste Vorlage war bei weitem immer die "leere" Vorlage, was auch eine häufige Kritik am klassischen ASP.NET war, dass die standardmäßige leere ASP.NET-Vorlage von VS.NET nicht leer genug war. Dies war der Zeitpunkt, an dem Sie ein "leeres" klassisches ASP.NET .NET Framework ohne MVC erstellen konnten, aber jetzt im neueren, leichteren und modulareren ASP.NET Core-Framework wird MVC im empfohlenen Mindeststartpaket gebündelt.

Wir sammeln auch Informationen aus persönlichen Besuchen, Telefonaten, E-Mails, sozialen Medien, Kundensupportanfragen, Blogs

Die Leute mögen kein Aufblähen, das oft mit nicht entfernbarer Komplexität gleichgesetzt wird. Wahrscheinlich wird gefordert, Projekte so einfach wie möglich zu gestalten, was im Mittelpunkt stehen sollte und ohne aufgeblähte Standardprojekte durchgeführt werden kann.

Nach meiner Erfahrung ist es einfacher, explizit zu sein als aufgeblähte Frameworks mit magischem Verhalten. Wenn es explizit ist, können Sie damit interagieren, danach suchen, darüber lesen, entfernen, testen, ohne es zu verwenden (um zu sehen, ob dies die Ursache von Problemen ist) und es ist sichtbar, wenn Projekte unterschiedlicher Konfigurationen verglichen werden. Aber mit dem magischen Verhalten von MVC-Tooling, das Builds meines mvc / rasiermesserlosen Projekts oben zerstört, hatte ich keine Ahnung, welcher Teil meines Projekts es auslöste, warum es überhaupt läuft, wie man es deaktiviert oder wie man es auflöst. Ich bin immer noch nicht sicher, dass meine Projekte, die MVC nicht verwenden, nicht verlangsamt werden, weil MVC gebündelt ist oder dass es eine suboptimale Ausgabe erzeugt, weil es MVC oder Razor aufnehmen muss.

Visual Studio-Telemetrie und mehr.

Es wird schwierig sein, die Telemetrie der Popularität eines Basis-Metapakets zu vergleichen, das nicht existiert, wenn es IMO wäre, hätte es mehr als genug Popularität, um seine Aufnahme zu verdienen. Früher zielte "Microsoft.AspNetCore.All" auf das andere Ende des Spektrums ab und umfasste das Universum, aber nicht die nützlichere Umkehrung einer minimalen nützlichen Baseline.

Es liegt auf der Hand, dass Sie, wenn Sie keine MVC-App erstellen und die Option, eine Baseline ohne sie zu wählen, genauso zugänglich sind, warum sollten Sie sie nicht der aufgeblähteren Starteroption mit MVC vorziehen?

@Bomret

Wäre sehr schön gewesen, eine grundlegende Web-Laufzeit/-lib zu haben, auf die Framework-Autoren wie nodejs aufbauen könnten, anstatt meinungsbildendes Zeug damit zu bündeln.

Aber genau so funktioniert es. Es steht Ihnen frei, Ihre Bewerbung so zu gestalten, wie Sie sie verwenden möchten. Wenn Sie MVC nicht verwenden möchten, fügen Sie die Middleware einfach nicht hinzu. Ja, die Vorlagen sind optional, aber Sie können Ihre App ändern, um das zu tun, was Sie möchten, und verwenden, was Sie wollen.

Ich denke, Sie interpretieren das gemeinsame Framework hier ein wenig falsch. Sie müssen es nur als eine Art Standardbibliothek sehen, die mit .NET Core geliefert wird. So erstellen Sie eine Node-Referenz: Stellen Sie sich vor, die aktuelle Version von Express wäre mit Node. Sie _müssen_ es nicht benutzen, aber es ist bereits da, wenn Sie es verwenden möchten.

Und was MVC betrifft, so wissen Sie meiner Meinung nach nicht genau, was MVC tatsächlich in ASP.NET Core enthält. Wenn Sie keine Controller und Razor-Ansichten verwenden möchten, ist dies in Ordnung, aber Sie werden wahrscheinlich trotzdem ziemlich viele MVC-Funktionen in Ihrer App verwenden.

Wenn Sie keine Controller und Razor-Ansichten verwenden möchten, ist dies in Ordnung, aber Sie werden wahrscheinlich trotzdem ziemlich viele MVC-Funktionen in Ihrer App verwenden.

Wie was?

Wenn Sie keine Controller und Razor-Ansichten verwenden möchten, ist dies in Ordnung, aber Sie werden wahrscheinlich trotzdem ziemlich viele MVC-Funktionen in Ihrer App verwenden.

Ja, bitte sagen Sie es, kommt etwas herablassend rüber, die meisten von uns sind an alternativen Frameworks beteiligt, die auf Core-Middleware/Kestrel basieren, also haben wir eine gute Vorstellung davon, was wir verwenden, Controller und Razor-Ansichten sind eine kleine Teilmenge von MVC, wir weiß das. Die F#-Frameworks Giraffe/Saturn & Zebra sind mit besserem Routing und vereinfachtem Verarbeitungsmodell besser als MVC. Beim Rendern ist Zebra x2 schneller als MVC auf TechEmpower, deshalb halten wir es standardmäßig eher außen vor. Wenn Assembly-Trimming/Linker später in der Lage ist, den Footprint zu reduzieren, ist dies zumindest etwas, aber ideal, wenn es nicht standardmäßig enthalten wäre, um ein gleichmäßigeres Spielfeld für andere Frameworks zu ermöglichen, maximieren Sie die asp.net-Kernplattform.

@mythz aus organisatorischer Sicht hast du Recht, hier gibt es einige logische Trennungen. Jede Unterteilung ist jedoch mit erheblich mehr Komplexität und technischem Aufwand verbunden, der Zeit für die Verbesserung der Produktfunktionen in Anspruch nimmt. Wenn wir erwarten, dass eine deutliche Mehrheit der Kunden die MVC-Komponenten nutzt, lohnt es sich einfach nicht, sie aufzuteilen. Die Nachteile für Entwickler, die sie nicht verwenden, sind vernachlässigbar, ein paar zusätzliche MB im Installationsverzeichnis und keine Auswirkungen auf die Laufzeit, es sei denn, Sie laden sie.

Ich kann nur auf @mythz verweisen , um den Punkt zu veranschaulichen. Je mehr gekoppelte Dinge sind, desto mehr verschränken sie sich. Ich meine Wat!? MVC beeinflusst den Build einer Asp-App, auch wenn Sie nirgendwo darauf verweisen?!

@Sack
Wie die anderen schon geschrieben haben: ist es nicht. Es bündelt Dinge, die nichts mit einer Basislaufzeit zu tun haben. Stellen Sie sich vor, das Express-Framework wäre standardmäßig mit Node gebündelt worden, denken Sie, dass das Ökosystem so lebendig und vielfältig geworden wäre?

Ich verstehe auch absolut nicht, wie das Entfernen von MVC, SingalR usw. aus der Basisinstallation und das Bereitstellen als einzelnes NuGet-Paket jeweils als „added complex“ bezeichnet werden kann. Entwickler installieren in den meisten Fällen sowieso zusätzliche Pakete. Und wenn die Bereitstellung als Extrapaket die Wiederherstellungszeiten „deutlich“ erhöhen würde, sind sie sowieso zu fett.

@Tratcher

Jedoch jede Unterteilung

Die Unterteilung, auf die sich dies bezieht, ist die Entkopplung von MVC, sodass ASP.NET Core-Apps eine minimale nützliche Baseline ohne eigenwillige Entwicklerframeworks haben könnten, die vorschreiben, was sie zum Entwickeln von ASP.NET Core-Apps verwenden sollten.

kommt mit erheblich erhöhter Komplexität und zusätzlichem Engineering-Aufwand, der Zeit für die Verbesserung der Produktfunktionen in Anspruch nimmt.

Um dies zu verdeutlichen: Es erfordert zu viel Engineering-Overhead, um unnötigen Overhead von jeder ASP.NET Core-App zu entfernen, die MVC nicht verwendet, denn wenn MVC wie jedes andere alternative Framework funktionieren müsste, würde dies "MVC" erheblich komplexer machen.

Wenn MVC eine erhebliche Komplexität erfordert, um mit den gleichen Erweiterbarkeitsoptionen zu arbeiten, in denen jedes andere alternative Framework funktionieren muss, ist dies ein Hinweis auf ein Problem mit MVC und alle Funktionen, die hinzugefügt wurden, um es nahtloser zu machen, könnten zum Vorteil aller hinzugefügt werden. Genau wie beim Zerlegen eines Monolithen wäre die Komplexität der Werkzeuge und der Laufzeit schlanker und weniger komplex, da die zusätzliche Komplexität dorthin verschoben würde, wo sie in MVC und seine Integration/Werkzeuge hingehört.

Stattdessen landeten wir in der Situation, in der MVC in den Standardwerkzeugen verankert ist, was Veröffentlichungsprojekte zerstören und die Ausgaben von Projekten aufblähen kann, die es nicht verwenden. Da es nicht wie alles andere funktioniert, gibt es keine Möglichkeit, ihm mitzuteilen, dass Sie MVC verwenden, oder ihm mitzuteilen, dass Sie MVC nicht verwenden, es wird immer davon ausgegangen.

Wenn wir davon ausgehen, dass eine deutliche Mehrheit der Kunden die Vorteile der MVC-Komponenten nutzen wird

Nun, das ist zu erwarten, zum Nachteil jeder anderen Alternative ist es das vorgeschriebene Framework, das in der empfohlenen Standardinstallation enthalten ist, wie Apple jedem einen kostenlosen U2-Song gibt, ob er es mag oder nicht.

Die Nachteile für Entwickler, die sie nicht verwenden, sind vernachlässigbar

Würden Entwickler von einem gesünderen Ökosystem mit mehr Vielfalt, Optionen und Innovation profitieren?

Profitieren Entwickler von der zusätzlichen Verwirrung und der unscharfen Definition dessen, was eine "ASP.NET Core-App" ist? "Früher war es wie node.js für Die App ist standardmäßig mit Express und seinen Abhängigkeiten vorinstalliert - es wird erwartet, dass Sie sie verwenden."

Profitieren Entwickler von dem speziellen Gehäuse von MVC? Es wird nicht wie alles andere installiert oder aktualisiert und basiert auf versteckten Werkzeugen und magischem Verhalten, das Sie durchsuchen müssen, um zu wissen, dass es existiert, und es deaktivieren. Spezielle Gehäuse wie diese erhöhen die versehentliche Komplexität. Wenn Sie über Ihr Projekt nachdenken, müssen Sie andere Regeln für die Funktionsweise von MVC als für alles andere einhalten.

Wenn es explizit wäre, würde es die Lesbarkeit verbessern und Sie könnten an der Projektkonfiguration erkennen, dass es sich um eine MVC-App handelt, z.

• Microsoft.AspNetCore.Mvc

Was signalisiert, dass es sich um eine MVC-App handelt und alle Abhängigkeiten zu installieren und alle MVC-Anforderungen für maßgeschneiderte Werkzeuge automatisch zu konfigurieren - idealerweise mit demselben offenen erweiterbaren Modell, auf das alle anderen Zugriff haben.

Indem Sie es im Standardprojekt "Microsoft.AspNetCore.App" belassen, binden Sie es für immer mit jeder ASP.NET Core-App und machen es nachteilig für bessere Ergebnisse. ASP.NET Web Pages war ein weiteres Razor-View-Framework, das ASP.NET vor Jahren hinzugefügt wurde und dessen invasives magisches Verhalten standardmäßig aktiviert war. Es wurde mit einer eigenen Web Matrix IDE geliefert, die nicht mehr unterstützt oder zum Download verfügbar ist. Was uns also bleibt, ist ein Fall, in dem die Komplexität einer toten Technologie für immer in das klassische ASP.NET eingebettet ist und aktiv Probleme für andere aktive Web Frameworks verursacht die Verwendung von Razor .cshtml Seiten, die für immer das unten stehende Gepäck mit sich herumtragen müssen, um explizit zu verhindern, dass Webseiten ihre View-Frameworks durchbrechen mit:

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

Um die Funktionsanfragen in der Reihenfolge ihrer Präferenz zu wiederholen, wäre:

1. Ändern Sie "Microsoft.AspNetCore.App" als minimale nützliche Baseline für alle ASP.NET Core-Apps (dh ohne MVC).
2. Pflegen Sie ein Metapaket wie "Microsoft.AspNetCore.Base", das jeder, der MVC nicht verwendet, als minimale nützliche Basislinie verwenden kann.

Wenn nichts davon in Betracht gezogen wird, können wir zumindest ein projektweites Flag wie mvc:enabled = false , gegen das alle MVC-Tools prüfen könnten, um sie zu deaktivieren und ihre Ausführung zu verhindern?

@mythz du

Wenn nichts davon in Betracht gezogen wird, können wir zumindest ein projektweites Flag wie

Können Sie genauere Angaben dazu machen, welche Werkzeugfunktionen Sie deaktivieren möchten? Das wäre vielleicht eine separate Ausgabe wert.

@Tratcher

Die zusätzliche Komplexität betrifft nicht MVC, sondern die Erstellung von Infrastruktur, Verpackung, Installationsprogrammen usw., die erforderlich sind, um eine weitere Schicht von Komponenten zu erstellen und zu versenden, unabhängig davon, woraus diese Schichtung besteht.

dh die zusätzliche Komplexität dessen, was erforderlich wäre, um MVC zum Laufen zu bringen.

Können Sie genauere Angaben dazu machen, welche Werkzeugfunktionen Sie deaktivieren möchten? Das wäre vielleicht eine separate Ausgabe wert.

Die 2 Probleme, auf die ich stieß, waren die manuelle Konfiguration von /p:MvcRazorCompileOnPublish=false was die Veröffentlichung meines Projekts (ohne .cshtml-Seiten) verhinderte. Das andere Flag, das deaktiviert werden sollte, ist:

<PreserveCompilationContext>false</PreserveCompilationContext>

Wie bei den meisten magischen Verhaltensweisen gehe ich davon aus, dass es mehr gibt, aber ich finde es erst heraus, wenn ich darauf stoße.

Grundsätzlich ein Flag, um anzugeben, dass MVC nicht verwendet wird, und um alle standardmäßig aktivierten Tools oder Konzessionen zu deaktivieren, die aufgrund von MVC hinzugefügt wurden.

@mythz mach weiter und

Sie können tatsächlich ein ähnliches freigegebenes Framework für den Dienststapel erstellen, wenn die zusätzlichen MVC- und SignalR-DLLs für Ihre Benutzer ein Problem darstellen.

@davidfowl Das klingt eigentlich ziemlich großartig, ich konnte ein paar verschiedene Anwendungsfälle für von der Community bereitgestellte Frameworks sehen. Gibt es dazu eine Dokumentation?

Wie Sie sich vorstellen können, würden wir dafür keinen erstklassigen Support aufbauen, da die Anzahl der Personen, die dies tun, gering ist. Das heißt, Sie können sich ansehen, wie wir unsere bauen und dieses Verhalten nachahmen.

@davidfowl Das minimale Basispaket wäre für alle Nicht-MVC-Apps nützlich - z. B. gibt es viele andere leichte Apps und Mikrodienste, die alle Frameworks umgehen und direkt in die Antwort selbst schreiben möchten. IMO sollte diese Option in der Box verfügbar sein, wir würden es vorziehen, nicht von einer inoffiziellen Basis aus Paketversionen zu starten, über die wir keine Kontrolle haben. Idealerweise würde alles aus dem Basispaket addiert werden, anstatt von einer anderen Tangente auszugehen, die extern gepflegt wird. Aber vielleicht ist dies ein Bereich, in dem die externe Community zusammenkommen kann, um eine grundlegende "AspNetCore"-Untergruppe zu verwalten, die für alle Nicht-MVC-Apps und -Frameworks nützlich ist.

Wo sollten wir vor diesem Hintergrund suchen, um ein benutzerdefiniertes Framework zu erstellen? Vielleicht ist es so einfach, mit einer Kopie dessen zu beginnen, was zum Erstellen von "Microsoft.AspNetCore.App" verwendet wurde, und alle nicht wesentlichen Bibliotheken zu entfernen, um sie auf eine minimale nützliche Teilmenge zurückzuführen.

@mythz warum brauchst du überhaupt ein Framework, du kannst den Kestrel-Server einfach direkt verwenden. Dies nur um zu sagen, dass Ihre Version von Licht vielleicht nicht die Vorstellung von Licht oder Kern von jemand anderem ist. Wir haben derzeit eine Meinung und es wäre erstaunlich, wenn die Community hier vorgehen und Vorlagen und ein alternatives gemeinsames Framework erstellen könnte, das ausreichend minimal ist. Wir sind OSS, alles was man braucht um etwas Custom zu machen ist da und wir sind sehr reaktionsschnell und helfen gerne weiter.

@natemcmaster Kann mit Details zum

@davidfowl Sie haben vorgeschlagen, ein benutzerdefiniertes zu

Dies nur um zu sagen, dass Ihre Version von Licht vielleicht nicht die Vorstellung von Licht oder Kern von jemand anderem ist.

Alle scheinen sich hier ziemlich einig zu sein, dass MVC nicht in das Basispaket gehört. Das einzige andere "Produkt", das enthalten zu sein scheint, ist SignalR, das meiner Meinung nach weniger genutzt wird als MVC und weniger Grund für die Aufnahme. Ich bin mit dem Inhalt der einzelnen Pakete nicht genau vertraut, aber alles andere scheint allgemein nützlich und ein förderlicher Teil der ASP.NET Core-"Plattform" zu sein.

OK, lassen Sie mich einen Vorschlag machen, um zu versuchen, hier konstruktiv zu sein. Wir ändern Microsoft.AspNetCore.App nicht, wir glauben, dass die Mehrheit der Benutzer dies benötigen und verwenden wird. Lassen Sie uns eine weitere Ebene vorstellen, die dieses gemeinsame "Kern"-Framework ist (wir haben so etwas ursprünglich mit https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497) gemacht. Dies ist das gemeinsame Framework, auf dem Sie diese anderen Frameworks (wie Nancy und ServiceStack) aufbauen würden.

Wir liefern unsere Standardvorlagen weiterhin mit Microsoft.AspNetCore.App wie jetzt, aber Framework-Autoren wie Sie können andere Vorlagen verwenden, die das gemeinsame Basisframework verwenden.

PS: Dieser Thread fängt nicht im Entferntesten an, eine Mehrheit unserer Kunden darzustellen, daher würde ich hier keine Schlussfolgerungen ziehen. Wir erhalten Feedback von vielen Orten und github hat unsere lautstärkste und leidenschaftlichste Anleitung.

Ja, ich denke, das ist näher daran, viele der wesentlichen Elemente zu enthalten, um eine App zu konfigurieren und zum Laufen zu bringen. Von den Deps in Microsoft.AspNetCore.App verwenden wir auch:

• Microsoft.Erweiterungen.Primitive
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Erweiterungen.Konfiguration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Es wäre also schön, Dinge wie HTTP, Hosting, Logging und Konfigurationsabstraktionen (nützlich für die meisten HTTP-Apps) aufzunehmen und alles andere, was jemand für angemessen hält. Meine einzige Präferenz ist, MVC/SignalR nicht enthalten zu haben.

und jetzt wird es interessant. wie David schon sagte: Menschen haben andere
Vorstellungen davon, was "Kern" bedeutet. Aus meiner Sicht glaube ich nicht, dass DependencyInjection
sollte drin sein. /schulterzucken

Am Do., 8. Nov. 2018 um 08:30 Uhr schrieb Demis Bellot <
[email protected]>:

Ja, ich denke, das ist näher daran, viele der wesentlichen Dinge zu enthalten, um zu
eine App konfigurieren und zum Laufen bringen. Von den Tiefen in
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App wir sind auch
Verwendung:

• Microsoft.Erweiterungen.Primitive
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Erweiterungen.Konfiguration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Also Sachen wie HTTP, Hosting, Logging und Konfigurationsabstraktionen
(nützlich für die meisten HTTP-Apps) wäre auch schön, eingeschlossen zu werden und alles
hält sonst jemand für angemessen. Meine einzige Vorliebe ist es nicht zu haben
MVC/SignalR enthalten.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz Die meisten davon sind transitiv enthalten.

@forki 😆 Willkommen in unserer Welt.

Wir ändern Microsoft.AspNetCore.App nicht, wir glauben, dass die Mehrheit der Benutzer dies benötigen und verwenden wird.

Berühmte letzte Worte. Dies ist die Rechtfertigung jeder schlechten Entscheidung - "WIR denken, SIE brauchen es".

Du weißt was ich denke? Microsoft sollte anfangen, seine Entwicklerbasis als unabhängige intelligente Ingenieure und nicht als Schafentwickler zu behandeln, und ja, ihr habt viele Schafentwickler, die verfolgen und verwenden werden, was immer ihr ihnen entgegenwirft, aber es sind die anderen, lauteren Entwickler, die eine lebendige Sache machen werden Community und bauen neue Startups auf dem .NET-Stack auf.

Manchmal ist es gut, Power-Usern zuzuhören.

Unabhängig davon werden wir Microsoft.AspNetCore.App nicht ändern. Ich habe einen Kompromiss angeboten, der meiner Meinung nach die Anforderungen hier erfüllt.

@forki Wenn Sie aspnet core verwenden, werden Sie sowieso mit DI konfrontiert, GetRequiredServiceund dergleichen sind in diesem Paket). Und hey F# kann diese aufgrund des fehlenden T:> U-Constraints nicht einmal selbst erstellen https://github.com/fsharp/fslang-suggestions/issues/255 also ¯_(ツ)_/¯

Ich möchte, dass dieses gemeinsame Basisframework @davidfowl erwähnt wird ... Ich denke, @mythz und @dustinmorris wären beide mit einem solchen Ansatz in

du wirst sowieso mit DI konfrontiert

Ich weiß, und wir hatten diese Diskussion mehrmals. Ich möchte es nur lieber nicht
;-) aber so ist es...

Am Fr., 9. Nov. 2018, 10:57 Uhr hat Nino Floris [email protected]
geschrieben:

@forki https://github.com/forki Wenn Sie Aspnet Core verwenden, sind Sie
ohnehin mit DI konfrontiert, lieber Convenience-Methoden einbeziehen von
default (Get service, GetRequiredService und dergleichen sind darin enthalten
Paket). Und hey F# kann diese aufgrund der fehlenden nicht einmal selbst erstellen
T :> U-Beschränkung fsharp/fslang-suggestions#255
https://github.com/fsharp/fslang-suggestions/issues/255 also ¯_(ツ)_/¯

Ich hätte gerne dieses gemeinsame Basisframework @davidfowl
https://github.com/davidfowl erwähnt... Ich denke @mythz
https://github.com/mythz und @dustinmorris
https://github.com/dustinmorris wäre beides in Ordnung mit einem solchen Ansatz.
Das ist auch für Saturn @Krzysztof-Cieslak günstig
https://github.com/Krzysztof-Cieslak

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

Der ursprüngliche Beitrag wurde aktualisiert und enthält Folgendes:

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

Diese werden aus dem freigegebenen Framework herausgezogen und als NuGet-Pakete ausgeliefert. Diese Assemblys haben eine Abhängigkeit von den IdentityModel-APIs, die noch nicht den Richtlinien für das freigegebene Framework entsprechen. Wir haben begonnen, mit dem IdentityModel-Team zusammenzuarbeiten und überlegen, diese in Zukunft wieder in das gemeinsame Framework zu integrieren. cref https://github.com/aspnet/AspNetCore/pull/6035

Aktualisieren Sie den ursprünglichen Beitrag, um Microsoft.AspNet.WebApi.Client einzuschließen. Siehe https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732.

Ich bin oft verwirrt genug, da es das ist, was ich aufnehmen muss.

Apropos Visual Studio - Soll ich den Knoten Microsoft.AspNetCore.App öffnen und auf alles darunter verweisen, was ich möglicherweise einzeln installiert habe?

Ich mache einen Hausputz und sehe, dass ich diese Pakete habe. Welche sind also überflüssig?

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

Ich war ziemlich überrascht zu sehen, dass derzeit sogar SpaServices- und EntityFramework-Tools enthalten sind (was ich vorher nicht bemerkt hatte - und großartig ist) - aber ich habe auch einige alte 2.2.1-Referenzen, die nichts helfen können.

Der Punkt ist - kann mit dem Visual Studio-Team eine bessere Koordinationsarbeit geleistet werden, um sicherzustellen, dass die IDE nur ein wenig intelligenter ist, diese Megapakete zu verstehen und mir zu sagen, dass es sicher ist, etwas zu entfernen - und dann in v3, dass ich es hinzufügen muss? wieder rein ;-)

@simeyla danke für das Feedback. Was du sagst, bezieht sich auf das Thema, aber es ist nicht genau das, worum es in diesem Thread geht. Tools zum Optimieren von Paketverweisen wäre ein neues Visual Studio-Feature. Dieses Feature könnte im Allgemeinen nützlich sein, nicht nur für dieses Szenario, daher würde ich vorschlagen, dieses Feedback direkt an Visual Studio zu senden. Verwenden Sie in VS "Hilfe > Feedback senden...". Wenn Sie den Link teilen, nachdem Sie den Beitrag erstellt haben, kann ich ihn intern an unsere Peer-Teams weiterleiten, die an VS arbeiten.

In 3.0 werden wir das Metapaket Microsoft.AspNetCore.App vollständig eliminieren und viele Anpassungen an den von uns ausgelieferten Paketen vornehmen. Wir haben mit der Dokumentation der Aktualisierung von 2.x auf 3.0 begonnen und werden dieses Dokument weiterhin aktualisieren, während wir die Liste der in 3.0 ausgelieferten Baugruppen fertigstellen.

Wechsel zum Meilenstein "Diskussionen", da dieses Element keine Arbeit verfolgt, sondern wir werden es als Details der Implementierungsänderung aktualisieren.

Microsoft.Extensions.DependencyModel zur Liste hinzugefügt. Geändert im Rahmen von https://github.com/aspnet/AspNetCore/pull/10271

Frage hier @natemcmaster @DamianEdwards , es wird erwähnt, dass die Vorlagen alles enthalten, was zum lokalen Erstellen benötigt wird. Bedeutet das mit diesem Gedanken und dem Entfernen der Auth-Bibliotheken, dass keine Auth-Vorlage in 3.0 offline erstellt wird? Ich verstehe, dass keine Authentifizierungsbibliothek offline funktioniert, aber wenn ich keinen Nuget-Cache habe, könnte ich theoretisch einen Buildfehler bekommen, nachdem ich eine neue Authentifizierungsvorlage neu erstellt habe, wenn ich offline war. Das scheint eine schlechte Erfahrung zu sein.

Ja, das ist eines der Ergebnisse dieser Änderung. Ab Preview 6 (demnächst verfügbar) haben dotnet new mvc , dotnet new razor , dotnet new web und andere keine PackageReferences, daher sollten sie nicht betroffen sein, aber zusätzliche Optionen angeben , wie --auth individual kann dazu führen, dass eine PackageReference vorhanden ist, die einen Paketdownload erfordert.

Wir gehen hier einen bewussten Kompromiss ein. Obwohl die Vorlagen mit PackageReference nicht offline auf einem sauberen Computer wiederhergestellt werden können, vermeiden wir auch viele der Probleme, die durch den Versuch entstehen, einen vorab gefüllten Offline-NuGet-Cache zu erstellen (für den Anfang: https://github.com/dotnet/ dotnet-docker/issues/237, https://github.com/NuGet/Home/issues/6309 und http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html).

@natemcmaster verstehe das völlig und ich verstehe die Argumentation, muss nur gut dokumentiert werden oder es werden eine Menge Probleme mit der ersten 3.0-Version auftauchen, bei denen die Leute sagen, dass dotnet new webapp --auth Individual nicht erstellt wird.

Kann mir jemand erklären, warum Microsoft.AspNetCore.Authentication.JwtBearer mit einer Abhängigkeit von .netcoreapp3.0 kompiliert wird? Kann es nicht an .netstandard2.x liegen? Ich möchte es in einer Klassenbibliothek verwenden und ich möchte meine Klassenbibliotheken alle .netstandard halten

@buvinghausen https://github.com/aspnet/Announcements/issues/324

@Pilchie Ich denke, dieses Problem ist es wert, in der Dokumentation für ASP.NET Core 3.0 erwähnt zu werden. Wie oben erwähnt, müssen Benutzer, die auf 3.0 aktualisieren, <PackageReference> hinzufügen, um die API zu kompensieren, die aus Microsoft.AspNetCore.App verschoben wurde.

@Bomret Fast jede reale Kunden-App, die wir inspiziert haben, verwendet MVC in irgendeiner Weise. Es hat viele Vorteile, es im gemeinsamen Framework zu belassen, und ich sehe keine klaren Gründe, warum wir es entfernen sollten.

Das tun wir sicherlich nicht, und ich kenne einige Leute in anderen Shops, die .net Core für serverlose Apps, Web-APIs usw. verwenden, wo wir absolut keinen Bedarf an MVC haben.

Abgeschlossen, da wir heute 3.0 ausgeliefert haben.

Wir müssen diese Liste in die Dokumente verschieben

@davidfowl es wurde hinzugefügt: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete-package-references

@pranavkm diese Liste ist eigentlich das genaue Gegenteil: Dinge, die keine Pakete mehr sind, sich aber wahrscheinlich noch im gemeinsamen Framework befinden.

Hier geht es um Dinge, die aus dem freigegebenen Framework entfernt wurden, aber jetzt wahrscheinlich nur als Pakete verfügbar sind.

@scottaddie Dies ist die Liste, auf die wir im Authoring-Dokument der ASP.NET Core-Bibliothek verweisen müssen.

@DamianEdwards das - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add -package-references-for-removed -Baugruppen?

Das ist der :)

Zu spät zur Party, aber das fühlt sich nicht so an, als würde es mir helfen, das Ziel zu erreichen, meine Entwicklung zu vereinfachen.

a) Es scheint, dass wir jetzt, wenn es eine Verbesserung an einer AspNetCore-Komponente (z sonst in dieser Packung?
b) Kann in Netstandard-Klassenbibliotheken (z. B. Auth-Middleware) keine Dienstprogrammklassen mehr für AspNetCore erstellen. Jetzt müssen Klassenbibliotheken netcoreapp3.0 sein, um dieses Zeug zu beherbergen. Dies bedeutet, dass wir unsere Dienstprogrammklassenbibliotheken in netstandard / netcore-Implementierungen aufteilen.
BEARBEITEN: c) Wie definiere ich eigentlich, welche Version des Pakets ich verwende, wenn ich <Project Sdk="Microsoft.NET.Sdk.Web"> tue? Offensichtlich möchten wir nach dem Update von dotnet reproduzierbare Builds in verschiedenen Branches haben.

a) Es scheint, dass wir jetzt, wenn es eine Verbesserung an einer AspNetCore-Komponente (z sonst in dieser Packung?

SignalR wird nach demselben Zeitplan wie der Rest von AspNetCore ausgeliefert, sodass hier keine Zeitplanänderung erfolgt.

SignalR wird nach demselben Zeitplan wie der Rest von AspNetCore ausgeliefert, sodass hier keine Zeitplanänderung erfolgt.

Das ist also nur ein schlechtes Beispiel? Gilt das Gleiche für alle anderen NuGet-Pakete, die entfernt wurden?

SignalR wird nach demselben Zeitplan wie der Rest von AspNetCore ausgeliefert, sodass hier keine Zeitplanänderung erfolgt.

Das ist also nur ein schlechtes Beispiel? Gilt das Gleiche für alle anderen NuGet-Pakete, die entfernt wurden?

Ich glaube schon. Alle .NET Core- und ASP.NET Core-Komponenten verwenden denselben Versandzeitplan. Wenn dies nicht der Fall wäre, müsste es in einem eigenen Paket versendet werden.

Ich glaube schon. Alle .NET Core- und ASP.NET Core-Komponenten verwenden denselben Versandzeitplan. Wenn dies nicht der Fall wäre, müsste es in einem eigenen Paket versendet werden.

Ich werde dich beim Wort nehmen. Ich habe keine konkreten Gegenbeispiele. Beim Aktualisieren der AspNetCore-NuGet-Pakete in der Vergangenheit fühlte es sich einfach nicht so an.