Aspnetcore: Assemblages supprimés de Microsoft.AspNetCore.App 3.0

Je pense que les packages MVC devraient également devenir des packages NuGet supplémentaires. MVC est génial, mais contrairement à vanille ASP.NET Core, il est extrêmement avisé de la façon dont une application we doit être présentée, ce qui n'est vraiment pas la tasse de thé de tout le monde, et encore moins correspond au paradigme de tous les langages .NET. Je crois vraiment que le framework partagé ASP.NET Core mérite d'être sans MVC ou d'en avoir une deuxième version sans MVC. Qu'est-ce que tu penses?

Quel serait l'avantage? Comment cela améliorerait-il la vie des personnes qui créent des applications ASP.NET Core ?

Super! J'ai juste besoin de ce dont j'ai besoin lorsque j'utilise le noyau asp.net.

@davidfowl

Quel serait l'avantage? Comment cela améliorerait-il la vie des personnes qui créent des applications ASP.NET Core ?

Pour les mêmes raisons pour lesquelles vous n'incluez pas les packages répertoriés en haut de ce numéro. Je pense juste qu'il est toujours plus facile d'ajouter plus de packages dans le framework qui sera livré avec .NET Core 3.0 que de supprimer des packages plus tard. Pourquoi ne commencez-vous pas à ajouter le plus petit dénominateur commun pour exécuter une application vanille ASP.NET Core, puis proposez le reste sous forme de packages NuGet. Si cela s'avère être un problème pour les développeurs, vous pouvez toujours ajouter plus de choses plus tard, mais vous ne pourrez plus les supprimer plus tard aussi facilement.

Parce que nous devons aussi trouver un équilibre avec le fait d'être utile par défaut.

Ok, eh bien, je pense que vanilla ASP.NET Core est déjà utile (et je pensais que vous le pensiez aussi, sinon pourquoi ne l'avez-vous pas rendu utile ?), mais si vous avez déjà décidé de ce qui devrait être dans le framework et quoi pas alors tant pis ;)

Si vous étiez un puriste, vous n'auriez pas la plupart des middleware ou MVC ou SignalR dans la boîte car ils ne sont pas strictement nécessaires. Tracer cette ligne entre ce que l'ensemble de choses par défaut devrait être et non est à peu près une sensation instinctive et une chose floue (basée sur l'expérience, en regardant d'autres plates-formes passées et présentes et en passant un appel). Depuis ASP.NET Core 3.0, nous n'avons pas l'intention de les retirer (du moins pour le moment).

Oui, je sais que c'est toujours un appel difficile à faire, mais je ne suis parfois pas sûr de la justification de la tendance (par Microsoft) à gonfler les choses plus que nécessaire. La façon dont vous positionnez vos propres produits sur le marché est la façon dont ils seront perçus. ASP.NET Core est censé être le nouveau framework web moderne composable et flexible, mais la façon dont vous positionnez tout est qu'ASP.NET Core est inutile à moins que vous ne forciez MVC + SignalR + Identity + EF sur tout le monde. À mon avis, vous avez déjà demandé où les lignes doivent être tracées, c'est pourquoi MVC et SignalR ne sont pas intégrés dans ASP.NET Core mais des frameworks distincts qui peuvent être ajoutés à volonté, alors pourquoi brouillez-vous ces lignes maintenant ? Cela semble incohérent et je ne vois aucune valeur que vous en retirerez. Au lieu de simplement promouvoir ASP.NET Core + un écosystème open source florissant, vous faites la promotion d'une expérience Web très étroite. Tout ce que cela fait, c'est créer de la frustration avec ceux qui veulent être légèrement différents et plus de travail pour vous-même alors que vous finissez par pousser des choses sur les gens qu'ils ne veulent peut-être pas.

Ce n'est pas comme si les gens n'utiliseraient pas MVC si vous ne le mettez pas dans le framework par défaut. Faites-en un seul package NuGet et personne ne se plaindra de devoir obtenir MVC de NuGet. Il est plus probable que plus de gens viendront et demanderont pourquoi vous avez gonflé le framework par défaut avec des choses qu'ils ne veulent pas comme moi.

Je suppose qu'il s'agit d'une discussion et que c'est toujours quelque chose que vous pourriez envisager, donc s'il y a une chose que j'aimerais que vous posiez, c'est peut-être à nouveau de soulever cette question avec votre équipe et de voir si vous êtes tous vraiment déterminés à cela ou si vous pouvez adoucir vers mon idée :)

PS : Je ne sais pas si c'est le cas, mais j'espère que SignalR est également un package NuGet distinct. C'est comme si vous incluiez Bootstrap et Angular2 dans votre framework par défaut. Si ces deux produits étaient développés par Microsoft, vous le feriez probablement, mais cela n'aurait aucun sens et je pense que ce n'est que parce qu'ils sont créés par un tiers que vous voyez à quel point cela n'a pas de sens.

TBH J'aimerais voir plus de choses supprimées de l'installation par défaut. Surtout MVC. C'est ce qui rend les frameworks alternatifs au-dessus d'ASP.NET Core encore plus attrayants. Je me demande aussi pourquoi des choses comme ContentResult vivent dans MVC et non dans core. Il est beaucoup utilisé dans les fonctions azur et maintenant je dois toujours référencer le contenu MVC - juste pour ContentResult.

Je pense que le fait est plus que cela ne devrait pas vraiment avoir un impact négatif sur vous d'avoir les éléments MVC dans le SDK ASPNET. La plupart des développeurs l'utiliseront, il est donc préférable de l'expédier de cette façon plutôt que de gonfler la charge de restauration. Si vous ne le voulez pas, vous ne pouvez tout simplement pas l'utiliser. La plupart des packages répertoriés ci-dessus intègrent des dépendances tierces (json), ont un aspect lourd (rasoir) ou sont conceptuellement séparés d'ASPNET et souvent référencés en dehors du SDK (EFCore).

Autant je suis d'accord avec les valeurs par défaut pour favoriser des règles du jeu égales pour les frameworks OSS, cela doit être équilibré. Au début du noyau (bêta et même 1.0), les choses étaient des paquets partout et c'était BEAUCOUP plus déroutant et la restauration prenait une éternité.

@psibernetic même si les éléments se

@psibernetic Vous êtes la deuxième personne à mentionner qu'il est important d'équilibrer, mais qu'est-ce que cela signifie ? L'équilibre entre quoi ? Ne parlons pas d'extrêmes, car ce n'est évidemment pas bien, parlons ici de propositions réalistes. Si MVC est un package NuGet unique, de quelle manière a-t-il un impact sur la convivialité ? Ce n'est vraiment pas le cas et c'est mon propos. Penser que vous allez résoudre un extrême en mettant en œuvre l'extrême opposé est une pensée étroite. Il y a beaucoup d'entre-deux. Le framework n'a pas besoin d'être pléthorique et MVC et SignalR n'ont pas non plus besoin d'être fragmentés en 100 packages. Les deux peuvent être évités en même temps.

Donnez-moi un cas réel où avoir MVC en tant que package NuGet unique serait déroutant, la restauration prendrait une éternité, ou l'un des autres points négatifs que vous avez mentionnés ?

Et en parlant de temps de restauration...

À mon humble avis, il est plus important d'avoir des conteneurs à démarrage rapide ou une architecture sans serveur (car c'est ce qui a un impact réel sur les entreprises) que d'avoir une construction légèrement plus rapide sur une machine de développeur. Oui, ce dernier est également extrêmement important et je veux qu'il soit incroyablement rapide, mais si je devais classer l'importance, je préfère prendre un coup mineur sur ma machine de développement que sur mon infrastructure de production dans le cloud. Donc, garder l'empreinte aussi petite que possible est juste (sinon plus) important que de réduire le temps de restauration.

Quel serait l'avantage? Comment cela améliorerait-il la vie des personnes qui créent des applications ASP.NET Core ?

Je pense qu'il s'agit d'un bloatware indésirable pour tous les autres utilisateurs qui n'utilisent pas MVC, comme CandyCrush pré-installé sur mon PC Windows 10. Le noyau d'Asp.net a prêché qu'il devenait moins avisé avec un middleware entièrement configurable, selon les besoins, etc. Les modèles dotnet permettent à MVC d'être un package inclus par défaut sans qu'il ait besoin d'être intégré au noyau ?

Il existe de nombreux autres frameworks comme Nancy, ServiceStack et Giraffe qui ont tous leurs mérites et ne devraient pas avoir le gonflement/les conflits avec une installation de force MVC non désirée/inutile. Cela semble simplement incohérent étant donné que l'authentification, le rasoir, EF, etc. sont tous emballés, mais MVC, l'enfant en or fait partie du framework de base alors qu'il ne l'est pas ?

Si cela est dû au fait que MVC est si étroitement couplé au noyau que le découplage représenterait une tonne de travail, je peux l'obtenir, mais sur cette base, cela facilite généralement la vie de certains développeurs, semble paresseux et ressemble beaucoup à l'ancien asp.net J'espérais que nous nous éloignions de la mentalité MVC.

.NET Core était censé être le clone modulaire maigre de node.js pour .NET, mais il ne semble pas qu'il ait l'intention de reproduire les caractéristiques qui favorisent son écosystème prospère et dynamique - un petit noyau flexible sans opinion avec des fonctionnalités incluses dans le noyau bénéficiant de tout cela, grâce à l'absence de tout framework Web opiniâtre, est mûr pour l'expérimentation bénéficiant d'un nombre sain de frameworks populaires avec leurs propres communautés indépendantes.

Je veux dire que l'équipe ASP.NET pense qu'elle construit le meilleur cadre possible, mais tout le monde n'est pas d'accord avec toutes les opinions choisies ou le niveau de complexité requis pour faire quelque chose. Tout dans .NET Core a été développé avec le recul, beaucoup s'inspirant des approches qui ont été couronnées de succès sur d'autres plates-formes, en faisant part de leurs opinions sur les technologies à utiliser, vous affamez la prochaine innovation venant de .NET et même lorsque la prochaine chose gagnera du terrain sur d'autres plates-formes, ASP.NET Core sera désavantagé pour reproduire son succès, car nous paierons pour toujours la "taxe MVC" par défaut où tout le monde est censé utiliser son modèle de développement pour tout le Web Des applications à l'infini.

La légèreté de Node le rend également adapté au développement d'un certain nombre d'autres cas d'utilisation tels qu'Electron, les applications mobiles natives, l'IOT, les scripts shell, etc. Plus l'installation par défaut est pléthorique, moins elle devient utile pour une utilisation dans d'autres scénarios.

OMI, la valeur par défaut devrait être de retour à la vision originale de .NET Core d'avoir un noyau léger et modulaire en mettant l'accent sur la facilitation de l'ajout de fonctionnalités (dont tout le monde peut profiter), c'est-à-dire pas en le regroupant par défaut et en gonflant la valeur par défaut installer.

Merci pour votre retour. Permettez-moi de partager quelques réflexions.

1. Nous ne rognons pas les assemblages parce que nous en avons envie. Chaque assemblage que nous supprimons est un changement décisif et augmente le coût de la mise à niveau de 2.x à 3.0. Ce sont les principes directeurs que nous utilisons pour décider de ce qui va dans Microsoft.AspNetCore.App : https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. Les assemblages que nous proposons de supprimer manquent certains des critères d'inclusion dans le cadre partagé. Notamment, ces assemblys : (1) ont des dépendances sur du code tiers que nous n'avons pas la capacité de servir (2) les assemblys eux-mêmes sont dépréciés dans 3.0 ou (3) ils implémentent des protocoles ou des mécanismes d'authentification qui sont très sujets à changement ( par exemple, Facebook/Google/Twitter pourraient décider demain de changer le fonctionnement de l'authentification)

2. La suppression de MVC de Microsoft.AspNetCore.App n'est pas quelque chose que nous envisagerions. Bien que nous reconnaissions que tous les utilisateurs ne font pas référence à MVC dans leur application, nous pensons qu'il s'agit d'un élément central de l'offre d'ASP.NET Core. Nous prévoyons de conserver cela dans Microsoft.AspNetCore.App.

3. MVC fait partie de Microsoft.AspNetCore.App depuis 2.1, mais comme vous le verrez dans les modèles 2.1 « Web vides » , vous n'êtes pas obligé d'utiliser MVC. Sa présence dans le framework partagé ne vous oblige pas à l'utiliser dans votre application. Vous pouvez toujours utiliser des alternatives, écrire votre propre framework de vue ou utiliser les API aspnetcore plus "brutes" pour lire et écrire directement des requêtes et des réponses HTTP.

4. @dustinmoris : Je pense juste qu'il est toujours plus facile d'ajouter plus de packages dans le framework qui sera livré avec .NET Core 3.0 que de supprimer des packages plus tard. Pourquoi ne commencez-vous pas à ajouter le plus petit dénominateur commun pour exécuter une application vanille ASP.NET Core, puis proposez le reste sous forme de packages NuGet. Si cela s'avère être un problème pour les développeurs, vous pouvez toujours ajouter plus de choses plus tard, mais vous ne pourrez plus les supprimer plus tard aussi facilement.

   C'est exactement ce que nous essayons de faire. Il est plus facile d'ajouter que de supprimer. Nous avons ajouté trop de choses dans 2.0, et nous nous réajustons à ce que nous pensons être un ensemble de choses maintenable pour la route prévisible à venir. La plupart des assemblys supprimés de Microsoft.AspNetCore.App seront toujours proposés en tant que packages NuGet. Si nous devions découvrir plus tard que 90% de tous les clients référencent le même package, c'est un bon candidat pour le framework partagé. Comme mentionné dans le document d'orientation , cependant, le degré d'utilisation d'une API est une mesure importante, mais pas le seul facteur que nous considérons.

5. "Vanille" est subjectif. Pour beaucoup de nos utilisateurs, MVC et SignalR sont "vanille".

6. Quelques personnes ont dit que .NET Core était censé être ceci ou cela ou quelque chose d'autre. Les choses changent, nous recueillons les commentaires des utilisateurs, nous observons comment le produit est utilisé et nous essayons d'ajuster les valeurs par défaut pour qu'elles correspondent à ce qui, selon nous, profitera au plus grand nombre de clients. Les ajustements proposés dans ce numéro reflètent les commentaires que nous avons reçus sur .NET Core 2.x.

Dernière réflexion : ce problème ne va pas faire plaisir à tout le monde. S'il semble que nous ignorons vos commentaires, je m'en excuse. Sachez que nous avons des centaines de milliers de clients et que seul un petit nombre d'entre eux viennent sur GitHub pour partager leurs commentaires. Nous collectons également des informations sur les visites en personne, les appels téléphoniques, les e-mails, les réseaux sociaux, les demandes de support client, les blogs, la télémétrie Visual Studio, etc. Tout cela fait partie de ce que nous considérons lorsque nous prenons des décisions et de ce qui fait partie de l'expérience par défaut et de ce qui ne l'est pas.

Si quelque chose n'est pas clair sur nos motivations ou raisons, faites-le moi savoir et j'essaierai de clarifier.

Si vous avez autant de contacts directs avec les clients, à quand remonte la dernière fois où vous avez demandé combien d'entre eux utilisent MVC et SignalR ? Y a-t-il de réelles mesures d'utilisation derrière cette position sur les garder définitivement au lieu de les avoir chacun dans un seul package NuGet qui peut être très facilement installé en cas de besoin ?

@dustinmoris incluant MVC dans le runtime partagé signifie qu'il est expédié pré-compilé, c'est un avantage qui serait perdu, ce qui augmenterait au minimum les temps de démarrage, ce qui en fait, IMO, un mauvais compromis dans votre exemple de démarrage rapide conteneurs dockers. En plus de cela, chaque déploiement devrait désormais expédier les packages avec l'application car il n'est pas dans le runtime, cela augmente la taille du package de déploiement de chaque application MVC. Enfin, tout package dépendant de MVC dans le runtime doit également devenir un déployable séparé, je ne sais pas combien, le cas échéant, car je ne trouve pas la liste complète.

Tout cela étant dit, et n'oubliez pas que j'ai 0 affiliation avec Microsoft ou l'équipe aspnet, je POURRAI voir un runtime séparé expédié qui était un aspnetcore barebones SI la communauté l'a vraiment exprimé et a prouvé qu'il s'agissait d'un besoin majeur. La mission offre une excellente expérience pour autant d'applications et de développeurs que possible et le fait qu'à l'heure actuelle un pourcentage incroyablement élevé de ceux-ci bénéficient de MVC dans le runtime partagé. @natemcmaster existe-t-il un moyen préféré pour les personnes concernées de voter pour cela à l'avenir, peut-être pour un problème GitHub, et est-ce une solution raisonnable ?

@psibernetic, vous pouvez commencer un nouveau problème GitHub pour supprimer MVC du framework partagé, mais comme je l'ai dit ci-dessus, la suppression de MVC de Microsoft.AspNetCore.App n'est pas quelque chose que nous envisagerions, il est donc peu probable que ce problème gagne du terrain dans notre équipe.

@Bomret Presque toutes les applications client du monde réel que nous avons inspectées utilisent MVC d'une manière ou d'une autre. Il y a de nombreux avantages à le conserver dans le cadre partagé, et je ne vois pas de raisons claires pour lesquelles nous devrions le supprimer.

@Natemcmaster : Je suis sur mon téléphone maintenant, mais merci pour l'explication et je viens de
réalisé qu'il s'agit du métapaquet alors que je parlais du
cadre partagé.

@natemcmaster Je pense que @forki , @dustinmorris , @gerardtoconnor et @mythz ont

Il s'appelle "Microsoft.AspNetCore.App", pourquoi ne pas en créer un deuxième "Microsoft.AspNetCoreMVC.App" ?

Quoi qu'il en soit, je comprends qu'il est très difficile de tracer la ligne, mais je pense que le retour général ici est que vous avez un nombre croissant de personnes qui aiment ce que vous avez fait avec aspnet core, mais qui n'aime pas vraiment les trucs comme MVC, razor , EF ou signalR.

En effet. Vous pouvez compter sur la communauté pour être suffisamment dynamique pour proposer de nombreuses idées de bibliothèques et de frameworks pour gérer les API, le Web, les Websockets, les modèles, l'accès à la base de données, etc. Vous fourniriez une option pour ceux qui ont MVC, Razor, EF, etc., mais pas la seule ni par défaut.

@natemcmaster Mon erreur, je parlais en fait du framework partagé dans ce numéro ici. Je pense que les mêmes raisons s'appliquent également au méta-package, mais pour être honnête, cela me dérange moins, car je peux déjà référencer des packages individuels au lieu du méta-package, mais je ne peux pas facilement réduire un framework partagé si je veux garder un conteneur aussi petit que possible, donc votre suggestion d'ouvrir un nouveau numéro pour le framework partagé a du sens 👍

@natemcmaster Pourriez-vous rapidement confirmer si j'ai bien compris les choses :

• Il y aura un framework ASP.NET Core partagé intégré au prochain runtime .NET Core (3.0), ce qui signifie qu'ASP.NET Core sera livré dans le cadre de l'installation de .NET Core sur un environnement.

• De plus, il existe un méta-package appelé Microsoft.AspNetCore.App et Microsoft.AspNetCore.All qui sont une collection de packages NuGet pour les applications ASP.NET Core

• Le framework ASP.NET Core partagé < le méta package Microsoft.AspNetCore.App qui inclut des éléments comme EF Core ?

• Je peux créer une application Web ASP.NET Core sans avoir à inclure le méta-package Microsoft.AspNetCore.App qui contient EF Core, SignalR, MVC, etc. si je veux juste créer une API extrêmement petite ?

• Quoi que vous fassiez, il sera possible de créer un conteneur Docker avec uniquement les dépendances les plus minimales pour ASP.NET Core afin d'exécuter une petite API ?

Il y aura un framework ASP.NET Core partagé intégré au prochain runtime .NET Core (3.0), ce qui signifie qu'ASP.NET Core sera livré dans le cadre de l'installation de .NET Core sur un environnement.

Oui

De plus, il existe un méta-package appelé Microsoft.AspNetCore.App et Microsoft.AspNetCore.All qui sont une collection de packages NuGet pour les applications ASP.NET Core

Non. Il existe un nouveau concept appelé FrameworkReference et Microsoft.AspNetCore.App en fera partie. Microsoft.AspNetCore.All n'existera pas dans la version 3.0.

Le framework ASP.NET Core partagé < le méta-package Microsoft.AspNetCore.App qui inclut des éléments comme EF Core ?

Non, cela n'inclut pas EF.

Quoi que vous fassiez, il sera possible de créer un conteneur Docker avec uniquement les dépendances les plus minimales pour ASP.NET Core afin d'exécuter une petite API ?

Avec le découpage de l'assembly et l'éditeur de liens, oui, pas en supprimant les packages car il n'y en aura pas pour ASP.NET Core.

@natemcmaster

Nous ne rognons pas les assemblages parce que nous en avons envie. Chaque assemblage que nous supprimons est un changement décisif et augmente le coût de la mise à niveau de 2.x à 3.0.

Le bon endroit pour apporter des corrections serait dans la fenêtre de la version principale v3, qui est effectivement le seul moment où des changements comme celui-ci pourraient se produire, c'est-à-dire en même temps que d'autres packages sont supprimés.

La suppression de MVC de Microsoft.AspNetCore.App n'est pas quelque chose que nous envisagerions. Bien que nous reconnaissions que tous les utilisateurs ne font pas référence à MVC dans leur application.

Il s'appelle "Microsoft.AspNetCore.App" qui se lit logiquement comme "référencer ce package" si vous créez une "application ASP.NET Core".

nous pensons qu'il s'agit d'un élément central de l'offre ASP.NET Core. Nous prévoyons de conserver cela dans Microsoft.AspNetCore.App.

Cela se rapproche du nœud du problème où il semble que les objectifs d'ASP.NET Core s'éloignent de la promotion d'un écosystème de style node.js-esque maigre et ouvert. L'intention des équipes est-elle que tout le monde confond les applications ASP.NET Core et les applications MVC ? Certains des arguments de vente d'ASP.NET Core étaient « Payer pour jouer » et une « superposition » découplée, mais cela suggère qu'une « application ASP.NET Core » est toujours destinée à = une application MVC.

Ce serait plus clair pour toutes les personnes impliquées si les packages étaient plus explicites où :

• Microsoft.AspNetCore.App => Base pour toutes les applications ASP.NET Core
• Microsoft.AspNetCore.Mvc => Application ASP.NET Core MVC

Mais si "Microsoft.AspNetCore.App" est intouchable, pourrions-nous au moins avoir un méta-paquet officiel "de base" (ou FrameworkReference) avec uniquement les fonctionnalités de base du serveur (c'est-à-dire sans aucune bibliothèque opiniâtre), quelques noms potentiels :

• Microsoft.AspNetCore.[Base | Nu | Lite | De base]

("Core" aurait également été approprié mais il y a déjà un usage excessif du terme).

Sans qu'il y ait un méta package/nom officiel, il ne sera pas aussi accessible que le "Microsoft.AspNetCore.App" actuellement recommandé, qui est la base recommandée pour toutes les applications ASP.NET Core.

Les contraintes engendrent l'innovation où si MVC ne pouvait fonctionner que sur le même terrain de jeu que tout le monde, nous pourrions peut-être tous avoir accès à une fonctionnalité qui nous permet de déclarer facilement et explicitement quels produits (alias suite de packages) les applications ont besoin, par exemple, cela pourrait ressembler à quelque chose Comme:

• Microsoft.AspNetCore.Mvc+SignalR+EF

Où chacun pourrait facilement déclarer et n'installer que ce dont il a besoin et où l'outillage en coulisse pourrait combiner les méta-packages "Microsoft.AspNetCore.Mvc", "Microsoft.AspNetCore.SignalR" et "Microsoft.AspNetCore.EF". (Ou alt solution supérieure pour remplir l'intention).

Sa présence dans le framework partagé ne vous oblige pas à l'utiliser dans votre application.

Cela ressemble à la justification de chaque monolithe jamais créé. "Vous n'êtes pas obligé d'utiliser tout ce que nous proposons, c'est juste là pour votre commodité".

Vous pouvez toujours utiliser des alternatives, écrire votre propre cadre de vue,

Ce n'est pas aussi accueillant que vous ne le pensez, par exemple, alors que nous développions notre propre alternative de "cadre de vue" à MVC et Razor, nous avons rencontré un comportement magique dans .NET Core où la construction échouait lors de l'exécution de la commande standard pour publier un fichier . NET Core, c'est-à-dire :

 dotnet publish -c Release

Ce qui échouerait avec :

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):

Comportement surprenant étant donné que nous développions une alternative à MVC qui ne faisait explicitement pas référence à MVC, Razor ou n'incluait aucune page .cshtml car son objectif était de créer des applications sans les utiliser.

Après avoir parcouru plusieurs threads GitHub en essayant différentes solutions de contournement, j'ai trouvé d'autres personnes rencontrant le même problème où la solution a fini par se retirer des compilations de rupture de compilation MVC Razor avec :

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

Ce qui a permis la publication du projet. Au cours de l'essai de différents commutateurs pour réparer la version cassée, nous avons également découvert que nous pouvions réduire notre empreinte publiée de 150 .dll dans /refs/*.dll en désactivant les métadonnées qui gonflaient inutilement notre application Web .NET Core 2.0 en se désinscrire des métadonnées nécessaires à Razor avec :

<PreserveCompilationContext>false</PreserveCompilationContext>

Donc, fondamentalement, obligé de jouer à whack-a-mole pour savoir de quels commutateurs nous avons besoin pour dire à l'outillage que nous n'utilisons pas MVC pour l'empêcher de casser les builds de projet et de produire des métadonnées inutiles dont seules les applications MVC/Razor ont besoin. Il aurait été beaucoup plus préférable de commencer avec un package de métadonnées "de base" où de tels problèmes ne pouvaient pas être possibles car l'outillage ne pouvait pas supposer que chaque application utilisait MVC car les bits MVC n'existeraient pas.

Bien qu'il soit facile de dire qu'ASP.NET Core est toujours une plate-forme accueillante qui encourage l'expérimentation, la création et l'utilisation de "frameworks de vue" alternatifs, le regroupement de frameworks Web avisés prescrits comme MVC est à peu près la chose la plus hostile qui pourrait être faite pour décourager la création et l'utilisation desdites alternatives. Prendre un moment pour jeter un coup d'œil au nombre d'alternatives populaires émergentes est un bon indicateur pour voir à quel point la plate-forme est attrayante pour eux.

S'il est prévu que chaque application ASP.NET Core devrait inclure MVC que tout autre "framework de vue" alternatif (y compris un seul fichier .cs drop-in de méthodes ext) va sembler être plus "lourd " et encombrant que d'utiliser le MVC fourni, car ils doivent tous être fournis avec lui + tout ce dont le framework de vue a besoin.

En résumé, il serait préférable que "MVC" soit opt-in et ne soit pas inclus dans le package .App , mais si la décision est irréversible, pourrions-nous au moins avoir une base de méta-package de base officielle qui ne tu ne l'inclus pas ?

Sachez que nous avons des centaines de milliers de clients et que seul un petit nombre d'entre eux viennent sur GitHub pour partager leurs commentaires.

OMI, la demande pour un package de départ non gonflé est sous-représentée, anecdote : de tous les modèles de projet C#/.NET que nous avons créés pour VS 2012, VS 2013, VS 2015, VS 2017 et .NET Core, toujours le modèle le plus populaire de loin a toujours été le modèle "Vide", qui était également une critique fréquente d'ASP.NET classique selon laquelle le modèle ASP.NET vide par défaut de VS.NET n'était pas assez vide. C'était à l'époque où vous pouviez créer un framework ASP.NET .NET classique "vide" sans MVC, mais maintenant, dans le framework ASP.NET Core plus récent, plus léger et plus modulaire, MVC est fourni dans le package de départ minimum recommandé.

Nous collectons également des informations sur les visites en personne, les appels téléphoniques, les e-mails, les réseaux sociaux, les demandes d'assistance client, les blogs

Les gens n'aiment pas le gonflement qui est souvent assimilé à une complexité inamovible, ce qui est probablement demandé est de rendre les projets aussi simples que possible, ce qui devrait être l'objectif et peut être fait sans gonfler les projets par défaut.

D'après mon expérience, être explicite est plus simple à raisonner que des frameworks gonflés avec un comportement magique. S'il est explicite, vous pouvez interagir avec, le rechercher, le lire, le supprimer, tester l'exécution sans l'utiliser (pour voir si c'est la cause des problèmes) et cela est visible lors de la comparaison de projets de différentes configurations. Mais avec le comportement magique de l'outillage MVC qui brise les versions de mon projet mvc/sans rasoir ci-dessus, je n'avais aucune idée de la partie de mon projet qui le déclenchait, pourquoi il s'exécute même, comment le désactiver ou comment le résoudre. Je ne suis toujours pas sûr que mes projets n'utilisant pas MVC ne soient pas ralentis parce que MVC est groupé ou qu'il génère une sortie sous-optimale car il doit s'adapter à MVC ou Razor.

Télémétrie Visual Studio, et plus encore.

Il va être difficile de comparer la télémétrie de la popularité d'un méta-paquet de base qui n'existe pas, si c'était le cas pour l'OMI, il aurait plus qu'assez de popularité pour mériter son inclusion. Auparavant, "Microsoft.AspNetCore.All" visait l'autre extrémité du spectre et incluait l'univers mais pas l'inverse plus utile d'avoir une ligne de base utile minimale.

Il va de soi que si vous ne créez pas d'application MVC et que l'option de choisir une ligne de base sans elle est tout aussi accessible, pourquoi ne la choisiriez-vous pas plutôt que l'option de démarrage plus gonflée contenant MVC ?

@Bomret

Cela aurait été très bien d'avoir un environnement d'exécution/librai Web de base sur lequel les auteurs de framework pourraient s'appuyer, comme nodejs, au lieu d'y intégrer des éléments d'opinion.

Mais c'est exactement comme ça que ça marche. Vous êtes libre de composer votre application comme vous le souhaitez. Si vous ne souhaitez pas utiliser MVC, n'ajoutez simplement pas le middleware. Oui, les modèles sont disponibles, mais vous pouvez modifier votre application pour faire ce que vous voulez, en utilisant ce que vous voulez.

Je pense que vous interprétez un peu le cadre partagé ici. Il suffit de le voir comme une sorte de bibliothèque standard fournie avec .NET Core. Pour faire une référence à Node : imaginez que la version actuelle d'Express a été fournie avec Node. Vous n'avez pas à l'utiliser mais il est déjà là quand vous voulez l'utiliser.

Et en ce qui concerne MVC, je pense que vous ne savez pas exactement ce que MVC inclut réellement dans ASP.NET Core. Si vous ne souhaitez pas utiliser de contrôleurs et de vues Razor, très bien, mais vous utiliserez probablement encore beaucoup de fonctionnalités MVC dans votre application de toute façon.

Si vous ne souhaitez pas utiliser de contrôleurs et de vues Razor, très bien, mais vous utiliserez probablement encore beaucoup de fonctionnalités MVC dans votre application de toute façon.

Comme quoi?

Si vous ne souhaitez pas utiliser de contrôleurs et de vues Razor, très bien, mais vous utiliserez probablement encore beaucoup de fonctionnalités MVC dans votre application de toute façon.

Oui, dites-le, cela semble un peu condescendant, la plupart d'entre nous sont impliqués dans des frameworks alternatifs construits sur le middleware/kestrel de base, nous avons donc une idée décente de ce que nous utilisons, les contrôleurs et les vues Razor sont un petit sous-ensemble de MVC, nous sache que. Les frameworks F#, Giraffe/Saturn & Zebra, fonctionnent mieux que MVC avec un meilleur routage et un modèle de traitement simplifié. En rendu, Zebra x2 plus rapide que MVC sur TechEmpower, c'est pourquoi nous préférons le garder par défaut. si l'assembly-trimming/linker est capable de réduire l'empreinte plus tard, c'est au moins quelque chose, mais ce serait idéal s'il n'était pas inclus par défaut pour permettre un terrain de jeu plus égal pour les autres frameworks, gagner un maximum d'attraction sur la plate-forme principale asp.net.

@mythz d'un point de vue organisationnel, vous avez raison, il y a des divisions logiques ici. Cependant, toute subdivision s'accompagne d'une complexité et d'une surcharge d'ingénierie considérablement accrues qui prennent du temps à améliorer les fonctionnalités du produit. Lorsque nous nous attendons à ce qu'une majorité significative de clients profitent des composants MVC, cela ne vaut tout simplement pas le coût de les séparer. Les inconvénients pour les développeurs qui ne les utilisent pas sont négligeables, quelques Mo supplémentaires dans le répertoire d'installation et aucun impact sur l'exécution à moins que vous ne les chargiez.

Je ne peux que citer @mythz pour illustrer ce point. Plus les choses sont couplées, plus elles s'emmêlent. Je veux dire Wat !? MVC influence la construction d'une application Asp même si vous ne la référencez nulle part ?!

@poussée
Comme les autres l'ont déjà écrit : non. Il regroupe des éléments qui n'ont rien à voir avec un environnement d'exécution de base. Imaginez que le framework express aurait été fourni avec un nœud par défaut, vous pensez que l'écosystème serait devenu si dynamique et diversifié ?

Je ne comprends absolument pas non plus comment supprimer MVC, SingalR, etc. de l'installation de base et les fournir sous la forme d'un seul package NuGet, chacun peut être étiqueté comme « complexité supplémentaire ». Les développeurs installent de toute façon des packages supplémentaires dans la plupart des cas. Et si les fournir en tant que packages supplémentaires augmenterait les temps de restauration de manière "significative", ils sont de toute façon trop gros.

@Tratcher

Cependant, toute subdivision

La subdivision à laquelle cela fait référence est le découplage de MVC afin que les applications ASP.NET Core puissent avoir une base de référence utile minimale sans aucun cadre de développement avisé qui prescrivent ce qu'elles doivent utiliser pour développer des applications ASP.NET Core.

vient avec une complexité et des frais généraux d'ingénierie considérablement accrus qui prennent du temps à améliorer les fonctionnalités du produit.

Pour clarifier la façon dont cela se lit : cela nécessite trop de frais généraux d'ingénierie pour supprimer les frais généraux inutiles de chaque application ASP.NET Core qui n'utilise pas MVC, car si MVC devait fonctionner comme tous les autres frameworks alternatifs, cela ajouterait considérablement de la complexité "à MVC".

Si MVC nécessite une complexité importante pour fonctionner avec les mêmes options d'extensibilité que tout autre framework alternatif doit fonctionner, cela indique un problème avec MVC et toutes les fonctionnalités ajoutées pour le faire fonctionner de manière plus transparente pourraient être ajoutées au profit de tous. Tout comme pour disséquer un monolithe, la complexité de l'outillage et de l'exécution serait plus légère et moins complexe avec la complexité supplémentaire déplacée là où elle appartient dans MVC et son intégration/outillage.

Au lieu de cela, nous nous sommes retrouvés avec la situation où MVC est ancré dans l'outil par défaut, ce qui peut casser les projets de publication et gonfler les résultats des projets qui ne l'utilisent pas. Comme cela ne fonctionne pas comme tout le reste, il n'y a aucun moyen de lui dire que vous utilisez MVC ou de lui dire que vous n'utilisez pas MVC, c'est toujours supposé.

Lorsque nous nous attendons à ce qu'une majorité significative de clients profite des composants MVC

Eh bien, c'est normal, au détriment de toutes les autres alternatives, il s'agit du cadre prescrit inclus dans l'installation minimale recommandée par défaut, comme Apple offrant à chacun une chanson U2 gratuite, qu'il le veuille ou non.

Les inconvénients pour les développeurs qui ne les utilisent pas sont négligeables

Les développeurs bénéficieraient-ils d'un écosystème plus sain avec plus de variété, d'options et d'innovation ?

Les développeurs bénéficient-ils de la confusion supplémentaire et de la définition floue de ce qu'est une « application ASP.NET Core » ? "Auparavant, c'était comme node.js pour .NET, mais maintenant il s'agit davantage d'un cadre de fournisseur unique où l'essentiel de chaque application commence par un tas de trucs avisés qui prescrivent comment vous devez créer des applications Web, vous pouvez le considérer comme chaque L'application est pré-installée avec express et ses dépendances par défaut - vous êtes censé l'utiliser"

Les développeurs bénéficient-ils du boîtier spécial de MVC ? Il n'est pas installé ou mis à jour comme toute autre chose et repose sur des outils cachés et un comportement magique que vous devez fouiller pour savoir exister et désactiver. Un boîtier spécial comme celui-ci ajoute une complexité accidentelle, lorsque vous raisonnez sur votre projet, vous devez maintenir un ensemble de règles différent pour le fonctionnement de MVC par rapport à la façon dont tout le reste fonctionne.

S'il était explicite, cela améliorerait la lisibilité et vous pourriez dire à partir de la configuration du projet qu'il s'agit d'une application MVC, par exemple :

• Microsoft.AspNetCore.Mvc

Ce qui signale qu'il s'agit d'une application MVC et pour installer toutes les dépendances et configurer automatiquement tous les outils sur mesure dont MVC a besoin - idéalement en utilisant le même modèle extensible ouvert auquel tout le monde a accès.

En le conservant dans le projet par défaut "Microsoft.AspNetCore.App", vous l'associez pour toujours à chaque application ASP.NET Core et le rend désavantageux pour que quelque chose de mieux se présente. Les pages Web ASP.NET étaient un autre framework de vue Razor ajouté à ASP.NET il y a des années qui a été installé et dont le comportement magique invasif était également activé par défaut. Il est livré avec son propre IDE Web Matrix qui n'est plus pris en charge ou disponible au téléchargement . Il nous reste donc un cas où la complexité d'une technologie morte est à jamais intégrée dans ASP.NET classique et cause activement des problèmes pour d'autres frameworks Web actifs. attacher à utiliser les pages Razor .cshtml qui doivent toujours transporter les bagages ci-dessous pour empêcher explicitement les pages Web de casser leurs cadres de vue avec:

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

Réitérer les demandes de fonctionnalités par ordre de préférence serait de :

1. Remplacez « Microsoft.AspNetCore.App » par la ligne de base minimale utile pour toutes les applications ASP.NET Core (c'est-à-dire sans MVC).
2. Maintenez un méta-package tel que "Microsoft.AspNetCore.Base" que tout le monde n'utilisant pas MVC pourrait utiliser comme base de référence utile minimale.

Si aucun de ces éléments ne doit être pris en compte, pouvons-nous au moins avoir un indicateur à l'échelle du projet comme mvc:enabled = false que tous les outils MVC pourraient vérifier pour les désactiver et les empêcher de s'exécuter ?

@mythz tu me

Si aucun de ceux-ci ne doit être pris en compte, pouvons-nous au moins avoir un indicateur à l'échelle du projet comme mvc:enabled = false que tous les outils MVC pourraient vérifier pour les désactiver et les empêcher de s'exécuter ?

Pouvez-vous être plus précis sur les fonctionnalités d'outillage que vous aimeriez voir désactivées ? Cela pourrait valoir un problème séparé.

@Tratcher

La complexité supplémentaire n'est pas liée au MVC, mais à la construction d'infrastructures, d'emballages, d'installateurs, etc. nécessaires pour créer et expédier une autre couche de composants, quelle que soit la composition de cette couche.

c'est-à-dire la complexité supplémentaire de ce qui serait nécessaire pour que MVC fonctionne.

Pouvez-vous être plus précis sur les fonctionnalités d'outillage que vous aimeriez voir désactivées ? Cela pourrait valoir un problème séparé.

Les 2 problèmes que j'ai rencontrés étaient de devoir configurer manuellement /p:MvcRazorCompileOnPublish=false ce qui empêchait la publication de mon projet (sans pages .cshtml). L'autre indicateur qui doit être désactivé est :

<PreserveCompilationContext>false</PreserveCompilationContext>

Comme pour la plupart des comportements magiques, je suppose qu'il y en a plus, mais je ne les découvre que lorsque je les rencontre.

Fondamentalement, un indicateur pour spécifier que MVC n'est pas utilisé et pour désactiver tous les outils ou concessions activés par défaut qui ont été ajoutés à cause de MVC.

@mythz va de l'avant et

Vous pouvez en fait créer un cadre partagé similaire pour la pile de services si les dll MVC et SignalR supplémentaires sont une préoccupation pour vos utilisateurs.

@davidfowl Cela semble en fait assez génial, j'ai pu voir quelques cas d'utilisation différents pour les frameworks fournis par la communauté. Existe-t-il de la documentation à ce sujet ?

Comme vous pouvez l'imaginer, ce n'est pas quelque chose pour lequel nous créerions un support de première classe car le nombre de personnes qui le font est petit. Cela dit, vous pouvez regarder comment nous construisons le nôtre et imiter ce comportement.

@davidfowl Le package de base minimal serait utile pour toutes les applications non MVC - par exemple, il y aura beaucoup d'autres applications légères et microservices qui voudront contourner tous les frameworks et écrire directement dans la réponse elles-mêmes. OMI, cette option devrait être disponible dans la boîte, nous préférons ne pas partir d'une base non officielle composée de versions de packages sur lesquelles nous n'avons aucun contrôle. Idéalement, tout serait additif à partir du package de base au lieu de partir d'une tangente différente maintenue à l'extérieur. Mais c'est peut-être un domaine où la communauté externe peut se réunir pour maintenir un sous-ensemble de base "AspNetCore" qui est utile pour toutes les applications et frameworks non MVC.

Cela dit, où devrions-nous chercher pour créer un cadre personnalisé ? Ce sera peut-être aussi simple que de partir d'une copie de ce qui a été utilisé pour créer "Microsoft.AspNetCore.App" et de supprimer toutes les bibliothèques non essentielles pour le ramener à un sous-ensemble utile minimal.

@mythz pourquoi avez-vous même besoin d'un framework, vous pouvez simplement utiliser directement le serveur Kestrel. Ceci juste pour dire que votre version de la lumière n'est peut-être pas l'idée de la lumière ou du noyau de quelqu'un d'autre. Nous avons actuellement un avis et ce serait incroyable si la communauté pouvait intervenir ici et créer des modèles et un cadre partagé alternatif suffisamment minimal. Nous sommes OSS, tout le nécessaire pour créer quelque chose de personnalisé est là et nous sommes très réactifs et serons ravis de vous aider.

@natemcmaster Peut vous aider avec des détails sur la façon de créer un cadre partagé personnalisé.

@davidfowl vous avez suggéré d'en créer un personnalisé, je ne suis qu'après avoir pu partir d'une base utile minimale sans frameworks avisés. Nous ne voulons pas référencer plusieurs packages individuellement pour la même raison que la recommandation est que toutes les applications ASP.NET Core référencent "Microsoft.AspNetCore.App" - il est plus accessible de pouvoir référencer un seul package.

Ceci juste pour dire que votre version de la lumière n'est peut-être pas l'idée de la lumière ou du noyau de quelqu'un d'autre.

Tout le monde semble être assez unanime ici sur le fait que MVC n'appartient pas au package de base. Le seul autre "produit" qui semble être inclus est SignalR qui, j'imagine, aurait moins d'utilisation que MVC et moins de raisons d'être inclus. Je ne connais pas intimement le contenu de chaque package, mais tout le reste semble être génériquement utile et une partie propice de la "plate-forme" ASP.NET Core.

OK, permettez-moi de faire une suggestion pour essayer d'être constructif ici. Nous ne changeons pas Microsoft.AspNetCore.App, nous pensons que c'est quelque chose dont la majorité des utilisateurs auront besoin et utiliseront. Introduisons une autre couche qui est ce framework partagé "de base" (nous avons fait quelque chose comme ça à l'origine avec https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497). C'est le framework partagé sur lequel vous baseriez ces autres frameworks (comme Nancy et ServiceStack).

Nous expédierons toujours nos modèles par défaut avec Microsoft.AspNetCore.App comme maintenant, mais les auteurs de framework comme vous peuvent avoir d'autres modèles qui utilisent le framework partagé de base.

PS: Ce fil ne représente pas à distance la majorité de nos clients, donc je ne tirerais pas de conclusions à partir d'ici seul. Nous recevons des commentaires de beaucoup d'endroits et github a nos conseils les plus vocaux et les plus passionnés.

Oui, je pense que c'est plus proche de contenir beaucoup des éléments essentiels pour configurer une application et la faire fonctionner. À partir des deps de Microsoft.AspNetCore.App, nous utilisons également :

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Ainsi, des éléments tels que HTTP, l'hébergement, la journalisation et les abstractions de configuration (utiles pour la plupart des applications HTTP) seraient également intéressants à inclure et tout ce que tout le monde juge approprié. Ma seule préférence est de ne pas inclure MVC/SignalR.

et maintenant ça devient intéressant. comme david l'a déjà dit : les gens ont des
idées de ce que "noyau" signifie. De mon POV, je ne pense pas que DependencyInjection
devrait être dedans. /hausse les épaules

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

Ouais, je pense que c'est plus proche de contenir beaucoup de l'essentiel pour
configurer une application et la faire fonctionner. Des profondeurs de
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App nous sommes également
à l'aide de:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Donc des trucs comme les abstractions HTTP, Hosting, Logging et Configuration
(utile pour la plupart des applications HTTP) serait également bien d'être inclus et tout
d'autre que quelqu'un juge approprié. Ma seule préférence est de ne pas avoir
MVC/SignalR inclus.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz La plupart d'entre eux sont inclus de manière transitive.

@forki 😆 Bienvenue dans notre monde.

Nous ne changeons pas Microsoft.AspNetCore.App, nous pensons que c'est quelque chose dont la majorité des utilisateurs auront besoin et utiliseront.

Derniers mots célèbres. Ceci est la justification de chaque mauvaise décision - "NOUS pensons qu'ILS en ont besoin".

Tu sais ce que je pense? Microsoft devrait commencer à traiter sa base de développeurs comme des ingénieurs intelligents indépendants et non comme des développeurs moutons, et oui, vous avez de nombreux développeurs moutons, qui suivront et utiliseront tout ce que vous leur lancerez, mais ce sont les autres développeurs plus vocaux qui feront un communauté et créer de nouvelles startups sur la pile .NET.

Parfois, il est bon d'écouter les utilisateurs expérimentés.

Quoi qu'il en soit, nous n'allons pas changer Microsoft.AspNetCore.App. J'ai proposé un compromis qui, je pense, satisfait aux exigences ici.

@forki si vous utilisez le noyau aspnet, vous êtes de toute façon confronté à DI, mieux vaut inclure des méthodes de commodité par défaut (Get service, GetRequiredServiceet les likes sont dans ce package). Et bon, F# ne peut même pas les créer tout seul en raison de la contrainte T :> U manquante https://github.com/fsharp/fslang-suggestions/issues/255 donc ¯_(ツ)_/¯

J'aimerais que ce framework partagé de base @davidfowl soit mentionné... Je pense que @mythz et @dustinmorris seraient tous les deux d'accord avec une telle approche. C'est aussi opportun pour Saturne @Krzysztof-Cieslak

vous êtes confronté à DI de toute façon

Je sais et nous avons eu cette discussion plusieurs fois. C'est juste que je préfère ne pas
;-) mais c'est comme ça...

Am Ven., 9. Nov. 2018, 10:57 chapeau Nino Floris [email protected]
geschrieben :

@forki https://github.com/forki si vous utilisez le noyau aspnet, vous êtes
confronté à DI de toute façon, mieux vaut lui faire inclure des méthodes de commodité en
par défaut (Get service, GetRequiredService et les goûts sont dans ce
emballer). Et bon, F# ne peut même pas les créer tout seul à cause de l'absence
T :> U contrainte fsharp/fslang-suggestions#255
https://github.com/fsharp/fslang-suggestions/issues/255 donc ¯_(ツ)_/¯

J'aimerais avoir ce framework partagé de base @davidfowl
https://github.com/davidfowl mentionné... Je pense que @mythz
https://github.com/mythz et @dustinmorris
https://github.com/dustinmorris serait tous les deux d'accord avec une telle approche.
C'est aussi opportun pour Saturne @Krzysztof-Cieslak
https://github.com/Krzysztof-Cieslak

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

Mise à jour du message d'origine pour inclure :

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

Ceux-ci sont retirés du framework partagé et seront expédiés sous forme de packages NuGet. Ces assemblys dépendent des API IdentityModel qui ne correspondent pas encore aux directives du framework partagé. Nous avons commencé à travailler avec l'équipe IdentityModel et envisageons de les remettre dans le cadre partagé à l'avenir. cref https://github.com/aspnet/AspNetCore/pull/6035

Mettez à jour le message d'origine pour inclure Microsoft.AspNet.WebApi.Client. Voir https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732.

Je suis souvent assez confus car c'est ce que je dois inclure.

Talking Visual Studio - Suis-je censé ouvrir le nœud Microsoft.AspNetCore.App et croiser tout ce qui se trouve en dessous avec ce que j'ai peut-être installé individuellement ?

Je fais du ménage et je vois que j'ai ces paquets. Alors, lesquelles sont redondantes ?

<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">

J'ai été assez surpris de voir que même les outils SpaServices et EntityFramework sont actuellement inclus (ce que je n'avais pas réalisé auparavant - et c'est génial) - mais j'ai aussi d'anciennes références 2.2.1 qui ne peuvent rien aider.

Le point étant - un meilleur travail de coordination peut-il être fait avec l'équipe Visual Studio pour s'assurer que l'IDE est juste un peu plus intelligent pour comprendre ces méga packages et me dire qu'il est sûr de supprimer quelque chose - puis dans v3 me dire que je dois l'ajouter de nouveau ;-)

@simeyla merci pour le retour. Ce que vous dites est lié au sujet, mais ce n'est pas exactement le sujet de ce fil. L'outillage pour optimiser les références de package serait une nouvelle fonctionnalité de Visual Studio. Cette fonctionnalité pourrait être généralement utile, pas seulement pour ce scénario, je suggère donc d'envoyer ces commentaires directement à Visual Studio. Dans VS, utilisez "Aide > Envoyer des commentaires...". Si vous partagez le lien après avoir créé le message, je peux le transmettre en interne à nos équipes de pairs qui travaillent sur VS.

Dans la version 3.0, nous éliminerons complètement le métapackage Microsoft.AspNetCore.App et apporterons de nombreux ajustements aux packages que nous expédions. Nous avons commencé à documenter la mise à niveau de 2.x vers 3.0 et continuerons à mettre à jour ce document au fur et à mesure que nous finalisons la liste des assemblys livrés en 3.0.

Passage au jalon « Discussions » car cet élément ne suit aucun travail, mais nous le mettrons plutôt à jour au fur et à mesure que les détails de la mise en œuvre changent.

Ajout de Microsoft.Extensions.DependencyModel à la liste. Modifié dans le cadre de https://github.com/aspnet/AspNetCore/pull/10271

Question ici @natemcmaster @DamianEdwards , il est fait mention des modèles ayant tout ce qu'il faut pour construire localement. Avec cette pensée et la suppression des bibliothèques Auth, cela signifie-t-il qu'aucun modèle d'authentification ne sera construit hors ligne dans 3.0 ? Je comprends qu'aucune bibliothèque d'authentification ne fonctionnera hors ligne, mais si je n'ai pas de cache nuget, je pourrais théoriquement obtenir un échec de construction après la création d'un nouveau modèle d'authentification si j'étais hors ligne. Cela semble être une mauvaise expérience.

Oui, c'est l'un des résultats de ce changement. À partir de l'Aperçu 6 (à venir), dotnet new mvc , dotnet new razor , dotnet new web et d'autres n'ont pas de PackageReferences, ils ne devraient donc pas être affectés, mais en spécifiant des options supplémentaires , comme --auth individual peut entraîner la présence d'une référence de package qui nécessite un téléchargement de package.

Nous faisons ici un compromis intentionnel. Bien que les modèles dotés de PackageReference ne soient pas restaurés hors ligne sur une machine propre, nous évitons également de nombreux problèmes liés à la tentative de création d'un cache NuGet hors ligne pré-rempli (pour commencer, consultez https://github.com/dotnet/ dotnet-docker/issues/237, https://github.com/NuGet/Home/issues/6309 et http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html).

@natemcmaster comprend parfaitement et je comprends le raisonnement, il faut juste que ce soit bien documenté ou il y aura une tonne de problèmes ouverts lors de la version 3.0 initiale où les gens disent que dotnet new webapp --auth Individual ne se construit pas.

Quelqu'un peut-il m'expliquer pourquoi Microsoft.AspNetCore.Authentication.JwtBearer est compilé avec une dépendance sur .netcoreapp3.0 ? Ne peut-il pas être sur .netstandard2.x ? Je veux l'utiliser dans une bibliothèque de classes et j'aime garder mes bibliothèques de classes toutes .netstandard

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

@Pilchie Je pense que ce problème mérite d'être <PackageReference> pour compenser l'API qui a été déplacée de Microsoft.AspNetCore.App.

@Bomret Presque toutes les applications client du monde réel que nous avons inspectées utilisent MVC d'une manière ou d'une autre. Il y a de nombreux avantages à le conserver dans le cadre partagé, et je ne vois pas de raisons claires pour lesquelles nous devrions le supprimer.

Nous ne le faisons certainement pas, et je connais pas mal de personnes dans d'autres magasins qui utilisent le noyau .net pour les applications sans serveur, les API Web, etc., où nous n'avons absolument aucun besoin de MVC.

Clôture, puisque nous avons expédié 3.0 aujourd'hui.

Nous devons déplacer cette liste vers la doc

@davidfowl, il a été ajouté : https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete-package-references

@pranavkm cette liste est en fait exactement le contraire : des choses qui ne sont plus des packages mais qui sont probablement toujours dans le framework partagé.

Il s'agit de choses qui ont été supprimées du framework partagé, mais qui sont probablement désormais disponibles uniquement sous forme de packages.

@scottaddie c'est la liste que nous devrons référencer dans le document de création de la bibliothèque ASP.NET Core.

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

C'est celui-là :)

En retard à la fête, mais cela n'a pas l'air de m'aider à atteindre l'objectif de simplifier mon développement.

a) Il semble que maintenant, s'il y a une amélioration d'un composant AspNetCore (disons, SignalR), alors nous devons attendre qu'un nouveau "dotnet pack" pour Microsoft.AspNetCore.App soit publié pour l'utiliser, emportant tout avec lui d'autre dans ce pack ?
b) Impossible de créer des classes utilitaires pour AspNetCore dans les bibliothèques de classes netstandard (par exemple, middleware Auth). Désormais, les bibliothèques de classes doivent être netcoreapp3.0 pour héberger ces éléments. Cela signifie diviser nos bibliothèques de classes utilitaires en implémentations netstandard / netcore.
EDIT : c) Comment définir la version du pack que j'utilise si je fais <Project Sdk="Microsoft.NET.Sdk.Web"> ? Évidemment, nous voulons avoir des builds reproductibles sur différentes branches après la mise à jour de dotnet.

a) Il semble que maintenant, s'il y a une amélioration d'un composant AspNetCore (disons, SignalR), alors nous devons attendre qu'un nouveau "dotnet pack" pour Microsoft.AspNetCore.App soit publié pour l'utiliser, emportant tout avec lui d'autre dans ce pack ?

SignalR est expédié selon le même calendrier que le reste d'AspNetCore, il n'y a donc pas de changement de calendrier ici.

SignalR est expédié selon le même calendrier que le reste d'AspNetCore, il n'y a donc pas de changement de calendrier ici.

Alors ce n'est qu'un mauvais exemple ? Peut-on en dire autant de tous les autres packages NuGet qui ont été supprimés ?

SignalR est expédié selon le même calendrier que le reste d'AspNetCore, il n'y a donc pas de changement de calendrier ici.

Alors ce n'est qu'un mauvais exemple ? Peut-on en dire autant de tous les autres packages NuGet qui ont été supprimés ?

Je pense que oui. Tous les composants .NET Core et ASP.NET Core utilisent le même calendrier d'expédition. Si quelque chose ne fonctionnait pas, il devrait être expédié dans son propre emballage.

Je pense que oui. Tous les composants .NET Core et ASP.NET Core utilisent le même calendrier d'expédition. Si quelque chose ne fonctionnait pas, il devrait être expédié dans son propre emballage.

Je te prendrai au mot. Je n'ai pas de contre-exemples précis. Cela ne "se sentait" tout simplement pas de cette façon lors de la mise à jour des packages AspNetCore NuGet dans le passé.