Aspnetcore: Ensamblados que se eliminan de Microsoft.AspNetCore.App 3.0

Creo que los paquetes MVC también deberían convertirse en paquetes NuGet adicionales. MVC es genial, pero a diferencia de ASP.NET Core de vainilla, es extremadamente obstinado sobre cómo se debe diseñar una aplicación we que realmente no es del agrado de todos, y mucho menos incluso encaja con el paradigma de todos los lenguajes .NET. Realmente creo que el marco ASP.NET Core compartido merece ser MVC gratuito o tener una segunda versión gratuita de MVC. ¿Qué piensas?

¿Cuál sería el beneficio? ¿Cómo mejoraría esto la vida de las personas que crean aplicaciones ASP.NET Core?

¡Excelente! Solo necesito lo que necesito cuando uso asp.net core.

@davidfowl

¿Cuál sería el beneficio? ¿Cómo mejoraría esto la vida de las personas que crean aplicaciones ASP.NET Core?

Por las mismas razones por las que no incluye los paquetes enumerados en la parte superior de este número. Creo que siempre es más fácil agregar más paquetes al marco que se enviarán con .NET Core 3.0 que eliminar paquetes más adelante. ¿Por qué no comienza a agregar el denominador común más pequeño para ejecutar una aplicación básica ASP.NET Core y luego ofrece el resto como paquetes NuGet? Si esto resulta ser un problema para los desarrolladores, siempre puede agregar más cosas más tarde, pero ya no podrá eliminarlas más fácilmente.

Porque también tenemos que encontrar un equilibrio con la utilidad por defecto.

Ok, bueno, creo que vainilla ASP.NET Core ya es útil (y pensé que tú también lo crees, de lo contrario, ¿por qué no lo hiciste útil?), Pero si ya te has fijado en lo que debería estar en el marco y lo que no, no importa;)

Si fueras un purista, no tendrías la mayor parte del middleware, MVC o SignalR en la caja porque no son estrictamente necesarios. Trazar esta línea entre lo que debería ser el conjunto predeterminado de cosas y lo que no es algo intuitivo y confuso (basado en la experiencia, mirando otras plataformas pasadas y presentes y haciendo una llamada). A partir de ASP.NET Core 3.0, no tenemos planes de eliminarlos (al menos en este momento).

Sí, sé que siempre es una decisión difícil de hacer, pero a veces no estoy seguro de cuál es la justificación de la tendencia (de Microsoft) de inflar las cosas más de lo necesario. La forma en que posicionas tus propios productos en el mercado es cómo se van a percibir. Se supone que ASP.NET Core es el nuevo marco web flexible y componible moderno, pero la forma en que coloca todo es que ASP.NET Core es inútil a menos que fuerce MVC + SignalR + Identity + EF hacia todos. En mi opinión, ya ha hecho la llamada de dónde se deben dibujar las líneas, es por eso que MVC y SignalR no están incrustados en ASP.NET Core, sino marcos separados que se pueden agregar cuando se desee, entonces, ¿por qué está difuminando estas líneas ahora? Se siente inconsistente y no puedo pensar en ningún valor que obtengas de eso. En lugar de simplemente promover ASP.NET Core + un próspero ecosistema de código abierto, está promoviendo una experiencia web muy limitada. Todo lo que hace es crear frustración con aquellos que quieren ser un poco diferentes y trabajar más para usted, ya que termina presionando cosas a las personas que tal vez no quieran.

No es que la gente no use MVC si no lo mete en el marco predeterminado. Conviértalo en un solo paquete de NuGet y nadie se quejará de tener que obtener MVC de NuGet. Es más probable que venga más gente y pregunte por qué infló el marco predeterminado con cosas que no quieren como yo.

Supongo que esta es una discusión y aún es algo que ustedes podrían considerar, así que si hay algo que me gustaría que hicieran es plantear esta pregunta a su equipo tal vez nuevamente y ver si están realmente decididos a esto o si puedes suavizar mi idea :)

PD: No estoy seguro si ese es el caso, pero espero que SignalR sea un paquete NuGet separado también. Es como si incluyera Bootstrap y Angular2 en su marco predeterminado. Si estos dos productos fueran desarrollados por Microsoft, probablemente lo harías, pero no tendría sentido y creo que solo porque los hace un tercero, ves que no tiene sentido.

TBH Me encantaría ver más cosas eliminadas de la instalación predeterminada. Especialmente MVC. Esto es lo que hace que los Frameworks alternativos sobre ASP.NET Core sean aún más atractivos. También me pregunto por qué cosas como ContentResult viven en MVC y no en el núcleo. Se usa mucho en funciones azules y ahora siempre tengo que hacer referencia a las cosas de MVC, solo para ContentResult.

Creo que el punto es más que no debería tener un impacto negativo en tener las cosas de MVC en el SDK de ASPNET. La mayoría de los desarrolladores lo usarán, por lo que es preferible enviarlo de esa manera a la carga de restauración hinchada. Si no lo desea, simplemente no puede usarlo. La mayoría de los paquetes enumerados anteriormente traen dependencias de terceros (json), tienen algún aspecto pesado (maquinilla de afeitar) o están conceptualmente separados de ASPNET y, a menudo, se hace referencia a ellos fuera del SDK (EFCore).

Por mucho que esté de acuerdo con el incumplimiento de los mínimos para fomentar un campo de juego equitativo para los marcos de OSS, eso tiene que ser equilibrado. En los primeros días del núcleo (beta e incluso 1.0) las cosas eran paquetes en todas partes y eso era MUCHO más confuso y la restauración tardaba una eternidad.

@psibernetic, incluso si las cosas están en paquetes separados, el instalador principal de .net puede colocar estos paquetes en cachés locales.

@psibernetic Eres la segunda persona que menciona que es importante

Dame un caso del mundo real en el que tener MVC como un solo paquete NuGet sería confuso, la restauración tardaría una eternidad, o cualquiera de los otros aspectos negativos que has mencionado.

Y hablando de tiempo de restauración ...

En mi humilde opinión, es más importante tener contenedores de inicio rápido o arquitectura sin servidor (ya que eso es lo que tiene un impacto en el mundo real en los negocios) que tener una compilación un poco más rápida en una máquina de desarrollo. Sí, esto último también es muy importante y quiero que sea increíblemente rápido, pero si tuviera que clasificar la importancia, prefiero recibir un golpe menor en mi máquina de desarrollo que en mi infraestructura de producción en la nube. Por lo tanto, mantener la huella lo más pequeña posible es solo (si no más) importante que reducir el tiempo de restauración.

¿Cuál sería el beneficio? ¿Cómo mejoraría esto la vida de las personas que crean aplicaciones ASP.NET Core?

Creo que es un bloatware no deseado para todos los demás usuarios que no usan MVC, como CandyCrush preinstalado en mi PC con Windows 10. Asp.net core predicó que se estaba volviendo menos obstinado con middleware totalmente configurable, según sea necesario, etc. ¿Las plantillas de dotnet permiten que MVC sea un paquete incluido por defecto sin necesidad de ser integrado en el núcleo?

Hay muchos otros marcos por ahí como Nancy, ServiceStack y Giraffe que todos tienen sus méritos y no deberían tener la hinchazón / conflictos con una instalación forzada de MVC no deseada / innecesaria. Simplemente parece inconsistente dado que la autenticación, la maquinilla de afeitar, EF, etc.están empaquetados, pero MVC, ¿el niño dorado llega a ser parte del marco central cuando no es central?

Si se debe a que MVC está tan estrechamente acoplado al núcleo que el desacoplamiento sería un montón de trabajo, puedo conseguirlo, pero sobre la base de que generalmente hace que la vida de algunos desarrolladores sea más fácil, parece perezoso y muy parecido al antiguo asp.net Esperaba que nos alejáramos de la mentalidad MVC.

Se suponía que .NET Core era el clon modular ajustado de node.js para .NET, pero no parece que tenga la intención de replicar las características que fomentan su ecosistema vibrante y próspero: un núcleo pequeño, flexible y sin pilares con características incluidas. En esencia, beneficia a todo eso, gracias a que no está incluido en ningún marco web obstinado, está maduro para la experimentación y disfruta de un número saludable de marcos populares con sus propias comunidades independientes.

Quiero decir, consigo que el equipo de ASP.NET crea que están construyendo el mejor marco posible, pero no todos están de acuerdo con todas las opiniones que se eligen o con el nivel de complejidad requerido para hacer algo. Todo en .NET Core se desarrolló con el beneficio de la retrospectiva y muchos de ellos se inspiraron en los enfoques que se vieron exitosos en otras plataformas, al elaborar opiniones sobre qué tecnologías usar, se está muriendo de hambre la próxima innovación proveniente de .NET e incluso cuando lo siguiente gane tracción en otras plataformas, ASP.NET Core estará en desventaja para replicar su éxito, ya que siempre pagaremos el "impuesto MVC" predeterminado en el futuro, donde se espera que todos usen su modelo de desarrollo para todos los sitios web. Aplicaciones hasta el infinito.

La ligereza de Node también lo hace adecuado para desarrollar una serie de otros casos de uso como Electron, aplicaciones móviles nativas, IOT, scripts de shell, etc., es decir, ninguno de los cuales se beneficia de tener un marco web incluido en la instalación predeterminada. Cuanto más hinchada se vuelve la instalación predeterminada, menos útil se vuelve para su uso en otros escenarios.

En mi opinión, el valor predeterminado debería ser volver a la visión original de .NET Core de tener un núcleo modular esbelto con el enfoque en facilitar la adición de funciones (que todos puedan aprovechar), es decir, no agruparlas de forma predeterminada e inflar las predeterminadas. Instalar en pc.

Gracias por los comentarios. Permítanme compartir algunos pensamientos.

1. No estamos recortando ensamblajes porque nos apetezca. Cada ensamblaje que eliminamos es un cambio importante y se suma al costo de actualizar de 2.xa 3.0. Estos son los principios rectores que usamos para decidir qué se incluye en Microsoft.AspNetCore.App: https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. A los ensamblados que proponemos eliminar les faltan algunos de los criterios para su inclusión en el marco compartido. En particular, estos ensamblados: (1) tienen dependencias en el código de terceros que no tenemos la capacidad de dar servicio (2) los ensamblajes en sí mismos están siendo obsoletos en 3.0 o (3) implementan protocolos o mecanismos de autenticación que están altamente sujetos a cambios ( por ejemplo, Facebook / Google / Twitter podría decidir mañana cambiar la forma en que funciona la autenticación)

2. Eliminar MVC de Microsoft.AspNetCore.App no ​​es algo que consideremos. Si bien reconocemos que no todos los usuarios hacen referencia a MVC en su aplicación, creemos que esta es una pieza central de la oferta de ASP.NET Core. Planeamos mantener esto en Microsoft.AspNetCore.App.

3. MVC ha sido parte de Microsoft.AspNetCore.App desde 2.1, pero como verá en las plantillas 2.1 "Web vacía" , no tiene que usar MVC. Su presencia en el marco compartido no le obliga a utilizarlo en su aplicación. Aún puede usar alternativas, escribir su propio marco de vista o usar las API aspnetcore más "sin procesar" para leer y escribir solicitudes y respuestas HTTP directamente.

4. @dustinmoris : Creo que siempre es más fácil agregar más paquetes al marco que se enviarán con .NET Core 3.0 que eliminar paquetes más adelante. ¿Por qué no comienza a agregar el denominador común más pequeño para ejecutar una aplicación básica ASP.NET Core y luego ofrece el resto como paquetes NuGet? Si esto resulta ser un problema para los desarrolladores, siempre puede agregar más cosas más tarde, pero ya no podrá eliminarlas más fácilmente.

   Eso es exactamente lo que estamos tratando de hacer. Es más fácil agregar que quitar. Agregamos demasiadas cosas en 2.0 y nos estamos reajustando a lo que creemos que es un conjunto de cosas que se puede mantener en el futuro futuro. La mayoría de los ensamblados eliminados de Microsoft.AspNetCore.App se seguirán ofreciendo como paquetes NuGet. Si más tarde descubriéramos que el 90% de todos los clientes hacen referencia al mismo paquete, sería un buen candidato para el marco compartido. Sin embargo, como se menciona en el documento de orientación , la cantidad de API que se usa es una métrica importante, pero no es el único factor que consideramos.

5. "Vainilla" es subjetivo. Para muchos de nuestros usuarios, MVC y SignalR son "vainilla".

6. Algunas personas han dicho que se suponía que .NET Core era esto o aquello o alguna otra cosa. Las cosas cambian, recopilamos comentarios de los usuarios, observamos cómo se usa el producto e intentamos ajustar los valores predeterminados para que coincidan con lo que creemos que beneficiará a la mayor cantidad de clientes. Los ajustes propuestos en este número son un reflejo de los comentarios que hemos recibido sobre .NET Core 2.x.

Pensamiento final: este tema no va a hacer felices a todos. Si parece que estamos ignorando sus comentarios, le pido disculpas. Por favor, reconozca que tenemos cientos de miles de clientes, y solo un pequeño número de ellos viene a GitHub para compartir sus comentarios. También recopilamos información de visitas en persona, llamadas telefónicas, correos electrónicos, redes sociales, solicitudes de atención al cliente, blogs, telemetría de Visual Studio y más. Todo esto es parte de lo que consideramos al tomar decisiones y lo que es parte de la experiencia predeterminada y lo que no lo es.

Si algo no está claro sobre nuestras motivaciones o razones, hágamelo saber e intentaré aclararlo.

Si tiene tanto contacto directo con el cliente, ¿cuándo fue la última vez que preguntó cuántos de ellos están usando MVC y SignalR? ¿Hay métricas de uso reales detrás de esta postura de mantenerlas definitivamente en lugar de tener cada una en un solo paquete NuGet que se puede instalar muy fácilmente cuando sea necesario?

@dustinmoris incluir MVC en el tiempo de ejecución compartido significa que se envía precompilado, este es un beneficio que se perdería, lo que aumentaría los tiempos de inicio como mínimo, lo que lo convierte, en mi opinión, en una mala compensación en su ejemplo de inicio rápido contenedores docker. Además de eso, cada implementación ahora necesitaría enviar los paquetes junto con la aplicación, ya que no está en el tiempo de ejecución, esto aumenta el tamaño del paquete de implementación de cada aplicación MVC. Finalmente, cualquier paquete que dependa de MVC en el tiempo de ejecución también tiene que convertirse en un implementable por separado, no estoy seguro de cuántos, si es que hay alguno, es esto, ya que no puedo encontrar la lista completa.

Dicho todo esto, y tenga en cuenta que no tengo ninguna afiliación con Microsoft o el equipo de aspnet, PODRÍA ver un tiempo de ejecución separado enviado que fuera uno básico de aspnetcore SI la comunidad realmente lo expresó y demostró que era un deseo importante. La misión es proporcionar una gran experiencia para tantas aplicaciones y desarrolladores como sea posible y, en este momento, un porcentaje increíblemente alto de los que se benefician de MVC en el tiempo de ejecución compartido. @natemcmaster, ¿hay una forma preferida para que las personas interesadas voten por esto en el futuro, quizás un problema de GitHub, y es esta una solución razonable?

@psibernetic, puede iniciar un nuevo problema de GitHub para eliminar MVC del marco compartido, pero como dije anteriormente, eliminar MVC de Microsoft.AspNetCore.App no ​​es algo que consideremos, por lo que es poco probable que este problema gane tracción en nuestro equipo.

@Bomret Casi todas las aplicaciones de clientes del mundo real que hemos inspeccionado utilizan MVC de alguna manera. Hay muchos beneficios de mantenerlo en el marco compartido, y no veo ninguna razón clara por la que debamos eliminarlo.

@Natemcmaster : Estoy en mi teléfono ahora, pero gracias por la explicación y solo
Me di cuenta de que se trata del metapaquete mientras hablaba del
marco compartido.

@natemcmaster Creo que @forki , @dustinmorris , @gerardtoconnor y @mythz han expresado razones muy sólidas contra las que aún no he escuchado argumentos en contra. Hubiera sido muy bueno tener un tiempo de ejecución web base / lib que los autores del marco pudieran construir en la parte superior como nodejs en lugar de agrupar cosas obstinadas con él. Como se mencionó anteriormente, el nodo es tan exitoso porque no exige demasiado, pero proporciona abstracciones agradables sobre las que puede construir. MVC no desaparecería, simplemente dejaría de serlo y se convertiría en una opción a elegir entre una variedad de otras bibliotecas web y marcos. Al incluirlo, toma una postura a favor. Por supuesto, la mayoría de los desarrolladores simplemente lo toman como se envía con el tiempo de ejecución, en lugar de buscar más. En mi sincera opinión, eso suena a política y marketing, sin ofender.

Se llama "Microsoft.AspNetCore.App", ¿por qué no crear un segundo "Microsoft.AspNetCoreMVC.App"?

De todos modos, entiendo que es muy difícil trazar la línea, pero creo que la retroalimentación general aquí es que ustedes tienen un número creciente de personas a las que les gusta lo que hicieron con aspnet core, pero a quienes realmente no les gustan cosas como MVC, razor , EF o señal R.

En efecto. Puede contar con que la comunidad será lo suficientemente dinámica como para aportar un montón de ideas para bibliotecas y marcos para manejar api, web, websockets, plantillas, acceso a la base de datos, etc. Ustedes estarían proporcionando una opción para aquellos con MVC, Razor, EF, etc. pero no la única ni la predeterminada.

@natemcmaster Mi error, en realidad estaba hablando del marco compartido en este número aquí. Creo que las mismas razones también se aplican al metapaquete, pero para ser honesto, eso me molesta menos, porque ya puedo hacer referencia a paquetes individuales en lugar del metapaquete, pero no puedo recortar fácilmente un marco compartido si quiero mantener un contenedor lo más pequeño posible, por lo que su sugerencia de abrir un nuevo número para el marco compartido tiene sentido 👍

@natemcmaster ¿Podría confirmar rápidamente si entendí las cosas correctamente?

• Habrá un marco ASP.NET Core compartido integrado en el próximo tiempo de ejecución de .NET Core (3.0), lo que significa que ASP.NET Core se envía como parte de la instalación de .NET Core en un entorno.

• Además, hay un metapaquete llamado Microsoft.AspNetCore.App y Microsoft.AspNetCore.All que son una colección de paquetes NuGet para aplicaciones ASP.NET Core

• ¿El marco ASP.NET Core compartido <el metapaquete Microsoft.AspNetCore.App que incluye cosas como EF Core?

• Puedo crear una aplicación web ASP.NET Core sin tener que incluir el metapaquete Microsoft.AspNetCore.App que contiene EF Core, SignalR, MVC, etc. si solo quiero crear una API extremadamente pequeña.

• Independientemente de lo que estén haciendo, ¿será posible crear un contenedor Docker con solo las dependencias más mínimas para ASP.NET Core para ejecutar una pequeña API?

Habrá un marco ASP.NET Core compartido integrado en el próximo tiempo de ejecución de .NET Core (3.0), lo que significa que ASP.NET Core se envía como parte de la instalación de .NET Core en un entorno.

sí

Además, hay un metapaquete llamado Microsoft.AspNetCore.App y Microsoft.AspNetCore.All, que son una colección de paquetes NuGet para aplicaciones ASP.NET Core

No. Hay un nuevo concepto llamado FrameworkReference y Microsoft.AspNetCore.App será uno de esos. Microsoft.AspNetCore.All no existirá en 3.0.

¿El marco ASP.NET Core compartido <el metapaquete Microsoft.AspNetCore.App que incluye cosas como EF Core?

No, no incluye EF.

Independientemente de lo que estén haciendo, ¿será posible crear un contenedor Docker con solo las dependencias más mínimas para ASP.NET Core para ejecutar una pequeña API?

Con el recorte de ensamblado y el vinculador, sí, no eliminando paquetes porque no habrá ninguno para ASP.NET Core.

@natemcmaster

No estamos recortando ensamblajes porque nos apetezca. Cada ensamblaje que eliminamos es un cambio importante y se suma al costo de actualizar de 2.xa 3.0.

El lugar correcto para hacer las correcciones sería dentro de la ventana de la versión principal v3, que es efectivamente el único momento en que podrían ocurrir cambios como este, es decir, al mismo tiempo que se eliminan otros paquetes.

Eliminar MVC de Microsoft.AspNetCore.App no ​​es algo que consideremos. Si bien reconocemos que no todos los usuarios hacen referencia a MVC en su aplicación.

Se llama "Microsoft.AspNetCore.App", que lógicamente se lee como "referencia a este paquete" si está creando una "Aplicación ASP.NET Core".

creemos que esta es una pieza central de la oferta de ASP.NET Core. Planeamos mantener esto en Microsoft.AspNetCore.App.

Esto se está acercando al meollo del problema en el que parece que los objetivos de ASP.NET Core se están alejando de fomentar un ecosistema de estilo de node.js esbelto y abierto. ¿Es la intención del equipo que todos combinen ASP.NET Core Apps como sinónimo de MVC Apps? Algunos de los puntos de venta de ASP.NET Core fueron "Pagar para jugar" y "capas" desacopladas, pero esto sugiere que una "Aplicación ASP.NET Core" está destinada para siempre a = Aplicación MVC.

Sería más claro para todos los involucrados si los paquetes fueran más explícitos donde:

• Microsoft.AspNetCore.App => Base para todas las aplicaciones ASP.NET Core
• Microsoft.AspNetCore.Mvc => Aplicación ASP.NET Core MVC

Pero si "Microsoft.AspNetCore.App" es intocable, ¿podríamos al menos tener un metapaquete oficial de "línea base" (o FrameworkReference) con solo las características del servidor central (es decir, sin bibliotecas obstinadas), algunos nombres potenciales:

• Microsoft.AspNetCore. [Base | Desnudo | Lite | Básico]

("Core" también habría sido apropiado, pero ya hay un uso excesivo del término).

Sin un metapaquete / nombre oficial, no será tan accesible como el "Microsoft.AspNetCore.App" recomendado actualmente, que es la base recomendada para todas las aplicaciones ASP.NET Core.

Las restricciones generan innovación en la que si MVC solo pudiera ejecutarse en el mismo campo de juego que todos los demás, tal vez todos podríamos tener acceso a una función que nos permite declarar de manera fácil y explícita qué productos (también conocidos como conjuntos de paquetes) necesitan las aplicaciones, por ejemplo, podría verse algo igual que:

• Microsoft.AspNetCore.Mvc + SignalR + EF

Donde todos pueden declarar fácilmente y solo instalar lo que necesitan y las herramientas detrás de escena podrían combinar los metapaquetes "Microsoft.AspNetCore.Mvc", "Microsoft.AspNetCore.SignalR" y "Microsoft.AspNetCore.EF". (O una solución superior alternativa para cumplir con la intención).

Su presencia en el marco compartido no le obliga a utilizarlo en su aplicación.

Suena como el fundamento de cada monolito jamás creado. "No tiene que usar todo lo que ofrecemos, solo está ahí para su conveniencia".

Aún puede usar alternativas, escribir su propio marco de vista,

No es tan acogedor como pensaría, por ejemplo, mientras estábamos desarrollando nuestra propia alternativa de "marco de vista" a MVC y Razor, nos encontramos con un comportamiento mágico en .NET Core donde la compilación fallaría al ejecutar el comando estándar para publicar un archivo. Proyecto .NET Core, es decir:

 dotnet publish -c Release

Que fallaría con:

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

Comportamiento sorprendente dado que estábamos desarrollando una alternativa a MVC que explícitamente no hacía referencia a MVC, Razor ni incluía páginas .cshtml ya que su propósito era crear aplicaciones sin usarlas.

Después de explorar varios subprocesos de GitHub probando diferentes soluciones, encontré que otros experimentaban el mismo problema en el que la solución terminó optando por no participar en las compilaciones de ruptura de la compilación MVC Razor con:

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

Lo que permitió publicar el proyecto. Durante el tiempo que probamos diferentes conmutadores para corregir la compilación rota, también descubrimos que podíamos reducir nuestra huella publicada en 150 .dlls en /refs/*.dll al optar por no participar en los metadatos que estaban inflando innecesariamente nuestra aplicación web .NET Core 2.0 al optar por no recibir los metadatos que necesita Razor con:

<PreserveCompilationContext>false</PreserveCompilationContext>

Así que, básicamente, me veo obligado a jugar whack-a-mole para descubrir qué interruptores necesitamos para decirle a las herramientas que no estamos usando MVC para evitar que rompa las compilaciones del proyecto y genere metadatos innecesarios que solo MVC / Razor Apps necesitan. Hubiera sido mucho más preferible comenzar con un paquete de metadatos "base" donde tales problemas no podrían ser posibles ya que las herramientas no podían asumir que todas las aplicaciones estaban usando MVC porque los bits de MVC no existirían.

Si bien es fácil decir que ASP.NET Core sigue siendo una plataforma acogedora que fomenta la experimentación, la creación y el uso de "marcos de vista" alternativos, agrupar los marcos web obstinados prescritos como MVC es lo más hostil que se puede hacer para desalentar la creación y uso de dichas alternativas. Tomarse un momento para echar un vistazo a la cantidad de alternativas populares emergentes es un buen indicador para ver qué tan atractiva es la plataforma para ellos.

Si se pretende que cada aplicación ASP.NET Core deba incluir MVC que cualquier otro "marco de vista" alternativo (incluido un solo archivo .cs drop-in de métodos ext) parecerá ser más "pesado "y engorroso que usar el MVC incluido, ya que todos deben incluirse con él + cualquier otra cosa que necesite el marco de visualización.

En resumen, sería preferible si "MVC" fuera opcional y no se incluyera en el paquete .App , pero si la decisión es irreversible, ¿podríamos al menos tener una base oficial de metapaquetes de línea base que no incluya ¿No lo incluyes?

Por favor, reconozca que tenemos cientos de miles de clientes, y solo un pequeño número de ellos viene a GitHub para compartir sus comentarios.

En mi opinión, la demanda de un paquete de inicio no hinchado está subrepresentada, anécdota: de todas las plantillas de proyecto C # / .NET que hemos creado para VS 2012, VS 2013, VS 2015, VS 2017 y .NET Core, consistentemente la plantilla más popular con mucho, siempre ha sido la plantilla "Vacía", que también era una crítica frecuente del ASP.NET clásico de que la plantilla ASP.NET vacía predeterminada de VS.NET no era lo suficientemente vacía. En ese momento se podía crear un marco ASP.NET .NET clásico "vacío" sin MVC, pero ahora en el marco ASP.NET Core más nuevo, más ligero y modular, MVC viene incluido en el paquete inicial mínimo recomendado.

También recopilamos información de visitas en persona, llamadas telefónicas, correos electrónicos, redes sociales, solicitudes de atención al cliente, blogs.

A la gente no le gusta la hinchazón, que a menudo se equipara con una complejidad inamovible, lo que probablemente se solicite es hacer que los proyectos sean lo más simples posible, que es lo que debería ser el foco y se puede hacer sin sobrecargar los proyectos predeterminados.

En mi experiencia, ser explícito es más fácil de razonar que los marcos inflados con comportamiento mágico. Si es explícito, puede interactuar con él, buscarlo, leer sobre él, eliminarlo, probar su ejecución sin usarlo (para ver si es la causa de los problemas) y es visible al comparar proyectos de diferentes configuraciones. Pero con el comportamiento mágico de las herramientas MVC que rompen las compilaciones de mi proyecto mvc / razor-less anterior, no tenía idea de qué parte de mi proyecto lo estaba activando, por qué se está ejecutando, cómo deshabilitarlo o cómo resolverlo. Todavía no estoy seguro de que mis proyectos que no usan MVC no se estén ralentizando porque MVC está incluido o que está generando una salida subóptima porque necesita adaptarse a MVC o Razor.

Telemetría de Visual Studio y más.

Va a ser difícil comparar la telemetría de la popularidad de un metapaquete de línea base que no existe; si lo hiciera, en mi opinión, tendría una popularidad más que suficiente para merecer su inclusión. Anteriormente, "Microsoft.AspNetCore.All" apuntaba al otro extremo del espectro e incluía el universo, pero no el inverso más útil de tener una línea de base útil mínima.

Es lógico que si no está creando una aplicación MVC y la opción de elegir una línea base sin ella es igual de accesible, ¿por qué no la elegiría en lugar de la opción de inicio más hinchada que contiene MVC?

@Bomret

Hubiera sido muy bueno tener un tiempo de ejecución web base / lib que los autores del marco pudieran construir en la parte superior como nodejs en lugar de agrupar cosas obstinadas con él.

Pero así es exactamente como funciona. Eres libre de redactar tu aplicación de la manera que quieras usarla. Si no desea utilizar MVC, simplemente no agregue el middleware. Sí, las plantillas son opcionales, pero puedes cambiar tu aplicación para hacer lo que quieras, usando lo que quieras.

Creo que está malinterpretando un poco el marco compartido aquí. Solo tiene que verlo como una especie de biblioteca estándar que se envía con .NET Core. Para hacer una referencia de nodo: Imagine que la versión actual de Express se incluye con Node. No _tiene_ que usarlo, pero ya está allí cuando quiera usarlo.

Y en cuanto a MVC, creo que no sabe exactamente qué incluye MVC en ASP.NET Core. Si no desea usar controladores y vistas de Razor, está bien, pero probablemente seguirá usando bastante funcionalidad MVC en su aplicación de todos modos.

Si no desea usar controladores y vistas de Razor, está bien, pero probablemente seguirá usando bastante funcionalidad MVC en su aplicación de todos modos.

¿Cómo qué?

Si no desea usar controladores y vistas de Razor, está bien, pero probablemente seguirá usando bastante funcionalidad MVC en su aplicación de todos modos.

Sí, por favor dígalo, parece un poco condescendiente, la mayoría de nosotros estamos involucrados en marcos alternativos construidos en middleware / kestrel, por lo que tenemos una idea decente de lo que estamos usando, los controladores y las vistas de Razor son un pequeño subconjunto de MVC, nosotros saber que. Los frameworks F #, Giraffe / Saturn & Zebra, funcionan mejor que MVC con un mejor enrutamiento y un modelo de procesamiento simplificado. En el renderizado, Zebra x2 más rápido que MVC en TechEmpower, es por eso que preferimos mantenerlo fuera de forma predeterminada. Si el ensamblaje-recorte / enlazador es capaz de reducir la huella más tarde, entonces eso es al menos algo, pero sería ideal si no se incluyera de forma predeterminada para permitir un campo de juego más uniforme para otros marcos, obtenga el máximo atractivo para la plataforma principal de asp.net.

@mythz desde una perspectiva organizacional, tienes razón, aquí hay algunas divisiones lógicas. Sin embargo, cualquier subdivisión viene con una complejidad y una sobrecarga de ingeniería significativamente añadidas que le quitan tiempo a la mejora de las características del producto. Cuando esperamos que una mayoría significativa de clientes aproveche los componentes de MVC, no vale la pena el costo de dividirlos. Las desventajas para los desarrolladores que no los usan son insignificantes, algunos MB adicionales en el directorio de instalación y ningún impacto en el tiempo de ejecución a menos que los cargue.

Solo puedo señalar @mythz para ilustrar el punto. Cuanto más acopladas están las cosas, más se enredan. Me refiero a Wat !? ¿MVC influye en la construcción de una aplicación Asp incluso si no hace referencia a ella en ningún lado?

@dar un toque
Como ya han escrito los demás: no lo es. Es un paquete de cosas que no tiene nada que ver con un tiempo de ejecución base. Imagine que el marco expreso se habría incluido con el nodo de forma predeterminada, ¿cree que el ecosistema se habría vuelto tan vibrante y diverso?

Tampoco entiendo en absoluto cómo eliminar MVC, SingalR, etc. de la instalación base y proporcionarlos como un solo paquete NuGet se puede etiquetar como "complejidad adicional". Los desarrolladores instalan paquetes adicionales en la mayoría de los casos de todos modos. Y si proporcionarlos como paquetes adicionales aumentaría "significativamente" los tiempos de restauración, de todos modos son demasiado gordos.

@Tratcher

Sin embargo, cualquier subdivisión

La subdivisión a la que esto se refiere es el desacoplamiento de MVC, por lo que las aplicaciones ASP.NET Core podrían tener una línea de base útil mínima sin marcos de desarrollo obstinados que prescriban lo que deben usar para desarrollar aplicaciones ASP.NET Core.

viene con una complejidad significativamente mayor y una sobrecarga de ingeniería que le quita tiempo a la mejora de las características del producto.

Para aclarar cómo se lee esto: requiere demasiada sobrecarga de ingeniería para eliminar la sobrecarga innecesaria de cada aplicación ASP.NET Core que no usa MVC porque si MVC tuviera que funcionar como cualquier otro marco alternativo, eso agregaría significativamente complejidad "a MVC".

Si MVC requiere una complejidad significativa para trabajar dentro de las mismas opciones de extensibilidad en las que tiene que funcionar cualquier otro marco alternativo, eso es indicativo de un problema con MVC y cualquier característica agregada para que funcione de manera más fluida podría agregarse en beneficio de todos. Al igual que diseccionar un monolito, la complejidad de las herramientas y el tiempo de ejecución sería más ágil y menos complejo con la complejidad adicional trasladada a donde pertenece en MVC y su integración / herramientas.

En cambio, terminamos con la situación en la que MVC está arraigado en las herramientas predeterminadas que pueden romper los proyectos de publicación e inflar los resultados de los proyectos que no lo usan. Dado que no funciona como todo lo demás, no hay forma de decirle que está usando MVC o cualquier forma de decirle que no está usando MVC, siempre se asume.

Cuando esperamos que una mayoría significativa de clientes aproveche los componentes MVC

Bueno, eso es de esperar, en detrimento de todas las demás alternativas, es el marco prescrito incluido en la instalación mínima recomendada predeterminada, como Apple les da a todos una canción U2 gratis, les guste o no.

Las desventajas para los desarrolladores que no los usan son insignificantes

¿Se beneficiarían los desarrolladores de un ecosistema más saludable con más variedad, opciones e innovación?

¿Se benefician los desarrolladores de la confusión añadida y la definición borrosa de lo que es una "Aplicación ASP.NET Core"? "Solía ​​ser como node.js para .NET, pero ahora es más un marco de trabajo de un solo proveedor obstinado en el que, esencialmente, todas las aplicaciones comienzan con un montón de cosas obstinadas que prescriben cómo debe crear aplicaciones web. La aplicación está preinstalada con express y sus dependencias de forma predeterminada; se espera que la use "

¿Se benefician los desarrolladores de la carcasa especial de MVC? No está instalado ni actualizado como cualquier otra cosa y se basa en herramientas ocultas y comportamiento mágico que debe buscar para saber que existe y deshabilitarlo. Una carcasa especial como esta es lo que agrega complejidad accidental, al razonar sobre su proyecto, debe mantener un conjunto diferente de reglas sobre cómo funciona MVC y cómo funciona todo lo demás.

Si fuera explícito, mejoraría la legibilidad y se podría decir por la configuración del proyecto que es una aplicación MVC, por ejemplo:

• Microsoft.AspNetCore.Mvc

Lo que indica que es una aplicación MVC y para instalar todas las dependencias y configurar automáticamente todas las herramientas a medida que necesita MVC, idealmente utilizando el mismo modelo extensible abierto al que todos los demás tienen acceso.

Al mantenerlo en el proyecto predeterminado "Microsoft.AspNetCore.App", lo vinculará para siempre con cada aplicación ASP.NET Core y hará que sea desventajoso para algo mejor. ASP.NET Web Pages fue otro marco de vista de Razor agregado a ASP.NET hace años que se instaló y también tenía su comportamiento mágico invasivo habilitado de forma predeterminada. Viene con su propio Web Matrix IDE que ya no es compatible ni está disponible para descargar, por lo que lo que nos queda es un caso en el que la complejidad de una tecnología muerta está incrustada para siempre en ASP.NET clásico y causa activamente problemas para otros marcos web activos. tratando de usar Razor .cshtml páginas que siempre deben llevar el equipaje a continuación para evitar explícitamente que las páginas web rompan sus marcos de vista con:

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

Repetir las solicitudes de funciones en orden de preferencia sería:

1. Cambie "Microsoft.AspNetCore.App" para que sea la línea de base útil mínima para todas las aplicaciones ASP.NET Core (es decir, sin MVC).
2. Mantenga un metapaquete como "Microsoft.AspNetCore.Base" que todos los que no usen MVC puedan usar como base mínima útil.

Si no se va a considerar ninguno de estos, ¿podemos al menos tener una marca para todo el proyecto como mvc:enabled = false que todas las herramientas de MVC puedan verificar para deshabilitarlas y evitar que se ejecuten?

@mythz me estás poniendo palabras en la boca. La complejidad adicional no es para MVC, es para construir infraestructura, empaque, instaladores, etc., necesarios para crear y enviar otra capa de componentes sin importar en qué consiste esa capa.

Si ninguno de estos se va a considerar, ¿podemos al menos tener un indicador de todo el proyecto como mvc: enabled = false que todas las herramientas de MVC podrían verificar para deshabilitar y evitar que se ejecuten?

¿Puede ser más específico sobre las funciones de herramientas que le gustaría que se deshabilitaran? Eso podría valer un tema aparte.

@Tratcher

La complejidad adicional no es para MVC, es para construir infraestructura, empaque, instaladores, etc., necesarios para crear y enviar otra capa de componentes sin importar en qué consiste esa capa.

es decir, la complejidad adicional de lo que se requeriría para que MVC funcione.

¿Puede ser más específico sobre las funciones de herramientas que le gustaría que se deshabilitaran? Eso podría valer un tema aparte.

Los 2 problemas que encontré fueron la necesidad de configurar manualmente /p:MvcRazorCompileOnPublish=false que impedía que mi proyecto (sin páginas .cshtml) se publicara. La otra bandera que debe deshabilitarse es:

<PreserveCompilationContext>false</PreserveCompilationContext>

Como con la mayoría de los comportamientos mágicos, supongo que hay más, pero solo los descubro cuando me encuentro con ellos.

Básicamente, una bandera para especificar que MVC no se usa y para deshabilitar todas las herramientas o concesiones habilitadas de forma predeterminada que se agregaron debido a MVC.

@mythz sigue adelante y presenta ese problema.

De hecho, puede crear un marco compartido similar para la pila de servicios si los dlls adicionales de MVC y SignalR son una preocupación para sus usuarios.

@davidfowl Eso en realidad suena bastante impresionante, pude ver algunos casos de uso diferentes para los marcos proporcionados por la comunidad. ¿Hay alguna documentación sobre eso?

Como puede imaginar, no es algo para lo que construyamos soporte de primera clase, ya que la cantidad de personas que hacen esto es pequeña. Dicho esto, puede ver cómo construimos el nuestro e imitar ese comportamiento.

@davidfowl El paquete base mínimo sería útil para todas las aplicaciones que no sean MVC; por ejemplo, habrá muchas otras aplicaciones ligeras y microservicios que querrán omitir todos los marcos y escribir directamente en la respuesta ellos mismos. En mi opinión, esta opción debería estar disponible en la caja, preferiríamos no comenzar desde una base no oficial compuesta por versiones de paquetes sobre las que no tenemos control. Idealmente, todo sería aditivo del paquete base en lugar de partir de una tangente diferente mantenida externamente. Pero tal vez esta sea un área en la que la comunidad externa puede unirse para mantener un subconjunto base "AspNetCore" que sea útil para todas las aplicaciones y marcos que no sean MVC.

Dicho esto, ¿dónde deberíamos buscar para crear un marco personalizado? Tal vez sea tan fácil como comenzar con una copia de lo que se usó para crear "Microsoft.AspNetCore.App" y eliminar todas las bibliotecas no esenciales para volver a un subconjunto mínimo útil.

@mythz, ¿por qué necesita un marco? Puede usar Kestrel directamente en el servidor. Esto solo para decir que tal vez su versión de la luz no sea la idea de luz o núcleo de otra persona. Actualmente tenemos una opinión y sería increíble si la comunidad pudiera dar un paso aquí y crear plantillas y un marco compartido alternativo que fuera lo suficientemente mínimo. Somos OSS, todo lo necesario para hacer algo personalizado está ahí y somos muy receptivos y con gusto lo ayudaremos.

@natemcmaster Puede ayudar con detalles sobre cómo crear un marco compartido personalizado.

@davidfowl sugirió hacer uno personalizado, solo después de poder comenzar desde una base útil mínima sin marcos de opiniones obstinados. No queremos hacer referencia a varios paquetes individualmente por la misma razón por la que la recomendación es que todas las aplicaciones ASP.NET Core hagan referencia a "Microsoft.AspNetCore.App"; es más accesible poder hacer referencia a un solo paquete.

Esto solo para decir que tal vez su versión de la luz no sea la idea de luz o núcleo de otra persona.

Todo el mundo parece ser bastante unánime aquí en que MVC no pertenece al paquete base. El único otro "producto" que parece estar incluido es SignalR, que me imagino que tendría menos uso que MVC y menos razones para su inclusión. No estoy muy familiarizado con lo que hay en cada paquete, pero todo lo demás parece ser genéricamente útil y una parte propicia de la "plataforma" ASP.NET Core.

De acuerdo, permítanme lanzar una sugerencia para tratar de ser constructivo aquí. No vamos a cambiar Microsoft.AspNetCore.App, creemos que es algo que la mayoría de los usuarios necesitarán y usarán. Introduzcamos otra capa que es este marco compartido "central" (hicimos algo como esto originalmente con https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497). Ese es el marco compartido en el que basaría estos otros marcos (como Nancy y ServiceStack).

Seguiremos enviando nuestras plantillas predeterminadas con Microsoft.AspNetCore.App igual que ahora, pero los autores de marcos como usted pueden tener otras plantillas que usen el marco compartido base.

PD: Este hilo no comienza remotamente a representar ningún tipo de mayoría de nuestros clientes, por lo que no sacaría conclusiones solo de aquí. Recibimos comentarios de muchos lugares y github tiene nuestra guía más vocal y apasionada.

Sí, creo que está más cerca de contener muchos de los elementos esenciales para configurar una aplicación y ponerla en funcionamiento. De los departamentos de Microsoft.AspNetCore.App también estamos usando:

• 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

Así que cosas como las abstracciones HTTP, Hosting, Logging y Configuration (útiles para la mayoría de las aplicaciones HTTP) también serían buenas para ser incluidas y cualquier otra cosa que cualquiera considere apropiada. Mi única preferencia es no tener MVC / SignalR incluido.

y ahora se pone interesante. como ya dijo David: la gente tiene diferentes
ideas de lo que significa "núcleo". Desde mi punto de vista no creo que DependencyInjection
debería estar adentro. / encogiéndose de hombros

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

Sí, creo que está más cerca de contener muchos de los elementos esenciales para
configurar una aplicación y ponerla en funcionamiento. De los deps en
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App también somos
utilizando:

• 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

Así que cosas como abstracciones de HTTP, Hosting, Logging y Configuration
(útil para la mayoría de las aplicaciones HTTP) también sería bueno que se incluyera y cualquier cosa
cualquier otra cosa que alguien considere apropiado. Mi única preferencia es no tener
MVC / SignalR incluido.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz La mayoría de ellos se incluyen de forma transitiva.

@forki 😆 Bienvenido a nuestro mundo.

No vamos a cambiar Microsoft.AspNetCore.App, creemos que es algo que la mayoría de los usuarios necesitarán y usarán.

Últimas palabras famosas. Esta es la justificación de toda mala decisión: "Creemos que ELLOS lo necesitan".

¿Sabes lo que pienso? Microsoft debería comenzar a tratar a su base de desarrolladores como ingenieros inteligentes independientes y no como desarrolladores de ovejas, y sí, ustedes tienen muchos desarrolladores de ovejas, que seguirán y usarán todo lo que les arrojen, pero son los otros desarrolladores más vocales los que harán un vibrante comunidad y cree nuevas empresas emergentes en la pila .NET.

A veces es bueno escuchar a los usuarios avanzados.

Independientemente, no vamos a cambiar Microsoft.AspNetCore.App. Ofrecí un compromiso que creo que satisface los requisitos aquí.

@forki, si está utilizando aspnet core, se enfrenta a DI de todos modos, es mejor que incluya métodos de conveniencia de forma predeterminada (Obtener servicio, GetRequiredServicey los me gusta están en ese paquete). Y oye, F # ni siquiera puede crearlos por sí solo debido a la restricción T:> U que falta https://github.com/fsharp/fslang-suggestions/issues/255 así que ¯_ (ツ) _ / ¯

Me gustaría que se mencionara ese marco compartido base @davidfowl ... Creo que @mythz y @dustinmorris estarían bien con ese enfoque. Esto también es oportuno para Saturno @ Krzysztof-Cieslak

te enfrentas a DI de todos modos

Lo sé y tuvimos esa discusión varias veces. Es solo que prefiero no
;-) Pero es lo que es...

Soy el viernes, 9. de noviembre de 2018, 10:57 hat Nino Floris [email protected]
geschrieben:

@forki https://github.com/forki si está usando aspnet core, está
confrontado con DI de todos modos, es mejor que incluya métodos de conveniencia
predeterminado (Get service, GetRequiredService y los me gusta están en ese
paquete). Y oye, F # ni siquiera puede crearlos por sí solo debido a la falta
T:> U restricción fsharp / fslang-examples # 255
https://github.com/fsharp/fslang-suggestions/issues/255 entonces ¯_ (ツ) _ / ¯

Me gustaría tener ese marco compartido base @davidfowl
https://github.com/davidfowl mencionado ... Creo que @mythz
https://github.com/mythz y @dustinmorris
https://github.com/dustinmorris ambos estarían bien con este enfoque.
Esto también es oportuno para Saturno @ Krzysztof-Cieslak
https://github.com/Krzysztof-Cieslak

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

Se actualizó la publicación original para incluir:

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

Estos se están retirando del marco compartido y se enviarán como paquetes NuGet. Estos ensamblados dependen de las API de IdentityModel que aún no se ajustan a las pautas del marco compartido. Hemos comenzado a trabajar con el equipo de IdentityModel y consideramos volver a colocarlos en el marco compartido en el futuro. cref https://github.com/aspnet/AspNetCore/pull/6035

Actualice la publicación original para incluir Microsoft.AspNet.WebApi.Client. Consulte https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732.

A menudo me confundo lo suficiente, ya que es lo que necesito incluir.

Hablando de Visual Studio: ¿se supone que debo abrir el nodo Microsoft.AspNetCore.App y hacer una referencia cruzada de todo lo que hay debajo con lo que pueda haber instalado individualmente?

Estoy limpiando un poco la casa y veo que tengo estos paquetes. Entonces, ¿cuáles son redundantes?

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

Me sorprendió bastante ver que incluso las herramientas SpaServices y EntityFramework están incluidas actualmente (de lo que no me había dado cuenta antes, y es genial), pero también tengo algunas referencias antiguas 2.2.1 que no pueden ayudar en nada.

El punto es: ¿se puede hacer un mejor trabajo de coordinación con el equipo de Visual Studio para garantizar que el IDE sea un poco más inteligente al comprender estos mega paquetes y decirme que es seguro eliminar algo? Y luego, en la v3, decirme que debo agregarlo. volver de nuevo ;-)

@simeyla gracias por los comentarios. Lo que estás diciendo está relacionado con el tema, pero no es exactamente de lo que trata este hilo. Las herramientas para optimizar las referencias de paquetes serían una nueva característica de Visual Studio. Esta característica podría ser útil en general, no solo para este escenario, por lo que sugiero enviar estos comentarios a Visual Studio directamente. En VS, use "Ayuda> Enviar comentarios ...". Si comparte el enlace después de crear la publicación, puedo reenviarlo internamente a nuestros equipos de pares que trabajan en VS.

En 3.0, eliminaremos el metapaquete Microsoft.AspNetCore.App por completo y realizaremos muchos ajustes en los paquetes que enviamos. Comenzamos a documentar cómo actualizar de 2.xa 3.0 y continuaremos actualizando este documento a medida que finalicemos la lista de ensamblajes que se envían en 3.0.

Pasando al hito de 'Discusiones' porque este elemento no rastrea ningún trabajo, sino que lo actualizaremos a medida que los detalles del cambio de implementación.

Se agregó Microsoft.Extensions.DependencyModel a la lista. Cambiado como parte de https://github.com/aspnet/AspNetCore/pull/10271

Pregunta aquí @natemcmaster @DamianEdwards , se menciona que las plantillas tienen todo lo que se necesita para construir localmente. Con este pensamiento y la eliminación de las bibliotecas de autenticación, ¿significa eso que ninguna plantilla de autenticación no se construirá sin conexión en 3.0? Entiendo que ninguna biblioteca de autenticación funcionará sin conexión, pero si no tengo caché nuget, teóricamente podría tener un error de compilación después de una nueva plantilla de autenticación si estuviera sin conexión. Parece una mala experiencia.

Sí, ese es uno de los resultados de este cambio. A partir de la Vista previa 6 (próximamente), dotnet new mvc , dotnet new razor , dotnet new web y otros no tienen ninguna PackageReferences, por lo que no deberían verse afectados, pero especificando opciones adicionales , como --auth individual puede resultar en una PackageReference que requiere la descarga de un paquete.

Estamos haciendo un intercambio intencional aquí. Aunque las plantillas que tienen PackageReference no se restaurarán sin conexión en una máquina limpia, también estamos evitando muchos de los problemas que surgen al intentar crear un caché NuGet sin conexión precargado (para empezar, consulte https://github.com/dotnet/ dotnet-docker / issues / 237, https://github.com/NuGet/Home/issues/6309 y http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html).

@natemcmaster lo entiendo totalmente y entiendo el razonamiento, solo necesita estar bien documentado o habrá un montón de problemas abiertos en la versión 3.0 inicial donde la gente dice que dotnet new webapp --auth Individual no se construye.

¿Alguien puede enseñarme por qué Microsoft.AspNetCore.Authentication.JwtBearer se compila con una dependencia de .netcoreapp3.0? ¿No puede estar en .netstandard2.x? Quiero usarlo en una biblioteca de clases y me gusta mantener todas mis bibliotecas de clases .netstandard

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

@Pilchie Creo que vale la pena mencionar este problema en la documentación de ASP.NET Core 3.0. Como se mencionó anteriormente, los usuarios que actualicen a 3.0 deberán agregar <PackageReference> para compensar la API que se mudó fuera de Microsoft.AspNetCore.App.

@Bomret Casi todas las aplicaciones de clientes del mundo real que hemos inspeccionado utilizan MVC de alguna manera. Hay muchos beneficios de mantenerlo en el marco compartido, y no veo ninguna razón clara por la que debamos eliminarlo.

Ciertamente no lo hacemos, y conozco a bastantes personas en otras tiendas que están usando .net core para aplicaciones sin servidor, apis web, etc., donde no tenemos absolutamente ninguna necesidad de MVC.

Cierre, ya que enviamos 3.0 hoy.

Necesitamos mover esta lista a los documentos.

@davidfowl se ha agregado: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete-package-reference

@pranavkm esa lista es en realidad exactamente lo contrario: cosas que ya no son paquetes pero que probablemente todavía están en el marco compartido.

Se trata de cosas que se eliminaron del marco compartido, pero que probablemente ahora solo estén disponibles como paquetes.

@scottaddie, esta es la lista a la que tendremos que hacer referencia en el documento de creación de la biblioteca ASP.NET Core.

@DamianEdwards esto: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add -package-reference-for-eliminado -¿Ensambles?

Ese es :)

Llego tarde a la fiesta, pero esto no parece que me ayude a lograr el objetivo de simplificar mi desarrollo.

a) Parece que ahora si hay una mejora en un componente AspNetCore (digamos, SignalR), entonces tenemos que esperar a que se lance un nuevo "dotnet pack" para Microsoft.AspNetCore.App para usarlo, llevándose todo con él. más en ese paquete?
b) Ya no se pueden crear clases de utilidad para AspNetCore en bibliotecas de clases netstandard (por ejemplo, middleware Auth). Ahora las bibliotecas de clases deben ser netcoreapp3.0 para albergar estas cosas. Esto significa dividir nuestras bibliotecas de clases de utilidad en implementaciones netstandard / netcore.
EDITAR: c) ¿Cómo defino realmente qué versión del paquete estoy usando si hago <Project Sdk="Microsoft.NET.Sdk.Web"> ? Obviamente, queremos tener compilaciones reproducibles en diferentes ramas después de actualizar dotnet.

a) Parece que ahora si hay una mejora en un componente AspNetCore (digamos, SignalR), entonces tenemos que esperar a que se lance un nuevo "dotnet pack" para Microsoft.AspNetCore.App para usarlo, llevándose todo con él. más en ese paquete?

SignalR se envía en el mismo horario que el resto de AspNetCore, por lo que no hay cambios de programación aquí.

SignalR se envía en el mismo horario que el resto de AspNetCore, por lo que no hay cambios de programación aquí.

¿Entonces este es solo un mal ejemplo? ¿Se puede decir lo mismo de todos los demás paquetes de NuGet que se eliminaron?

SignalR se envía en el mismo horario que el resto de AspNetCore, por lo que no hay cambios de programación aquí.

¿Entonces este es solo un mal ejemplo? ¿Se puede decir lo mismo de todos los demás paquetes de NuGet que se eliminaron?

Creo que sí. Todos los componentes de .NET Core y ASP.NET Core usan el mismo programa de envío. Si algo no lo hiciera, entonces tendría que enviarse en su propio paquete.

Creo que sí. Todos los componentes de .NET Core y ASP.NET Core usan el mismo programa de envío. Si algo no lo hiciera, entonces tendría que enviarse en su propio paquete.

Confiaré en tu palabra. No tengo ningún contraejemplo específico. Simplemente no se "sentía" de esa manera al actualizar los paquetes AspNetCore NuGet en el pasado.