Aspnetcore: Los nuevos paquetes ASP.NET Core 2.0 ya no se pueden usar en .NET Desktop

Este sería un cambio extremadamente extraño y malo de hacer. He escrito una gran cantidad de código central asp.net solo para netfx y no quiero ver que esa inversión se desperdicie. En términos más generales, los clientes de .NET necesitarán poder interoperar entre ASP.NET Core y el código de escritorio en el futuro previsible: imagine aplicaciones web que usan Active Directory, o la automatización de Office COM, o que hacen miniaturas usando algún System.Drawing basado biblioteca o compartir código con una aplicación WPF. Es trivial pensar en muchos escenarios como este y espero que simplemente no hayamos entendido lo que está pasando.

Actualmente estamos en AspNetCore 1.1.1, es decir, la rama de soporte "actual". Si no podemos pasar a 2.0 debido a las dependencias de Net4XX, ¿significa eso que no seremos compatibles cuando caiga 2.0+3 meses?

Usamos una combinación de WPF y ASP.NET Core y apuntamos en ambos casos al marco completo.
Entonces, ¿supongo que no habrá 2.0 en el futuro previsible?

¿Pero el marco completo 4.6.1 admitirá netstandard 2? ¿Me estoy perdiendo de algo? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

¿No es esto que las herramientas actuales no están actualizadas?

estaría totalmente bien y se espera que asp.net core se ejecute en el estándar de red 2. Lo alarmante es la perspectiva de pasar a net core app2.0, lo que implicaría que ya no se podría usar el código heredado dentro de asp.net sitios web principales

oh, eso es un problema... Aunque supongo que se mitiga un poco con las correcciones de compatibilidad en netcore2 que le permiten hacer referencia a ensamblajes antiguos, pero aun así, significa trasladar todos los proyectos al nuevo sistema de proyectos y mucho otro trabajo...

Sería bueno escuchar a los equipos razonar sobre esto.

oh, ¿entonces crees que los proyectos netcoreapp2.0 simplemente podrán hacer referencia a netfx libs gracias a la unificación de tipos? Eso explicaría mucho. mi pregunta, si es así, es cuánto código funcionará realmente cuando se ejecute en Windows pero en el CLR principal.

Guau. Esto sería un bloqueo total para nosotros y básicamente nos aseguraría de que nunca podamos actualizar estos paquetes en un futuro lejano. Incluso es posible que necesitemos migrar nuestro proyecto MvcCore de nuevo a Mvc, porque actualmente no podemos evitar apuntar a net462+.

Tengo mucha curiosidad por esto también. Realmente espero que esto sea un paso intermedio (y de corta duración) o una gran falta de comunicación. Sin duda, también sería un obstáculo para la adopción de la mayoría de nuestras aplicaciones.

Mover todo a Core es demasiado para una gran base de código existente (sin detener a los desarrolladores para que lo hagan), moviéndose a las nuevas Clases ASP.NET (HttpRequest, controladores, etc.) como un paso intermedio que debe ocurrir para nuestros proyectos principales.

¿Quizás @DamianEdwards o @davidfowl pueden comentar sobre los planes aquí? También tengo problemas para encontrar cualquier razonamiento adicional.

Puedo ver por qué este es inicialmente un momento WTF aterrador. Me explico porque es menos raro de lo que parece.

• Dijiste que los clientes de .NET necesitarán interoperar. Totalmente de acuerdo.
  
  
  
  • Podemos compartir bibliotecas netstandard entre ASP.NET Core 2.0 y TODAS PARTES.
  
  
  • Incluso podemos hacer referencia a muchos ensamblajes net461+ de ASP.NET Core 2.0 debido a typeforwarding y netstandard20
  
  
• Usted dijo que WebApps puede necesitar usar:
  
  
  
  • AD – Totalmente, esta es una brecha SI desea llamar a LDAP directamente. Ciertamente puede autenticarse contra Windows Auth AHORA. Planeamos tener específicamente el espacio de nombres DirectoryServices para Core 2.0 alrededor del período de verano.
  
  
  • Dibujo – Totalmente, esta es una brecha. Planeamos tener esto para Core 2.0 alrededor del período de verano. Hasta este momento, estas opciones estándar de red también existen ImageSharp, ImageResizer, opciones Mono, etc.
  
  
  • Automatización COM: esto nunca ha sido posible con Core 2.0, pero ciertamente puede PInvoke si quiere lastimarse. También puede usar WebAPI local en un proceso net461+ si realmente quiere lastimarse.
  
  
  • Compartir código con aplicaciones WFP: SÍ. Totalmente posible con netstandard2.0.
  
  
• Este es un cambio extraño de hacer.
  
  
  
  • Se siente así pero…
  
  

Piensa en ello de esta manera. WPF no es netstandard2.0, sabe que está en net461+ y está bien. Está optimizado, pero puede hacer referencia a librerías netstandard. ASP.NET Core 2.0 está optimizado para Core 2.0 pero puede hacer referencia a bibliotecas compartidas. Xamarin es lo mismo.

.NET Core está uno al lado del otro y se está moviendo rápido. Es MUCHO más rápido de lo que .NET (Full) Framework puede mover, lo cual es bueno. Al construir ASP.NET Core 2.0 sobre .NET Core 2.0 (que, recuerde, es un SUPERCONJUNTO de .NET Standard), eso significa que las cosas se pueden construir más rápido que NetFx o incluso Netstandard.

NetCore > Net Standard > NetFx cuando se trata de innovación y velocidad de desarrollo.

El punto es, si está haciendo un trabajo nuevo, netstandard20. Si tiene bibliotecas net461+ más antiguas, se puede hacer referencia a la MAYORÍA de ellas en ASP.NET Core 2.0.

ASP.NET Core 1.1, que se ejecuta en .NET Framework, será totalmente compatible durante un año después de que lancemos 2.0. Esa carga de trabajo es totalmente compatible hasta al menos julio de 2018.

Los grandes vacíos restantes que faltan en .NET Core 2 son System.DirectoryServices y System.Drawing. Estamos trabajando para tener un paquete de compatibilidad con Windows que habilitaría ambos en .NET Core en Windows este verano.

Lo que necesitamos de todos ustedes es una lista clara/comprensión de POR QUÉ creen que necesitan ASP.NET Core 2.0 para ejecutarse en net461+.

Pensé que .NET Standard 2.0 tenía que ver con la compatibilidad y la interoperabilidad, lo que cierra la brecha entre .NET Core y .NET fx que todos están esperando; esto parece acabar con eso.

Por alguna razón, habrá muchos clientes que tendrán dependencias que requieren .NET 4.x, ya sean dependencias externas personalizadas, componentes comerciales, dependencias de bibliotecas heredadas, etc.

¿La intención es que los Clientes no puedan crear aplicaciones ASP.NET Core 2.0 que se ejecuten en Desktop CLR para que puedan hacer referencia a sus dependencias .NET 4.x existentes?

@shanselman Gracias por la respuesta, hay muchos buenos ejemplos allí.

Un seguimiento sobre las bibliotecas:
¿Se mantendrán todas las bibliotecas de abstracción como compiladas de forma cruzada? Por ejemplo, si estoy usando HttpRequest , mantener compilaciones 1.x y 2.x en la versión de ASP.NET Core que está usando (que ahora se asigna limpiamente a un TFM al menos) sería algo Preferiría evitar... así que espero que las abstracciones permanezcan en netstandard . ¿Ese es el plan general?

Ya mantenemos múltiples variantes para cosas que dependen de ASP.NET/MVC porque System.Web 's HttpRequest es totalmente diferente, por lo que es otra biblioteca completamente diferente (por ejemplo MiniProfiler vs. . MiniProfiler.AspNetCore ). Solo quiero asegurarme de que tengamos en cuenta la cantidad de variantes que estamos cargando para mantener para cualquier autor de lib si sus dependencias se mueven fuera de netstandard ... y espero evitar ese dolor de cabeza por completo.

Estoy muy feliz de que esto no parezca tan importante como parece, gracias por la aclaración detallada.

Tengo dos preguntas/inquietudes:

• Parece que consumir bibliotecas de .NET Framework desde ASP.NET Core debería tener una fricción mínima. ¡Eso es genial! ¿Qué hay del revés? Probablemente existan bibliotecas y aplicaciones de .NET Framework o netstandard que incrustan partes o componentes de Mvc y otras bibliotecas ASP.NET Core compatibles (lo sé porque tengo un par). Esos se romperán, ¿correcto? ¿Hay algún consejo sobre cómo solucionar ese escenario? Si las bibliotecas netstandard ya no pueden consumir bibliotecas de ASP.NET Core, eso parece ser un gran problema para los escenarios de ASP.NET Core integrados.

• Desde una perspectiva no técnica, parece que esto causará mucha confusión. Fuera de las personas que están activas en GitHub, siguen en Twitter, etc., ya hay mucha confusión en torno a las diferentes plataformas, etc. Puedo ver desarrolladores que solo han estado siguiendo parcialmente o que recién ahora se están levantando. para acelerar la frustración cuando van a usar ASP.NET Core (quizás siguiendo un tutorial desactualizado) y no pueden hacer que funcione en sus plataformas .NET Framework. No estoy seguro de qué se puede hacer al respecto, si es que se puede hacer algo.

Incluso podemos hacer referencia a muchos ensamblajes net461+ de ASP.NET Core 2.0 debido a typeforwarding y netstandard20

Desafortunadamente, esto no significa que una biblioteca compilada y diseñada para el marco completo funcionará en .NET Core (¡el riesgo es alto de que las cosas exploten en el tiempo de ejecución!).

Muchas de las API "antiguas" que se reintrodujeron en .NET Core 2.0 son apéndices que nunca funcionarán (funcionalmente). Sin mencionar que todavía faltan muchas API, e incluso áreas enteras que se excluyeron deliberadamente de .NET Core (Modelo de identidad, servidor WCF, comunicación remota, compatibilidad completa con AppDomain, etc.)

Intentar convencer a las personas de que pueden migrar "de forma segura" sus aplicaciones de escritorio ASP.NET Core 1.0 con .NET a ASP.NET Core 2.0 con .NET Core es, en mi humilde opinión, una mentira.

.NET Core está uno al lado del otro y se está moviendo rápido. Es MUCHO más rápido de lo que .NET (Full) Framework puede mover, lo cual es bueno. Al construir ASP.NET Core 2.0 sobre .NET Core 2.0 (que, recuerde, es un SUPERCONJUNTO de .NET Standard), eso significa que las cosas se pueden construir más rápido que NetFx o incluso Netstandard.

No creo que eso sea lo que (la mayoría) de la gente está buscando. Mucha gente no necesita bibliotecas que se mueven rápidamente, necesitan material estable que pueda integrarse con gracia en su material anterior sin correr el riesgo de romperlo todo.

@daveaglick

• Correcto en el sentido de que no hay una capacidad implícita para hacer referencia a netcoreapp2.0 desde net461 o incluso netstandard2.0 . El puente va en una dirección. Siempre puede evitarlo especificando TFM para el respaldo del paquete, pero obviamente es una vía de escape, no un escenario admitido (aunque será suficiente para desbloquear a muchas personas). Es una cantidad de trabajo no trivial para nosotros admitir subsistemas de ASP.NET Core fuera de la pila más grande (que es lo que implica apuntar a netstandard ).
• El potencial de confusión va en ambos sentidos. Por ejemplo, hemos recibido muchos comentarios de que el hecho de que "ASP.NET Core" pueda ejecutarse en .NET Framework (que no es .NET Core) es confuso. Este cambio hace que ASP.NET Core sea parte de la pila de .NET Core, lo que significa que si usa ASP.NET Core, está usando .NET Core.

@shanselman Por cierto, no dijiste por qué la compilación cruzada no era una opción. Los componentes de ASP.NET Core que podrían beneficiarse de netcoreapp2.0 solo las API podrían tener net46 / netstandard1.x / netstandard2.0 y netcoreapp2.0 TFM y haga que las nuevas cosas geniales/rápidas sean solo .NET Core.

@NickCraver actualmente el plan no incluye dejar los paquetes *.Abstractions dirigidos a netstandard . La separación simplemente no es tan limpia como en todos los ámbitos. Sin embargo, a los efectos de que alguien intente una migración como la que está sugiriendo, el uso de la reserva de destino del paquete debería llevarlo allí de todos modos (pero podría estar malinterpretándolo).

También su punto acerca de que la división TFM limpia es correcta, y es una ventaja de este plan, ya que un solo paquete ahora puede apuntar a ASP.NET Core 1.x y 2.0+ simultáneamente usando el TFM como pivote.

He estado jugando con la idea de "aplicaciones mixtas". Por ejemplo, una aplicación WPF que expone una API web o un servidor que ofrece una API REST y puntos finales de WCF (esto podría ser por compatibilidad con clientes anteriores). Estos escenarios se vuelven imposibles con este cambio y hace que ASP.NET Core solo sea adecuado para nuevas aplicaciones en lugar de ser "solo una biblioteca".

@PinpointTownes como dijo @shanselman , estamos muy interesados ​​en los requisitos específicos y los bloqueadores que tienen los clientes con respecto a la necesidad de continuar apuntando a .NET Framework directamente. Nuestro trabajo con los clientes en este barco hasta ahora ha indicado que System.DirectoryServices y System.Drawing y el bloqueador No.1 y 2 y tenemos un plan para abordar eso. Más allá de eso, estamos viendo los comentarios y evaluaremos.

La compilación cruzada es una sobrecarga que debe equilibrarse con las necesidades del cliente y del producto. Es por eso que queremos recibir estos comentarios para poder definir de manera más concreta cómo se ve el panorama tanto para nuestros clientes como para nosotros a medida que continuamos con la evolución de ASP.NET Core.

@DamianEdwards Gracias por la aclaración adicional. Las bibliotecas netstandard -> ASP.NET Core son un gran problema para mí. Incrusté Kestrel (que también parece estar cambiando a netcoreapp) en varias bibliotecas netstandard. También incorporé Razor en varios lugares, y sé que está trabajando en la nueva versión más modular, pero si eso solo se dirige a netcoreapp también, le dolerá. También hay toneladas de bibliotecas que son "parte" de ASP.NET Core pero que tienen muchas utilidades fuera de él.

En otras palabras, estoy mucho más preocupado por eliminar la capacidad de las bibliotecas netstandard de consumir paquetes ASP.NET Core que por lo contrario. Parece que esto está eliminando toda una clase de casos de uso de la consideración.

@daveaglick Razor (el motor) seguirá teniendo como objetivo netstandard . Nuevamente, hay un costo involucrado en el soporte de subsistemas particulares de un gráfico grande y complejo (como ASP.NET Core 2.0) en diferentes plataformas. Para cosas como la incrustación, hay otras opciones (incrustación de fuente, copia, etc.) pero, por supuesto, vienen con sus propias ventajas y desventajas.

Definitivamente lo escuchamos sobre las diferentes clases de casos de uso, de hecho, tenemos diferentes grupos de clientes a considerar al diseñar y enviar una pila como la nuestra.

Comparto las preocupaciones de @daveaglick aquí: ASP.NET Core desea usar las API más recientes es totalmente comprensible, pero que todo lo demás en sentido descendente requiera lo mismo se complica un poco. No tienes ninguna opción después de 1.0 de estable o de actualización, estás en el tren más rápido disponible con netcoreapp2.0 y esa es la única opción. Si todos los bits (incluso las abstracciones básicas) no se pueden consumir sin que los usuarios consuman netcoreapp2.0 , eso significa que efectivamente no hay netstandard2.0 para toda esa línea de bibliotecas... y todos eso depende de ellos

Muevo la pila de aplicaciones principal, pero no estoy necesariamente de acuerdo con las abstracciones en particular. Uno de los puntos principales de las abstracciones era evitar un acoplamiento estrecho como este, al menos desde mi punto de vista como consumidor. Sería muy curioso ver algunos ejemplos en los que netstandard2.0 no tiene las API necesarias para ellos, pero netcoreapp2.0 sí. ¿Hay algunos ejemplos? ¿Se trata principalmente de nuevos tipos en parámetros de método? No dudo que haya un amplio razonamiento, solo tengo mucha curiosidad: ver ejemplos ayudaría a mostrar el costo de mantenimiento del que no tenemos tanta información diaria.

El caso de Kestrel es más complicado, pero ciertamente veo los argumentos para tenerlo en el último conjunto de API. Me imagino que continuamente se crearán nuevas API para Kestrel dado el trabajo que está generando.

@PinpointTownes como dijo @shanselman , estamos muy interesados ​​en los requisitos específicos y los bloqueadores que tienen los clientes con respecto a la necesidad de continuar apuntando a .NET Framework directamente.

Como consultor, ayudé a un grupo de clientes a mover sus aplicaciones a ASP.NET Core y, a menudo, tenía que apuntar a .NET Desktop para poder usar bibliotecas de terceros (de código cerrado) según IdentityModel / WCF o confiando en AppDomain . apoyo.

No tener estas cosas en ASP.NET Core 2.0 sería un gran obstáculo para ellos.

También hay bibliotecas que no funcionarían en .NET Core incluso si las API estuvieran allí, porque serían funcionalmente diferentes. Aquí hay un caso concreto que he visto muchas veces:

En .NET Core, RSA.Create() devuelve una instancia de RSACng en Windows, pero en .NET Desktop, se devuelve una instancia de RSACryptoServiceProvider . Sin embargo, muchas bibliotecas, incluido el propio BLC, intentan convertir RSA a RSACryptoServiceProvider , lo que siempre fallará en .NET Core, ya que RSACng no se puede convertir a RSACryptoServiceProvider .

@NickCraver , ¿qué abstracciones en particular? El problema de mover solo las abstracciones es que luego terminará queriendo todo lo que se basa en esas abstracciones también (a menos que esté diciendo literalmente que solo necesita Microsoft.AspNetCore.Http.Abstractions y nada más)

@davidfowl Sí, solo las abstracciones: por ejemplo, HTTP, Hosting, HTML y Logging. Parece que Microsoft.Extensions.* están cubiertos por comentarios anteriores, que son la mayoría de estos. Esos son con los que estoy interactuando hoy.

Para un ejemplo concreto: el MiniProfiler Middleware no responde en nada más que abstracciones ( enlace )

Si está usando MVC y demás, entonces está en netcoreapp2.0 todos modos, y eso es lo que es (y en mi opinión, eso está bien). Pero actualmente tengo la libertad de dividir las API lógicamente donde se comparten y hacerlo fácilmente porque son abstracciones. Soy un gran fanático de la división actual, por favor no bloquee eso innecesariamente.

je. Como consultor, definitivamente escuché el "¿Qué? ¡ASP.NET Core se ejecuta en .NET Framework de escritorio!" pregunta bastantes veces. El hecho de que "ASP.NET Core" tenga literalmente ".NET Core" en el nombre es realmente desafortunado.

De todos modos... Así como era un fanático de eliminar las API obsoletas/heredadas/rotas cuando comenzó .NET Core (un comienzo "nuevo"), también soy un fanático de este cambio para obtener un marco más rápido y eficiente. con más funciones y un mayor índice de innovación.

Dicho esto, también simpatizo con todos los desarrolladores que no pueden, por alguna razón, migrar todo su código a .NET Core antes de junio del próximo año.

Esto incluye a mi cliente actual, que tiene una biblioteca/marco heredado increíblemente grande, dirigido a .NET Framework, consumido por varios proyectos de ASP.NET Core que se están desarrollando actualmente en paralelo. Para cuando estos sistemas entren en producción, habrá poco o ningún tiempo para a) migrar todo a .NET Core, o b) mover todo a ASP.NET de marco completo, antes de que ASP.NET Core 1.x no sea compatible.

¿Es un año de soporte realmente suficiente aquí? Me imagino que hay otros casos similares por ahí...

@khellang como se indicó anteriormente, podrán continuar haciendo referencia a bibliotecas/marcos que se dirigen a .NET Framework, y eso funcionará bien suponiendo que las API a las que llaman sean parte del cierre de netstandard2.0 . ¿Sabes si se basan en cosas fuera de ese espacio? Eso es lo que realmente nos encantaría recibir comentarios para que podamos evaluar la prioridad de portar esas API (como System.DirectoryServices y System.Drawing ).

Entonces, ¿alojar una API web (por ejemplo, una capa de comunicación) o incluso los próximos sockets centrales de asp.net será imposible para un servicio de Windows actual o una aplicación de escritorio WPF? (con versiones compatibles).

Me imagino que habrá una lista próxima de cosas que solían ser netstandard1.x que ahora son netcoreapp2.0

He buscado en los repositorios y parece que las cosas específicas de MVC son netcoreapp2.0 pero HttpAbstractions, Logging, Configuration, etc. siguen siendo netstandard ¿O hay más cambios por venir?

@NickCraver Veo que está usando Extensiones pero todavía está usando System.Web. ¿Tiene planes para corregir Microsoft.AspNetCore.Http.HttpContext con System.Web.HttpContext ? ¿Tiene una idea de la cantidad de API que necesita?

Si está utilizando MVC y demás, bueno, entonces está en netcoreapp2.0 de todos modos, y eso es lo que es (y en mi opinión, eso está bien). Pero actualmente tengo la libertad de dividir las API lógicamente donde se comparten y hacerlo fácilmente porque son abstracciones. Soy un gran fanático de la división actual, por favor no bloquee eso innecesariamente.

Sin embargo, no estoy hablando de MVC, solo estoy hablando de otros ayudantes que exponen más funcionalidad además de las abstracciones subyacentes. El gran valor del patrón de "abstracciones" que elegimos es que se pueden construir otras cosas encima de ellas, no tanto las abstracciones en sí. Mi instinto me dice que si hacemos las abstracciones de ASP.NET netstandard, entonces terminaremos teniendo que hacer todo el middleware netstandard también.

Los servicios de Windows de @dasMulli funcionarán una vez que hayamos transferido la API (también hay bibliotecas de código abierto que admiten servicios de Windows en .NET Core).

¿Aplicación de escritorio WPF? (con versiones compatibles).

Si. Este ya no será el predeterminado. Ya no lo admitiremos desde el primer momento con .NET Core 2.0.

@davidfowl No estoy seguro de que hayas mirado las piezas correctas allí:

pero todavía están usando System.Web

...no en las mismas bibliotecas, debido a esta división. Para lograr una sobrecarga mínima y no un montón de dependencias para los consumidores, hay MiniProfiler para ASP.NET MVC < 6 (System.Web) y MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (gran cantidad de NuGet ).

Creo que está hablando de un vestigio de System.Web que estaba en MiniProfiler.Shared : estaba esperando para limpiarlos hasta que se solucionó el problema de NuGet anoche en los ensamblajes de marco. Acabo de quitarlo para aclarar las cosas.

@DamianEdwards No estoy al 100 % en el cierre de netstandard2.0 , pero me encantaría (con su permiso) ejecutar un analizador de portabilidad y compartir los resultados. ¿El analizador de portabilidad sigue existiendo y está actualizado?

ASP.Net Core se está convirtiendo rápidamente en el nuevo Python 3*; solo que peor Esto me parece un movimiento en la dirección equivocada. Esto solo significa que una tonelada de escenarios obligará a los desarrolladores a mantener (y escribir nuevo) código en las "plataformas antiguas" durante muchos años en lugar de mudarse. "Desarrollo más rápido" no parece un muy buen argumento si todo lo que significa es que llegas a un lugar peor/inadecuado "Más rápido".

*Me gusta Python 3, pero ha estado fuera casi una década y la comunidad de Python todavía está fracturada.

Solo para que quede claro: ¿hay algún bloqueador técnico (cosas de rendimiento elegante) o es solo para ahorrar el costo de mantener la compatibilidad en el futuro?
Creo que la mayoría de nosotros sabíamos que este movimiento vendría, pero nadie lo esperaba tan pronto... dado que el tiempo de transición aún continúa (como las bibliotecas que se están portando, .net estándar 2.0 a la vuelta de la esquina, pero aún no se han creado bibliotecas para eso) - Sería genial mantener el soporte net* para al menos una versión (por ejemplo, 2.0, no 2.1).

@shanselman Veo sus puntos y personalmente incluso estoy de acuerdo, pero mucha gente no lo verá de esa manera.

El problema principal no es llamar a los ensamblajes net46 desde el núcleo, las correcciones de compatibilidad se ocupan de eso en la mayoría de los casos. El problema es el código net46 existente y el código asp.net core 1.* que se ejecuta en 46. Como alguien mencionó, el objetivo de netstandard era permitir que el código, incluido asp.net, se ejecutara en todas partes, esto se sentirá como un paso lejos de eso y tal vez incluso un fracaso de esa visión para algunas personas.

No creo que el problema sea que la gente no quiera migrar al núcleo de red. El problema es que las organizaciones, gerentes, CTO y similares deben estar convencidos de que el costo/beneficio de hacerlo vale la pena. La portabilidad no solo consume suficiente tiempo como para afectar las entregas, sino que también presenta riesgos de regresiones, etc.

en otras palabras, no siempre son razones técnicas las que impiden que las personas se muevan. Incluso diría que es raro, _técnicamente_ casi cualquier proyecto puede dar el salto. Pero motivar ese albarán de costo/entrega, ese es el problema. Puede ser una venta muy difícil, una que he tenido que hacer unas cuantas veces. Sin embargo, en esos casos, poder decir "pero se puede ejecutar en el marco completo" ha sido una forma de impulsar ese movimiento.

Si quieres hacerte daño

Esto es exactamente. Los desarrolladores y la administración de Net46 no lo verán así, lo verán como _usted_, microsoft, quiere lastimarlos para mantenerse al día con la última versión. "Bueno, entonces no te muevas", se podría decir, pero con el soporte de asp.net core 1.x tan corto como es, tienen que hacerlo, al menos desde la perspectiva de los gerentes que deben ser responsables si un el error causa tiempo de inactividad o pérdida de información. (incluso si el marco no es responsable)

Muchos desarrolladores que realmente presionaron por asp.net core 1.1 también se sentirán traicionados porque ahora no podrán pasar a 2.0 sin core. Eso puede estar justificado o no, pero solo te digo que mucha gente se va a sentir así, serán ellos los que tendrán que responder ante sus colegas más conservadores.

¿Algo de eso importa? ¿Asp.net core2/dotnet core2 "morirá" debido a esto? No, pero retrasará la adopción y fracturará el ecosistema y eso es realmente triste, en mi opinión. Quiero que la gente pueda usar todas estas cosas geniales que vienen en 2.0 y cortar la compilación cruzada al estándar de red tendrá un impacto en eso. Ciertamente, la mayoría de las personas que pasan el rato en estos repositorios no tendrán ningún problema, son los desarrolladores de Joe y Jane y, más aún, su gerente es el problema.

@DamianEdwards
Estoy de acuerdo en que esto ha sido una fuente de confusión, he tenido que explicarlo muchas veces, pero el resultado de eso siempre ha sido convertir a un desarrollador decepcionado en uno emocionado porque pensaban que no podían usar las cosas nuevas y geniales. pero resultó que podían.

Para resumir, estoy seguro de que esta decisión no se tomó a la ligera, pero si tiene que hacer esto, creo que debe ser muy _muy_ cuidadoso con la mensajería. Tiene que demostrar que migra al núcleo de asp.net, especialmente desde 1. x en net46 es _súper_ simple y súper pulido. La historia para hacer referencia a otras bibliotecas netstandard de net46 tanto como referencias de proyectos como de otra manera tiene que ser sólida como una roca. Creo que debes mostrar/abordar esto explícitamente para evitar que la gente se asuste.

@khellang llamando a @terrajobst para la pregunta del analizador de portabilidad.

@khellang

Sí, acabamos de actualizar el VSIX para 2017, pero simplemente uso la versión de línea de comandos de aquí .

@NickCraver Claro, puede escribir una pieza de middleware que apunte a netstandard, ¿de qué le sirve a usted como autor de biblioteca si ASP.NET Core es compatible con netcoreapp2.0?

@aL3891 gran resumen! Un gran problema que tenemos en el futuro es cómo aprovechamos las nuevas API para las cosas que también están en netstandard. .NET Core obtendrá nuevas API que necesitamos para implementar nuevas funciones (una que me viene a la mente es la compatibilidad con SSLStream ALPN para la compatibilidad con HTTP2 en Kestrel). Entonces, podría argumentar que nos mantenemos en netstandard y usamos constantemente la versión más alta (que .NET Framework aún no es compatible), pero entonces estaríamos en el mismo barco.

Un gran problema que tenemos en el futuro es cómo aprovechamos las nuevas API para las cosas que también están en netstandard. .NET Core obtendrá nuevas API que necesitamos para implementar nuevas funciones (una que me viene a la mente es la compatibilidad con SSLStream ALPN para la compatibilidad con HTTP2 en Kestrel).

Según https://github.com/dotnet/corefx/issues/4721 , la compatibilidad con ALPN para SslStream no estará lista para .NET Core 2.0. Suponiendo que esto finalmente se implemente unos meses más tarde, ¿eso significa que uno podrá usarlo cuando se dirija al TFM netcoreapp2.0 ? En este caso, ¿qué sucederá si decido lanzar una biblioteca basada en netcoreapp2.0 que usa nuevas API que no formaban parte de la forma inicial netcoreapp2.0 si mis usuarios usan un tiempo de ejecución de .NET Core más antiguo? ? ¿Se estrellará? ¿O se alineará netcoreapp2.x con netstandard1.x , cuyo contrato no se puede cambiar sin incrementar la versión de TFM?

@davidfowl para otras implementaciones de cualquier pieza de la pila y pruebas. Y debido a que las abstracciones son (no requieren MVC) como una división decente entre 2 bibliotecas en lugar de "suponer que todos tienen MVC y quieren todas las dependencias".

Si las abstracciones no son en realidad abstracciones y están tan estrechamente relacionadas con ASP.NET Core, ¿por qué no eliminamos esos paquetes? Es una pregunta honesta, ya que eso haría la vida más fácil y clara si ese es el objetivo general de la relación. Estoy tratando de entender el punto de tener abstracciones como paquetes separados si están efectivamente vinculados a una implementación/uso simple. Yo diría que nadie fuera de Microsoft quiere o tiene los recursos para dedicarse a un servidor web netcoreapp2.x de la competencia (¡feliz de ser corregido allí!).

¿Puede aclarar cuál sería el punto de las abstracciones en un mundo netcoreapp2.x ? ¿O si hay planes para simplemente desaprobarlos en 2.0?

Según dotnet/corefx#4721, la compatibilidad con ALPN para SslStream no estará lista para .NET Core 2.0. Suponiendo que esto finalmente se implemente unos meses más tarde, ¿eso significa que uno podrá usarlo cuando se dirija al netcoreapp2.0 TFM? En este caso, ¿qué sucederá si decido lanzar una biblioteca basada en netcoreapp2.0 que usa nuevas API que no formaban parte de la forma inicial de netcoreapp2.0 si mis usuarios usan un tiempo de ejecución de .NET Core más antiguo? ¿Se estrellará? ¿O se alineará netcoreapp2.x con netstandard1.x, cuyo contrato no se puede cambiar sin incrementar la versión de TFM?

La versión x de ASP.NET simplemente se alineará con la versión x de .NET Core. El TFM se actualizará para alinearse con cada versión de .NET Core. Es un producto único que finalmente puede ser tratado como tal. Esa es una de las principales simplificaciones que estamos haciendo como @DamianEdwards menciona arriba. No romperemos a las personas que construyen bibliotecas agregando nuevas API en el núcleo sin cambiar el TFM.

@NickCraver

para otras implementaciones de cualquier pieza de la pila y pruebas.

¿Qué otras implementaciones? ¿Existen otras piezas de la pila que implementen ASP.NET Core?

Si las abstracciones no son en realidad abstracciones y están tan estrechamente relacionadas con ASP.NET Core, ¿por qué no eliminamos esos paquetes? Es una pregunta honesta, ya que eso haría la vida más fácil y clara si ese es el objetivo general de la relación. Estoy tratando de entender el punto de tener abstracciones como paquetes separados si están efectivamente vinculados a una implementación/uso simple. Yo diría que nadie fuera de Microsoft quiere o tiene los recursos para dedicarse a un servidor web netcoreapp2.x de la competencia (¡feliz de ser corregido allí!).

¿Puede aclarar cuál sería el punto de las abstracciones en un mundo netcoreapp2.x? ¿O si hay planes para simplemente desaprobarlos en 2.0?

Podríamos poner todo en un solo ensamblaje, pero la refactorización nos permite una flexibilidad futura que de otro modo no tendríamos si hiciéramos esto. Incluso abre la posibilidad de tener otras implementaciones y realmente no lo excluye a largo plazo.

En pocas palabras, las abstracciones tienen que ver con reducir el número de dependencias, no con la portabilidad de la plataforma.

No romperemos a las personas que construyen bibliotecas agregando nuevas API en el núcleo sin cambiar el TFM.

Ustedes dijeron que querían optar por netcoreapp2.0 , solo porque se estaba moviendo más rápido, en comparación con .NET Desktop y, por extensión, .NET Standard, pero ¿cuál es el punto de apuntar a netcoreapp2.0 en lugar de netstandard2.0 si no puede beneficiarse de las nuevas API de .NET Core sin cambiar el TFM? (por ejemplo netcoreapp2.1 )

Ustedes dijeron que querían optar por netcoreapp2.0 solo porque se estaba moviendo más rápido, en comparación con .NET Desktop y, por extensión, .NET Standard, pero ¿cuál es el punto de apuntar a netcoreapp2.0 en lugar de netstandard2.0 si puede? ¿No se beneficia de las nuevas API de .NET Core sin cambiar el TFM? (por ejemplo, netcoreapp2.1)

Lo siento, me expresé mal, quiero decir netcoreapp2.x no netcoreapp2.0 .

Bien, estoy totalmente confundido, ahora.

Lo siento, me expresé mal, me refiero a netcoreapp2.x no netcoreapp2.0.

No estoy seguro de entender. ¿Quiere decir que habrá una equivalencia entre los paquetes ASP.NET Core 2.1 y el TFM netcoreapp2.1 ?

¿Quiere decir que habrá una equivalencia entre los paquetes ASP.NET Core 2.1 y netcoreapp2.1 TFM?

Sí. Piensa en los 2 como uno en lo mismo. Consulte https://github.com/aspnet/Home/issues/2022#issuecomment -299544884

Entonces, ¿qué le impide adoptar un patrón similar, pero con netstandard ? Sería el mejor enfoque, en mi humilde opinión: se podrían adoptar nuevas API a través de nuevos TFM y las personas que necesitan admitir .NET Desktop aún podrían ejecutar sus aplicaciones ASP.NET Core en el marco completo.

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

@PinpointTownes porque .NET Framework en el escritorio no puede enviarse lo suficientemente rápido, ese es el quid de la mayoría de los problemas de versiones con Core. Es un problema duro en una cadena inmensa.

.NET Standard no se moverá a la misma velocidad que .NET Core. Ni por asomo en realidad. Un movimiento en .NET Standard esencialmente deja atrás a todas las plataformas, hasta que se ponen al día, y .NET Framework es tanto el más lento como el más grande.

Token de punto, aunque no estoy seguro de qué tan rápido se supone que debe enviarse .NET Framework (por ejemplo, las nuevas API de ECDSA se transfirieron de CoreFX a NetFX en menos de un año, lo que parece ser un marco de tiempo razonable para componentes criptográficos tan sensibles ).

La compilación cruzada es una sobrecarga que debe equilibrarse con las necesidades del cliente y del producto.

Cuando tenga un minuto, me encantaría saber más sobre la naturaleza exacta de la sobrecarga causada por la compilación cruzada. Gracias.

Lo que necesitamos de todos ustedes es una lista clara/comprensión de POR QUÉ creen que necesitan ASP.NET Core 2.0 para ejecutarse en net461+. Sea específico para que podamos cerrar esas brechas y permitir que todos tengan éxito.

Por el momento, necesitamos la versión de marco completo de las bibliotecas cliente de WCF, ya que las versiones netstandard / netcore (https://github.com/dotnet/wcf) no están casi completas.

Cuando tenga un minuto, me encantaría saber más sobre la naturaleza exacta de la sobrecarga causada por la compilación cruzada. Gracias.

Llegará un momento en un futuro muy cercano en el que, literalmente, no podremos polillenar funciones como la compatibilidad con ALPN para SSLStream. Además, ni siquiera hemos comenzado a estirar las piernas y agregar API en .NET Core, hasta ahora nos hemos atascado con la migración de las cosas a .NET Standard y .NET Core 2.0 (el propósito completo de .NET Standard 2.0) . Agregaremos nuevas API y finalmente las consumiremos en ASP.NET Core el día 1.

Por el momento, necesitamos la versión de marco completo de las bibliotecas cliente de WCF, ya que las versiones netstandard/netcore (https://github.com/dotnet/wcf) no están casi completas.

@ctolkien Ese es un problema y es la razón por la que portamos el cliente WCF en primer lugar. ¿Sabes lo que te está bloqueando? Esta es una buena oportunidad para ayudarnos a priorizar.

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

Puede haber más, este fue solo el primer obstáculo que enfrentamos antes de hacer la transición al marco completo de wcf.

Llegará un momento en un futuro muy cercano en el que, literalmente, no podremos polillenar funciones como la compatibilidad con ALPN para SSLStream.

cuál es el problema? AFAICT, aquí nunca se ha dicho que las variantes .NET Desktop y .NET Core de ASP.NET Core tenían que admitir exactamente el mismo conjunto de características. Si una función no está disponible en .NET Desktop debido a la falta de API (por ejemplo, HTTP 2/0), ¿por qué no hacer que sea solo .NET Core y arrojar un PlatformNotSupportedException diciéndole al desarrollador que la función que está buscando es ¿no disponible?
Sería mucho mejor que hacer que todos los paquetes de ASP.NET Core sean solo .NET Core, aunque es poco probable que la mayoría de ellos utilice nuevas API de BCL.

@davidfowl Supongo que uno de los principales temores es que las cosas no se arreglen en netcoreapp2.3 , se arreglen en netcoreapp2.4 . Si ASP.NET Core se enfoca en el tren más rápido, ¿cuánto tiempo con cada versión secundaria obtendrá el amor? Si tenemos que actualizar constantemente, entonces cada consumidor tiene que actualizar constantemente.

Eso es excelente para obtener lo último y lo mejor, pero no es lo mejor para la mayoría de las empresas. Por lo tanto, tenemos que mantener muchas versiones (cada una de ellas menor) con nuestras bibliotecas para cada consumidor de ASP.NET Core (para no depender de la última y mantenernos al día), o arrastrar a los usuarios a la última versión para mantenernos al día. Esto no es amigable con cosas como el entorno validado.

A menos que las abstracciones necesiten acelerar tan rápido (¿ejemplos?), sería preferible tenerlas desconectadas. De esa manera, no está arrastrando todo el ecosistema junto con cada actualización. Supongo que no me preocupa más que estén en netcoreapp , sino que se actualicen continuamente y todo esté estrechamente acoplado.

Si las abstracciones mantendrán cada versión menor y trasladarán el dolor (para ser franco) a tu lado, estoy mucho menos preocupado. ¿Pueden ustedes dar más detalles sobre las intenciones con las revisiones aquí?

@PinpointTownes :

¿Por qué no hacerlo solo para .NET Core y lanzar una PlatformNotSupportedException que le dice al desarrollador que la función que está buscando no está disponible?
Sería mucho mejor que hacer que todos los paquetes de ASP.NET Core sean solo .NET Core, aunque es poco probable que la mayoría de ellos utilice nuevas API de BCL.

Nooooooo, por favor no. Esa es una falla de tiempo de ejecución y un comportamiento muy poco deseable. Queremos tener tantas garantías en tiempo de compilación de que nuestras bibliotecas funcionarán como sea posible. Ha habido muchos debates sobre esto, simplemente no es un buen camino. PlatformNotSupported debe evitarse tanto como sea humanamente posible.

Esa es una falla de tiempo de ejecución y un comportamiento muy poco deseable.

Esto es exactamente lo que sucederá con el enfoque "traiga sus ensamblajes de escritorio .NET a .NET Core" si sus ensamblajes intentan usar una API no compatible, excepto que obtendrá MissingMemberException en lugar de PlatformNotSupportedException .

Con mi enfoque, al menos podría definir una mejor historia de herramientas con cosas como los analizadores Roslyn que podrían determinar en tiempo de compilación si las API que está utilizando son compatibles o no.

Y por cierto, lanzar un PlatformNotSupported sería realmente un caso de esquina. Con la compilación cruzada, la mejor opción sería simplemente excluir las API no admitidas del contrato público.

@PinpointTownes Yo también pensé de esta manera, pero la realidad es que se envían nuevas plataformas y no es tan simple. Después de discutir esto muchas veces, mi mente ha cambiado mucho sobre cómo hacer compatibilidad aquí. Ir con la dirección netcoreapp permite que las correcciones se envíen en versiones menores. Ir al otro lado significa que tiene que esperar en .NET Desktop para enviar las correcciones, lo cual... buena suerte. Ese es un vehículo muy lento para las resoluciones.

AFAICT, aquí nunca se ha dicho que las variantes .NET Desktop y .NET Core de ASP.NET Core tenían que admitir exactamente el mismo conjunto de características. Si una función no está disponible en .NET Desktop debido a la falta de API (por ejemplo, HTTP 2/0), ¿por qué no hacerla solo para .NET Core?

La primera mitad de eso es lo que es netstandard . Diferenciar a netcoreapp es exactamente lo que están haciendo aquí. Sin las excepciones intencionales. Es un contrato adecuado esta ruta.

Desea ir en la dirección de lo que se puede arreglar y mejorar más rápido cuando hay brechas involucradas, no al revés. Las excepciones "PlatformNotSupported" se pueden corregir en la biblioteca mañana, en lugar de esperar a que la plataforma se actualice dentro de 3 meses. .NET Core puede admitirlos más rápido porque el código real se envía con él , no por separado como reenviadores la mayor parte del tiempo.

[@PinpointTownes] Si una función no está disponible en .NET Desktop debido a la falta de API (p. ej., HTTP 2/0), ¿por qué no hacerlo solo para .NET Core y arrojar un PlatformNotSupportedException diciéndole al desarrollador que la función que busca no está disponible?

Necesitamos equilibrar la simplicidad en la superficie y el alcance de la API con la productividad del desarrollador. Hasta ahora, hemos utilizado principalmente PlatformNotSupportedException para ofrecer una superficie de API que sea compatible con el pasado. No tenemos la intención de usar PlatformNotSupportedException como una forma de ofrecer conjuntos de funciones inconexas en el futuro. En su lugar, eliminaremos la compatibilidad con las versiones de las plataformas .NET que no tienen las funciones o entregaremos la función como un paquete NuGet independiente que no se admite en todas partes.

Seguir la dirección de netcoreapp permite que las correcciones se envíen en versiones menores.

¿En qué se diferencia del enfoque 1.0? @davidfowl dijo que las nuevas API requerirían nuevos TFM, lo que significa que tendrá que optar por no participar en LTS para obtener correcciones que dependan de las nuevas API de .NET Core. No es realmente una situación ideal.

Diferenciarse de netcoreapp es exactamente lo que están haciendo aquí.

La diferenciación está totalmente bien y definitivamente estoy de acuerdo en que .NET Core debería ser el destino preferido para ASP.NET Core. Pero eso no implica abandonar .NET Desktop por completo, especialmente cuando existen alternativas como la compilación cruzada.

Necesitamos equilibrar la simplicidad en la superficie y el alcance de la API con la productividad del desarrollador.

Por supuesto. Pero también debe equilibrar eso con el hecho de que las bibliotecas heredadas, desarrolladas para .NET Desktop y que usan funciones que no están disponibles en .NET Core, deberían funcionar bien en ASP.NET Core 2.0, tal como lo hicieron en 1.0.

En su lugar, eliminaremos la compatibilidad con las versiones de las plataformas .NET que no tienen las funciones o entregaremos la función como un paquete NuGet independiente que no se admite en todas partes.

Eso está totalmente bien en teoría. Pero la cosa es que la plataforma que actualmente carece de funciones importantes es .NET Core, no .NET Desktop. Esto probablemente cambiará en algunos años, pero lo que es seguro es que las personas seguirán encontrando características faltantes en .NET Core 2.0.

¿Podría valer la pena tener un repositorio de forward-port en dotnet donde las personas pueden realizar solicitudes de API para elementos específicos que consideran que faltan en .NET Core de .NET Framework?

Entonces, ¿se pueden realizar comentarios, revisiones y orientación fuera del ruido diario de los repositorios de código? O una revisión general de api/repositorio de especificaciones (algo así como csharplang vs roslyn)

También será una buena opción para: "Tengo un problema de conversión y necesito buscar un problema relacionado con X api" Mientras que corefx es muy ruidoso para eso.

[@benaadams] ¿Podría valer la pena tener un repositorio de puerto de reenvío en dotnet donde las personas pueden realizar solicitudes de API para elementos específicos que consideran que faltan en .NET Core de .NET Framework?

Diría que estos son simplemente problemas en CoreFx. Además, nuestra promesa generalmente es: si el tipo se comparte entre .NET Framework y .NET Core, tenemos la intención de transferir los miembros recién agregados a .NET Framework. En casos muy raros, esto podría no ser posible, pero lo que está en juego es que se consideran automáticamente.

[@benaadams] O una revisión general de api/repositorio de especificaciones

No estoy seguro de que valga la pena. Las revisiones de API ya son un poco pesadas; extraerlos a otro repositorio parece amplificar eso. Preferiría que siguiéramos optimizando CoreFx para que agregar nuevas API sea tan simple como hacerlo, por ejemplo, en ASP.NET.

como se indicó anteriormente, podrán continuar haciendo referencia a bibliotecas/marcos dirigidos a .NET Framework, y eso funcionará bien suponiendo que las API a las que llaman sean parte del cierre de netstandard2.0

@DamianEdwards ¿Qué pasa con las API que no están en el cierre de netstandard2.0? La mayoría de las bibliotecas de terceros son de código cerrado. ¿Cómo puedo saber que cada caso extremo está en el cierre de netstandard2.0?
Como insinuó @PinpointTownes , esto es como jugar a la ruleta rusa.

Las herramientas de @MJomaa ayudarán aquí, pero obviamente la única forma de saberlo con certeza es ejecutarlo. En realidad, eso no es diferente de una biblioteca de .NET Standard que se ejecuta en un marco compatible con .NET Standard. Las API existentes no reemplazan la necesidad de probar estas bibliotecas. Eso no quiere decir que las implementaciones de netstandard no pretendan ser compatibles, pero son bordes, por ejemplo, https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt

Esas son API que existen en NS 2.0 pero no en .NET Framework 4.6.1.

Me puse muy nervioso con este cambio, pero después de leer el hilo parece estar bien en teoría. Tenemos 5 aplicaciones ASP.NET Core con 4 de ellas en el marco completo, pero en su mayoría solo nos mostramos a la defensiva y tomamos el camino de menor resistencia.

Creo que algún tipo de herramienta integrada en VS como .NET Core Portability Analyzer podría ayudar a los desarrolladores que no están actualizados en Twitter/GitHub y no saben que esta extensión existe. Me viene a la mente la ventana emergente "sugerir una extensión", pero no estoy seguro de qué acción tomaría una persona para desencadenar eso. ¿Quizás tratando de agregar una biblioteca net46x a una aplicación ASP.NET Core 2+?

Las cosas que Microsoft no puede controlar, como el soporte de terceros con Telerik, Syncfusion, etc., también serán un posible bloqueador dependiendo de lo que estén haciendo.

Los mensajes en este hilo de GitHub deben publicarse en una publicación de blog lo antes posible con preguntas frecuentes o algo así. Siento que he estado al tanto de todo, y todavía no estaba 100% seguro de si esto significaba que podíamos hacer referencia a las bibliotecas net46x o no. Claramente, tampoco fui el único confundido por eso.

Para hacer eco de lo que otros han estado diciendo. Hablé con al menos 10 desarrolladores que no sabían que ASP.NET Core podía ejecutarse en el marco completo. Tuve la misma experiencia que @aL3891 , aunque los desarrolladores estaban muy contentos de poder ejecutar ASP.NET Core en el marco completo y sus bibliotecas internas simplemente funcionaban. Una vez más, el mensaje acerca de que .NET Core 2.0 tiene una gran mayoría de casos de uso será muy, muy importante. La pieza sobre tener al menos una solución solo para Windows para System.DirectoryServices en proceso también será importante. Muchos desarrolladores de NET con los que hablo se encogen de hombros cuando escuchan que .NET Core es multiplataforma y se preocupan más por el funcionamiento de su código existente que x-plat/perf.

Chicos, esto es una especie de basura :(
Construimos sobre ASP.NET Core debido a la opción de usarlo con netfx, y creamos cosas que estaban destinadas a durar de 5 a 10 años, no para 1 año de soporte como máximo. Esto es lo que significa el nombre ASP.NET en los negocios y es la razón por la cual las organizaciones grandes y de lento movimiento lo eligen en lugar de los marcos de referencia del mes. Permítanme pasar a los casos de uso concretos.

Trabajo en un grupo de herramientas que crea bibliotecas y aplicaciones de línea de negocios para uso interno de una empresa y para la venta a clientes 'empresariales'. En nuestro caso, en su mayoría organizaciones gubernamentales, pero estoy seguro de que escuchará lo mismo del sector privado. Tenemos marcos internos que codifican patrones comerciales en abstracciones comunes (piense en "IDatabaseConnection", "IEntityProvider", "IWizardFlow", "ICodeGenerator") y construimos interfaces RAD sobre estos backends conectables.

En nuestra pila, ASP.NET Core es un 'complemento': es un destino HTTP, que se usa como abstracción del almacén de datos y para servicios de alojamiento, etc. También es una 'interfaz'; obviamente, muchas de las aplicaciones de LOB que existen son sitios web, y es un gran marco nuevo para las aplicaciones web. Por lo tanto, tenemos requisitos de interoperabilidad bidireccional: código AN-C que hace referencia a otros componentes aleatorios y otro código aleatorio que hace referencia a AN-C.

Somos totalmente fanáticos de Core CLR y la portabilidad, y hemos portado un montón de nuestros componentes al estándar de red objetivo o multiobjetivo. Tenemos una aplicación alojada en Linux hasta ahora y esperamos tener más por venir. Sin embargo, ¡no hay forma de que todo se transfiera pronto! Tenemos un código aún vivo y desarrollado activamente que se basa en

• Autenticación NTLM (incluidos escenarios avanzados en torno a tokens y SPN)
• System.Drawing como arriba (arruga interesante aquí: necesitamos formatos de imagen antiguos como TIFF, que las nuevas bibliotecas OSS no admiten)
• Conectarse a WCF/SOAP apis: todavía hay toneladas y toneladas de estas por ahí
• API criptográficas de Windows (incluidos RSACng, ECDSA y CSP para tokens PKI)
• WPF guis: nuestros clientes no cambiarán a Windows 10 en el corto plazo e incluso cuando lo hagan, no querrán aplicaciones de la Tienda
• Interoperabilidad de Microsoft Office (particularmente Access y Excel) para la importación y exportación de datos
• Extensibilidad de Visual Studio
• Complementos de terceros como el proveedor Oracle ADO.NET

Algunas de estas tecnologías nunca serán compatibles con Core CLR. Pero son tecnologías reales, que son la base del desarrollo de nuevas aplicaciones: necesitamos una versión de .NET que tenga acceso a estas cosas. En este momento, nuestra posición es manejable: aislamos las dependencias "heredadas" (en realidad: específicas de la plataforma) en sus propios componentes, que son específicos de net461. Las aplicaciones comerciales específicas luego dependen de netfx si necesitan estas funciones, y no de otra manera. Preveo un futuro en el que esto es raro para las nuevas aplicaciones... pero es difícil imaginar que alguna vez sea 0%.

Hizo todo este trabajo en csproj y el SDK porque la interoperabilidad es importante. ASP.NET Core es la zanahoria, la razón para querer interoperabilidad. No creo que tenga sentido quitarlo. Y no, "puede cargar sus referencias en una dirección, pero probablemente fallarán en el tiempo de ejecución" no es interoperabilidad.

@gulbanana ¿Puede describir las partes del sistema que usan ASP.NET Core por qué necesitan estar en el mismo proceso que .NET Framework? Agradezco la lista (complementos de Visual Studio, interoperabilidad de Office, etc.), pero ¿está integrado ASP.NET Core en todos esos lugares hoy (no tengo una buena imagen de la descripción anterior)?

Además, ¿qué estaba usando antes de que existiera ASP.NET Core? ¿O es solo un nuevo esfuerzo que nunca usó ASP.NET pero apostó de 5 a 10 años en ASP.NET Core en .NET Framework? ¿Miraste a Katana?

Bien, aquí hay algunos estudios de casos específicos. Diré desde el principio que estoy seguro de que muchos de estos podrían manejarse ejecutando el trabajo específico del escritorio en un proceso separado, aunque parece una gran molestia convertir básicamente un montón de implementaciones de interfaz en RPC. Tampoco es que podamos usar la serialización remota o binaria entre los CLR centrales y de escritorio.

NTLM/AD

Para fines de inicio de sesión único, tenemos aplicaciones que dependen de que el navegador pase las credenciales de inicio de sesión de Windows a través de IIS, que las pasa a un sitio web de ASP.NET Core. Parte del proceso de autenticación es buscar información, como si el usuario está en un grupo de AD en particular. Realmente me gustaría saber más sobre el "paquete de soporte de Windows" y si está destinado a cubrir cosas como esta.

Sistema.Dibujo

Esto se usa en una aplicación web que crea miniaturas y ediciones de imágenes básicas (rotación, superposición de marca de agua). Muchas de las imágenes que se utilizan se remontan a la época de los dinosaurios, por lo que hay cosas como TIFF allí. Son datos mantenidos por un departamento gubernamental relacionados con listados de propiedades particulares y administración de tierras. En este caso, la aplicación era inicialmente ASP.NET MVC y se actualizó/reescribió a través de MVC 2, 4, 5 y ahora Core.

VSIX

Este es un caso de incrustación de AN-C en netfx en lugar de al revés. Tenemos extensiones de Visual Studio para la generación de código que ejecutan 'plantillas' para varios escenarios de RAD. Algunas de estas plantillas se crearon para el desarrollo web y hacen referencia a los tipos AN-C en el momento del diseño (se crean con el preprocesador/tiempo de ejecución T4).

Cripto

Creo que este realmente tiene que estar en proceso: tenemos escenarios de licencias en los que el código es muy sensible a la seguridad. En términos generales, está descifrando y verificando archivos de licencia con respecto al entorno en el que se ejecuta el código; esta es una biblioteca común que se usa en el backend de las aplicaciones web, así como en las aplicaciones de escritorio. Eventualmente, parece probable que .NET Core obtenga suficiente soporte criptográfico para que este pueda ser portado, pero no lo ha sido hoy. Por ejemplo, una de las opciones que tenemos hoy es la compatibilidad con tokens PKI de Fortinet/ePass2003, donde su middleware definitivamente no es compatible con Core (y no hay un plazo para hacerlo).

Oracle ADO.NET

El uso de Entity Framework 6 con un backend de Oracle no tiene que estar en proceso, ¡pero seguro que sería un inconveniente para nuestros sitios web agregar un nivel adicional solo para acceder a una base de datos!

Interoperabilidad de WPF

Usamos Microsoft.Extensions.Logging en todas nuestras aplicaciones de escritorio en estos días: las abstracciones de registro en sí mismas deberán estar en proceso, incluso si las implementaciones no lo están.

En cuanto a lo que usamos antes de ASP.NET Core, ¡ASP.NET MVC! Podríamos volver atrás, pero sería una gran pena renunciar a todos los beneficios.

Como arquitecto, es mi error no haber investigado si "ASP.NET Core se ejecuta en el marco completo" persistiría más allá de la primera versión. Honestamente, nunca se me ocurrió que no lo haría. Simplemente no imaginé la posibilidad de que ya en 2018, por ejemplo, no haya una versión compatible que pueda cargar documentos de Office ...

Una cosa que no tengo clara es dónde se usa ASP.NET Core en cada uno de esos escenarios que mencionas.

NTLM/AD

Este tiene sentido y me gustaría entender a qué API termina mapeándose. ¿Es esto solo System.DirectoryServices? En ese se está trabajando activamente (puedes verlo en corefx).

Sistema.Dibujo

Esta es una brecha conocida que estamos tratando de abordar. Todavía no tengo ninguna respuesta aquí y no sugeriré volver a escribir usando ImageSharp (aunque esa es una opción). Esto tendrá que ser abordado.

VSIX

¿Dónde está ASP.NET Core aquí? ¿Se está ejecutando dentro de una extensión de Visual Studio?

Cripto

¿Hay un problema de corefx para este? ¿Por qué no sería portado? A diferencia de .NET Framework, las versiones de .NET Core están desacopladas del sistema operativo, por lo que es posible que esto suceda más temprano que tarde si se considera importante. (Descargo de responsabilidad: no sé lo suficiente sobre criptografía para comprender las implicaciones de hacer esta plataforma cruzada).

Oracle ADO.NET

¿Dónde entra ASP.NET Core aquí? ¿Está diciendo que el proveedor de Oracle aún no se ha portado a .NET Core?

Usamos Microsoft.Extensions.Logging en todas nuestras aplicaciones de escritorio en estos días: las abstracciones de registro en sí mismas deberán estar en proceso, incluso si las implementaciones no lo están.

Microsoft.Extensions.* seguirá siendo netstandard, por lo que estará cubierto allí.

¿Por qué no hay anuncio/discusión?
Me encanta lo que hace el equipo central de aspnet/.net, pero tengo los mismos temores que @jhurdlow.

Me alegra escuchar sobre MEL En los otros puntos-

NTLM

Aquí hay una clase que se usa en la mayoría de nuestras aplicaciones. Hace un uso bastante trivial de la API, algo que, con suerte, podría ser portado en teoría (pero no lo ha sido).
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

Las plantillas de generación de códigos específicas del núcleo de asp.net utilizan el sistema de acción/enrutamiento (IFileProvider, etc.) para descubrir controladores y vistas, etc., y completar nuestro andamiaje. No estamos alojando un servidor web ASP.NET dentro de Visual Studio, solo estamos haciendo una introspección sobre las aplicaciones ASP.NET.

Cripto

Sospecho que los algoritmos que usamos serán portados, pero aún no lo han sido. Todo esto se vería muy diferente si la premisa fuera, como, un anuncio de un plan a largo plazo para eliminar el soporte para asp.net-core-on-netfx y una discusión sobre cuándo podría ser posible.

Oráculo

Sí, esto se resolvería si ocurre un puerto de Oracle (suponiendo que tenga todas las funciones, etc.).

Un caso de uso más:
Una de nuestras aplicaciones importa datos heredados de una aplicación de Access. En este momento, ese proceso de importación se ejecuta en un servidor en un sitio web principal de asp.net. Utiliza la interoperabilidad COM para cargar acedao.dll desde el redistribuible del motor accdb/jet, lee las tablas en nuestras abstracciones de entidad y luego las guarda en una base de datos SQL más moderna.

Este es otro caso de 'podría estar fuera de proceso, pero ¿por qué debería estarlo?'. Básicamente, estaríamos usando AN-C como una interfaz para un sitio web WebAPI 2 o algo así, en cuyo caso hemos vuelto a esa dependencia en el pasado :(

En general, nuestro objetivo es mover la gran mayoría de lo que hacemos a .NET Core. Nos gustaría la mayor interoperabilidad posible durante el mayor tiempo posible mientras movemos las cosas...

WTF!!! 😨
¿Está diciendo que ASP.NET Core 2 ya no tendrá como objetivo Full .NET Framework 4.x?
Recién comenzamos un proyecto hace 1 mes con ASP.NET Core 1.1 y apuntamos a .NET 4.6 porque hacemos referencia a algunos Full .NET Lib. E íbamos a actualizar a ASP.NET Core 2. Pero lo que escucho de esta publicación... 😞
Mire, elegimos ASP.NET Core debido a sus beneficios (DI, API y MVC fusionados, ... poderoso), así que, por favor, dé como cambio amigo.

Recién comenzamos un proyecto hace 1 mes con ASP.NET Core 1.1 y apuntamos a .NET 4.6 porque hacemos referencia a algunos Full .NET Lib

¿Qué hacen esas bibliotecas? ¿Leyó la respuesta inicial de @shanselman https://github.com/aspnet/Home/issues/2022#issuecomment -299536123? Es posible hacer referencia a algunas bibliotecas de .NET Framework en .NET Core 2.0 (suponiendo que permanezcan dentro del subconjunto de las API).

¿Qué hacen esas bibliotecas? ¿Leíste la respuesta inicial #2022 (comentario) de @shanselman ? Es posible hacer referencia a algunas bibliotecas de .NET Framework en .NET Core 2.0 (suponiendo que permanezcan dentro del subconjunto de las API).

@davidfowl sí, leí el comentario de @shanselman , usamos algunas bibliotecas hechas por la compañía, algunas de esas bibliotecas usan WCF, todas esas bibliotecas son estables, tienen como objetivo .NET 3.5 y no podemos tocarlas.

Esta va a ser una situación muy común. Me encantaría saber si se ha recopilado información (¿telemetría?) sobre cuántos usuarios de ASP.NET Core hay en .NET Core frente a .NET Framework hasta el momento.

Personalmente, no estoy emocionado por esto, pero algunas observaciones:

• la mayoría de los clientes que tengo hoy usan la combinación de asp.net core 1.x/full framework porque tienen miedo de participar en las cosas nuevas
• a partir de los números de descarga del paquete nuget, la adopción de asp.net core no es excelente. Con ese movimiento, será aún un poco más difícil vender algo que no se vende bien en este momento.
• es genial que haya identificado las cosas de LDAP como una brecha (creo que nunca vi a nadie en los últimos 10 años usando esas bibliotecas, pero tal vez solo soy yo). El mayor problema serán las librerías de terceros. Estas serán las verdaderas razones por las que la gente no se mudará a .net core

Toda esta situación es nuevamente otro buen ejemplo de que la EM simplemente toma una decisión sin previo aviso. Solo porque algunas personas siguen los registros, existe este hilo aquí.

Puede que me equivoque, pero pensé que .NET Core ahora está bajo el control de DNF, por lo que estas decisiones ya no son puramente internas de MS.

Las cosas de LDAP/AD son definitivamente una razón por la que necesito estar al tanto de net462 en este momento. Me encantaría ir por completo, BAM -> NetCore por completo, pero esto es un inconveniente.

También estoy usando XML-RPC.net en uno de mis proyectos. Utiliza algunos Reflection.Emit serios en él, y no estoy seguro de si NetCore 2 lo admitirá por completo. Sin embargo, tendré que probar el Analizador de portabilidad para estar seguro.

Encuentro toda esta situación un poco desalentadora con la rapidez y facilidad con la que una decisión importante como esta que afecta el futuro de .NET puede ocurrir sin ninguna transparencia, en el último minuto, una vez más. Se ha invertido mucha energía en vender el ecosistema .NET existente al migrar a ASP.NET Core con el mensaje (según tengo entendido) de que .NET Standard 2.0 se centrará en la compatibilidad y será el lanzamiento que cierre la brecha con .NET v4.x para finalmente producir una plataforma .NET sólida y estable en la que el ecosistema finalmente pueda depender. Personalmente, no creo que .NET Core realmente despegue hasta después del lanzamiento de .NET Standard 2.0, ya que anticipé que sería la "tierra estable prometida" que todos estamos esperando; ahora no tengo idea de qué es ".NET Standard". 2.0" significa qué cubrirá exactamente y qué bibliotecas se planea que sean solo .NET Core.

Como no ha habido un anuncio oficial previo, una solicitud de comentarios, una encuesta o una justificación, esta decisión "parece" haberse tomado sin participación de la comunidad o análisis de impacto en el ecosistema .NET existente y probablemente fragmentará todo el ecosistema por muchos los próximos años. La eliminación de la compatibilidad con .NET v4.x elimina una ruta de migración fluida para que muchas empresas puedan migrar sus bases de código existentes al nuevo modelo de desarrollo de ASP.NET. Esto no los alentará a saltar a .NET Core más rápido, sino que les impedirá siquiera intentarlo, lo que provocará una fragmentación masiva que dividirá el ecosistema .NET en dos. No veo cómo terminará siendo diferente de Python 2/3, que ha sido dañado irremediablemente por la fragmentación de la que aún no ha podido recuperarse en casi una década.

La mayoría de las bases de código .NET existentes son brownfield y están siendo desarrolladas entre bastidores por desarrolladores de .NET de "materia oscura", la mayoría de los cuales no tendrán idea de que se tomó esta decisión dado que .NET Core 1.1 es compatible con .NET v4.x y la mensajería para .NET Standard 2.0 fue la promesa de una compatibilidad mejorada. Espero una reacción violenta masiva una vez que la noticia y el impacto de esta decisión finalmente lleguen a casa. Muchos desarrolladores que han estado vendiendo la adopción de .NET Core internamente dentro de su organización se sentirán traicionados dado que efectivamente han estado migrando a una plataforma sin salida (si no pueden migrar completamente a .NET Core por cualquier motivo). ) una dura realidad a la que deberán enfrentarse justo después de haber logrado la monumental decisión de convencer a las partes interesadas de su organización para que aprueben los recursos necesarios para su migración actual.

La mayoría de las organizaciones necesitan migrar sus bases de código existentes "sobre la marcha", donde necesitan implementar continuamente sus sistemas existentes mientras migran su base de código "en paralelo", que primero querrán implementar a .NET v4.x, luego una vez que todo se haya estabilizado y se hayan solucionado todos los problemas, pueden planificar una migración completa a .NET Core desde allí.

Esta decisión también se tomó en el contexto de años de cambios importantes en ASP.NET que, en mi opinión, han erosionado la confianza de que .NET es una plataforma estable en la que las organizaciones pueden confiar. Me encanta el nuevo modelo de desarrollo de .NET Core, pero en mi opinión, lo que más necesitamos es una plataforma estable en la que podamos confiar y que el resto del ecosistema pueda alcanzar. .NET Core todavía está en un valle inquietante, con herramientas inmaduras, dependencias incompatibles, problemas de tiempo de ejecución, documentación desactualizada, etc. No he visto .NET tan inestable desde los primeros días cuando se lanzó por primera vez.

¿Por qué no realizar una encuesta sobre qué quieren más los desarrolladores de .NET? es decir, una plataforma pulida sólida y estable o una plataforma de "movimiento rápido" que ofrece nuevas características más rápido? Entiendo que requeriría mucho menos esfuerzo no tener que preocuparse por las funciones de retroportación a .NET v4.x, pero sería invaluable tener una versión de ASP.NET Core que se enfocara principalmente en brindar una plataforma compatible estable con soporte de término que puede ejecutarse en .NET v4.x o .NET Core.

¿Ha zarpado este barco o existe una opción para mantener ASP.NET Core 2.0 como está? es decir, con la mayoría de las bibliotecas y abstracciones cubiertas por .NET Standard 2.0 y luego, en la próxima versión de ASP.NET Core 3.0, ¿anunciará que la próxima plataforma será solo .NET Core? Esto permitirá a las organizaciones seguir avanzando y adoptar ASP.NET Core 2.0 y permitir que el resto del ecosistema se ponga al día, con herramientas y bibliotecas estables y bien compatibles, mientras tiene una división limpia desde donde solo la plataforma .NET Core/ comienzan las características.

Es posible hacer referencia a algunas bibliotecas de .NET Framework en .NET Core 2.0 (suponiendo que permanezcan dentro del subconjunto de las API).

Esto genera incertidumbre, muy pocas personas van a querer arriesgar su reputación y la salud y la estabilidad de sus sistemas e intentar una migración completa a .NET Core cuando existe incertidumbre sobre exactamente cuál de sus dependencias podrá y no podrá ejecutarse. .NET Core, lo que significa que más personas permanecerán en .NET v4.x en el futuro previsible.

Realmente no sé cómo se desarrollará esto en última instancia y cuál será el verdadero impacto de esta decisión en todo el ecosistema de .NET, pero es preocupante el hecho de que decisiones importantes como esta con un impacto amplio puedan ocurrir sin ninguna participación externa de la comunidad.

Ojalá estuvieran un poco menos empeñados en bifurcar su base de usuarios.

Mi punto de vista al crear una biblioteca es que sea lo más fácil de usar posible, para tantas personas como sea posible, en tantos lugares como sea posible. Es un dolor en el cuello (busque las directivas del compilador #if en Newtonsoft.Json y obtendrá más de 1300 resultados), pero "simplemente funciona" es un poderoso punto de venta.

¿Por qué no realizar una encuesta sobre qué quieren más los desarrolladores de .NET? es decir, una plataforma pulida sólida y estable o una plataforma de "movimiento rápido" que ofrece nuevas características más rápido? Entiendo que requeriría mucho menos esfuerzo no tener que preocuparse por las funciones de retroportación a .NET v4.x, pero sería invaluable tener una versión de ASP.NET Core que se enfocara principalmente en brindar una plataforma compatible estable con soporte de término que puede ejecutarse en .NET v4.x o .NET Core.

Pregunta genuina, ASP.NET Core 1.x actualmente es compatible con .NET Framework y .NET Core. Digamos que fue la plataforma estable que mencionas anteriormente, que corrigimos errores y brindamos soporte en ambos tiempos de ejecución, pero no obtuvimos más funciones. ¿Sería eso suficiente?

ASP.NET Core y .NET Core son las plataformas ricas en características de rápido movimiento para .NET en este momento. Es una versión de .NET que no está atada a ningún sistema operativo y que nos brinda la agilidad necesaria para innovar rápidamente y lanzar más rápido.

¿Ha zarpado este barco o existe una opción para mantener ASP.NET Core 2.0 como está? es decir, con la mayoría de las bibliotecas y abstracciones cubiertas por .NET Standard 2.0 y luego, en la próxima versión de ASP.NET Core 3.0, ¿anunciará que la próxima plataforma será solo .NET Core? Esto permitirá a las organizaciones seguir avanzando y adoptar ASP.NET Core 2.0 y permitir que el resto del ecosistema se ponga al día, con herramientas y bibliotecas estables y bien compatibles, mientras tiene una división limpia desde donde solo la plataforma .NET Core/ comienzan las características.

Siempre estamos abiertos a recibir comentarios y ASP.NET Core 2.0 aún no se ha enviado. Si ASP.NET Core 3.0 fuera la versión que eliminó .NET Framework, ¿eso mejoraría las cosas? Si observa algunos de los comentarios de @gulbanana y @ikourfaln , hay tecnologías que es probable que nunca se transfieran y, por lo tanto, nunca funcionarán en .NET Core, ¿no significa eso admitir .NET Framework prácticamente para siempre? ¿No tendríamos esta misma discusión dentro de un año? ¿Quizás para entonces el ecosistema o las bibliotecas que admiten .NET Core serían más grandes y tendrían menos impacto? ¿Qué pasa con esas bibliotecas empresariales que nunca se actualizarán (o donde se perdió el código fuente)? ¿Cambiarán en un año?

Mi punto de vista al crear una biblioteca es que sea lo más fácil de usar posible, para tantas personas como sea posible, en tantos lugares como sea posible. Es un dolor en el cuello (busque las directivas del compilador #if en Newtonsoft.Json y obtendrá más de 1300 resultados), pero "Simplemente funciona" es un poderoso punto de venta.

Sin ofender a @JamesNK , pero JSON.NET es un analizador JSON y, en su mayor parte, un solo paquete (sé que hay algunos más). ASP.NET Core tiene > 200 paquetes.

Sin ofender, pero soy un tipo que trabaja medio tiempo. Tu problema es más difícil pero tienes exponencialmente más recursos.

Después de leer esto y revisar las dependencias que tenemos, estoy mucho menos convencido de que sea una buena idea.

Tal como están los planes, no podemos transferir ninguna de nuestras aplicaciones a netstandard / netcoreapp hasta que System.DirectoryServices esté disponible ( problema de CoreFX n.º 2089 aquí ). Entonces, si bien podemos migrar a ASP.NET Core 1.x, no podemos ir a 2.0. Mirando las aplicaciones aquí: Opserver, Stack Overflow en sí, nuestras aplicaciones internas... nada estaría listo como 2.0 se presenta en este punto. De acuerdo con el standup de esta semana, las cosas críticas como DirectoryServices seguirán en una versión posterior 2.x.

Entonces, entre 1.0 y 2.0, pasó de ser algo a lo que me estaba preparando para mudarme a algo a lo que no puedo ir. Así que sí, yo diría que no está listo. ASP.NET es una forma de exponer los bits que necesito a través de HTTP. ASP.NET no es lo que necesito en sí mismo. No estoy usando .NET solo para los bits web, lo estoy usando para la plataforma... al igual que mucha gente. La plataforma no está lista para la amplia variedad de casos de uso que exigen los usuarios, por lo que obligar a los usuarios a usar esa plataforma genera molestias y bloqueos.

La conclusión es que si necesitamos autenticación de AD (una gran parte de la plataforma), acabamos de ser abandonados en la línea 1.x. Ahí es donde me dirigía con nuestras aplicaciones... pero si esta es la dirección, entonces no tiene sentido esforzarse aquí hasta que los bits que necesito estén disponibles en el destino.

Si podemos decir estas cosas críticas como System.DirectoryServices , System.Drawing , y los otros elementos principales que la gente necesita estarán listos con ASP.NET Core 2.0, mi opinión cambia mucho. Si son una ocurrencia tardía (como muestran los cronogramas actuales), continúe admitiendo .NET Framework hasta que lo sean.

Moverse rápido es genial. Me encanta. Estoy ejecutando alfas en producción en este momento. Pero nada de eso importa si no funciona para su caso de uso en primer lugar.

Una cosa con la que estoy luchando personalmente es la "plataforma estable" frente a las "nuevas funciones". Por un lado, queremos que la plataforma sea estable, confiable y compatible; por otro lado, nadie quiere permanecer en 1.x porque no tiene las características de 2.x. ¿Existen funciones súper atractivas en ASP.NET Core 2.x que atraen a las personas en esa dirección o es solo el hecho de que tenemos más funciones que las que teníamos en 1.x (porque es nuevo y brillante)?

Si es lo último, ¿a esas personas les importa la estabilidad? Si la respuesta es sí, ¿por qué no es suficiente ASP.NET Core 1.x?

No estoy usando .NET solo para los bits web, lo estoy usando para la plataforma... al igual que mucha gente. La plataforma no está lista para la amplia variedad de casos de uso que exigen los usuarios, por lo que obligar a los usuarios a usar esa plataforma genera molestias y bloqueos.

De acuerdo, pero en su opinión, ¿cómo se relaciona eso con la eliminación de la compatibilidad con .NET Framework de ASP.NET Core 2.x? Cuando se conecten más dependencias, funcionarán en todas partes, por lo que, en cierto sentido, a medida que la plataforma avanza, el amplio conjunto de tiempos de ejecución obtendrá los beneficios. Todas las versiones de las aplicaciones ASP.NET Core de repente podrían aprovechar esas características.

Si es lo último, ¿a esas personas les importa la estabilidad? Si la respuesta es sí, ¿por qué no es suficiente ASP.NET Core 1.x?

Todo el mundo siempre quiere nuevas funciones, la posibilidad de nuevas funciones o, al menos, saber que tendrán la opción de obtener más beneficios en algún momento posterior. Cuando cierra una plataforma y la pone en modo "estable"/"mantenimiento", la gente ve que ya no se le presta atención.

¿Existen funciones súper atractivas en ASP.NET Core 2.x que atraen a las personas en esa dirección o es solo el hecho de que tenemos más funciones que las que teníamos en 1.x (porque es nuevo y brillante)?

Soporte - eso es lo que estamos pagando.

Si la respuesta es sí, ¿por qué no es suficiente ASP.NET Core 1.x?

Porque el soporte finaliza aproximadamente un año después del lanzamiento (según Scott arriba). Y es posible que apenas haya terminado de portar Stack Overflow para entonces.

¿Cómo se relaciona eso con ASP.NET Core 2.x dejando de admitir .NET Framework?

Porque las bibliotecas que tengo que tener no están allí. Y no sé cuándo serán. Así que estaría atascado en 1.x y tengo una bomba de tiempo hasta que finalice el soporte. ¿Tendré tiempo suficiente para migrar de 1.0 a 2.x (o 3.x) antes de que finalice el soporte? Probablemente no.

Las bases de código grandes no pueden simplemente detenerse y portar, necesitan tiempo, debe suceder en etapas. Hacer un puerto de .NET 4.6.x en ASP.NET Core fue factible como un paso intermedio. Ir al núcleo a la vez es mucho más difícil, lleva mucho más tiempo y requiere ramas más duraderas y más dolor. Si no podemos hacer esto por etapas, sinceramente, no creo que podamos salir de la línea ASP.NET 5 ahora abandonada. No hay forma de que pueda justificar el tiempo, el costo y el impacto en el desarrollo que tendrá.

Creo que muchos autores de OSS también son como yo: es una extensión de nuestros trabajos diarios. Si no estamos usando la plataforma o no la estamos probando, las bibliotecas están mucho peor o no se crean. Y no podemos justificar el tiempo para mantenerlos con las horas de trabajo que dedicamos hoy. Y cada biblioteca que hacemos proviene de una necesidad que encontramos en la producción. Los casos de uso de caída del ecosistema tienen un gran impacto posterior que no es repentino, pero aún así se suma.

Actualmente, mi opinión es esta: hay una nueva plataforma que funciona hasta aproximadamente julio de 2018. Después de eso: no sé nada, solo espero que lo que necesito esté disponible en netstandard / netcoreapp para entonces. Y espero tener suficiente tiempo para portar antes de que finalice el soporte. Sin embargo, no me pagan para esperar, me pagan para tomar decisiones de plataforma para nuestra empresa, y ASP.NET Core es una mala apuesta (para nosotros) con este cambio y sin fecha para una versión que funcionará.

Permítanme ofrecer un resumen de una línea: sin la compatibilidad con .NET Full Framework, ASP.NET Core no ofrece una plataforma compatible para nuestros casos de uso durante los próximos 2 años.

Como una versión corta, es esto:

Prioridad 1: Esto tiene que funcionar en net461 , no importa qué ifdefs, perf haya.
Prioridad 2. Si puede hacerlo 10 veces más rápido en .NET Core 2.0, entonces eso es increíble. Es una gran razón para que las personas elijan la plataforma y/o migren cuando puedan.

La clave aquí es que para el soporte a largo plazo, todavía tiene que funcionar en el marco completo, incluso si es más lento allí.

Prioridad 1: Esto tiene que funcionar en net461

Y si .NET Core fuera totalmente compatible con net461 (dentro de lo razonable); así que cualquier cosa escrita para net461 funcionó en Core; ¿entonces estaría bien?

Básicamente, en ese momento tiene una plataforma más estable que net4x, ya que puede hacerlo en paralelo y autónomo (toque de x-plat también). Mientras que net461 tiene cambios en toda la máquina a 4.6.1, 4.6.2, 4.7, etc.

Obviamente algunas cosas nunca funcionarán; como confianza parcial, pero eso nunca funcionó de todos modos.

Pregunta genuina, ASP.NET Core 1.x actualmente es compatible con .NET Framework y .NET Core. Digamos que fue la plataforma estable que mencionas anteriormente, que corrigimos errores y brindamos soporte en ambos tiempos de ejecución, pero no obtuvimos más funciones. ¿Sería eso suficiente?

Me encantaría ver una versión LTS de ASP.NET Core 2.0 como lo hace Ubuntu / Redhat con sus versiones LTS que admiten durante más de 5 años. Proporcionaría un objetivo sólido y compatible que el resto del ecosistema puede tener la confianza para comprometerse a adoptar.

Personalmente, estoy más interesado en un .NET Standard 2.0 estable que en cualquier característica futura exclusiva de .NET Core, ya que me encantaría volver al desarrollo de .NET, donde todo vuelve a funcionar, las herramientas no están rotas, el popular .NET. Todos los paquetes de NET brindan soporte, las soluciones de alojamiento e implementación circundantes están pulidas y hay una gran cantidad de documentos, publicaciones, videos y base de conocimientos disponibles para un ASP.NET Core estable en el que podemos comenzar a crear soluciones.

¿No tendríamos esta misma discusión dentro de un año? ¿Quizás para entonces el ecosistema o las bibliotecas que admiten .NET Core serían más grandes y tendrían menos impacto? ¿Qué pasa con esas bibliotecas empresariales que nunca se actualizarán (o donde se perdió el código fuente)? ¿Cambiarán en un año?

En un mundo ideal, .NET v4.x y .NET Core serían compatibles con ASP.NET Core en un futuro previsible y solo se trata de funciones nuevas exclusivas de .NET Core que solo estarán disponibles en paquetes exclusivos de .NET Core. Pero si MS está destinado a dejar atrás .NET 4.x, entonces una versión de ASP.NET 2.0 LTS antes de que se separen oficialmente sería la siguiente mejor opción. Por definición, nadie depende de nuevas funciones que aún no existen, por lo que nadie se verá obligado a actualizar a .NET Core solo v3.0.

Con la libertad de tener que admitir solo 1 plataforma, podría ofrecer nuevas funciones que atraerían a los desarrolladores a adoptar la próxima versión más reciente y mejor con un flujo continuo de nuevas funciones. Personalmente, estoy contento con la funcionalidad que ASP.NET tiene ahora. Estoy más interesado en una versión estable donde todo esté pulido para poder volver a ser productivo nuevamente y concentrarme en desarrollar soluciones en lugar de perseguir una plataforma en constante movimiento.

En primer lugar, gracias a @davidfowl por meterse en el hilo y ponerse de pie/hacer preguntas, etc. Cuando hay una comunidad acalorada que pregunta montones de preguntas, es fácil no intervenir y evitar ser 'un objetivo'. Así que gracias por involucrarse, de manera constructiva. /me te saluda.

Veo dos puntos/hilos principales que surgen de esta conversación:

1. Solicitud de compatibilidad con escritorio .NET en vnext. (eso es el 99% de las respuestas aquí)
2. Falta de consulta comunitaria sobre una decisión tan importante. (las 2 o 3 respuestas aquí).

TL;RD;

• ¿Podemos ser más abiertos con grandes cambios importantes de vnext?
• Asigne algo de tiempo para algunos RFC de la comunidad sobre estos cambios de vnext.

@mythz lo expresó muy bien en su oración de apertura de su (en este punto), ~más reciente~ 2do comentario más reciente:

Encuentro toda esta situación un poco desalentadora con la rapidez y facilidad con la que una decisión importante como esta que afecta el futuro de .NET puede ocurrir sin ninguna transparencia, en el último minuto, una vez más.

Esto es lo que realmente me impactó personalmente y me encantaría recibir respuestas/comentarios oficiales de las personas apropiadas en MS que hacen estas llamadas, por favor. "Nosotros" hemos estado en esta comunidad durante mucho tiempo: caras conocidas, nombres familiares y, es bastante justo decirlo, todos siguiendo los mismos objetivos positivos. Incluso continuaría diciendo que "nosotros" somos una familia extensa bastante grande, con verrugas y todo.

Así que siento que con la nueva dirección que ha tomado MS (OSS-all-the-things, etc.) y con algunos mega-uber-.NET-threads recientes en los últimos 12/18 meses (léase: aprendiendo de esas experiencias de discusión de la comunidad ) ... que "nosotros" estamos todos juntos en esto y que algunas de estas cosas realmente grandes ™️ se discutirán abiertamente, con mucha anticipación.

Entonces, ¿podemos hablar abiertamente sobre algunas de estas grandes decisiones de antemano? ¿Obtener alguna consulta y discusión comunitaria positiva?

Nota: Acepto que este(s) proyecto(s) no son una democracia y que las _decisiones_ las toma MS. No hay problema. No estoy criticando _eso_. Estoy hablando de los pasos mucho antes de eso. Además, no estoy pidiendo que se presente _todo_ para RFC, etc.

Pero si MS está destinado a dejar atrás .NET 4.x, entonces una versión de ASP.NET 2.0 LTS antes de que se separen oficialmente sería la siguiente mejor opción. Por definición, nadie depende de nuevas funciones que aún no existen, por lo que nadie se verá obligado a actualizar a .NET Core solo v3.0.

No entiendo. Nadie depende de las funciones de ASP.NET 2.0 todavía, ya que no existen en una versión. Entonces, ¿no es ASP.NET Core 1.x esa versión? Se ejecuta en el marco completo, core 1.0 y core 2.0 y puede actuar como trampolín para ASP.NET Core 2.x.

@onovotny

Todo el mundo siempre quiere nuevas funciones, la posibilidad de nuevas funciones o, al menos, saber que tendrán la opción de obtener más beneficios en algún momento posterior. Cuando cierra una plataforma y la pone en modo "estable"/"mantenimiento", la gente ve que ya no se le presta atención.

Sí, pero es realmente difícil garantizar el mismo nivel de calidad cuando .NET Framework es el gran soporte estable vinculado al componente del sistema operativo. Como dijo @terrajobst , algunas cosas definitivamente se portarán en algún momento, pero otras deberán resolverse. El hecho es que ASP.NET Core funciona mejor en .NET Core porque tenemos la capacidad de acelerar toda la pila a la vez. Hasta el momento, existen grandes diferencias de rendimiento entre los 2 tiempos de ejecución y todavía tenemos que tomar dependencias en las nuevas API debido a la compatibilidad con .NET Framework. A medida que avancemos, agregaremos nuevas API que pueden o no aparecer en .NET Framework en algún momento y no queremos acelerar al ritmo del tiempo de ejecución más estable y lento (.NET Framework).

@NickCraver

Porque el soporte finaliza aproximadamente un año después del lanzamiento (según Scott arriba). Y es posible que apenas haya terminado de portar Stack Overflow para entonces.

No estoy seguro de que eso sea del todo exacto. Cuando 2.0 esté disponible, 1.1 seguirá siendo compatible. Entonces, ¿qué es este "apoyo" del que estás hablando? ¿Quiere decir soporte pagado o quiere decir que solucionaremos los problemas cuando surjan?

Porque las bibliotecas que tengo que tener no están allí. Y no sé cuándo serán. Así que estaría atascado en 1.x y tengo una bomba de tiempo hasta que finalice el soporte. ¿Tendré tiempo suficiente para migrar de 1.0 a 2.x (o 3.x) antes de que finalice el soporte? Probablemente no.

Sin embargo, como dije, esas bibliotecas se iluminarán independientemente de la versión de .NET Core. Creo que lo que está diciendo es que quiere usar la última versión de ASP.NET Core (sea lo que sea) y quiere que sea compatible con .NET Framework hasta que haya suficientes bibliotecas en .NET Core para que el puerto es fácil para su escenario específico.

Las bases de código grandes no pueden simplemente detenerse y portar, necesitan tiempo, debe suceder en etapas. Hacer un puerto de .NET 4.6.x en ASP.NET Core fue factible como un paso intermedio. Ir al núcleo a la vez es mucho más difícil, lleva mucho más tiempo y requiere ramas más duraderas y más dolor. Si no podemos hacer esto por etapas, sinceramente, no creo que podamos salir de la línea ASP.NET 5 ahora abandonada. No hay forma de que pueda justificar el tiempo, el costo y el impacto en el desarrollo que tendrá.

¿Cómo afectan las versiones aceleradas de ASP.NET Core? Si elimináramos el soporte de .NET Framework en 3.0 (como la gente parece estar eludiendo en este hilo), ¿no estaría usted en el mismo callejón sin salida de todos modos? Tendría su aplicación ASP.NET Core 2.0 portada ejecutándose en el marco durante un año y cuando salga 3.0, no podrá actualizar. Podría hacer esto de todos modos con ASP.NET Core 1.1.x, que se ejecuta en .NET Framework y es compatible incluso cuando ASP.NET Core 2.0 no está disponible.

Actualmente, mi opinión es esta: hay una nueva plataforma que funciona hasta aproximadamente julio de 2018. Después de eso: no sé nada, solo espero que lo que necesito esté disponible en netstandard/netcoreapp para entonces. Y espero tener suficiente tiempo para portar antes de que finalice el soporte. Sin embargo, no me pagan para esperar, me pagan para tomar decisiones de plataforma para nuestra empresa, y ASP.NET Core es una mala apuesta (para nosotros) con este cambio y sin fecha para una versión que funcionará.

Entonces, ¿un año más es tiempo suficiente para todos? Esa no es la sensación que me da este hilo.

Prioridad 1: Esto tiene que funcionar en net461, no importa qué ifdefs, perf haya.
Prioridad 2. Si puede hacerlo 10 veces más rápido en .NET Core 2.0, entonces eso es increíble. Es una gran razón para que las personas elijan la plataforma y/o migren cuando puedan.

La clave aquí es que para el soporte a largo plazo, todavía tiene que funcionar en el marco completo, incluso si es más lento allí.

La única razón por la que .NET Framework funciona tan bien como lo hace hoy es porque teníamos la intención de admitirlo. No fue gratis, no es "simplemente más rápido en el núcleo", tuvimos que diseñar el sistema intencionalmente para que fuera posible hacerlo funcionar en .NET Framework. Aunque todavía no lo ve, la brecha de características aumentará entre los 2 una vez que decidamos (y lo hemos decidido) tomar dependencias en las API que aún no existen en .NET Framework. Podemos hacer lo que dice @PinpointTownes y comenzar a arrojar NotSupportedException cuando aparezcan esas brechas en las funciones, pero en mi opinión, esa es una experiencia bastante mala.

Gastamos un gran presupuesto de desarrollo en la migración de nuestra aplicación ASP.net MVC5 al marco completo central de ASP.net para que funcione bien con Azure Service Fabric. Todo el proyecto fue de varios meses en los que hubo varias semanas dedicadas a portar nuestra aplicación web (y, francamente, luchar con las incómodas herramientas VS2015).

La única razón por la que funcionó fue porque se admitía el marco completo, ya que actualmente estamos ejecutando SignalR en ASP.net core (para el desánimo de @davidfowl ). Por lo que puedo decir, ¿SignalR todavía no es compatible con Asp.net Core?

Luego pasamos una semana más o menos migrando a las nuevas herramientas VS2017. Multa.

_Tenga en cuenta que hasta este punto no hay ninguna mejora en el producto, solo se trata de ajustar la forma del código para que se ajuste a la plataforma y los requisitos de herramientas de Microsoft._

¿Ahora me está diciendo que dentro de 12 meses tendré que realizar más esfuerzos de desarrollo sin características sin garantía de que pueda hacerlo, dependiendo de un montón de manos y debería poder hacerlo? No, gracias.

En primer lugar, obtenga todo lo que la gente con la marca Microsoft está usando en el marco completo de ASP.net core hoy en día, trabajando solo en ASP.net core. En segundo lugar, averigüe qué más (si es que hay algo) estaría impidiendo que el ecosistema adopte el núcleo de ASP.net como se desea. Entonces, y solo entonces, elimine el soporte para Netfx como se está discutiendo.

Podemos hacer lo que dice @PinpointTownes y comenzar a lanzar NotSupportedException cuando aparezcan esas brechas de funciones, pero en mi opinión, esa es una experiencia bastante mala.

Eso no es exactamente lo que dije: cuando se va con la compilación cruzada, ifdefs definitivamente debería ser la opción preferida para excluir las API que no están disponibles en una plataforma específica, pero si por alguna razón DEBES tener esta firma API en el público contrato, entonces puede ir con NotSupportedException .

No entiendo. Nadie depende de las funciones de ASP.NET 2.0 todavía

Espero que la mayoría de los desarrolladores estén esperando un .NET Standard 2.0 estable y altamente compatible que sus dependencias admitan antes de comprometerse a migrar a ASP.NET Core. No van a querer adoptar .NET Core 1.1 ahora que saben que ha llegado al final de su vida útil y que MS no tiene un buen historial de brindar soporte a largo plazo para ninguna versión antigua de DNX/.NET Core. Si hubiera una versión LTS estable altamente compatible que el resto del ecosistema pueda adoptar de manera segura, las empresas deberían tener todo lo que necesitan para ejecutar sus sistemas en ella y no se sentirán obligadas a actualizar a .NET Core vNext, ya que tendrán todo lo que necesitan. necesita en v2.0 y cuando llegue el momento será mucho más fácil planificar su migración de ASP.NET Core 2.0/.NET v4.6 a una futura versión de .NET Core únicamente.

@mitos

Personalmente, estoy más interesado en un .NET Standard 2.0 estable que en cualquier característica futura exclusiva de .NET Core, ya que me encantaría volver al desarrollo de .NET, donde todo vuelve a funcionar, las herramientas no están rotas, el popular .NET. Todos los paquetes de NET brindan soporte, las soluciones de alojamiento e implementación circundantes están pulidas y hay una gran cantidad de documentos, publicaciones, videos y base de conocimientos disponibles para un ASP.NET Core estable en el que podemos comenzar a crear soluciones.

De acuerdo con todo, pero no veo cómo esta decisión afecta nada de lo que dijiste. Quiero todas esas mismas cosas 👍 .

Con la libertad de tener que admitir solo 1 plataforma, podría ofrecer nuevas funciones que atraerían a los desarrolladores a adoptar la próxima versión más reciente y mejor con un flujo continuo de nuevas funciones. Personalmente, estoy contento con la funcionalidad que ASP.NET tiene ahora. Estoy más interesado en una versión estable donde todo esté pulido para poder volver a ser productivo nuevamente y concentrarme en desarrollar soluciones en lugar de perseguir una plataforma en constante movimiento.

Correcto, ¿no es eso ASP.NET Core 1.x? Si se ampliara el soporte en 1.x, ¿no sería suficiente? Podríamos asegurarnos de que ASP.NET Core 1., que es netstandard 1.x, se ejecute en .NET Core 2.0 (que ya lo hace) y admitirlo durante, digamos, otro año más o menos.

Eso no es exactamente lo que dije: cuando se va con la compilación cruzada, ifdefs definitivamente debería ser la opción preferida para excluir las API que no están disponibles en una plataforma específica, pero si por alguna razón necesita tener esta firma API en el contrato público, entonces puede ir con NotSupportedException.

Ni siquiera estoy hablando de exponer la API pública. Estoy hablando de las API que debemos llamar que no existirán en netstandard. #ifdefs no ayuda aquí. Simplemente lanzaríamos a medida que aumentan las brechas.

@davidfowl Preguntas totalmente válidas - respuestas:

¿Quiere decir soporte pagado o quiere decir que solucionaremos los problemas cuando surjan?

Correcciones activas para problemas: ¿1.x recibirá correcciones para todas las cosas que fallamos, o se nos pedirá que actualicemos para una solución en algunos casos? (nota: esa es una actualización que no podemos hacer hasta que nuestras bibliotecas, como DirectoryServices, estén allí... e incluso si podemos, no es gratis ni barato, es probable que sean meses como mínimo). Somos grandes, somos rápidos, encontraremos quiebres en el marco. Tenemos para cada lanzamiento mayor y menor durante años. El apoyo es fundamental para nosotros.

Creo que lo que estás diciendo es que quieres usar la última versión de ASP.NET Core

No, quiero una versión que funcione y un camino a seguir. Con 1.x, solo tenemos la primera mitad. Hasta este problema, el segundo era algo asumido.

¿Cómo afectan las versiones aceleradas de ASP.NET Core?

Porque si está eliminando el soporte para el marco completo, nos vemos obligados a hacer un cambio importante para mantener el soporte.

Si elimináramos el soporte de .NET Framework en 3.0 (como la gente parece estar eludiendo en este hilo), ¿no estaría usted en el mismo callejón sin salida de todos modos?

¿Quizás? El punto es tener paridad en los casos de uso antes de realizar la inmersión. Es mi carrera, no puedo decirle a nuestra empresa que salte cuando el otro lado puede no apoyarnos. Eso sería irresponsable de mi parte. Si nuestros casos de uso fueran compatibles con el marco de tiempo 2.x, entonces hay un camino claro hacia adelante y es mucho más seguro apostar por ASP.NET Core.

Entonces, ¿un año más es tiempo suficiente para todos?

El período de tiempo absoluto realmente no importa: debe ser compatibilidad de casos de uso + tiempo (IMO). Si nuestros casos de uso funcionaron hoy (por ejemplo, autenticación AD), entonces 2 años es suficiente, sí. Pero actualmente ese no es el caso, por lo que aceptar que un punto arbitrario en el tiempo a partir de ahora está bien es, en el mejor de los casos, prematuro.

No fue gratis, no es "simplemente más rápido en el núcleo", tuvimos que diseñar el sistema intencionalmente para que fuera posible hacerlo funcionar en .NET Framework. Aunque todavía no lo ve, la brecha de características aumentará entre los 2 una vez que decidamos (y lo hemos decidido) tomar dependencias en las API que aún no existen en .NET Framework.

Entonces no te ofendas, pero ¿por qué no decir eso y cerrar el tema? Esa declaración parece que no hay nada más que discutir, y es mejor pasar nuestro tiempo en otro lugar. Si ese no es el caso, por favor aclare?

El principal problema es que no podemos transferir nuestras cargas de trabajo a netstandard hoy o, como se propone actualmente, en el lanzamiento. Si lo que ya tenemos no funciona, ¿por qué deberíamos preocuparnos por las nuevas funciones? El equipo sigue hablando sobre el rendimiento (y eso es increíble, de verdad), pero algo que no puedo usar corriendo rápido realmente no importa mucho.

Como líder de arquitectura/plataforma, tengo que decidir qué apuestas hacemos. Actualmente, esta es una mala apuesta. Cuando la versión 1 lo admite, pero la versión 2 no, pero con suerte lo hará algún día , es una apuesta realmente mala para hacer con el tiempo y el dinero de otras personas. Al menos para nosotros, elegimos .NET por las características, el ecosistema y el soporte. Actualmente, en la nueva palabra, hemos pasado de los 3 a 1. El ecosistema aún no está allí (superficie API, librerías), y el soporte es mucho más corto de lo que estamos acostumbrados, sin ninguna ruta de actualización garantizada y una cantidad desconocida de tiempo para hacerlo.

@jahmai

La única razón por la que funcionó fue porque se admitía el marco completo, ya que actualmente estamos ejecutando SignalR en ASP.net core (para el desánimo de @davidfowl ). Por lo que puedo decir, ¿SignalR todavía no es compatible con Asp.net Core?

Incluso SignalR 2 no es compatible con ASP.NET Core (aunque la gente lo ha pirateado para que funcione). SignalR todavía está en desarrollo y ni siquiera saldrá con ASP.NET Core 2.0, llegará más tarde.

¿Ahora me está diciendo que dentro de 12 meses tendré que realizar más esfuerzos de desarrollo sin características sin garantía de que pueda hacerlo, dependiendo de un montón de manos y debería poder hacerlo? No, gracias.

¿Hay funciones que necesita en ASP.NET Core 2.0? ¿O solo está especulando que eventualmente necesitará actualizar al próximo ASP.NET Core y en ese momento las cosas no funcionarán en .NET Framework?

En primer lugar, obtenga todo lo que la gente con la marca Microsoft está usando en el marco completo de ASP.net core hoy en día, trabajando solo en ASP.net core. En segundo lugar, averigüe qué más (si es que hay algo) estaría impidiendo que el ecosistema adopte el núcleo de ASP.net como se desea. Entonces, y solo entonces, elimine el soporte para Netfx como se está discutiendo.

Como parte de netstandard 2.0, se trabajó mucho para identificar las API importantes que se recuperarían para que las bibliotecas destinadas a .NET Framework fueran, en su mayor parte, compatibles binariamente con él. Por supuesto, hay áreas que simplemente no funcionarán como WCF, WPF, etc., pero ayudarán, ya que investigamos un poco y ~60% de las bibliotecas son compatibles con API con netstandard 2.0 (corríjame si me equivoco en ese número @terrajobst) y puede funcionar en .NET Core 2.0.

Correcto, ¿no es eso ASP.NET Core 1.x? Si se ampliara el soporte en 1.x, ¿no sería suficiente?

Esperaba que .NET Standard 2.0 fuera la plataforma estable que uniera la compatibilidad con .NET 4.x, por lo que tiene más sentido que la compatibilidad con LTS esté en torno a eso. Nadie espera que la versión 1.1/.NET v4.x finalice a mitad del lanzamiento, por lo que sería respetuoso anunciar LTS en la última versión cuando se lance, sin obtener compatibilidad con .NET 4.x antes de su lanzamiento, no. uno hace LTS en retrospectiva a versiones antiguas como esa.

Sé que mantenemos nuestros paquetes de .NET Core en paquetes *.Core separados para que podamos permanecer en una cadencia de lanzamiento separada que sigue la última versión de .NET Core en el momento en que nos fusionamos con los paquetes principales de NuGet. nos comprometemos a una versión estable que admitiremos oficialmente, por lo que debemos estar muy seguros de que tenemos una versión que podemos admitir en el futuro previsible que esperaba de .NET Standard 2.0, no del actual .NET Standard Mezcla 1.1/1.3/1.6. Recuerdo que también hubo un momento en el que iba a haber un lanzamiento de brecha de parada 1.7/8 que iba a ser incompatible con 2.0 rompiendo la expectativa de versiones estándar de .NET que no son señales de una plataforma estable.

Esperaba ansiosamente que .NET Standard 2.0 estuviera destinado a proporcionar el tan buscado área de superficie altamente compatible y la estabilidad que tanto necesitaba.

Incluso SignalR 2 no es compatible con ASP.NET Core (aunque la gente lo ha pirateado para que funcione). SignalR todavía está en desarrollo y ni siquiera saldrá con ASP.NET Core 2.0, llegará más tarde.

No estoy seguro de cuál fue la intención de esa declaración, pero siento que solo refuerza mis preocupaciones.

¿Hay funciones que necesita en ASP.NET Core 2.0? ¿O solo está especulando que eventualmente necesitará actualizar al próximo ASP.NET Core y en ese momento las cosas no funcionarán en .NET Framework?

Quiero pasar a netstandard2 en algún momento por algunas razones. Tendré que mover mi aplicación web a asp.net core 2 para eso, ¿verdad?

Como parte de netstandard 2.0, se trabajó mucho para identificar las API importantes que se recuperarían para que las bibliotecas destinadas a .NET Framework fueran, en su mayor parte, compatibles binariamente con él. <...>

Claro, y me gusta lo que se está haciendo con netstandard, pero si falta algo de netstandard, puede solucionarlo porque puede apuntar al marco completo en las aplicaciones que lo necesitan. Ahora tenemos un puñado de bibliotecas netstandard 1.3 puras (nuestra fuente) compartidas en: Xamarin.iOS, Xamarin.Android, net46, Asp.net core 1.1, porque podemos complementar la funcionalidad que falta en netstandard con bibliotecas específicas de marco de referencia, incluidas las cosas de net46. en nuestra aplicación web central asp.net.

La _ única _ razón por la que tenemos estas bibliotecas netstandard es porque necesitábamos portar nuestra enorme aplicación web (como mencioné anteriormente). Me _gustaría_ no tener que expandir la base de código específica de nuestra plataforma para otras plataformas y, en cambio, seguir ascendiendo en la cadena netstandard. Realmente no quiero quedarme atrapado en netstandard 1.3 porque no hay una ruta para pasar a asp.net core 2.

Correcciones activas para problemas: ¿1.x recibirá correcciones para todas las cosas que fallamos, o se nos pedirá que actualicemos para una solución en algunos casos? (nota: esa es una actualización que no podemos hacer hasta que nuestras bibliotecas, como DirectoryServices, estén allí... e incluso si podemos, no es gratis ni barato, es probable que sean meses como mínimo). Somos grandes, somos rápidos, encontraremos quiebres en el marco. Tenemos para cada lanzamiento mayor y menor durante años. El apoyo es fundamental para nosotros.

No creo que haya problema con el soporte. De hecho, no creo que esto sea un gran problema y si hiciera que las personas se sintieran más seguras al hacer una apuesta, entonces tal vez valga la pena extender el soporte para 1.x a un período de tiempo más largo.

No, quiero una versión que funcione y un camino a seguir. Con 1.x, solo tenemos la primera mitad. Hasta este problema, el segundo era algo asumido.

Simplemente significa que debe permanecer en 1.x hasta que todas sus dependencias sean portadas, ¿no?

@NickCraver Todas sus quejas se refieren a cosas que faltan en .NET Core en lugar de ASP.NET Core. En .NET Core 1.x y ASP.NET Core 1.x, esas 2 entidades se envían juntas pero están completamente desacopladas. No he escuchado una sola razón para querer usar ASP.NET Core 2.0 específicamente aparte de las preocupaciones válidas acerca de que v1 admita algo y v2 no lo admita. Creo que tendríamos exactamente la misma discusión dentro de un año si hubiera otra razón por la que no pudiste migrar solo a .NET Core (tal vez durante el desarrollo de ASP.NET Core en el marco completo tomaste algunas dependencias nuevas que nunca será portado como un ejemplo).

Entonces no te ofendas, pero ¿por qué no decir eso y cerrar el tema? Esa declaración parece que no hay nada más que discutir, y es mejor pasar nuestro tiempo en otro lugar. Si ese no es el caso, por favor aclare?

Estoy aquí respondiendo y respondiendo porque estoy tratando de averiguar por qué necesitamos admitir .NET Framework, de ser así, por cuánto tiempo. Todavía tengo una vibra mixta en este hilo sobre esos marcos de tiempo. También hay un temor general que puedo entender acerca de ser "relegado a ASP.NET Core 1.x", pero nada concreto en términos de características específicas que se necesitan en 2.x.

Una de las principales cosas que me gustan de combinar .NET Core y ASP.NET Core es que resuelve parte de la locura de las versiones y los nombres. Mucha gente ni siquiera sabe que ASP.NET Core se ejecuta en .NET Framework (incluso confunde a los recién llegados a la pila). Dicho esto, tenemos muchos clientes con muchas necesidades diferentes y escuchamos sus comentarios.

@mitos

Esperaba ansiosamente que .NET Standard 2.0 estuviera destinado a proporcionar el tan buscado área de superficie altamente compatible y la estabilidad que tanto necesitaba.

Claro, pero como dije, ASP.NET Core, .NET Core y .NET Standard en 1.x están completamente desacoplados. Puede usar cualquier biblioteca de .NET Standard en cualquier versión de .NET Core que la admita. Entonces, si .NET Core 2.0 es un nuevo LTS, aún podríamos declarar que ASP.NET Core 1.x es compatible con él.

@jahmai

Quiero pasar a netstandard2 en algún momento por algunas razones. Tendré que mover mi aplicación web a asp.net core 2 para eso, ¿verdad?

No, eso no está bien. Puede pasar a netstandard 2 cuando lo desee sin mover su aplicación web a ASP.NET Core 2.0.

La única razón por la que tenemos estas bibliotecas netstandard es porque necesitábamos portar nuestra enorme aplicación web (como mencioné anteriormente). Me gustaría no tener que expandir la base de código específica de nuestra plataforma para otras plataformas y, en cambio, seguir ascendiendo en la cadena netstandard. Realmente no quiero quedarme atrapado en netstandard 1.3 porque no hay una ruta para pasar a asp.net core 2.

No necesita estar atascado en netstandard 1.3. Las 2 cosas no están relacionadas.

Cuando la versión 1 lo admite pero la versión 2 no, pero _con suerte lo hará algún día_, es una apuesta realmente mala...

Este creo que es el quid de la cuestión. Hemos recibido comentarios de que _algunos_ de los vacíos ( DirectoryService , et. al.) se conocen y se abordarán. Necesitamos algo más concreto que eso.

Estoy de acuerdo con ASP.NET Core apuntando a .NET Core y con nosotros perdiendo el bote 2.0 si la hoja de ruta es clara sobre cuándo podemos esperar que se aborden estas brechas (y cuáles) (nuevamente, suponiendo que hay suficiente tiempo para portar antes 1.X deja de ser compatible).

Tal como están las cosas actualmente, el problema en el que estamos bloqueados para WCF ha estado estancado desde mayo de 2015 y es posible que nunca se aborde. Dejándonos efectivamente varados.

@davidfowl

No, eso no está bien. Puede pasar a netstandard 2 cuando lo desee sin mover su aplicación web a ASP.NET Core 2.0.

Excelente. En ese caso, mientras Microsoft se asegure de que 1.x es compatible (todo tipo de correcciones de errores y soporte operativo) hasta que ofrezca a los clientes una ruta de migración 2.x adecuada (por ejemplo, SignalR), me siento cómodo esperando mi momento hasta que necesita asp.net core 2.

Simplemente significa que debe permanecer en 1.x hasta que todas sus dependencias sean portadas, ¿no?

Correcto, pero eso tiene que ser un marco de tiempo conocido. No tenemos fechas, lo único que nos han dicho hasta ahora es "no en 2.0"... así que eso no es bueno. Por ejemplo, System.DirectoryServices se ha solicitado desde mediados de 2015 y todavía falta, pero a menudo se repite como el más buscado por los usuarios (seguido de System.Drawing ). Decir que estamos llevando .NET Standard 2.0 a una paridad de API de ~60 %, pero que faltan los bits que los usuarios han pedido, sin duda envía señales contradictorias sobre lo que es importante.

Todas sus quejas se refieren a cosas que faltan en .NET Core en lugar de ASP.NET Core.

Eso es incorrecto. Necesito los bits que necesitamos para ejecutar (por ejemplo, autenticación de AD) en una plataforma compatible. Lo que falta es el apoyo de este último. El soporte para 1.x es sin duda mi principal preocupación. No tenemos un camino a seguir respaldado ni ningún cronograma para cuándo podemos esperar uno.

Creo que estaríamos teniendo exactamente la misma discusión en un año.

No creo que ese sea el caso. El problema es que no pudimos portar hoy . Las API no están allí. Siempre que no haya un punto único en el tiempo que pudiéramos portar, las discusiones sobre el futuro son un poco discutibles. Esperaría que la compatibilidad con el marco completo de .NET en ASP.NET Core quedara obsoleta una vez que hubiera paridad y la mayoría de los usuarios pudieran cambiar. Y espero que ese lanzamiento tenga un marco de tiempo de soporte prolongado para que la gente se cambie.

Si DirectoryServices, Drawing, etc. vienen en 2.x, entonces genial. Esa versión debe ser compatible con .NET Framework y ser una versión LTS. Y 3.x debería eliminar el soporte completo del marco.

Una de las principales cosas que me gustan de combinar .NET Core y ASP.NET Core es que resuelve parte de la locura de las versiones y los nombres. Mucha gente ni siquiera sabe que ASP.NET Core se ejecuta en .NET Framework (incluso confunde a los recién llegados a la pila). Dicho esto, tenemos muchos clientes con muchas necesidades diferentes y escuchamos sus comentarios.

Está bien, pero toda la locura es secundaria a "¿funciona?". Actualmente, eso es un firme no. ASP.NET y .NET Core/Standard/lo que sea pueden ser 2 conjuntos de cosas dentro de Microsoft (y lo entiendo totalmente), pero para los desarrolladores sigue siendo 1 plataforma. El lado de ASP.NET necesita que las API sean útiles para muchos, y aún no están allí. Este movimiento reduce aún más las API disponibles. El equipo de ASP.NET puede obtener los que quiere, pero es a expensas de los que necesitamos.

@ctolkien @NickCraver

Este creo que es el quid de la cuestión. Hemos recibido comentarios de que algunas de las brechas (DirectoryService, et. al.) son conocidas y se abordarán. Necesitamos algo más concreto que eso.

Correcto, pero eso tiene que ser un marco de tiempo conocido. No tenemos fechas, lo único que nos han dicho hasta ahora es "no en 2.0"... así que eso no es bueno. Por ejemplo, System.DirectoryServices se ha solicitado desde mediados de 2015 y aún falta, pero a menudo se repite como el más buscado por los usuarios (seguido de System.Drawing).

Sin embargo, estas brechas están relacionadas con .NET Core y puedo entender la ansiedad de no saber cuándo estarán disponibles esas dependencias y es por eso que ayudarnos a priorizarlas sería bueno. La buena noticia es que netstandard 2.0 y netcoreapp2.0 hicieron trabajar en grupo para que otras bibliotecas fueran más fáciles de portar. Espero que una vez que lancemos la versión 2.0, será mucho más fácil abrir otras dependencias mediante la transferencia de franjas de código sobre nuestra base muy compatible.

¿Se ejecutará CSOM en netcore 2? Eso sería un gran obstáculo para nosotros y un área sobre la que no he oído nada.

@davidfowl Espero sinceramente que ese también sea el caso, pero no apuesto a nuestra empresa a ello. Dejar el soporte antes de que eso suceda, y no después, estoy totalmente en desacuerdo. Creo que esto que sucede en el marco de tiempo 3.x después de que esas API críticas para muchos consumidores estén en su lugar es totalmente válido. Hacerlo antes de que estén listos solo detiene nuestra adopción.

Estaba en el camino de adoptar 1.0 asumiendo que 2.x (o lo que sea que se haya desarrollado/arreglado activamente) admitiría el marco completo hasta que esas API críticas estuvieran listas (lo digo en serio, ya sabes cuánto trabajo he puesto en las bibliotecas ). Pero en este punto, no puedo hacer eso en Stack... fue una mala suposición. No puedo en buena conciencia decirle a nuestros equipos que usen .NET Core mientras el futuro de cualquier puerto sea tan incierto. Realmente desearía poder hacerlo, pero no vale la pena el riesgo y el dolor en este momento.

@NickCraver

Esperaría que la compatibilidad con el marco completo de .NET en ASP.NET Core quedara obsoleta una vez que hubiera paridad y la mayoría de los usuarios pudieran cambiar. Y espero que ese lanzamiento tenga un marco de tiempo de soporte prolongado para que la gente se cambie.

¿Cuál es la medida de "la mayoría de los usuarios" aquí? ¿Cuál es la lista de dependencias que deben cubrirse hasta que podamos eliminar el soporte? Su lista es diferente de otros usuarios en esta lista. También espero que algunas personas digan para siempre o hasta que .NET Core alcance la paridad de .NET Framework (lo cual no es realista). Todavía planteo que ASP.NET Core 1.x es lo suficientemente bueno para ese propósito y deberíamos considerar extender el soporte hasta ese momento.

Eso es incorrecto. Necesito los bits que necesitamos para ejecutar (por ejemplo, autenticación de AD) en una plataforma compatible. Lo que falta es el apoyo de este último. El soporte para 1.x es sin duda mi principal preocupación. No tenemos un camino a seguir respaldado ni ningún cronograma para cuándo podemos esperar uno.

¿Qué componente de ASP.NET falta para este escenario? Cuando dice 1.x frente a 2.x, sería útil mencionar ASP.NET Core frente a .NET Core.

Si DirectoryServices, Drawing, etc. vienen en 2.x, entonces genial. Esa versión debe ser compatible con .NET Framework y ser una versión LTS. Y 3.x debería eliminar el soporte completo del marco.

Mencioné esto antes, ¿qué características de ASP.NET Core necesita que ASP.NET Core 1.x no sea suficiente para esto?

ASP.NET y .NET Core/Standard/lo que sea pueden ser 2 conjuntos de cosas dentro de Microsoft (y lo entiendo totalmente), pero para los desarrolladores sigue siendo 1 plataforma

De acuerdo, pero necesitamos aclarar el FUD en esta discusión para que podamos evaluar adecuadamente el impacto. ASP.NET Core 1.x apunta a .NET Standard 1.x (1.0 - 1.6) y .NET Framework 4.5.1. Esto significa que puede ejecutarse en cualquier plataforma que admita esas versiones de netstandard y .NET Framework. Significa que ASP.NET Core 1.x se ejecutará en .NET Core 2.0.

@smbecker

¿Se ejecutará CSOM en netcore 2? Eso sería un gran obstáculo para nosotros y un área sobre la que no he oído nada.

No tengo idea de qué es eso. ¿Es esto https://msdn.microsoft.com/en-us/library/ff798388.aspx? Si es así, no se realizó ningún trabajo para respaldarlo explícitamente. Es posible que solo funcione en función de la compatibilidad de .NET Framework en .NET Core 2.0, pero supongo que nunca se transferirá a .NET Core (solo en base a mis 5 minutos de mirarlo), pero podría estar equivocado.

¿Cuál es la medida de "la mayoría de los usuarios" aquí? ¿Cuál es la lista de dependencias que deben cubrirse hasta que podamos eliminar el soporte? Su lista es diferente de otros usuarios en esta lista. También espero que algunas personas digan para siempre o hasta que .NET Core alcance la paridad de .NET Framework (lo cual no es realista). Todavía planteo que ASP.NET Core 1.x es lo suficientemente bueno para ese propósito y deberíamos considerar extender el soporte hasta ese momento.

Comencemos con las principales API que faltan: esas son las que causan bloqueos para la mayoría de las personas. Para nosotros, eso es DiretoryServices, que es el número 1. Si eso ni siquiera está ahí, es una muy mala señal para la comunidad. Estoy de acuerdo en que las listas son diferentes, pero si ni siquiera incluimos el número 1 ...

¿Qué componente de ASP.NET falta para este escenario? Cuando dice 1.x frente a 2.x, sería útil mencionar ASP.NET Core frente a .NET Core.

Mencioné esto antes, ¿qué características de ASP.NET Core necesita que ASP.NET Core 1.x no sea suficiente para esto?

Me refiero a la compatibilidad con el último ASP.NET Core que admite Full Framework (y, por lo tanto, las bibliotecas que necesito). Espero que sea 2.x, ya que queremos módulos, páginas de afeitar, etc. Tenemos usos para muchas características de 2.x. Pero parece que nuestra única opción es 1.x en este punto. No podemos dar el salto de ASP.NET 5 a ASP.NET Core y del marco completo con todas nuestras bibliotecas de trabajo a netcoreapp en 1 movimiento. Es demasiado. Es demasiado costoso. Es demasiado arriesgado. Y ahora no estamos seguros si podemos hacer ese movimiento costoso y arriesgado dentro de una ventana de soporte. Esa es una mala situación, tan mala que es mejor no moverse (como están las cosas hoy). Creo que eso es realmente desafortunado.

¿Qué componente de ASP.NET falta para este escenario? Cuando dice 1.x frente a 2.x, sería útil mencionar ASP.NET Core frente a .NET Core.

• A menos que haya una manera de manejar la autenticación/consultas de AD a través de algún paquete Microsoft.Authentication.* NuGet, entonces eso es una gran cosa. Actualmente estoy en el mismo barco, pero como estoy ejecutando .NET Core 1.1 sobre .NET 462, podré lograrlo. Fuera de eso, ¿cómo podría consultar cualquier grupo de AD, metadatos a través de medios admitidos? Sin embargo, he visto en el repositorio de corefx que HAY mucho trabajo en System.DirectoryServices , así que al menos estoy contento con eso.

• System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter . Actualmente, solo puedo acceder a eso cuando ejecuto .NET Core sobre .NET Framework completo. Supongo que es más una cuestión de conveniencia, ya que todavía puedo usar DbDataReader / SqlDataReader .

Básicamente, necesito saber que habrá una garantía de ALGUNA forma compatible de manejar la autenticación AD mientras se usa ASP.NET Core 2.x, sin la necesidad de .NET Framework completo.

He estado pensando mucho en esto hoy y me doy cuenta de que mis preocupaciones son diferentes a las de la mayoría de los que están aquí (no es que esas preocupaciones no sean tan importantes, si no más).

Todavía estoy un poco atascado en el caso de uso de consumir paquetes ASP.NET Core en netstandard . Hasta este problema, había asumido (quizás erróneamente) que netstandard era el objetivo de facto para las bibliotecas. En otras palabras, el comportamiento previsto para los autores de bibliotecas sería apuntar a netstandard a menos que hubiera una razón necesaria y convincente para no hacerlo. Esto garantiza no solo la compatibilidad con Framework, sino también con otras plataformas como Xamarin y UWP. El trabajo en .NET Standard 2.0 parecía respaldar esto al intentar unificar el área superficial de la API de los diversos tiempos de ejecución en un objetivo común que no es necesario pensar en ello.

Para mí, este cambio indica algo diferente. Por supuesto, al final del día, ASP.NET Core es solo una biblioteca y tal vez tenga "razones necesarias y convincentes" para no admitir el área de superficie común netstandard . Pero también es una de las bibliotecas .NET desarrolladas por Microsoft más visibles y al decir "queremos lo último y lo mejor, así que vamos a dejar de admitir netstandard " indica a todos los demás desarrolladores de bibliotecas (o al menos menos a mí) que tal vez deberían dejar de esforzarse tanto para admitir netstandard y simplemente comenzar a apuntar al tiempo de ejecución de Core. ¿Por qué molestarse con todas esas cosas de compatibilidad cuando a Microsoft ni siquiera le importa tanto? .NET Core 4 vida. Y tal vez eso sea lo mejor: sin duda, es diferente de donde pensé que íbamos con múltiples tiempos de ejecución y un área de superficie de API en su mayoría unificada.

Esta preocupación se vuelve aún más profunda cuando se considera que ASP.NET Core contiene muchas, muchas bibliotecas que son útiles fuera del contexto de ASP.NET directamente. Tal vez fue un error suponer que alguna vez fueron destinados a usarse de forma aislada, pero sería una lástima terrible perderlos. Los autores de bibliotecas que deseen utilizarlos tendrán que decidir cambiar su propia orientación a .NET Core también o permanecer en netstandard y perder el acceso a ellos. Sospecho que muchos elegirán el primero, fragmentando aún más el soporte de la biblioteca para plataformas alternativas. Al menos si he entendido los comentarios aquí, apuntar a diferentes plataformas para las bibliotecas de soporte es demasiado difícil.

Finalmente, estoy algo (aunque un poco menos) preocupado por los comentarios aquí que tan pronto como sea posible se agregarán nuevas API a Core para rev junto con ASP.NET. En particular, es posible que esas nuevas API nunca lleguen a netstandard o .NET Framework. Ciertamente entiendo que puede haber algunas cosas emocionantes que se pueden hacer si se eliminan o aflojan las preocupaciones sobre el legado y la compatibilidad. Pero, para ser sincero, tengo la impresión de que el equipo de ASP.NET Core a menudo se adelanta. Eso no es necesariamente algo malo, pero también condujo a una serie de decisiones más amplias que tuvieron que ser revertidas. No puedo evitar preguntarme si esto, y la subsiguiente evolución rápida del tiempo de ejecución de Core, tendrán el resultado de fracturar en gran medida el conjunto de tiempos de ejecución con el tiempo (y de nuevo, no es solo Windows/Framework lo que se quedará atrás, hay también Xamarin, Mono, UWP, etc.).

Todo este hilo me ha llevado a reorientar mi comprensión del futuro de .NET en torno a .NET Core en lugar de netstandard . Tal vez estoy siendo extremo y eso se suavizará en las próximas semanas, o tal vez esa es incluso la posición prevista y todo es lo mejor; de cualquier manera, actualmente estoy tentado a salir y apuntar a .NET Core por mi cuenta. cosas y solo enfócate en eso en el futuro de todo lo que he leído aquí.

@NickCraver

Me refiero a la compatibilidad con el último ASP.NET Core que admite Full Framework (y, por lo tanto, las bibliotecas que necesito). Espero que sea 2.x, ya que queremos módulos, páginas de afeitar, etc. Tenemos usos para muchas características de 2.x.

Ahora mismo es 1.1.1 (no hay módulos en 2.0), Razor Pages es bueno, otro es SignalR. Esas son las 2 cosas que veo más dolorosas como parte de esto.

No podemos dar el salto de ASP.NET 5 a ASP.NET Core y de un marco completo con todas nuestras bibliotecas de trabajo a netcoreapp en 1 movimiento. Es demasiado. Es demasiado costoso. Es demasiado arriesgado. Y ahora no estamos seguros si podemos hacer ese movimiento costoso y arriesgado dentro de una ventana de soporte. Esa es una mala situación, tan mala que es mejor no moverse (como están las cosas hoy). Creo que eso es realmente desafortunado.

¿Sin embargo, lo es? El cambio de ASP.NET Core 1.x a 2.x o 3.x, suponiendo que sus dependencias hayan sido portadas, sería trivial. Si planea migrar a ASP.NET Core en general, migrar a 1.1 es un buen primer paso y no ahorrará ningún trabajo al evitarlo.

@snickler

Básicamente, necesito saber que habrá una garantía de ALGUNA forma compatible de manejar la autenticación AD mientras se usa ASP.NET Core 2.x, sin la necesidad de .NET Framework completo.

Hasta que System.DirectoryServices sea compatible con .NET Core, ¿hay alguna razón por la que no pueda usar ASP.NET Core 1.x en .NET Framework?

Hasta que System.DirectoryServices sea compatible con .NET Core, ¿hay alguna razón por la que no pueda usar ASP.NET Core 1.x en .NET Framework?

Eso es lo que estoy haciendo actualmente. Solo estoy esperando con la esperanza de no tener que preocuparme por .NET Framework si no es necesario. Actualmente, me restringe a mi máquina con Windows ya que el espacio de nombres System.DirectoryServices.AccountManagement no existe en Mono. En ese mismo sentido, ¿habrá System.DirectoryServices.AccountManagement disponible fuera de la restricción de Windows? Esa pequeña pieza me obliga a saltar entre máquinas mientras depuro mi proyecto MVC y mi aplicación Xamarin.iOS localmente.

Si planea migrar a ASP.NET Core en general, migrar a 1.1 es un buen primer paso y no ahorrará ningún trabajo al evitarlo.

Estoy totalmente de acuerdo, si supiéramos que el soporte estaba allí hasta que actualizáramos a otra plataforma que funcionara . En este momento, no sabemos cuándo estarán disponibles los bits necesarios en el mundo de .NET Core, por lo que establecer un límite de tiempo ahora y no saber cuándo llegarán esos bits más adelante es una promesa. Ese es el problema central. Si tenemos una versión compatible superpuesta que permita la portabilidad, estaría listo y feliz de invertir. Si se elimina el soporte antes de que las API estén allí, estamos saltando una brecha de fe, con una cantidad desconocida de pista.

Sigo haciendo referencia a DirectoryServices porque eso es lo que sé que no funciona en netcoreapp2.0 hoy. Por supuesto, habrá otras cosas que encontremos que caigan en el mismo barco. Necesitamos ASP.NET Core + full framework + soporte por varios años en alguna plataforma. Con 1.x, no obtenemos muchas ganancias, en realidad obtenemos muy pocas. El rendimiento no es un gran argumento ya que renderizamos páginas en ~18 ms y se ve eclipsado por el tiempo de transporte. 2.0 sin embargo, ofrece bastantes cosas buenas. Las páginas de Razor y la perspectiva de los complementos hacen que sea muy atractivo para migrar. Tanto como para ser justificable.

En este momento, no vale la pena pasarse a la única versión a la que se puede acceder con soporte (1.1.x con soporte más largo, es lo que espero después de leer este hilo). Básicamente sería mucho tiempo y esfuerzo para llegar a donde estamos hoy. 2.x al menos ofrece algunas mejoras decentes y bits que nos gustaría aprovechar. Ayudan a justificar el costo de la mudanza.

El rendimiento no es un gran argumento ya que renderizamos páginas en ~18ms

En una diatriba menor de OT, me gustaría saber cómo puede renderizar páginas en ~ 18ms @NickCraver . Eso es genial

@daveaglick

Todavía estoy un poco atascado en el caso de uso de consumir paquetes ASP.NET Core en netstandard. Hasta este problema, había asumido (quizás erróneamente) que netstandard era el objetivo de facto para las bibliotecas. En otras palabras, el comportamiento previsto para los autores de bibliotecas sería apuntar a netstandard a menos que hubiera una razón necesaria y convincente para no hacerlo. Esto garantiza no solo la compatibilidad con Framework, sino también con otras plataformas como Xamarin y UWP. El trabajo en .NET Standard 2.0 parecía respaldar esto al intentar unificar el área superficial de la API de los diversos tiempos de ejecución en un objetivo común que no es necesario pensar en ello.

Nada ha cambiado aquí. De hecho, muchas de nuestras bibliotecas que queremos ejecutar en otras plataformas siguen siendo netstandard. Si vuelves a leer algo de lo anterior:

• Microsoft.Extensions.* (Registro, DI, Configuración, proveedores de archivos, etc.)
• Marco de la entidad
• Clientes de SignalR (deben ejecutarse en .NET Framework, Xamarin, UWP, etc.).

.NET Standard es la forma de facto de escribir bibliotecas que se ejecutan en todas partes. Los autores de bibliotecas deben apuntar a netstandard siempre que sea posible para obtener el mayor alcance de la plataforma. Los autores de la biblioteca tienen que decidir si quieren tener alcance o no. Es por eso que bibliotecas como JSON.NET admiten netstandard1.x y .NET framework 2.0. Hacen un esfuerzo adicional para hacer que las cosas "simplemente funcionen", como @JamesNK mencionó anteriormente.

El alejamiento de ASP.NET Core de netstandard en algunos lugares es más una declaración de que estas API no están diseñadas para aplicaciones UWP y ciertamente no las probamos allí (como ejemplo). También trata de solidificar que .NET Core y ASP.NET Core son un solo producto que se versiona en conjunto (ya que tiene Core en el nombre). Con ASP.NET Core 1.x compatible con .NET Core y .NET Framework, ese mensaje estaba un poco borroso y causa confusión a muchas personas (especialmente a los nuevos desarrolladores) y lo hicimos para aliviar el problema de la brecha de la biblioteca.

Esta preocupación se vuelve aún más profunda cuando se considera que ASP.NET Core contiene muchas, muchas bibliotecas que son útiles fuera del contexto de ASP.NET directamente. Tal vez fue un error suponer que alguna vez fueron destinados a usarse de forma aislada, pero sería una lástima terrible perderlos. Los autores de bibliotecas que deseen utilizarlos tendrán que decidir cambiar su propia orientación a .NET Core también o permanecer en netstandard y perder el acceso a ellos. Sospecho que muchos elegirán el primero, fragmentando aún más el soporte de la biblioteca para plataformas alternativas. Al menos si he entendido los comentarios aquí, apuntar a diferentes plataformas para las bibliotecas de soporte es demasiado difícil.

Supongo que todavía son netstandard. ¿Cuáles no lo son?

No puedo evitar preguntarme si esto, y la subsiguiente evolución rápida del tiempo de ejecución de Core, tendrán el resultado de fracturar en gran medida el conjunto de tiempos de ejecución con el tiempo (y de nuevo, no es solo Windows/Framework lo que se quedará atrás, hay también Xamarin, Mono, UWP, etc.).

Creo que netstandard evolucionará, pero .NET Framework siempre será el último en obtener nuevas API (Xamarin y Mono son bastante rápidos para agregar cosas).

@snickler

Eso es lo que estoy haciendo actualmente. Solo estoy esperando con la esperanza de no tener que preocuparme por .NET Framework si no es necesario. Actualmente, me restringe a mi máquina Windows ya que el espacio de nombres System.DirectoryServices.AccountManagement no existe en Mono. En ese mismo sentido, ¿habrá System.DirectoryServices.AccountManagement disponible fuera de la restricción de Windows? Esa pequeña pieza me obliga a saltar entre máquinas mientras depuro mi proyecto MVC y mi aplicación Xamarin.iOS localmente.

Asegúrese de presentar problemas como ese en dotnet/corefx. Asumir que sus dependencias serán portadas (a menos que sea muy popular) es lo incorrecto.

@davidfowl Pregunta: Quiero archivar -> Nuevo proyecto con ASP.NET Core 2.0 y autenticar contra AD. ¿Será esto posible? Simplemente no puedo imaginar el envío de una plataforma de Microsoft sin la capacidad de hacer esto.

De acuerdo con todo, pero no veo cómo esta decisión afecta nada de lo que dijiste. Quiero todas esas mismas cosas

Al eliminar el soporte para .NET v4.x, eliminará una ruta de migración popular y fragmentará aún más el ecosistema .NET y evitará que muchos desarrolladores y organizaciones puedan adoptarlo, lo que reducirá el conjunto más amplio de conocimiento e inversión de la comunidad en ASP. NET Core, ya que muchos desarrolladores de .NET necesitarán admitir sus bases de código existentes de ASP.NET v4.x indefinidamente (en las que se les paga por trabajar a tiempo completo).

Cuanto menor sea la participación de mercado de .NET Core, menor será la prioridad para los mantenedores de bibliotecas para admitirlo y es probable que algunos nunca lo hagan si trabajan para una organización que ya no podrá considerar migrar a ASP.NET Core debido a esto, que a su vez afecta a cualquier otra persona dependiendo de sus paquetes, y así sucesivamente. Todos estos son efectos secundarios del aumento de la carga en la adopción de ASP.NET Core, al no tener una plataforma estable, garantías de soporte a largo plazo y ahora eliminando una ruta de migración popular.

Creo que todos aquí quieren que el ecosistema .NET prospere, pero parece que estamos en desacuerdo con el equipo de MS sobre la mejor manera de lograrlo, ya que creo firmemente que lanzar .NET v4.x tan temprano antes de una cantidad conocida, altamente compatible, La versión estable de LTS está disponible es un error que tendrá efectos perjudiciales en los años venideros.

@davidfowl Gracias, tu comentario ayuda mucho. Había deducido (aparentemente de forma incorrecta) que la mayoría/todas las bibliotecas de soporte se iban a mudar de netstandard como parte de este cambio. Uso bastantes y conozco a otros que también lo hacen, por lo que escuchar que no lo son es una buena noticia.

@NickCraver, ¿qué tipo de autenticación está usando contra AD hoy? OpenIdConnect, WsFed, NTLM, ¿otro?

@Tratcher AD auth, a través de DirectoryServices (necesitamos consultar la membresía del grupo, etc., los bits estándar)

@mythz Creo que es razonable y creo que extender la vida útil de soporte de ASP.NET Core 1.x sería suficiente para cubrir la mayoría de los casos.

Veo por qué tienes que tomar esta decisión en algún momento, pero yo también creo que es prematuro y sería más feliz con:

• ASP.NET Core 2.x es LTS y el último en admitir Full Framework (seguramente, dado que ya estábamos en la vista previa, no se ha ido demasiado) y SignalR también lo seguirá más adelante en el año, por lo que es el marco objetivo para dar el salto. de ASP.NET a ASP.NET Core
• 3.x eliminando la compatibilidad con Full Framework y se lanzará cuando se migren las principales dependencias

En mi opinión, simplemente extender el soporte para ASP.NET Core 1.1 no sería suficiente ya que esa plataforma no está lo suficientemente madura/adoptada como para ser un objetivo para muchas migraciones de ASP.NET (en mi caso, SignalR es el bloqueador).

Solo para el lulz, intenté usar EntityFramework 6, que he visto utilizado masivamente en las aplicaciones ASP.NET Core 1.0 en las que he trabajado, con las últimas compilaciones nocturnas de preview2 .NET Core. Adivina qué...

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

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

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

</Project>

Deje de fingir que los ensamblajes diseñados y compilados para el marco completo funcionarán sin problemas en .NET Core: los casos triviales (léase aplicaciones hola mundo) probablemente funcionarán, pero en muchos casos, terminará bloqueado por API faltantes o no funcionales .

Lo que es absolutamente terrible es que solo te darás cuenta de que no funciona en tiempo de ejecución. En algunos casos, ni siquiera será obvio en absoluto. Por ejemplo, SqlClient .NET Core no admite el registro de transacciones ambientales ni las transacciones distribuidas con TransactionScope : incluso si encuentra una forma de hacer que EF 6 funcione, sus TransactionScope no será efectivo en absoluto y sus llamadas DB no usarán el nivel de aislamiento que necesita.

Siento que es necesario agregar mis dos centavos aquí en cuanto a mis preocupaciones con este movimiento. Tenemos una aplicación de escritorio que es principalmente Windows Forms con algunas de las áreas más nuevas desarrolladas en WPF. Hay más de 15 años de esfuerzo en esa aplicación y llevará años alejarse completamente de WinForms. Ojalá no fuera así, pero lo es. Hemos estado trabajando para construir más modularidad en la base de código para que podamos consumir las capas de negocios y acceso a datos a través de una interfaz web más nueva y la aplicación WinForms existente. Tenía la intención de pasarme a ASP.NET Core para nuestra aplicación web más nueva muy pronto, pero como acabo de decir, tendré que consumir una gran mayoría de nuestro código base existente que apunta a .NET v4.6.x. Estoy seguro de que estamos usando System.Drawing y System.Security.Cryptography. También hacemos un uso intensivo de TransactionScope en las formas mencionadas anteriormente.

Tenía muchas ganas de obtener algunos de los beneficios de ASP.NET Core, como la capacidad de encapsular áreas de nuestra aplicación web en ensamblajes separados sin necesidad de depender de MEF para unirlo todo. Hay muchas razones adicionales, pero esa es la que lo hace realmente agradable. Sin embargo, si hago la transición de nuestra aplicación a ASP.NET Core, es probable que me quede atascado en 1.x en el futuro previsible porque tenemos que mantener la portabilidad en nuestro código de back-end con WinForms. Me he centrado principalmente en el producto web, por lo que no puedo decirles dónde nos estamos conectando a cosas como WMI, etc., y si afecta la cuestión de la portabilidad, pero sé que estamos dentro de nuestra base de código. Estamos en una fase realmente interesante en este momento y lo último que quiero hacer es desarrollar todas las versiones web de nuestras funciones en ASP.NET MVC 5 y acumular un montón de código heredado nuevo que deberá ser portado en algún momento. esfuerzo futuro.

Estoy seguro de que vamos a tener muchos usos que nos mantendrán alejados de apuntar a .NET Standard incluso si ya no usamos WinForms. Somos un socio de Microsoft y trabajamos directamente con Microsoft para nuestro producto de varias maneras, por lo que no quiero entrar en demasiados detalles sobre lo que hacemos aquí, pero me encantaría tener una discusión más privada con @ shanselman o @davidfowl si necesita más detalles sobre lo que estamos haciendo. También estaré en MS Build y podría reunirme y hablar con cualquiera de ustedes allí si están presentes.

Creo que no ha considerado a las empresas que usan su pila con este tipo de desafíos. Sin embargo, descargo de responsabilidad completo: tengo la intención de ejecutar el analizador de portabilidad mencionado anteriormente para ver dónde estamos realmente atascados debido a la necesidad de mantener esa portabilidad dentro de nuestra base de código. Con mucho gusto le proporcionaré una lista de las API de .NET Framework que fallan en esa verificación.

Muahaha. No sé si reír o llorar...

Aquí está el informe generado por la herramienta de análisis ApiPort para mi aplicación trivial EF 6 de 23 líneas que no funciona:

La compilación cruzada es una sobrecarga que debe equilibrarse con las necesidades del cliente y del producto. Es por eso que queremos recibir estos comentarios para poder definir de manera más concreta cómo se ve el panorama tanto para nuestros clientes como para nosotros a medida que continuamos con la evolución de ASP.NET Core.

Antes de abrir este problema, ¿hubo un proceso de retroalimentación?

Todos estamos hablando de marcos de tiempo y soporte para 1.1, pero el hecho de que ASP.NET Core va a eliminar el marco completo ha sido una gran sorpresa para mí.

Entendí que el marco central era un juego multiplataforma, un nuevo marco que se compone de un subconjunto del marco completo que no está acoplado a Windows. La versión 2.0 fue la que todos esperábamos, donde recuperamos la mayor parte de las API.

ASP.NET Core fue la comida para perros para este nuevo marco, un nuevo marco web que dependía de un área de superficie tan pequeña de las API del marco que podía ejecutarse en todas partes.

Esperaba que una vez que el marco central hiciera una paridad cercana con el marco completo, todas las API nuevas se agregarían a netstandard y eventualmente se convertirían en ambos marcos. Todos comenzaríamos a apuntar a netstandard y todo sería arcoíris y unicornios.

Ahora, para encontrar que ASP.NET ni siquiera será dogfood netstandard y será específico del marco, eh: /

@rohatsu

En mi opinión, simplemente extender el soporte para ASP.NET Core 1.1 no sería suficiente ya que esa plataforma no está lo suficientemente madura/adoptada como para ser un objetivo para muchas migraciones de ASP.NET (en mi caso, SignalR es el bloqueador).

¿Qué pasaría si SignalR funcionara en ASP.NET Core 1.x? ¿Qué más es inmaduro sobre la plataforma que necesita?

@millman82 Gracias por compartir eso. Parece que estaría atascado en la versión antes de que se elimine el soporte de .NET Framework por un tiempo. Por lo tanto, algunas de las sugerencias aquí donde mantenemos la compatibilidad con 2.x y 3.x lo descartarían, es posible que ni siquiera funcionen para usted. ¿Por qué no permanecer en ASP.NET Core 1.x? ¿Qué le falta que necesita en su puerto? ¿O es solo la preocupación la misma que la de @NickCraver (que 2.x no lo admita lo pone nervioso acerca de apostar por él).

@jkells

Esperaba que una vez que el marco central hiciera una paridad cercana con el marco completo, todas las API nuevas se agregarían a netstandard y eventualmente se convertirían en ambos marcos. Todos comenzaríamos a apuntar a netstandard y todo sería arcoíris y unicornios.

Eso no es descabellado, solo falta el componente de tiempo. Eventualmente lo hará en todo el marco que cada envío en su propio horario.

Ahora, para encontrar que ASP.NET ni siquiera será dogfood netstandard y será específico del marco, eh: /

Parte de él todavía apunta a netstandard como se mencionó varias veces en este hilo.

¿Por qué no permanecer en ASP.NET Core 1.x?

No puede: está fuera de soporte 1 año desde que cae 2.0 (suponiendo que 2.0 sea el próximo LTS).

@davidfowl Definitivamente es una gran parte de eso. También usamos OData y SignalR en nuestra aplicación web actual y eso debe estar en ASP.NET Core antes de que podamos cambiar. Sin embargo, lo único que no quiero que suceda es quedar atrapado en el limbo cuando se elimine el soporte para ASP.NET Core 1.x y no haya una ruta de migración con las partes del marco que estamos usando que actualmente no son compatibles. Preveo que ASP.NET Core reemplazará a ASP.NET al por mayor. Puede estar en algún lugar del camino, pero está llegando. Sabiendo que odiaría volver a escribir nuestra interfaz de usuario ahora en ASP.NET MVC 5 (tenemos algunas cosas allí ahora, pero es fácil de mover porque es pequeño) solo unos años más tarde volver a escribirlo en ASP.NET Core una vez que llegue el final de la vida útil de ASP.NET.

Podríamos estar preparándonos para quemarnos gravemente si esa ruta de migración no existe cuando llega el EOL de ASP.NET Core 1.x si se extiende en el ínterin si apuntamos a Core 1.x ahora. Probablemente podríamos navegar por algunos de ellos con microservicios, sin embargo, eso, por supuesto, tiene sus propias preocupaciones.

@ctolkien

No puede: está fuera de soporte 1 año desde que cae 2.0 (suponiendo que 2.0 sea el próximo LTS).

Suponga por un segundo que no está fuera de soporte cuando cae 2.0. ¿No es eso suficiente?

Sin embargo, lo único que no quiero que suceda es quedar atrapado en el limbo cuando se elimine el soporte para ASP.NET Core 1.x y no haya una ruta de migración con las partes del marco que estamos usando que actualmente no son compatibles.

Reemplace 1.x con 2.x en esa oración. ¿Crees que en un año se portarán todas tus dependencias?

Reemplace 1.x con 2.x en esa oración. ¿Crees que en un año se portarán todas tus dependencias?

No, en absoluto, sin embargo, esperaría que cuando ya no puedan apuntar a .NET Full lo sean. Entiendo por qué querría impulsar eso, pero no creo que pueda esperar que las empresas adopten algo que dejará de ser compatible sin medios para realizar la transición a una versión más nueva porque las dependencias que faltan no se han portado.

No creo que pueda esperar que las empresas adopten algo que dejará de ser compatible sin medios para realizar la transición a una versión más nueva porque las dependencias que faltan no se han portado.

¿Por qué se quedaría sin soporte? En mi mundo hipotético, seríamos compatibles con ASP.NET Core 1.x en .NET Framework durante más tiempo.

¿Por qué se quedaría sin soporte? En mi mundo hipotético, seríamos compatibles con ASP.NET Core 1.x en .NET Framework durante más tiempo.

Mi pregunta es cuanto tiempo mas? Además, ¿el equipo es lo suficientemente grande como para traer esas dependencias necesarias como SignalR y OData a ASP.NET Core 1.x y mantener el soporte hasta que todas esas dependencias faltantes hayan sido portadas? Parece que contrarresta los argumentos presentados anteriormente sobre por qué querría eliminar el soporte completo de .NET ahora. Pregunta honesta...

Mi pregunta es cuanto tiempo mas? Además, ¿el equipo es lo suficientemente grande como para traer esas dependencias necesarias como SignalR y OData a ASP.NET Core 1.x y mantener el soporte hasta que todas esas dependencias faltantes hayan sido portadas? Parece que contrarresta los argumentos presentados anteriormente sobre por qué querría eliminar el soporte completo de .NET ahora. Pregunta honesta...

Tiraré un número al azar, 3 años. El equipo de ASP.NET no posee la integración de Odata, el equipo de odata sí, por lo que no puedo responder por ellos. En cuanto a SignalR, creo que sería posible apuntar a ASP.NET Core 1.x.

El problema que veo es que cada persona tiene un conjunto diferente de "dependencias faltantes", lo que hace que sea imposible razonar acerca de cuándo está "bien" eliminar el soporte de .NET Framework para todos. También es probable que algunas de esas dependencias nunca se transfieran (como CSOM).
Por supuesto, al estar en el tren 1.x, obtendrá correcciones de errores y funciones menores, pero la mayor parte del trabajo aún estaría ocurriendo en la última versión principal de ASP.NET Core.

Además, nada de esto le impide usar .NET Core 2.0 o .NET Standard 2.0 con ASP.NET Core 1.x. Solo quiero asegurarme de que todos lo sepan porque esta constante de subprocesos combina ASP.NET Core con .NET Core (que es una de las razones por las que queremos apuntar solo a .NET Core).

El problema que veo es que cada persona tiene un conjunto diferente de "dependencias faltantes", lo que hace que sea imposible razonar acerca de cuándo está "bien" eliminar el soporte de .NET Framework para todos.

Involucrar al ecosistema para averiguar cuál es la lista (no, este número no es el lugar para hacerlo). Si es una dependencia propiedad de Microsoft, transfiérala. Si no es así, comuníquese con el propietario para informarle sobre los planes y ayudar con una guía de migración (si no hacen nada, no es culpa de Microsoft). En el tiempo que lleva pasar por este proceso, admita ASP.net core 1.x. No veo otra forma de lograr tus objetivos sin molestar a mucha gente. Esta es una gran cosa que se propone que necesita un alto nivel de cuidado y atención para hacer lo correcto.

Personalmente, creo que hay mucha más confusión en torno a .NET Framework, .NET Standard y .NET Core. Cuando vi que podía apuntar a .NET Framework, nunca dije: "pero esto es ASP.NET Core, ¿por qué puedo usar .NET Framework?". Las distinciones entre lo anterior son mucho más confusas para la mayoría de su base de clientes. Me encanta todo lo que está haciendo ASP.NET Core. También me encanta la dirección con .NET con respecto a la independencia de la plataforma. Solo creo que el dominio de la confusión se establece incorrectamente. Diría que la mayoría de su base de usuarios tendrá una cierta cantidad de código que no es portátil debido a la naturaleza de lo que está haciendo y las API a las que se dirige dentro del marco.

Mi preferencia sería trabajar hacia la paridad de API dentro de .NET Core y .NET Standard y .NET Framework. Además, averigüe cuál es el objetivo al que las personas deberían esforzarse. Como creo que se dijo anteriormente, quizás de una manera ligeramente diferente, .NET Standard se siente como un curita. Eventualmente, esperaría que .NET Core sea la única opción de "marco" y cuando eso suceda, .NET Framework y .NET Standard se quedarán en el camino. A mí, y creo que a la mayoría de los que han hablado desde el anuncio, nos gustaría poder seguir beneficiándonos del trabajo que está haciendo en el lado de ASP.NET Core sin tener la libertad de ejecutar su código en la parte superior. de ser eliminado.

Creo que los casos que se consideran excepcionales, como el mío, en el que dependo de cosas como WMI, no son tan excepcionales como el equipo puede pensar. Nuevamente, investigaré y veré lo que falta (aunque la publicación anterior que da resultados de portabilidad incorrectos me tiene un poco preocupado por la precisión) y con gusto se lo informaré en un medio más privado.

En pocas palabras, nos apasiona esto porque queremos usarlo.

Personalmente, creo que hay mucha más confusión en torno a .NET Framework, .NET Standard y .NET Core. Cuando vi que podía apuntar a .NET Framework, nunca dije: "pero esto es ASP.NET Core, ¿por qué puedo usar .NET Framework?". Las distinciones entre lo anterior son mucho más confusas para la mayoría de su base de clientes. Me encanta todo lo que está haciendo ASP.NET Core. También me encanta la dirección con .NET con respecto a la independencia de la plataforma. Solo creo que el dominio de la confusión se establece incorrectamente. Diría que la mayoría de su base de usuarios tendrá una cierta cantidad de código que no es portátil debido a la naturaleza de lo que está haciendo y las API a las que se dirige dentro del marco.

Tenemos muchos clientes y tenemos nuevos desarrolladores que nunca han visto .NET en su vida. Necesitamos atender a todos porque eso es lo que tratamos de hacer como Microsoft. Las personas que ejecutan .NET Framework saben, aman y entienden que funciona, así que asegúrese de comprender que ASP.NET Core se ejecuta en .NET Framework, pero como nuevo desarrollador que se acerca a la plataforma, espero no mencionarlo nunca, ya que enturbia la historia en comparación con algo como go o node (que tienen prácticamente 0 legado en este momento).

Mi preferencia sería trabajar hacia la paridad de API dentro de .NET Core y .NET Standard y .NET Framework. Además, averigüe cuál es el objetivo al que las personas deberían esforzarse. Como creo que se dijo anteriormente, quizás de una manera ligeramente diferente, .NET Standard se siente como un curita. Eventualmente, esperaría que .NET Core sea la única opción de "marco" y cuando eso suceda, .NET Framework y .NET Standard se quedarán en el camino. A mí, y creo que a la mayoría de los que han hablado desde el anuncio, nos gustaría poder seguir beneficiándonos del trabajo que está haciendo en el lado de ASP.NET Core sin tener la libertad de ejecutar su código en la parte superior. de ser eliminado.

Todas estas cosas suceden en paralelo. ASP.NET Core no deja de trabajar en funciones hasta que "todo" se transfiera a .NET Core desde .NET Framework. ASP.NET continuará innovando y aprovechando las API que están disponibles en .NET Core, ya que lo enviamos como parte de la misma caja.

Veo algunas ideas de tendencias en este hilo de:

• Quiero que admita .NET Framework para siempre.
• Quiero que admita .NET Framework hasta que se transfieran las dependencias que necesito para mi aplicación.
• Solo necesito 1 año más, será tiempo suficiente para dejar de admitir .NET Framework (ASP.NET Core 3.x).

También está el hecho de que no escribimos un anuncio (que es culpa nuestra) pero viene uno (lo prometo, culpo al fin de semana).

Tampoco sé cómo se ve la paridad de API para la mayoría de las personas aquí, supongo que es diferente para diferentes personas. .NET Framework es una tecnología empresarial sólida y confiable de más de 15 años vinculada a Windows.
.NET Core se creó para escribir microservicios multiplataforma livianos y modernos y ha ido evolucionando lentamente para ser más compatible, de modo que la migración de bibliotecas sea más fácil. Dicho esto, no sé qué significa acercarse a .NET Framework en términos de compatibilidad o si ese es un objetivo (originalmente no lo era). En algún momento, no podrá usar ASP.NET Core sobre .NET Framework y habrá alguna dependencia que no se puede reescribir y que no es compatible con .NET Core. Las aplicaciones deberán tener esto en cuenta cuando se diseñen con ASP.NET Core en mente (en un futuro cercano).

Con respecto a los proyectos en los que trabajo, un período mucho más largo de soporte para 1.1 sería una mitigación decente. Es poco probable que podamos eliminar las dependencias de netfx en 1 año, pero es mucho más probable con los +3 años que sugirió como testaferro. Sin embargo, sería muy bueno tener un lanzamiento en el que todo se juntara en el nivel 2.0 primero, ¡ese es el punto en el que se suponía que todo sería más fácil de portar! Solo hablo en nombre de una organización, pero "2.0 será una versión LTS; 3.0 eliminará netfx" sería básicamente lo de siempre para nosotros en lugar de una causa para FUD.

También me gustaría hacerme eco de lo que dijo @PureKrome acerca de apreciar este compromiso, ha sido una discusión muy informativa.

Sobre el tema de la paridad: anteriormente había asumido que .net core nunca se acercaría a los niveles de compatibilidad de .net framework, pero esto estaba bien porque asp .net core continuaría admitiendo ambos.

Creo que, como comunidad, básicamente usamos .net core para usar asp.net core, no por sus propios méritos. Como dijiste, son un producto, y había pensado en el core clr como una parte opcional de ese producto con ventajas e inconvenientes si se elegía.

Después de dormir sobre él por una noche -

Personalmente, creo que es una buena idea dejar atrás el antiguo marco .net y escribir el mejor marco web posible para el tiempo de ejecución moderno.

Pero sabe que definitivamente es arriesgado y podría perder algunos de sus clientes aquí en el camino (espero que no, pero realizo muchas consultas, y .NET Core está fuera del alcance de muchas empresas en este momento, esperemos que 2.0 cambia eso).

..y sí, la comunicación en torno a esto fue (como de costumbre) algo que puede mejorar (la versión más educada de esta oración para un alemán);)

+1

Personalmente, creo que es una buena idea dejar atrás el antiguo marco .net y escribir el mejor marco web posible para el tiempo de ejecución moderno.

Estoy totalmente de acuerdo. Mi esperanza era que esto hubiera sido un cambio gradual, por ejemplo, Kestrel eliminando el soporte primero para perf (queda el alojamiento basado en http.sys), luego mvc/* siguiendo para API y mejoras de funcionalidad mientras comienzan los esfuerzos de portabilidad/pruebas de compatibilidad para netstandard2.0.

Excelente. En ese caso, mientras Microsoft se asegure de que 1.x es compatible (todo tipo de correcciones de errores y soporte operativo) hasta que ofrezca a los clientes una ruta de migración 2.x adecuada (por ejemplo, SignalR), entonces me siento cómodo esperando mi momento. hasta que necesitemos asp.net core 2.

+1

capaz de portar solo a .NET Core (tal vez durante el desarrollo de ASP.NET Core en el marco completo, tomó algunas dependencias nuevas que nunca se portarán como ejemplo).

Totalmente de acuerdo.
Ahora mismo creo que es una buena decisión. Creo que, en escenarios ideales, necesitamos más de 1 año de soporte, no sé, tal vez 2 o 3 años, e información sobre lo que se portará, para la confianza de la comunidad.
Sin compatibilidad con .net 461.

@dasmulli

Estoy totalmente de acuerdo. Mi esperanza era que esto hubiera sido un cambio gradual, por ejemplo, Kestrel eliminando el soporte primero para perf (queda el alojamiento basado en http.sys), luego mvc/* siguiendo para API y mejoras de funcionalidad mientras comienzan los esfuerzos de portabilidad/pruebas de compatibilidad para netstandard2.0.

Ni siquiera ejecutamos pruebas de rendimiento en .NET Framework... Las pruebas de portabilidad y las mejoras a .NET Core y .NET Standard ocurrirán de todos modos, eso IMO no tiene nada que ver con si el soporte de .NET Framework se elimina o no. En todo caso, nos hace enfocarnos con láser en esos escenarios porque es el único objetivo.

@gulbanana

Sin embargo, sería muy bueno tener un lanzamiento en el que todo se juntara en el nivel 2.0 primero, ¡ese es el punto en el que se suponía que todo sería más fácil de portar! Solo hablo en nombre de una organización, pero "2.0 será una versión LTS; 3.0 eliminará netfx" sería básicamente lo de siempre para nosotros en lugar de una causa para FUD.

¿Por qué necesita ASP.NET Core 2.0 (olvídese de .NET Standard y .NET Core 2.0)?

En particular, no necesitamos las características de asp.net core 2.0. Me gustaría mucho tener los procesos de compilación más simples y la interoperabilidad que viene con la ola 2.0. ¿Asp.net core 1.1, si se ejecuta en netcoreapp2.0, podrá usar las bibliotecas netstandard2.0? ¿Se consideraría eso un escenario 'estándar' y compatible en lugar de algo que nadie prueba o presta atención?

Básicamente, si 1.1 se convirtió en LTS, me preocupa que los problemas se cierren dentro de dieciocho meses con 'bueno, puedes hacer esto usando las API 2.0'.

En particular, no necesitamos las características de asp.net core 2.0. Me gustaría mucho tener los procesos de compilación más simples y la interoperabilidad que viene con la ola 2.0. ¿Asp.net core 1.1, si se ejecuta en netcoreapp2.0, podrá usar las bibliotecas netstandard2.0? ¿Se consideraría eso un escenario 'estándar' y compatible en lugar de algo que nadie prueba o presta atención?

Por supuesto que funcionaría. Como he estado diciendo todo el tiempo, las 3 cosas están completamente desacopladas hoy. Aquí hay un proyecto de muestra que ejecuta ASP.NET Core 1.1 en .NET Core 2.0 usando una versión de las API System.Configuration que se han migrado a un paquete .NET Standard 2.0:

https://github.com/davidfowl/AspNetCore1OnNetCore2

Estaría más feliz de aceptar esto si hubiera una capa de interoperabilidad automática entre .NET Core y .NET Framework (no la actual que puede generar excepciones en el tiempo de ejecución, y no llamadas WebAPI internas hechas por sí mismo), una especie de contenedor ("¿WowNET"?) que nos obligaría a mantener el código dependiente de 4.6 en archivos .dll separados pero permitiría ejecutar el legado a costa del rendimiento (que en el caso de las aplicaciones LOB no es la principal preocupación). ¿Crees que esto sería técnicamente posible?

También me pregunto si este cambio significa que el marco completo en sí está llegando al final de su vida útil y no desempeñará ninguna otra función importante que la de ser un componente heredado una vez que la mayoría de las API se trasladen a .NET Standard.

Básicamente, si 1.1 se convirtió en LTS, me preocupa que los problemas se cierren dentro de dieciocho meses con 'bueno, puedes hacer esto usando las API 2.0'.

Eso siempre es una preocupación. La respuesta siempre es "depende". Las correcciones de errores se sopesan en consecuencia y es probable que las características importantes caigan en ese cubo la mayoría de las veces.

@rohatsu

Estaría más feliz de aceptar esto si hubiera una capa de interoperabilidad automática entre .NET Core y .NET Framework (no la actual que puede generar excepciones en el tiempo de ejecución, y no llamadas WebAPI internas hechas por sí mismo), una especie de contenedor ("¿WowNET"?) que nos obligaría a mantener el código dependiente de 4.6 en archivos .dll separados pero permitiría ejecutar el legado a costa del rendimiento (que en el caso de las aplicaciones LOB no es la principal preocupación). ¿Crees que esto sería técnicamente posible?

Algo así como https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root pero para .NET Core y .NET Framework. Hicimos algo muy similar cuando ASP.NET admitió Helios, una corrección de compatibilidad de .NET Framework que se usó para impulsar coreclr en IIS. Los trucos para que funcionara eran bastante feos, aunque era una combinación de COM y estructuras de paso al método Main a través de string[] args. Sin embargo, todo técnicamente factible. No estoy seguro de qué tipo de fidelidad esperaría, ya que no tienen el mismo tiempo de ejecución y no puede pasar objetos de un lado a otro. También estaría ejecutando 2 GC, 2 Jits toneladas más de dlls en el mismo proceso y no estoy seguro de lo que está ganando al hacer algo fuera del proceso.

También me pregunto si este cambio significa que el marco completo en sí está llegando al final de su vida útil y no desempeñará ninguna otra función importante que la de ser un componente heredado una vez que la mayoría de las API se trasladen a .NET Standard.

Lejos de. .NET Framework evoluciona y se envía al ritmo de Windows, ya que es un componente de Windows. Acabamos de lanzar .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/annunciando-the-net-framework-4-7/) también con un montón de características nuevas. El hecho es que .NET Core puede y se enviará más rápido porque no está vinculado a nada más, por lo que las API, las funciones de tiempo de ejecución, etc., aparecerán allí primero. No significa que las cosas finalmente no lleguen a .NET Standard y .NET Framework. Solo tomará más tiempo llegar allí. El hecho de que .NET Framework se actualice en el lugar es la razón por la que somos tan cuidadosos al trasladar los cambios. Cualquier cambio puede romper cualquier aplicación cuando una actualización se envía automáticamente a mil millones de máquinas 😉. Con .NET Core, el marco está en paralelo, por lo que las aplicaciones deben optar por la versión más reciente para obtener funciones o correcciones más nuevas. Hay mucha más libertad allí.

Solo para evaluar las bibliotecas net4x que tenemos actualmente en ASP.NET Core 1.x, eso no funcionaría en 2.0: EntityFramework 6. EFCore solo tiene muchas funciones faltantes que usamos (por ejemplo, enlaces de interceptación/ciclo de vida). Así que estamos atascados en EF6 por un tiempo.

Y según la publicación de @PinpointTownes , EF6 no funciona con la versión actual (en desarrollo) de ASP.NET Core 2.x.

@nphmuller , entonces seguiría usando ASP.NET Core 1.x hasta que se movieran más dependencias (no sé cuántas cosas necesita de EF Core y cuál es el estado).

@davidfowl Claro, si la ventana de soporte de ASP.NET Core 1.x no pasa durante ese tiempo.
La característica principal es la intercepción (ganchos de ciclo de vida). Otras características que faltan se pueden solucionar más fácilmente para nosotros. La intercepción está en su cartera de pedidos, pero no está vinculada a un lanzamiento. Y mi instinto me dice que no se implementará por un tiempo.

@gulbanana : Creo que, como comunidad, básicamente usamos .net core para usar asp.net core, no por sus propios méritos.

Habla por ti mismo. Hay varios de nosotros para quienes el principal beneficio de .NET Core es salir de Windows en el servidor.

Y, supongo, todos ustedes hippies sucios propietarios de Mac. 😝

@bradwilson Y, supongo, todos ustedes, sucios hippies propietarios de Mac.

Habla por ti mismo, algunos de nosotros no somos hippies ;P

Pero sí, escapar de Windows (o realmente, IIS y http.sys) es lo que quiero .NET Core junto con la implementación de xcopy, perf, etc.

Aislar el código antiguo en servicios separados o migrar a ASP.NET Core vale la pena por otras razones que no sean nuevas y brillantes.

@PinpointTownes es un error de referencia, ¿qué sucede si hace referencia a System.Configuration según https://github.com/aspnet/Home/issues/2022#issuecomment -299810945? EF6 dice que no tiene dependencias debido a que todo está en el antiguo paquete GAC/Full Framework

@benaadams y @PinpointTownes, la razón por la que falla es porque System.Configuration.ConfigurationManager no es el nombre de DLL que espera .NET Framework. No estoy seguro si el puerto de System.Configuration es válido.

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

Sí, poder ejecutar servidores que no sean de Windows es excelente y un gran atractivo... pero sin el núcleo de asp.net, ¿qué ejecutaría en ellos? Incluso Nancy para .net core se basa en asp.net core a través de kestrel, UseOwin(), etc.

Creé varios microservicios que no usan ASP.NET Core. Son cosas como procesos de trabajo que sondean una cola para hacer su trabajo.

¡Esto no es justo, seguimos las hojas de ruta, y no dijiste nada sobre eso antes!
Si dijo eso antes, no usaremos ASP.NET Core en nuestro proyecto porque necesitamos .NET 4.x Libs.
Nuestra planificación incluye la actualización de nuestros proyectos a ASP.NET Core 2 debido a las nuevas funcionalidades necesarias.
Necesitamos ASP.NET Core 2 para apuntar a .NET 4.x también. si no es posible, ¿qué pasa con el soporte de ASP.NET Core 1.x? ¿Está planeando agregarle todas las funcionalidades nuevas o simplemente corregir errores?

Nuestra planificación incluye la actualización de nuestros proyectos a ASP.NET Core 2 debido a las nuevas funcionalidades necesarias.

¿Cuáles?

@PinpointTownes es un error de referencia, ¿qué sucede si hace referencia a System.Configuration según #2022 (comentario)?

Agregar <Reference Include="System.Configuration" /> no tiene ningún efecto (es decir, se lanza la misma excepción), ya que parece que no se puede resolver desde el GAC (aunque no estoy seguro de que sea realmente sorprendente):

No estoy seguro si el puerto de System.Configuration es válido.

Entonces, la conclusión oficial es... ¿no puede usar una biblioteca escrita para .NET Framework 4.x en .NET Core si usa System.Configuration ?

@PinpointTownes Ni siquiera estoy seguro de que la versión de System.Configuration se envíe (la que está en el paquete). Tal vez lo sea, tal vez no lo sea (esa es una discusión para comenzar en corefx). Solo te estoy diciendo por qué tu muestra se rompió de la forma en que lo hizo.

agregando no tiene ningún efecto (es decir, se lanza la misma excepción), ya que parece que no se puede resolver desde el GAC (aunque no estoy seguro de que sea realmente sorprendente):

AFAIK, no hay soporte predeterminado para las referencias GAC en proyectos SDK. Consulte https://github.com/dotnet/sdk/issues/987#issuecomment -286307697 para ver cómo habilitarlo.

Entonces, la conclusión oficial es... ¿no puede usar una biblioteca escrita para .NET Framework 4.x en .NET Core si usa System.Configuration?

Mi conclusión es que debe abrir un problema en CoreFX con la muestra que proporcionó anteriormente.

@davidfowl gracias por responder
Algunas características y ayudantes necesarios en EF Core están planeados en 2.0, especialmente para mapear datos (mapeos de tipo autónomo)...
De todos modos, solo necesito tener una idea clara sobre la hoja de ruta de ASP.NET Core 1.x, nuestro equipo está confundido y preocupado.

Una cosa con la que estoy luchando personalmente es la "plataforma estable" frente a las "nuevas funciones". Por un lado, queremos que la plataforma sea estable, confiable y compatible; por otro lado, nadie quiere permanecer en 1.x porque no tiene las características de 2.x. ¿Existen funciones súper atractivas en ASP.NET Core 2.x que atraen a las personas en esa dirección o es solo el hecho de que tenemos más funciones que las que teníamos en 1.x (porque es nuevo y brillante)?

@davidfowl Creo que signlarR es una de esas características, al menos habría estado en mi proyecto anterior. Sin embargo, también creo que gran parte de la preocupación se debe a las ventanas de soporte relativamente cortas para 1.1 (¿2018?) también estar cubierto por parches que calmarían un poco a la gente.

También creo que vale la pena destacar aún más la compatibilidad con asp.net core 1.1 en .net core 2.0, le da a la gente (lo que pienso) una buena ruta de migración: asp.net 5 en 46 > asp.net core 1.x en 46 > asp.net core 1.x en .net core 2.0 > asp.net core 2 en .net core 2. Ese sería un camino que reduciría el riesgo que preocupa a mucha gente.

He estado siguiendo esto desde el primer día e incluso después de todas estas discusiones y aclaraciones (gracias @davidfowl ) siento que muchos de nosotros estamos siendo arrojados debajo del autobús.

Entiendo el razonamiento para dejar de usar Full/desktop .NET framework. Demonios, incluso estoy de acuerdo en que esa es la forma de potenciar ASP.NET, PERO no veo cómo se decide esto ahora en lugar de desde el principio.

Por supuesto, los clientes nos quejaríamos seriamente en ambos escenarios, pero prefiero estar en el "No puedo usar la nueva cosa brillante" que apostar por "Puedo usarla, invertir en migrar lentamente y reemplazar cuando sea posible" y simplemente descubre que es falso.

No veo cómo se está decidiendo esto ahora en lugar de desde el principio.

En una conjetura:

En .NET Core 1.x no podía ejecutar bibliotecas de marco completas, por lo que habría sido un descanso completo.

En .NET Core 2.x, puede ejecutar principalmente el marco completo y puede ejecutar las bibliotecas .NET Standard 1.x - 2.0, por lo que no es una interrupción importante.

Cualquier problema con la ejecución de bibliotecas Full Framework en .NET Core 2.0, probablemente debería archivarse en dotnet/corefx

Está claro que el escenario principal son las "aplicaciones web modernas en la nube", que a menudo no tienen muchas dependencias de terceros (o son "solo de código").

La mayor parte de la discusión hasta ahora se ha centrado en la disponibilidad de BCL, pero muchos de nosotros dependemos de componentes de terceros (integración de bajo nivel con subsistemas complejos de video, audio, por ejemplo...) que a menudo se retrasan en el panorama de .NET y casi siempre confiar en tecnologías de nivel inferior que probablemente no terminen siendo compatibles.

Con ASP.NET Core 1, estamos desarrollando nuestros servicios modernos, apuntando al estándar .NET para Libs y eligiendo implementar en Full .NET o .NET Core por dependencias de servicios.

Podría apostar por esto porque en el caso de encontrar características/componentes no admitidos, podríamos apuntar fácilmente a Full .NET. Y la apuesta estaba en la plataforma a largo plazo, ya que permanecer en Full .NET parece una decisión a evitar en unos años.

_En .NET Core 2.x, puede ejecutar principalmente el marco completo y puede ejecutar las bibliotecas .NET Standard 1.x - 2.0, por lo que no es una interrupción importante._

@benaadams Hay una gran diferencia entre poder usar la mayor parte de BCL y poder usar bibliotecas que se han creado para Full .NET (e internamente podrían usar funciones no compatibles en .NET Standard 2.0/type unification).

Supongo que esta decisión no tiene impacto en facilitar la migración a ASP.NET Core 2.0 desde ASP.NET 4.
Algunas de las aplicaciones que administro realmente podrían beneficiarse de una actualización a ASP.NET Core 2.0, pero dado que no hay compatibilidad con OWIN/Katana para ASP.NET Core, supongo que necesito migrar manualmente y eso es demasiado trabajo. @damianh sugirió algo similar en https://github.com/aspnet/AspNetKatana/issues/27

Estamos ejecutando en el marco completo porque necesitamos EF6 (para espacial) y servicios de directorio y estamos esperando SignalR propiamente dicho (actualmente usamos una versión no compatible pero funciona). Hace tiempo que no reviso ningún otro bloqueador, pero probablemente haya más.

Según tengo entendido, ahora se nos impedirá pasar a asp.net core 2.0 y recibir señales cuando salga.

Hemos estado en el camino desde dnx, RC1 a RC2 y project json a csproj y finalmente sentimos que estábamos fuera de peligro... ahora no tanto.

Puedo entender que este cambio llegue eventualmente, pero ¿es este realmente el momento de hacerlo cuando el núcleo de asp.net está tratando de ganar tracción? Además, mi intuición me dice que EF Core aún no está lo suficientemente maduro (y ciertamente no para el espacio) y cualquiera que apueste por el soporte en el núcleo está asumiendo más riesgos con respecto a la migración de bibliotecas ... parece que esperar otra versión para esta transición daría algo de estabilidad y una oportunidad para que EF Core y otros puertos se pongan al día sin mencionar la señal r en el marco completo.

Apuesto a que la mayor parte de la empresa está ejecutando asp.net core (que por cierto es excelente) en el marco completo y bien podría estar en una posición similar a la nuestra.

Dado este paso al tren rápido para ASP.NET Core, ¿eso significa que presentará una versión actual y LTS, y cuál será la duración del soporte en estas instancias?

Supongo que estoy en el caso afortunado en el que estoy trabajando en una solución nueva que no ha tenido requisitos para ejecutarse en netfx, _pero_ siempre fue bueno tenerlo si pudiera. Lo único que me bloquearía serían los servicios de Windows, a los que me dirijo a netfx, pero hay un plan para eso.

Siento que este cambio va en la dirección equivocada. Entiendo que algunas características son exclusivas del núcleo hasta que netstandard se ponga al día. Pero seguir esta ruta solo del núcleo es una pendiente resbaladiza hacia la creación de un ecosistema fracturado.

Este cambio hace una declaración que no estoy seguro de que me guste: está bien apuntar solo a netcoreapp.

También quería escribir mi opinión.

Creo que es demasiado pronto para abandonar .net framework. No sé cuál es el problema de admitir .net framework + .net core juntos, pero creo que esta decisión hará que migrar a AspNet Core sea un poco más difícil. Porque algunas empresas piensan que: "Comencemos AspNet Core con .net core... si tenemos problemas serios (como una biblioteca imprescindible que no lo admita en el futuro) siempre podemos volver a .net framework". Pero ahora eso ya no será posible y las empresas dudarán en comenzar con AspNet Core. Además, esta decisión puede reducir el valor de .netstandard.

@hikalkan

Porque algunas empresas piensan que: "Comencemos AspNet Core con .net core... si tenemos problemas serios (como una biblioteca imprescindible que no lo admita en el futuro) siempre podemos volver a .net framework".

Aunque siempre puedes usar ASP.NET Core 1.1, ¿verdad?

Además, esta decisión puede reducir el valor de .netstandard.

No veo por qué ese sería el caso. Como dije antes, nuestras bibliotecas transversales todavía se dirigen a .NET Standard, así como a las API que deben funcionar en todas las implementaciones de .NET.

Claro, pueden usar asp.net core 1.1. Pero no es bueno decir: "La última versión de ASP.NET Core es 2.x, pero debe usar ASP.NET Core 1.x si desea apuntar a .net framework". Eso no es muy diferente a decir "usar MVC 5.x" :)

Creo que .net core es el futuro (no el futuro, ¡incluso es ahora!), pero es pronto para abandonar .net framework (la comunidad entenderá esta decisión como si .net framework estuviera obsoleto).

Aunque siempre puedes usar ASP.NET Core 1.1, ¿verdad?

no hay un beneficio claro. Primero, aún no está maduro, por lo que es una apuesta.
En segundo lugar, los desarrolladores de ASP.Net Core no querrán escribir en herramientas antiguas y quedarse atrás.
Estoy interesado en algunas cosas.

1. Trabajamos ya en proyecto greenfield completamente en ASP.Net Core, Dapper, etc.
   Pero en otros proyectos, nuestra lógica comercial está en 4.6 ensamblajes. Como leí anteriormente, no deberíamos tener problemas para hacer referencia a ellos. Espero haber entendido bien.
2. SignalR . Servicios de directorio, MS Orleans, Azure.
3. tal vez irrelevante con la conversación anterior, pero quiero alojar localmente un ASP.Net Core con Kestrel u otro HttpListener como aplicación de escritorio UWP o como puente de escritorio en UWP.

Tengo que decir que estoy bastante decepcionado con la comunicación sobre esto. Creo que podemos vivir con la decisión, pero salió de la nada.

En julio, mi equipo comenzará a trabajar en un proyecto nuevo de 12 a 18 meses que se ejecutará en ASP.NET Core 2.0 con todas las cosas interesantes sobre las que hemos estado leyendo durante años en .NET Core.

Sin embargo, mientras tanto, tenemos una aplicación ASP.NET MVC Core 1.0 que es el centro de nuestro producto heredado que esencialmente sirve como contenedor para llamar a las bibliotecas de .NET Framework.

Confirmé con el equipo que su plan era actualizar la aplicación a ASP.NET MVC Core 2.0 y hacer que se convirtiera en parte de la nueva aplicación a medida que intercambiamos los componentes de .NET Framework. Ahora estamos atascados con ASP.NET MVC Core 1.0, que terminará antes de que terminemos el proyecto.

Justo antes de emitir mi opinión, solo me gustaría tener claridad en una parte.
¿Estaría en lo correcto al suponer que si queremos continuar usando ASP.NET Core,
¿No podremos hacer referencia a los dll que se dirigen a .Net 4.5 o superior y hacer que funcionen como lo hacen actualmente?

@ louislewis2 No, eso no es correcto. Podrá usar las bibliotecas net45 - net461 , siempre que permanezcan dentro del espacio de API compatible para netstandard2.0 . No necesitará volver a compilar esas bibliotecas.

@bradwilson Gracias por la aclaración. Eso seguramente me hará dormir mejor esta noche.
Muchas de las bibliotecas no están bajo nuestro control, por lo que habría sido un gran problema.

Muy aliviado ahora :)

@shanselman @DamianEdwards @davidfowl Para su lista de elementos que usamos que aún no han sido portados, serían elementos en el dll system.management. Hacemos uso de los identificadores de hardware específicamente, esto se usa para la generación automática de enlaces para Azure Service Bus y todo nuestro paquete de cliente y servidor de licencias. Me imagino que si ellos no son la API actualmente, ¿nos causaría algunos problemas serios?

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

Este es nuestro mayor retraso que nos mantiene ejecutando algunas de nuestras aplicaciones en el marco completo.

Esto nos pone en una situación incómoda.

Estoy en medio de la migración de nuestros microservicios de ASP.Net 4.5 autohospedado en proceso sobre Kestrel (razones de compatibilidad heredadas), a ASP.Net Core 1.x totalmente autohospedado. Sin embargo, necesitamos ejecutar estas cosas en el marco completo, por ahora. Y hay buenas razones para ello.

Tenemos una serie de dependencias físicas de Windows que ya forman parte de nuestra infraestructura y no están sujetas a cambios. Eso incluye autenticación NTLM, registro de registro de eventos, etc. Si ASP.Net Core 2.x se está quedando sin soporte de netstandard, entonces es mejor que no lo haga en absoluto. El problema es que no hay ninguna alternativa de marco completo desarrollada activamente. Katana es muerta y lenta (en comparación).

Si alguien pudiera indicarme un servidor HTTP que sea tan rápido como Kestrel para .Net Framework, entonces claro. Pero eso no existe. Así que solo tengo que aceptar que ASP.Net está dejando atrás a los clientes de producción reales como yo con este cambio.

Si la pila necesita todas las novedades, como Pipelines y Span, entonces se deben proporcionar como bibliotecas estándar de red. ¿Qué API usa ASP.Net Core 2.x que están en netcoreapp2.0 que no están en netstandard2.0, y por qué esas API no pueden convertirse en bibliotecas de extensión netstandard2.0 mientras tanto?

¿Estamos diciendo en serio que MS pasó 2 años trabajando en un estándar (neto) en todos sus marcos solo para dar la vuelta y lanzar un producto insignia que no usa este estándar?

Creo que el equipo de GitHub agregará la función de paginación para la sección de problemas debido a este problema.

@mattnischan

Estoy en medio de la migración de nuestros microservicios de ASP.Net 4.5 autohospedado en proceso sobre Kestrel (razones de compatibilidad heredadas), a ASP.Net Core 1.x totalmente autohospedado. Sin embargo, necesitamos ejecutar estas cosas en el marco completo, por ahora. Y hay buenas razones para ello.

Puede seguir usando ASP.NET Core 1.x, ¿verdad?

Si la pila necesita todas las novedades, como Pipelines y Span, entonces se deben proporcionar como bibliotecas estándar de red. ¿Qué API usa ASP.Net Core 2.x que están en netcoreapp2.0 que no están en netstandard2.0, y por qué esas API no pueden convertirse en bibliotecas de extensión netstandard2.0 mientras tanto?

Cuando aparecen API en .NET Standard que no están en .NET Framework, ¿cómo las va a usar?

@stefan2410

Puede usar ASP.NET Core 1.x para eso, ¿verdad? ¿Qué funciones de ASP.NET Core 2.0 necesita? ¿Es solo SignalR?

Mantenga la aplicación tal como está durante los próximos dos años, pero cambie las bibliotecas de .NET Framework con su equivalente de .NET Core cuando termine. Esto mantendría nuestra lógica comercial, etc., compartida entre las dos aplicaciones.
No podemos hacer esto porque julio de 2018 es la fecha límite para la compatibilidad con ASP.NET MVC Core 1.0.

Una vez más, en mi mundo hipotético, extendemos la vida útil de 1.x

Actualice la aplicación a ASP.NET MVC Core 2.0 y haga que forme parte de la nueva aplicación a medida que intercambiamos los componentes de .NET Framework.
Tampoco podemos hacer esto, ya que Core 2.0 no es compatible con .NET Framework, por lo que es todo o nada.

¿Realmente necesita ASP.NET Core 2.0? ¿O solo .NET Core 2.0?

Cuando aparecen API en .NET Standard que no están en .NET Framework, ¿cómo las va a usar?

Nuestro plan era: esperar hasta que estén dentro. Dijiste antes que es solo cuestión de tiempo, ¿verdad? Retrasar el borde sangrante en una cantidad fija por el bien de la estabilidad hubiera estado bien. Mucho mejor que quedarse atrás permanentemente, al menos.

@davidfowl
Me moveré en ASP.Net core 2.0. No tengo otra solución. No puedo decirle al equipo que se quede atrás de la evolución, esperamos mucho tiempo el ASP.Net Core.
En la medida en que no tengamos problemas con nuestras referencias de ensamblajes de lógica empresarial 4.6.
Necesito SignalR, DirectoryServices, no problemas con las bibliotecas de Azure/Amazon, MS Orleans.
Tal vez también sea irrelevante con la conversación anterior, pero quiero que una aplicación de escritorio aloje localmente un ASP.Net Core con Kestrel/HttpListener como una aplicación de escritorio UWP o como un puente de escritorio en UWP.
No podemos reescribir el código para XAML y no me gustaría usar Electron.

Puede seguir usando ASP.NET Core 1.x, ¿verdad?

¿Para qué plazo? No puedo ver algo como Event Log llegando a netstandard.

Cuando aparecen API en .NET Standard que no están en .NET Framework, ¿cómo las va a usar?

¿Es esto una cosa? netstandard20 parece seguir ejecutándose en net461 según los documentos. ¿Está diciendo que la API bajo netstandard20 no es lo suficientemente completa para implementar las nuevas ventajas? ¿O hay algún plan para mover netstandard más allá del marco que aún no se ha divulgado?

Nuestro plan era: esperar hasta que estén dentro. Dijiste antes que es solo cuestión de tiempo, ¿verdad? Retrasar el borde sangrante en una cantidad fija por el bien de la estabilidad hubiera estado bien. Mucho mejor que quedarse atrás permanentemente, al menos.

Las bibliotecas se pueden escribir encima del estándar. Cuando las cosas en el estándar en sí necesitan cambiar, llevará mucho más tiempo adoptarlas en todas las implementaciones de .NET y eso incluye .NET Framework. Puede significar un par de cosas:

• .NET Standard evolucionará al ritmo de la implementación más lenta
• .NET Standard evolucionará a otro ritmo y .NET Framework será el último en ponerse al día.

Por supuesto, no significa que las bibliotecas no se puedan escribir en su contra, solo significa que esas advertencias deben tenerse en cuenta al elegir la versión de .NET Standard que desea admitir.

Tal vez también sea irrelevante con la conversación anterior, pero quiero que una aplicación de escritorio aloje localmente un ASP.Net Core con Kestrel/HttpListener como una aplicación de escritorio UWP o como un puente de escritorio en UWP.

ASP.NET Core en UWP no se encuentra actualmente en ninguna hoja de ruta, por lo que realmente no puedo decir qué sucederá aquí. Sin embargo HttpListener es parte de .NET Standard 2.0, por lo que tal vez exista la posibilidad de que funcione.

Quiero tomarme un momento para agradecer a todos por sus comentarios y comentarios aquí. Realmente lo apreciamos, así como su paciencia mientras descubrimos el camino a seguir. Tenga en cuenta que no teníamos la intención de que este cambio fuera tan difícil, tan tarde y sin previo aviso. La retrospectiva es 20/20 y si supiéramos lo que sabemos ahora, habríamos comunicado las cosas antes. Nos esforzaremos más para seguir adelante.

Tenemos un plan basado en los comentarios que recibimos aquí que quiero compartir con ustedes antes de publicarlo como un anuncio más adelante esta semana con el lanzamiento 2.0.0-preview1. Cuando eso suceda, abriremos una nueva edición para facilitar la discusión sobre ese plan, pero por ahora siga adelante y continúe compartiendo sus pensamientos y comentarios aquí:

• El soporte para ASP.NET Core 1.x en .NET Framework se extenderá por al menos otro año (hasta julio de 2019). Reevaluaremos esto anualmente y nos comprometemos a proporcionar un aviso de 12 meses antes de finalizar el soporte de ASP.NET Core 1.x (por lo tanto, en julio de 2018 anunciaremos si extenderemos por otros 12 meses hasta julio de 2020) ( Nota al margen: es ¿Alguien más se asustó por el hecho de que ya estamos hablando de 2020? ¿No? Ok, solo yo).
• El nuevo SignalR apuntará y será totalmente compatible con ASP.NET Core 1.x (disponible más adelante este año)
• Seguiremos actualizando ASP.NET Core 1.x para admitir nuevas versiones de idioma, etc., como lo hacemos con System.Web
• ASP.NET Core 1.x ejecutándose en .NET Core 1.x será compatible hasta julio de 2018 (sin cambios)
• Se admitirá ASP.NET Core 1.x que se ejecuta en .NET Core 2+ siempre que se admita ASP.NET Core 1.x en .NET Framework
  
  
  
  • Esto es para garantizar que siempre haya una superposición de un ASP.NET Core compatible en un .NET Core compatible mientras admitimos la ejecución en .NET Framework, lo que permite a los clientes migrar con el tiempo mientras permanecen en los bits compatibles.
  
  
• La compatibilidad con .NET Core 1.x (como tiempo de ejecución) no cambia. Finaliza en julio de 2018. Los clientes que ejecutan ASP.NET Core 1.x deben pasar a .NET Core 2.0 o estar en .NET Framework en ese momento (o pasar a ASP.NET Core 2.0 en .NET Core 2.0)
• Transferiremos System.DirectoryServices y System.Drawing a .NET Core este año (totalmente compatible, multiplataforma, vista previa para al menos Windows en verano)
• La lista de cosas para migrar a .NET Core después de eso actualmente incluye ServiceBase (para admitir .NET Core Windows Services). No hay una línea de tiempo más que la siguiente (las líneas de tiempo obviamente se vuelven más concretas a medida que avanzamos en la lista). Desarrollaremos esta lista a medida que avanzamos en función de los comentarios de los clientes.
• Actualmente no tenemos ningún plan para migrar System.ServiceModel (WCF del lado del servidor) a .NET Core. El WCF para .NET Core puede seguir mejorándose y se le pueden agregar funciones según los comentarios, por ejemplo, el cifrado de mensajes HTTP.

@DamianEdwards @davidfowl una gran parte del problema es que puede llevar meses de planificación y esfuerzo de desarrollo mientras se sacrifica un gran costo de oportunidad para comprometerse a migrar a ASP.NET Core, donde muchas organizaciones no podrán moverse de un lugar a otro. .NET 4.x, ya que es la única plataforma de la que pueden estar seguros que podrá ejecutar todas las dependencias de sus sistemas.

Hasta este punto, MS ha estado promocionando .NET Core agresivamente como el futuro de ASP.NET, donde no está claro si el desarrollo de ASP.NET 4.x se ha detenido y si todos los esfuerzos de desarrollo futuros se invertirán en ASP.NET Core, por lo que habrá muchas migraciones en curso para mantener sus sistemas actualizados. Muchas personas se sentirán como si hubieran sido arrojadas debajo de un autobús si, como resultado final de todos sus esfuerzos, han migrado efectivamente a una plataforma EOL'ed. Esto perjudicará tanto a las organizaciones como a los desarrolladores/consultores que fueron los principales defensores de iniciar el cambio a .NET Core. Es posible que ahora no necesiten nada de ASP.NET Core 2.0, pero definitivamente querrán tener algo de margen para sus sistemas y poder acceder a algunas funciones nuevas por todos sus esfuerzos.

Tampoco entiendo por qué el código "heredado" existente se considera una responsabilidad cuando, en mi opinión, debería considerarse uno de los mayores activos de .NET, .NET Core no sería tan atractivo si no pudiera ejecutar las bibliotecas .NET existentes. . Java sigue siendo tan fuerte debido al ecosistema masivo y estable de JVM, que es más importante que la debilidad inherente del lenguaje en sí.

No creo que MS haya comenzado a sentir la reacción negativa por la eliminación de la compatibilidad con .NET 4.x, que no se conocerá ampliamente hasta que se anuncie, espero que la mayoría de los desarrolladores aquí que siguen activamente el desarrollo en GitHub estén más interesados ​​​​en ver nuevas características entonces están en interoperabilidad y aseguran que haya una ruta de migración sin problemas para las bases de código existentes. Me sorprendería mucho, pero si no te molesta esta decisión después de que se anuncie, entonces podría ser la correcta, ya que tal vez no habrá tanta gente herida por ella.

¿Sería demasiado esfuerzo centrarse en una versión estable/compatible con ASP.NET Core 2.0 y luego anunciar el futuro exclusivo de .NET Core para las versiones posteriores? Parece que es lo más justo en esta situación dado que fue completamente imprevisto.

@DamianEdwards gracias por la actualización y un plan claro. No estoy de acuerdo con eso, pero aun así aprecio que lo expongas.

Todavía hay una gran brecha fundamental aquí. El puerto a 1.x es casi completamente lateral, hay pocas características para nosotros. 2.x es donde se encuentran algunas actualizaciones que valen la pena y todavía no tenemos garantía de que podamos hacer ese movimiento. Existe una gran posibilidad de que gastemos una cantidad significativa de tiempo, dinero y esfuerzo en migrar a 1.x solo para quedar atrapados allí debido a las dependencias completas del marco. No haré esa apuesta con nuestra empresa. Es posible que terminemos con menos soporte del que tenemos en ASP.NET 4.x ahora.

A menos que eso cambie, nuestras aplicaciones no harán el viaje a ASP.NET Core, y todas nuestras bibliotecas estarán mucho peor por la falta de pruebas internas.

Espero sinceramente que reconsideres esta decisión. Espero que algún día podamos hacer que Stack Overflow aproveche las miles de horas personales que hemos dedicado a ayudar a desarrollar la plataforma .NET Core.

@NickCraver

Existe una gran posibilidad de que gastemos una cantidad significativa de tiempo, dinero y esfuerzo en migrar a 1.x solo para quedar atrapados allí debido a las dependencias completas del marco.

A lo largo de este hilo, llamó a System.DirectoryServices como una de las cosas principales. Supongo que tiene algunas dependencias que cree que tardarán mucho en ser portadas o que nunca se portarán. Si 2.0 fuera compatible con .NET Framework, ¿se moverían esas dependencias en un año?

2.x es donde se encuentran algunas actualizaciones que valen la pena y todavía no tenemos garantía de que podamos hacer ese movimiento.

¿Cuáles? Sería bueno saberlo porque estábamos hablando de volver a portar algunas cosas de gran importancia a ASP.NET Core 1.1 para facilitar la transición.

A menos que eso cambie, nuestras aplicaciones no harán el viaje a ASP.NET Core, y todas nuestras bibliotecas estarán mucho peor por la falta de pruebas internas.

No sé nada sobre stackoverflow.com, pero ¿es posible dividir partes (no quiero decir "microservicios") para que ASP.NET Core pueda usarse para algunas partes?

@mitos

Esto perjudicará tanto a las organizaciones como a los desarrolladores/consultores que fueron los principales defensores de iniciar el cambio a .NET Core.

¿Quiso decir ASP.NET Core? ¿O .NET Core?

@davidfowl Me refiero a ASP.NET Core, pero también afecta a los desarrolladores que planeaban una migración por etapas desde ASP.NET Core/.NET 4.x primero y luego .NET Core.

Hablando de eso, noté que no hay bibliotecas en ASP.NET Core/.NET Core para manejar SAML. Tengo el requisito de manejar SSO a través de un IdP de terceros, pero no sé si eso será posible.

@davidfowl Quise decir ASP.NET Core, pero también afecta a los desarrolladores que planean una migración por etapas desde ASP.NET Core .NET 4.x primero y luego .NET Core.

No veo por qué ese sería el caso.

Creo que ese plan probablemente sería lo suficientemente justo para que mi organización evite mudarse de la plataforma. Lo principal es tener un período más largo con soporte (=parches de seguridad) durante el cual las dependencias de netfx restantes pueden reescribirse o eliminarse. Sin embargo, todo sigue siendo un poco arriesgado y conceptualmente extraño. ¿Qué sucede si dentro de tres años queremos crear un sitio web que pueda ingerir documentos de Excel o integrar un servidor web en una aplicación? ¿Qué sucede con otros marcos como Orleans que se construyen sobre el estándar en lugar de netcoreapp?

En serio, no entiendo por qué se hizo tanto trabajo en netstandard2.0 si nunca iba a ser lo suficientemente bueno para que ASP.NET Core realmente lo usara.

¿Qué sucede si dentro de tres años queremos construir un sitio web que pueda ingerir documentos de Excel?

Difícil de decir. No puedo hablar por los equipos que poseen eso, pero tal vez se transfiera a .NET Core y funcione entre plataformas.

o para incrustar un servidor web en una aplicación?

HttpListener es parte de netstandard 2.0.

¿Qué sucede con otros marcos como Orleans que se construyen sobre el estándar en lugar de netcoreapp?

Depende de los marcos decidir si quieren ejecutarse en .NET Framework, UWP, .NET Core, mono, etc. Es una elección. Orleans no incluye .NET Core. ASP.NET Core sí. Esos productos son uno y el mismo.

Lo que será una decisión difícil para nosotros (y nuestros clientes) no se trata de las bibliotecas que tengo hoy, sino de las bibliotecas que no sé si necesitaré dentro de 6 meses. Hay una gran cantidad de bibliotecas y marcos que aún no son compatibles netstandard . Por ejemplo, un mes después de un proyecto nos dimos cuenta de que necesitábamos algunas funciones en NHibernate que ni siquiera estaban cerca de EF6, y mucho menos de EF Core. Entonces, ¿cuál sería mi opción allí: apuntar a ASP.NET Core 1.x en .NET completo?

Parece que tengo algo de ApiPort en mi futuro.

Entonces, ¿cuál sería mi opción allí: apuntar a ASP.NET Core 1.x en .NET completo?

Si.

Difícil de decir. No puedo hablar por los equipos que poseen eso, pero tal vez se transfiera a .NET Core y funcione entre plataformas.

Correcto, pero seguramente está dentro del alcance del equipo de asp.net decidir si vale la pena proporcionar acceso a ese ecosistema de bibliotecas tal vez no portadas.

Correcto, pero seguramente está dentro del alcance del equipo de asp.net decidir si vale la pena proporcionar acceso a ese ecosistema de bibliotecas tal vez no portadas.

.NET es grande y antiguo, no hay manera de que no pueda esperar que el equipo de ASP.NET hable con todas las bibliotecas que existen en el ecosistema .NET. No es realista. Acabo de enterarme de lo que era CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) como parte de este hilo y dudo que se transfiera, pero no podría decirlo por Por supuesto.

Ampliar la compatibilidad con ASP.NET 1.1 en .NET Framework ayuda a mitigar esto un poco, pero creo que también ayuda porque será necesario aislar algunas dependencias para pasar correctamente a ASP.NET Core en .NET Core (que es el futuro previsto).

Dejaré de lado las bibliotecas ya que ese punto ya se ha discutido extensamente. En nuestro caso (amilia.com, SaaS de comercio electrónico), las herramientas de terceros ya son impresionantes, ni siquiera podemos ejecutar ASP.NET Core en el marco completo en este momento. Reconozco que esto no suena como una razón legítima, pero es una limitación con la que tenemos que lidiar.

En teoría, podríamos reemplazar esas herramientas (es decir, generadores de perfiles, monitoreo, compilación de servidores, etc.) con alternativas compatibles con .NET Core, pero eso es un par de meses de trabajo que preferiría dedicar a resolver problemas más urgentes. Con el tiempo, realizaremos la migración a ASP.NET Core/.NET Core, pero en este momento es un objetivo bastante cambiante.

Hasta este punto, se creó la expectativa de que ASP.NET Core podría seguir ejecutándose en el marco de escritorio y, por lo tanto, hablar de la amplitud de, etc., etc. No sé qué tipo de hojas de té se suponía que debíamos leer para saber. que eso no era realista :/

Como, para ser claros: la idea de que ASP.NET Core solo podría ejecutarse en .NET Core no es una locura en sí misma, pero nunca antes habíamos oído hablar de ella. Toda la información pública era que funcionaba bien en .NET Framework y no había indicios de que esto tuviera que cambiar.

.NET es grande y antiguo, no hay forma de que pueda esperar que el equipo de ASP.NET hable con todas las bibliotecas que existen en el ecosistema .NET. no es realista

¿No es esa una buena razón para seguir admitiendo .NET 4.x? La carga de la compatibilidad/interoperabilidad se puede contener en la plataforma .NET 4.x, que puede ser una solución de trabajo que podría aliviar a .NET Core de la necesidad de interoperar con librerías más antiguas y aliviar la presión para trasladar las bibliotecas .NET populares existentes a .NET Core ( para MS y autores externos).

@mitos

¿No es esa una buena razón para seguir admitiendo .NET 4.x? La carga de la compatibilidad/interoperabilidad se puede contener en la plataforma .NET 4.x, que puede ser una solución de trabajo que podría aliviar a .NET Core de la necesidad de interoperar con librerías más antiguas y aliviar la presión para trasladar las bibliotecas .NET populares existentes a .NET Core ( para MS y autores externos).

Es por eso que se ha extendido la vida útil de ASP.NET Core en 1.1 (aunque no de forma permanente). Nos aseguraremos de que SignalR funcione porque se declaró como una de las principales razones para usar ASP.NET Core 2.0. Al mismo tiempo, no es donde ASP.NET Core quiere estar a largo plazo. La intención siempre fue enviarse como parte de una plataforma .NET Core unificada.

@gulbanana

Hasta este punto, se creó la expectativa de que ASP.NET Core podría seguir ejecutándose en el marco de escritorio y, por lo tanto, hablar de la amplitud de, etc., etc. No sé qué tipo de hojas de té se suponía que debíamos leer para saber. que eso no era realista :/

Desafortunadamente, ASP.NET Core en .NET Framework nunca se comunicó como una solución temporal para facilitar la migración (eso es algo que notificamos muy mal). Nunca tuvo la intención de ser una plataforma compatible para siempre, lo cual es la conclusión lógica si se supusiera que algunas dependencias simplemente nunca se portarán.

Es por eso que se ha extendido la vida útil de ASP.NET Core en 1.1 (aunque no de forma permanente).

El problema es si eso es suficiente o no, la versión actual básicamente se ha agotado antes de que se haya entregado una versión compatible/estable.

No creo que se esté considerando el valor de las inversiones existentes, ¿quién va a querer hacer todo el esfuerzo para migrar a una plataforma EOL? Los desarrolladores trabajarán indefinidamente en sus sistemas brownfield existentes, básicamente se les dice que sus habilidades actuales de ASP.NET v4.x se volverán obsoletas y no podrán migrar al nuevo modelo de desarrollo de ASP.NET Core porque . NET 4.x se está eliminando y sería irresponsable que consideraran o recomendaran migrar a una plataforma sin salida.

@davidfowl

Desafortunadamente, ASP.NET Core en .NET Framework nunca se comunicó como una solución temporal para facilitar la migración (eso es algo que notificamos muy mal). Nunca tuvo la intención de ser una plataforma compatible para siempre, lo cual es la conclusión lógica si se supusiera que algunas dependencias simplemente nunca se portarán.

Los errores ocurren, eso está bien. El problema ahora es que muchas personas hicieron esta suposición y, por lo tanto, solo usan ASP.NET Core debido a su conclusión lógica pero errónea. Veremos cuántos, supongo :/

Esperé tanto asp.net core 2/ .net core 2, pero el resultado es muy deprimido.

@mitos

No creo que se esté considerando el valor de las inversiones existentes, ¿quién va a querer hacer todo el esfuerzo para migrar a una plataforma EOL?

¿No se puede hacer el mismo argumento acerca de que ASP.NET Core 2.0 será EOL en .NET Framework el próximo año cuando salga 3.0? Si dice que un año no es suficiente en ASP.NET Core 1.1, ¿por qué sugeriría que un año está bien en ASP.NET Core 2.0?

Los desarrolladores trabajarán indefinidamente en sus sistemas brownfield existentes, básicamente se les dice que sus habilidades actuales de ASP.NET v4.x se volverán obsoletas y no podrán migrar al nuevo modelo de desarrollo de ASP.NET Core porque . NET 4.x se está eliminando y sería irresponsable que consideraran o recomendaran migrar a una plataforma sin salida.

¿A quién se le dijo que las habilidades de ASP.NET 4.x se volverán obsoletas? En todo caso, esperamos que no lo sean. MVC, en particular, promociona la compatibilidad del concepto con algunas características nuevas. ASP.NET Core se parece mucho a Katana (y eso no es por error). Si está hablando de formularios web, ¿qué pasa con MVC?

No tengo ninguna experiencia en consultoría, pero estaría de acuerdo en que si las dependencias no están disponibles, estaría de acuerdo. O eso, o la aplicación necesita ser rediseñada para tener esto en cuenta.

@xyting , ¿puedes aclararlo?

@davidfowl

¿No se puede hacer el mismo argumento acerca de que ASP.NET Core 2.0 será EOL en .NET Framework el próximo año cuando salga 3.0? Si dice que un año no es suficiente en ASP.NET Core 1.1, ¿por qué sugeriría que un año está bien en ASP.NET Core 2.0?

Durante mucho tiempo supuse que ASP.NET Core 1.1 era solo una solución provisional para ASP.NET Core 2.0 y .NET Standard 2.0, que sería la versión LTS estable y centrada en la compatibilidad que cerrará la brecha con la mayoría de la funcionalidad principal que falta en .NET 4.x, hasta que este hilo básicamente destruyó esa suposición. Mantener la compatibilidad de .NET 4.x con ASP.NET Core 2.0 no es ideal, pero es mucho mejor que terminarlo en la versión actual que nadie esperaba.

¿A quién se le dijo que las habilidades de ASP.NET 4.x se volverán obsoletas? En todo caso, esperamos que no lo sean.

MS lo hace con todo su marketing agresivo en .NET Core con todos los nuevos anuncios y funciones aparentemente centrados en ASP.NET Core. ¿Se está desarrollando al aire libre el antiguo ASP.NET WebForms/MVC? ¿Qué proporción del esfuerzo de desarrollo se está invirtiendo en el antiguo ASP.NET WebForms/MVC frente a .NET Core? No tengo idea, todo lo que he visto recientemente, todos los standups semanales, los tutoriales en video parecen estar enfocados únicamente en ASP.NET Core. Sé que definitivamente no me sentiría cómodo iniciando nuevos proyectos nuevos utilizando la antigua tecnología ASP.NET WebForms o MVC.

Si espera que no sean MS, definitivamente debería comunicarlo mejor con hojas de ruta claras. Dado lo volátil que ha sido ASP.NET en los últimos años (este problema es un ejemplo perfecto), es imposible saber cuál es el futuro sin un compromiso y anuncio oficial.

¿Alguien más siente que hubiera sido mejor si la versión 1 nunca se ejecutara en el marco completo? No me lo esperaba por el nombre. Ahora que lo hace y lo he probado, me decepciona perderlo.

Entiendo de dónde vienes con esto, quieres iterar toda la pila lo más rápido posible. Está compitiendo con un montón de marcos web de campos verdes que controlan toda la pila y no tienen equipaje que arrastrar. Dejar caer el equipaje de System.Web es una de las razones principales por las que ASP.NET Core es tan emocionante.

Habiendo dormido sobre él, puedo decir que nuestro uso estará bien, las dependencias que necesitamos deberían funcionar todas en 2.0.

Al mismo tiempo, no es donde ASP.NET Core quiere estar a largo plazo. La intención siempre fue enviarse como parte de una plataforma .NET Core unificada.

Si bien no hace falta ser un psíquico para darse cuenta de que .NET Core es la plataforma del futuro de .NET... si la intención desde el principio (o como dices "siempre") fue combinar ASP.NET Core con . NET core, eso definitivamente no se comunicó en ningún medio que haya visto.

Literalmente he visto cada minuto de cada standup de ASP.NET (incluidos Hanselman y Glenn resolviendo problemas de Docker durante 3 horas... porque no tengo vida), leo los blogs, siempre estoy en Twitter, voy a Más de 2 conferencias al año, asistir a grupos de usuarios, etc. y nunca escuché que eso se comunicara como la intención de ASP.NET Core. En cambio, he escuchado una y otra vez "funciona en ambas plataformas" y, con razón, las personas sienten que alguien les quitó la silla de debajo. Incluso he dado charlas sobre ASP.NET Core y he dicho "se ejecuta en ambas plataformas", y ahora me siento culpable por cualquier persona a la que haya llevado por este camino. Diría que es probable que la gente de ITT esté a la vanguardia y que sea la que más acepte este tipo de noticias, y hay muchas reacciones violentas aquí. Parece que esto solo empeorará a medida que esta noticia llegue a los desarrolladores y sus gerentes que no están tan conectados y probablemente sean más conservadores que los de ITT.

Además de la falta de comunicación y la falta de soporte para algunos escenarios, creo que gran parte de la reacción se debe solo al momento de este anuncio. .NET Core 2 ni siquiera tiene RTM todavía y ya se ha considerado el único camino a largo plazo, y esencialmente se ha puesto una bomba de relojería en Full Framework para ASP.NET Core. Creo que muchos de nuestros miedos podrían aclararse una vez que tengamos algo tangible con lo que jugar además de las veladas nocturnas.

Realmente creo que debe haber una mejor experiencia de herramientas que "ejecutarlo y ver si funciona" al hacer referencia a net461+ libs de .NET Core 2+ en VS, porque ya puedo ver el mensaje de "probablemente podamos ejecutar la mayoría de ¡Sus 461+ asambleas también!" será comercializado hasta la muerte. Algo que podría analizar las API faltantes de lo que hicimos referencia, proporcionando errores de tiempo de compilación, idealmente incluso sugiriendo nupkgs de compatibilidad si existen (como System.Configuration en el ejemplo de EF6 anterior... y hacer que funcione :smile :). Obviamente, no todo se puede analizar en tiempo de compilación (el escenario de transacción distribuida mencionado anteriormente viene a la mente como algo difícil de analizar antes de tiempo), pero cuanto más se pueda, mejor. Algo parecido a lo que Immo hizo aquí por PlatformNotSupportedException y las API de net461 que faltan para netstandard2 estaría bien.

Sólo mis 2 centavos. Espero estar exagerando. En última instancia, muchos de nosotros simplemente estamos decepcionados, porque amamos ASP.NET Core y no queremos que nada se interponga en nuestra forma de usarlo. ❤️

Uniendo mi voz a las preocupaciones ya enumeradas, estamos comenzando un nuevo proyecto ASP.NET MVC el próximo mes y será .NET Framework simple con ASP.NET MVC, porque el cliente no confía en que Microsoft haga lo correcto con respecto a planificación a largo plazo.

La organización del cliente aún usa implementaciones de Windows 7 y este proyecto es una excepción, porque la mayoría de sus proyectos web se realizan en UNIX con Java, y .NET se usa principalmente en aplicaciones de escritorio.

Este tipo de incertidumbre simplemente se suma a la historia rota que fueron la pila .NET de Windows 8 y UWP, lo que aumenta el interés del CTO de la organización para buscar alternativas más estables al futuro de .NET.

Si está obligando a este tipo de organizaciones a escribir módulos desde cero para trabajar en ASP.NET Core, también puedo aconsejar a nuestros clientes que adopten algo con hojas de ruta más estables, en lugar de perder la cara por problemas que no puedo controlar.

@davidfowl Puede ser que este cambio funcione bien para el 99% de los proyectos. Pero se vendió como "funciona en ambas plataformas" y "puede usarlo con el marco completo si es necesario". Todos sabían que la versión de marco completo de asp.net core era para los proyectos que no podían migrar, y eso estaba bien. Y la gente planeó con eso en mente.

Es posible que este cambio no sea el peor en términos de código, pero lo más probable es que cree una gran tormenta de mierda cuando los desarrolladores más regulares vean las noticias. Y no se tratará del código, se tratará de lo prometido. Y la promesa era "ejecutar net o core, y netstandard para combinarlos todos".

@DamianEdwards @davidfowl Gracias por compartir el plan.

SignalR en 1.x es un gran alivio para reemplazar nuestra versión no compatible y también la noticia de que ServiceBase es el siguiente en la lista, ya que actualmente también lo estamos usando.

Sin embargo, dependemos en gran medida de EF6 y espacial, por lo que estaremos atascados en 1.x hasta que tenga el conjunto de características que necesitamos...

Sin embargo, en una nota al margen semidivertida, esto finalmente puede forzar una implementación de más microservicios para esto. Sin embargo, no esperaré explicar por qué nuestros clientes de LOB necesitan tener varias API más instaladas en IIS para que nuestros productos funcionen...

Realmente desearía que esto pudiera retrasarse, ya que parece ser demasiado pronto y, como varias personas han mencionado, esto generará una reacción negativa significativa cuando se publique la publicación del blog.

También debo decir que me siento un poco vendido cuando desde el principio el sentimiento ha sido que esto se ejecutará en el marco completo y he estado predicando lo mismo a los colegas. Sin embargo, explica la confusa elección de nombres de asp.net core.

@shanselman @davidfowl Mi mayor problema es NHibernate. Incluso después del lanzamiento de EF Core, sigue siendo el único mapeador O/R con todas las funciones más avanzado.

@shanselman @DamianEdwards Estoy en el proceso de empezar a pensar en actualizar un sitio de ASP.NET MVC 4 a la última versión (no sé si es 5 o una). Todavía necesito ejecutar el marco completo de .NET porque estoy haciendo referencia a las bibliotecas SyncFusion y Telerik. SyncFusion para mostrar archivos PDF y Telerik para generar archivos Word .docx. Como otros han señalado, simplemente no es razonable que la estrategia de Microsoft para lidiar con esto sea "pruébelo y vea si funciona". No puedo garantizar que todo vaya a funcionar en producción porque es una base de código muy grande de código de terceros.

Si bien el soporte de SyncFusion es generalmente muy bueno, el soporte de Telerik no lo es y me sorprendería si pudieran hacerlo funcionar con .net core. No tengo idea de qué Apis podrían estar usando que no sean compatibles con .net core, y como usuario final ese es el punto central del producto de terceros, simplemente lo conecto y hace lo que debe hacer.

Francamente, para un cliente que no se ocupa de las cosas con mucha frecuencia (principalmente hago WPF), todo esto es extraordinariamente confuso. Hay demasiadas versiones diferentes, con varias incompatibilidades. Como alguien ha señalado, es un poco como UWP XAML: similar pero completamente incompatible con WPF XAML.

No es bueno para los desarrolladores y solo otra cosa que hace que los desarrolladores pierdan la confianza en Microsoft (una de muchas en los últimos años). Me parece que ASP.NET definitivamente debería ejecutarse en el marco completo de .net, porque hay una gran biblioteca de herramientas que las personas pueden necesitar usar en su servidor. En mi caso, puedo actualizar fácilmente a una versión posterior de .net framework si lo necesito para usar las últimas novedades de ASP.net si se requiere una actualización para la nueva funcionalidad de ASP.net.

Cualquier mensaje que se envíe a los desarrolladores debe ser mucho más claro, antes de que las personas simplemente abandonen el barco por completo.

... Stefan

Desafortunadamente, ASP.NET Core en .NET Framework nunca se comunicó como una solución temporal para facilitar la migración (eso es algo que notificamos muy mal). Nunca tuvo la intención de ser una plataforma compatible para siempre, lo cual es la conclusión lógica si se supusiera que algunas dependencias simplemente nunca se portarán.

Personalmente, no tengo ningún problema con los cambios enumerados en este problema, entiendo el razonamiento y tienen sentido, ahora que he leído muchas respuestas aquí. Sin embargo, lo que acaba de decir destaca cuál es, en última instancia, el quid de la cuestión: la mala comunicación de Microsoft en su conjunto (lo cual aprecio que no sea culpa suya ni de ninguna persona _específica_).

Tal vez me estoy perdiendo algo, pero hay más en "desarrollar abiertamente" que simplemente tener el código en github para que todos lo exploren y jueguen. Este mismo problema se creó porque un día apareció un cambio en el código que tomó a la gente por sorpresa, pero obviamente usted y todos en el equipo de .net lo sabían y lo entendían, por lo que tardó mucho en llegar. El problema es que el resto de nosotros, simples mortales, estábamos completamente ciegos.

Peor aún, sospecho que la mayoría de los desarrolladores no prestan demasiada atención a github para obtener su conocimiento e información, por lo que este cambio sorprenderá a muchas más personas de las que ya están comentando aquí. Solo descubrí este problema porque apareció en mi fuente RSS de noticias de hackers, que no es lo que yo llamaría mi principal fuente de noticias e información.

Cualquiera que siga las publicaciones del blog en MSDN sabrá que 2.0 está por llegar y lo verán como el santo grial para cerrar la brecha entre el núcleo de asp.net y todo lo que "faltaba" anteriormente, pero desconocen por completo lo que es esencialmente un cambio radical para ciertos flujos de trabajo. Ha habido muy pocos detalles sobre lo que realmente está sucediendo con el diseño de asp.net core 2.0. Sospecho que habrá más detalles más adelante esta semana en Build? Uno solo puede esperar.

El .net slack es otro recurso de información, pero es un poco ruidoso mantenerse al día con lo que realmente sucede. Es genial para involucrar a los desarrolladores y hacer preguntas, pero difícilmente es una fuente de noticias.

Twitter y las redes sociales son otra fuente de información, pero nuevamente un poco como este problema de github cuando aparece allí, generalmente se debe a que alguien expresó su preocupación con una decisión que ya se tomó y tomó a la gente por sorpresa.

Esta tampoco es la primera vez que tenemos este problema exacto. ¿Recuerdas el fiasco causado por volver a cambiar a csproj? No quiero entrar en los debates sobre ese cambio, pero es otro ejemplo de un cambio que sucedió para sorpresa de la gente, que fue tan mal comunicado que hasta el día de hoy, muchas personas simplemente no se dan cuenta de que no es lo mismo. csproj de los "malos viejos tiempos".

No estoy completamente seguro de lo que estoy tratando de sugerir aquí, pero definitivamente hay algo que "falta" en el desarrollo abierto de .net. Microsoft hace un gran trabajo al proporcionar recursos y documentación para desarrolladores, pero solo para productos terminados y cosas que se han enviado. La hoja de ruta, las reuniones de planificación, todo lo que llega a decidir el diseño y la dirección de los marcos parece hacerse a puerta cerrada, con la mención ocasional de "socios selectos" y cosas por el estilo. No digo que todas las reuniones deban transmitirse por streaming en todo el mundo, pero definitivamente podría haber un mejor término medio mediante el cual las decisiones que se toman y las razones detrás de ellas se comunican lo antes posible a la comunidad, de una manera que sea fácil. para aquellos de nosotros que realmente _queremos_ seguir para digerir y estar al tanto. Tal vez un blog dedicado en MSDN (o en otro lugar) que se actualice regularmente cuando se tomen esas decisiones.

Uno de mis mayores problemas con esto es que en casi todas las conferencias del último año que se presentó ASP.NET Core, lo presentó con una diapositiva que muestra el núcleo de asp.net ejecutándose tanto en .net framework como en .net core, simplemente eche un vistazo a esto: Explore el desarrollo web con Microsoft ASP.NET Core 1.0 de Ignite el año pasado. Aproximadamente a las 7.50, verá la diapositiva.

Los mayores obstáculos para mí son System.DirectoryServices, ServiceBase, EF6 (EF Core no está listo), ClosedXML (para crear hojas de Excel).

El soporte para ASP.NET Core 1.x en .NET Framework se extenderá por al menos otro año (hasta julio de 2019). Reevaluaremos esto anualmente y nos comprometemos a proporcionar un aviso de 12 meses antes de finalizar el soporte de ASP.NET Core 1.x (por lo tanto, para julio de 2018 anunciaremos si extenderemos por otros 12 meses hasta julio de 2020) (Nota al margen: es ¿Alguien más se asustó por el hecho de que ya estamos hablando de 2020? ¿No? Ok, solo yo).

@DamianEdwards Gracias por el anuncio.

En este momento, nuestra empresa está desarrollando aplicaciones empresariales para varios clientes que utilizan ASP.NET Core 1.1 en .NET Framework 4.6.2. Escuchar que el soporte para ese combo de marco es compatible hasta al menos 2019, y posiblemente extendido hasta 2020, es un gran alivio.

Transferiremos System.DirectoryServices y System.Drawing a .NET Core este año (totalmente compatible, multiplataforma, vista previa para al menos Windows en verano)

Estas son las dos únicas razones por las que apuntamos a .NET Framework en este momento. Si estos se migran por completo a .NET Core 2, estoy seguro de que podemos portar nuestras aplicaciones a ASP.NET Core 2 de manera segura el próximo año.

Parece que muchas personas han roto la regla fundamental de ser un desarrollador de MS: no se comprometa con ningún producto/bifurcación hasta al menos la versión V2.

pero sí, ¡habla de alienar a los clientes de tu empresa! la única razón por la que usan MS es por compatibilidad con versiones anteriores.

A la mayoría de las personas que ejecutan ASP.NET NO les importa si se ejecuta en Linux. Y si vieron una publicación de blog, con una comparación de velocidad con ASPNET Core, ni siquiera leerían más allá de la plataforma cruzada si vieran que no es compatible con .NET heredado.

lolcats

Creo que vale la pena que ASP.NET Core 2.0 se ejecute completamente en net46x para brindarle a muchas personas una ruta de migración sin problemas hacia el nuevo mundo. Creo que mucha gente esperaba ASP.NET Core 2.0 y .NET Core 2.0 con la esperanza de que cerraría muchas de las brechas actuales y permitiría una migración. Si ASP.NET Core 2.0 requerirá que todo se transfiera a netcoreapp2.0, entonces será una desaceleración masiva para los equipos y quizás incluso pondrá en peligro la viabilidad.

Sin embargo, eso no significa que no pueda haber un ASP.NET Core 3.0 poco después del cual solo se enfocará en netcoreapp2.0 para todas las personas que trabajan en todas las cosas nuevas y brillantes y quieren estar en la vía rápida.

Tener dos versiones de ASP.NET Core (2.0 y 3.0) una al lado de la otra podría ser realmente bueno (al menos durante un tiempo). Eso podría permitir que MSFT elimine más rápidamente la pila MVC 5 actual, porque la nueva versión de MVC sería esencialmente ASP.NET Core MVC 2.0, que también se ejecutaría en .NET completo.

Creo que vale la pena tener ASP.NET Core 2.0 completamente ejecutado en net46x para brindarle a muchas personas una ruta de migración sin problemas hacia el nuevo mundo.

¿Qué lo haría más sencillo que migrar desde ASP.NET Core 1.x?

Creo que mucha gente esperaba ASP.NET Core 2.0 y .NET Core 2.0 con la esperanza de que cerraría muchas de las brechas actuales y permitiría una migración.

La mayor parte del trabajo realizado para hacer las cosas compatibles se realizó en .NET Core 2.0 y .NET Standard 2.0. ASP.NET Core 2.0 honestamente no tiene tantas características nuevas. Dijimos que vamos a respaldar SignalR a ASP.NET Core 1.x (que es posterior a 2.0 de todos modos). ¿Es solo una cosa de percepción?

Tener dos versiones de ASP.NET Core (2.0 y 3.0) una al lado de la otra podría ser realmente bueno.

Esto es lo que estamos haciendo con 1.1 y 2.0 (simplemente voltea los números).

Eso podría permitir que MSFT elimine más rápidamente la pila MVC 5 actual, porque la nueva versión de MVC sería esencialmente ASP.NET Core MVC 2.0, que también se ejecutaría en .NET completo.

MVC 5 nunca desaparecerá, no desaprobamos nada. Será compatible mientras exista .NET Framework. Todavía no puede ejecutar proyectos ASP.NET Core dentro de la canalización integrada de IIS (en System.Web) y no hace las mismas cosas que MVC 5 en System.Web, por lo que realmente no es un reemplazo para ciertos escenarios. .

@davidfowl ¿Podré crear una aplicación ASP.NET Core 1.x, que apunte a .NET completo y netcoreapp2.0 para poder migrar una aplicación heredada actual a ASP.NET Core primero con todas las dependencias net46x y migrar lentamente? una dependencia tras otra para apuntar a netstandard2.0 hasta que todo esté en netstandard2.0, lo que me permitiría actualizar la aplicación ASP.NET Core 1.x a 2.x (y eliminar el objetivo para net46x como parte de eso)?

Si es así, entonces creo que entendí mal el hilo. Creo que esto es realmente lo que la mayoría de la gente busca aquí.

@dustinmoris sí puedes hacer eso. La principal preocupación que tienen las personas es qué sucede si no migran a ASP.NET Core 2.x antes de que finalice el soporte en ASP.NET Core 1.x, si es que es posible que migren.

@alexwiese ah, está bien, eso es genial, entonces, ¿de qué estamos hablando aquí ahora? En lugar de discutir a qué marco apuntar, deberíamos discutir el período de soporte de ASP.NET Core 1.x, que es algo que MSFT podría cambiar fácilmente si quisiera :)

EDITAR:
@DamianEdwards escribió esto un poco más arriba en el hilo:

El soporte para ASP.NET Core 1.x en .NET Framework se extenderá por al menos otro año (hasta julio de 2019). Reevaluaremos esto anualmente y nos comprometemos a proporcionar un aviso de 12 meses antes de finalizar el soporte de ASP.NET Core 1.x (por lo tanto, para julio de 2018 anunciaremos si extenderemos por otros 12 meses hasta julio de 2020) (Nota al margen: es ¿Alguien más se asustó por el hecho de que ya estamos hablando de 2020? ¿No? Ok, solo yo).

Suena bien para mí. Comprometerse a un año más de apoyo y luego reevaluar periódicamente. Tiene mucho sentido para mí.

He leído todos los mensajes de este hilo. Todavía queda una pregunta sin respuesta: ¿por qué se toma esta decisión? Solo puedo concluir que era necesario debido a un problema técnico. Si el problema es la "confusión" del nombre, Microsoft debería contratar a una mejor persona de relaciones públicas y dejar de revolver la mierda como lo está haciendo el equipo en este hilo.

Entonces, ¿cuál es el problema técnico que bloqueó ASP.NET core 2.0 en netstandard2.0? Nada es imposible en la tierra del software, por lo que no puede ser que no pueda encontrar una solución que no sea factible en .NET completo (y, por lo tanto, no se puede incluir en netstandard20). Sí, eso requiere tiempo y esfuerzo, pero tengo la sensación de que realmente no se dieron cuenta de los efectos secundarios de esta decisión para sus usuarios, la cantidad de tiempo/esfuerzo que tienen que invertir debido a esto.

Esta decisión tiene otra desventaja: ASP.NET Core no es un consumidor de netstandard y, por lo tanto, no lo impulsa. Hace que netstandard sea un seguidor y, como ASP.NET core no depende de él, un seguidor con poco significado: la API de .net core 2.0+ es la superficie a la que apunta, ya que ASP.NET core apunta a esa superficie, no estándar de red 2.0.

Y, lo siento, @davidfowl , sé que tiene buenas intenciones, pero sugerir ASP.NET core 1.x a las personas una y otra vez muestra que realmente no tiene idea de cuál es la situación para las personas a las que sugiere que: las personas no pueden migrar a ASP.NET core 1.x porque no saben si hay un camino sin problemas sin una fecha límite firme: es posible que necesiten permanecer en esa plataforma por más tiempo de lo que piensan actualmente (las dependencias deben ser portadas etc). Solo eso hace que la decisión de pasar a ASP.NET core 1.xa se base nada más que en una "promesa" de Microsoft. Es una API destinada al código orientado a Internet. Necesitan saber si pueden ejecutar una aplicación creada hoy también dentro de 3 años porque Microsoft solucionará las fallas de seguridad en ella (por ejemplo).

Francamente, no siento la necesidad de comenzar otro grupo de caos dentro del ecosistema .NET: necesitamos estabilidad, confiabilidad, confiabilidad: "mi código escrito hoy se ejecutará dentro de 5 años tal como está". sí, sé que suena tonto para algunas personas, pero esa es la realidad: ya hay más paquetes de software en este planeta que desarrolladores para mantenerlos y la brecha solo se está agrandando. No puede simplemente suponer que una organización decidirá usar ASP.NET Core como su pila web y esperar que el código escrito con él se ejecute dentro de 5 años, las organizaciones ya no hacen eso: saben que hay pilas por ahí que son confiable y bríndeles eso: saben que es posible que no puedan volver a escribir la aplicación completa dentro de ese período de tiempo, por lo que necesitan esa garantía.

Microsoft ha demostrado con este hilo y, lo siento, sus terribles relaciones públicas en torno a este tema, no pueden dar esa seguridad. Y no importa cuánto intente darle eso en los próximos días en \build, nosotros del otro lado de la cerca hemos aprendido que Microsoft Marketing != asegura que las cosas funcionarán mañana.

@FransBouma No creo que haya sido un problema técnico, parece que la motivación para apuntar solo a netcoreapp2.0 es porque esta es la única pista que MSFT puede mover tan rápido como quiera, lo cual es bueno para nosotros después todo, porque significa que ASP.NET Core 2.x puede moverse mucho más rápido que cualquier otra pila web en el mundo .NET anterior. Si no puede comprometerse con este tren rápido, puede permanecer en ASP.NET Core 1.x por más tiempo (actualmente compatible hasta 2019)

@FransBouma como @davidfowl y @shanselman mencionaron que se están agregando nuevas API a un ritmo acelerado en .NET Core, y ASP.NET Core 2.x usará algunas de ellas, por lo tanto, el deseo de apuntar a netcoreapp20. Si tuvieran que agregar estas API a netstandard2x, entonces .NET Framework y otras plataformas tendrían que ponerse al día, y son notoriamente lentas.

Voy a sumar mi voz en el lado del debate Esto es algo bueno . Este es el por qué:

• El equipo no solo está haciendo esto por el gusto de hacerlo. Hay una gran cantidad de nuevas funciones y optimizaciones listas (o casi listas) para implementar .NET Core que son increíblemente útiles para las personas que crean aplicaciones web modernas, API y microservicios, y esperan que esas funciones lleguen a Windows .NET Framework completo. retrasaría el lanzamiento por muchos meses.
• Muchas de las quejas que veo en este hilo son una variación de "No puedo hacer X en .NET Core 2.0" cuando lo que el escritor realmente quiere decir es _"Tengo que cambiar la forma en que hago X en .NET Core 2.0" _. Sí, tienes que cambiar. No, eso no es algo malo. Si tiene una pequeña pieza de funcionalidad discreta en su aplicación ASP.NET MVC que hace algo con archivos PDF o DOCX, y _realmente_ no puede encontrar una mejor manera de hacer lo que sea (¿lo ha intentado?), entonces rompa eso la funcionalidad en un microservicio que se ejecuta en .NET completo en Windows Server y llámelo como una API HTTP desde su aplicación .NET Core. Descomponer aplicaciones y mover funcionalidades específicas a servicios pequeños e independientes ni siquiera es una solución alternativa, es una mejor práctica de propósito general._
  
  
  
  • NB Por lo que puedo decir, los paquetes OpenXML ahora son compatibles con .NET Standard, por lo que trabajar con Word/Excel/lo que sea no debería ser imposible.
  
  
• .NET Core 2.0 ni siquiera está en la vista previa pública adecuada todavía, por lo que quejarse de que no tiene soporte para LDAP o lo que sea parece prematuro. Si RTM aparece en el tercer trimestre y todavía no hay forma de interactuar con AD o Kerberos o lo que sea, entonces quéjese (aunque también piense en migrar a sistemas modernos de autenticación basados ​​en token porque ya no es 2008).
• Existe una migración fluida de ASP.NET MVC 4.5 a ASP.NET Core 2.0. Se llama ASP.NET Core 1.0 (y estoy de acuerdo en que debería haber alguna promesa de soporte a largo plazo para 1.0 dadas las circunstancias). Puede crear aplicaciones con 1.0 y ejecutarlas en Full .NET en una canalización integrada en IIS 8.5 en Windows Server 2012 R2 hasta
  
  
  
  • .NET completo se pone al día y puede ejecutar ASP.NET Core 2.x en él, o
  
  
  • Independientemente de la tecnología de terceros de la que dependa, es compatible con .NET Core (o puede reemplazarse por una tecnología equivalente que sea compatible con .NET Core).
  
  
• Recuerde que, si bien su equipo puede verse obstaculizado por dependencias externas o políticas o políticas internas de la empresa o simplemente por inercia, hay cientos de miles, si no millones, de desarrolladores en el mundo que buscan crear aplicaciones, servicios y API utilizando tecnologías modernas. patrones arquitectónicos y nuevas plataformas tecnológicas (nube/borde/IoT/etc), para quienes ASP.NET Core 2.0 encaja perfectamente. Quieren que sea rápido, escalable y multiplataforma; esas cosas son importantes para mucha gente. Pedirle a Microsoft que ignore ese mercado en rápida expansión, solo porque su proveedor de control de terceros o un proyecto de código abierto aún no han portado su código, es una tontería.

@dustinmoris que sugiere que netstandard carece de las API para crear una pila web rápida. Si es así, todos tenemos problemas mayores.

@alexwiese como dije, leí el hilo completo y, por lo tanto, también las publicaciones a las que te refieres. Sé lo que dicen y puedo ver su punto, pero la decisión tomada muestra que no tienen idea de lo que hacen sus usuarios con sus cosas. Yo mismo construyo un producto, desde hace muchos años, y sé que después de un tiempo llegas a un punto en el que quieres cortar las cosas y moverte más rápido, sin la vieja rutina que está desactualizada. Pero hacer eso tiene consecuencias, y una cosa que he aprendido en los últimos 14 años es que la compatibilidad con versiones anteriores es una de las características más importantes que puede tener un producto de software: poder usarlo y que "simplemente funcione" es un punto clave para muchas muchas personas para decidir por su plataforma. Puede que no creas que es tan importante, y eso está bien, pero hay muchas personas que no pueden verlo de esa manera porque su realidad es diferente.

No es que el equipo central de asp.net no deba moverse rápido, es que lo hacen de una manera que rompe con las suposiciones de muchas personas cuando se mudaron a asp.net core 1.x.

@FransBouma ¿Por qué cree que tiene una mejor idea de lo que hacen los usuarios de Microsoft con las cosas de Microsoft que Microsoft?

@markrendle

El equipo no solo está haciendo esto por el gusto de hacerlo. Hay una gran cantidad de nuevas funciones y optimizaciones listas (o casi listas) para implementar .NET Core que son increíblemente útiles para las personas que crean aplicaciones web modernas, API y microservicios, y esperan que esas funciones lleguen a Windows .NET Framework completo. retrasaría el lanzamiento por muchos meses.

Entonces, dígame, ¿por qué no crear estas API súper duper como paquetes .net estándar 2.0 y publicarlas en nuget?

¿Por qué cree que tiene una mejor idea de lo que hacen los usuarios de Microsoft con las cosas de Microsoft que Microsoft?

Oh, no sé, ¿leyendo las publicaciones en este hilo?

@FransBouma

eso sugiere que netstandard carece de las API para crear una pila web rápida. Si es así, todos tenemos problemas mayores.

No creo que a netstandard le falte nada, porque netstandard no es más que una lista de funciones que debe implementar una plataforma que quiera admitir ese estándar. En teoría, podemos mover netstandard tan rápido como queramos, solo agregue más a la especificación, pero en realidad no es factible que todas las plataformas se pongan al día con esas nuevas especificaciones.

Entonces, la pregunta es, ¿ASP.NET Core 2.x quiere comprometerse con netstandard2.0 (el más alto actualmente) y luego saber que está atascado con todo lo que se ha definido allí, o ASP.NET Core 2.x solo? comprométete con netcoreapp2.x, que puede ser mucho más que netstandard2.0. Después de un tiempo, estoy seguro de que habrá un estándar de red más nuevo (3.x?) . Es bueno tener una pila de ASP.NET Core que se mueva realmente rápido, siempre que también haya una segunda que brinde a las personas un soporte a más largo plazo que se adhiera a netstandard.

@FransBouma Oh, lo siento, no me di cuenta de que el tamaño de tu muestra era tan grande. 257 comentarios con un fuerte sesgo hacia las personas a las que no les gusta la decisión? Es difícil discutir con eso.

DESCARGO DE RESPONSABILIDAD: No soy un experto en Big Data.

@davidfowl :

A lo largo de este hilo, llamó a System.DirectoryServices como una de las cosas principales. Supongo que tiene algunas dependencias que cree que tardarán mucho en ser portadas o que nunca se portarán. Si 2.0 fuera compatible con .NET Framework, ¿se moverían esas dependencias en un año?

Sí, tenemos otras cosas. Los servicios System.Directory son lo que señalo porque incluso el espacio de nombres más solicitado no está listo. Todos los demás están peor. El analizador de portabilidad API ni siquiera está actualizado para VS 2017, donde podemos ejecutarlo. No se ha invertido en el analizador para ver si incluso puede portar y ya estamos eliminando el soporte.

¿Cuáles?

Razor Pages es enorme, lo he mencionado varias veces.

No sé nada sobre stackoverflow.com, pero ¿es posible dividir partes (no quiero decir "microservicios") para que ASP.NET Core pueda usarse para algunas partes?

No, esto no es realmente posible. No renderizamos en 18 ms haciendo llamadas API y agregando sobrecarga entre cosas. Estoy feliz de repasar la arquitectura en cualquier momento, verás que no es realmente una ruta razonable.

Pensé que había explicado esto antes, pero aquí está de nuevo:

Cualquier API que sea parte de netstandard que necesite evolucionar evolucionará lentamente. Las cosas se pueden construir sobre netstandard y se pueden ejecutar en cualquier lugar, y eso está bien. En el momento en que necesite una nueva API en, digamos, cliente http, SSL Stream, Int, String, Array, LINQ o cualquiera de las primitivas que existen en NET Standard, se debe crear una nueva versión de .NET Standard y las implementaciones necesitan acordar que lo implementarán. Ahora, ese no es el fin del mundo porque ahora poseemos la mayoría de ellos, mono, .NET Core, .NET Framework, UWP, pero hay otros, como Unity (y probablemente otros). Cada vertical de .NET tiene su propio marco de tiempo y ciclo de envío, cada uno es su propio producto por separado y eso no se puede ignorar.

Pero ahora entiende la idea, se crea una nueva versión de netstandard cuando las nuevas API se ponen en línea. Si las bibliotecas quieren usar estas nuevas API, perderá inmediatamente el soporte para todas las plataformas. Puede realizar una compilación cruzada e intentar realizar un polyfill, pero eso no se adapta a todos los cambios.

Con suerte, eso le dará una idea de cómo sería el proceso de llevar las API a netstandard. @terrajobst tendría una mejor idea de cuál es el plan.

@DamianEdwards y @shanselman ¿Qué pasa con Service Fabric y Unit Tests?

En nuestro caso, tenemos un gran proyecto de microservicio con muchas aplicaciones SF que son proyectos Core pero usan .Net Framework 4.5 hasta 4.6. (algo). Actualmente, SF no es compatible con netcoreapp, por lo tanto, tuvimos que usar .Net Framework, pero como no queríamos quedarnos atrás, usamos el proyecto .Net Core.

(otro problema es) Debido a que nuestros servicios son .Net Framework y MS Fakes no están disponibles para netcoreapp, todas nuestras pruebas unitarias son proyectos normales (o debería decir heredados) de .Net Framework. Casi todas nuestras bibliotecas están en netstandard 1.0 a 1.6.

Nuevamente, nuestras aplicaciones cliente usan Xamarin Forms + UWP y logramos usar netstandard para que nuestras bibliotecas sean compatibles.

¿Significa esto que estamos atascados y no podremos actualizar a .Net Core 2.0 y netcoreapp2.0 y netstandard 2.0?

@NickCraver

Razor Pages es enorme, lo he mencionado varias veces.

Entiendo esto, pero no puedo creer que vayas a convertir todo el desbordamiento de pila en páginas de afeitar solamente. Si ya está usando MVC hoy, ¿por qué no simplemente migrar a vistas regulares y cuando haya más dependencias en línea, migrar a páginas de afeitar? La forma en que se diseñan las páginas de afeitar hace que sea trivial pasar de una acción de controlador a una página de afeitar.

Sí, tenemos otras cosas. Los servicios System.Directory son lo que señalo porque incluso el espacio de nombres más solicitado no está listo. Todos los demás están peor. El analizador de portabilidad API ni siquiera está actualizado para VS 2017, donde podemos ejecutarlo. No se ha invertido en el analizador para ver si incluso puede portar y ya estamos eliminando el soporte.

Solo asegúrese de escalar esa lista de dependencias para que sepamos qué es importante.

@aboo

¿Significa esto que estamos atascados y no podremos actualizar a .Net Core 2.0 y netcoreapp2.0 y netstandard 2.0?

¿Quiso decir ASP.NET Core 2.0 y? .NET Core 2.0 y .NET Standard 2.0 realmente no se aplican aquí.

Sí, deberá permanecer en ASP.NET Core 1.x.

La mayor parte del trabajo realizado para hacer las cosas compatibles se realizó en .NET Core 2.0 y .NET Standard 2.0. ASP.NET Core 2.0 honestamente no tiene tantas características nuevas. Dijimos que vamos a respaldar SignalR a ASP.NET Core 1.x (que es posterior a 2.0 de todos modos). ¿Es solo una cosa de percepción?

@davidfowl Creo que está subestimando enormemente el miedo que golpea el corazón de un desarrollador de Windows cuando le dicen que tendrá que migrar cosas. _Especialmente_ cuando la nueva pila no ha alcanzado la paridad de características con la pila anterior, y no se sabe si eso sucederá ni cuándo. Básicamente, esto anuncia el fin de vida de ASP.NET Core en .NET Framework completo. Y, si bien ese probablemente no era el plan a largo plazo, se anunció como una característica y la gente pensó que podría mantenerse por un tiempo. Las hojas de ruta están cambiando mientras hablamos. Se tendrán reuniones.

Tenemos algunas cosas asquerosamente viejas que tenemos que admitir debido a los conectores de base de datos y SDK nominalmente mantenidos. Es mucho más probable que algunos de estos proveedores lancen una nueva API eliminada con un 30 % de la funcionalidad existente, una interfaz HTML5 y una nueva serie de errores que mantener sus productos existentes. O pueden adquirir un competidor, lanzar el producto y terminarlo rápidamente. Algunos de estos proveedores son lo suficientemente grandes como para ser reconocibles. Tenemos un montón de buen código, pero parte de ese código también vive en los barrios marginales de Windows a pesar de nuestros mejores esfuerzos porque no siempre está bajo nuestro control. La vieja tecnología no se retira con elegancia. Se esconde debajo de tu cama, en nuestro armario y debajo de tu teclado.

Estoy más preocupado por este movimiento que señala la posible marginación de .NET Standard que por el resto. Inicialmente, .NET Standard parecía algo que acercaría cada vez más las diferentes implementaciones a la paridad de funciones, al mismo tiempo que permitiría a los consumidores migrar a la plataforma en constante evolución y crecimiento. Ahora suena como nada más que un hito de las características de .NET Core. No podrá (ni querrá) apuntar ejecutables hacia .NET Standard, solo bibliotecas. Y parece que habrá una planificación significativamente menor involucrada en .NET Standard y, en su lugar, simplemente se sellará con lo que se haya usado en ASP.NET porque ya es demasiado tarde para cambiar. Después de todo, ya estará en producción.

Otros desarrolladores tienen que salpicar el código con directivas de compilación, dividir el código en bibliotecas específicas de la plataforma y compilar con múltiples objetivos. La parte grosera de mí quiere que el equipo de ASP.NET Core lo pruebe, por lo que estará interesado en un mejor tiempo de ejecución y soporte de herramientas para escenarios multiplataforma y de objetivos múltiples. Y si su equipo lo quiere, entonces podríamos conseguirlo. La parte práctica de mí dice que, como mínimo, debe tener versiones periódicas de ASP.NET Core que apunten al estándar .NET. Necesitas hacer lanzamientos _estables_ reales de todos modos. Nadie simplemente va a compilar la rama maestra de git e implementarla en producción. ¿Por qué no hacer iteraciones más pequeñas de .NET Standard y combinarlas con una versión etiquetada de ASP.NET?

Además, ¿habrá un nuevo ASP.NET para el escritorio? Toda la fanfarria hizo que pareciera que ASP.NET Core era el único ASP.NET. Ahora parece que no obtendrá nada nuevo en ASP.NET a menos que esté en .NET Core. Y eso va a cambiar muchas estrategias comerciales. Hay mucha confusión con las hojas de ruta.

MVC 5 nunca desaparecerá, no desaprobamos nada. Será compatible mientras exista .NET Framework.

Sí, somos bastante conscientes de que las cosas viejas se quedarán allí. Por lo general, lo hace, y lo apreciamos. Pero si las cosas nuevas entrarán en el marco "completo" es muy importante. Necesitamos saber hacia dónde van las cosas. No queremos viajar en el tren hasta el final y solo entonces pensar en cómo seguir adelante. También tenemos que preocuparnos por nuestros pasajeros. Y la disparidad entre .NET Core y .NET Framework deja a mucha gente insegura sobre el futuro. Hice una pregunta hace un año y medio sobre cuándo se admitiría una parte particular de la funcionalidad en .NET Core. Incluso pregunté si sería aceptado si tuviera que trabajar en él personalmente. La comunicación ha sido escasa. Todavía no tengo idea de lo que va a pasar con él. Ese tipo de incertidumbre sobre los escenarios admitidos y los plazos marca una gran diferencia en el código que escribimos. Incluso saber qué secciones del marco de escritorio son de baja prioridad podría dar a las personas tiempo suficiente para migrar en lugar de esperar actualizaciones de estado.

En resumen, apoyo lo que estás haciendo y los objetivos que hay detrás. Y sé que es difícil cuando llegamos aquí y nos quejamos de las decisiones que has tomado por una muy buena razón. Pero muchas personas no van a subirse al tren pionero porque no pueden, y otras no lo harán porque no saben a dónde va.

@davidfowl supongo. ¿Cómo se llama un proyecto central (nuevo) con .Net Framework? Sea lo que sea, mi entendimiento de la publicación es que netstandard vNext no lo admitirá.

@markrendle Somos clientes reales. Le estamos diciendo a la gente que las cosas no funcionarán. Conozco mi arquitectura mejor que tú, así que los comentarios arrogantes no ayudan. A tus puntos:

El equipo no solo está haciendo esto por el gusto de hacerlo. Hay una gran cantidad de nuevas funciones y optimizaciones listas (o casi listas) para implementar .NET Core que son increíblemente útiles para las personas que crean aplicaciones web modernas, API y microservicios, y esperan que esas funciones lleguen a Windows .NET Framework completo. retrasaría el lanzamiento por muchos meses.

Nadie está en contra de que también apoyen estas cosas. Nuestras quejas se refieren universalmente a la eliminación del soporte, no a la adición condicional de nuevas funciones.

Muchas de las quejas que veo en este hilo son una variación de "No puedo hacer X en .NET Core 2.0" cuando lo que el escritor realmente quiere decir es "Tengo que cambiar la forma en que hago X en .NET Core 2.0". Sí, tienes que cambiar. No, eso no es algo malo. Si tiene una pequeña pieza de funcionalidad discreta en su aplicación ASP.NET MVC que hace algo con archivos PDF o DOCX, y realmente no puede encontrar una mejor manera de hacer lo que sea (¿lo ha intentado?), entonces rompa eso la funcionalidad en un microservicio que se ejecuta en .NET completo en Windows Server y llámelo como una API HTTP desde su aplicación .NET Core. Descomponer aplicaciones y mover funcionalidades específicas a servicios pequeños e independientes ni siquiera es una solución alternativa, es una mejor práctica de propósito general.

Esto está tan lejos de la base que no sé por dónde empezar. Nuestras páginas serían mucho más lentas y más caras en "micro-servicios". Pasaríamos mucho más tiempo en GC que en renderizados de página con una configuración de este tipo. Esto también supone que la dependencia completa del marco no es una parte crítica de cada representación de página. Mala suposición.

.NET Core 2.0 ni siquiera está en la vista previa pública adecuada todavía, por lo que quejarse de que no tiene soporte para LDAP o lo que sea parece prematuro. Si RTM aparece en el tercer trimestre y todavía no hay forma de interactuar con AD o Kerberos o lo que sea, entonces quéjese (aunque también piense en migrar a sistemas modernos de autenticación basados ​​en token porque ya no es 2008).

Nos han dicho que no estarán allí. Mira el stand up. O mire GitHub donde está etiquetado como "Futuro". Nos quejamos ahora porque esta mala decisión se habrá enviado en el tercer trimestre.

Hay una migración fluida de ASP.NET MVC 4.5 a ASP.NET Core 2.0. Se llama ASP.NET Core 1.0 (y estoy de acuerdo en que debería haber alguna promesa de soporte a largo plazo para 1.0 dadas las circunstancias).

El soporte a largo plazo no significa que no sea un callejón sin salida. Todavía podemos quedarnos varados fácilmente en 1.x cuando llegue al final de su vida útil. En ese caso, habríamos tenido más soporte en el marco completo.

.NET completo se pone al día y puede ejecutar ASP.NET Core 2.x en él

Está dirigido a netcoreapp , eso no sucederá.

... o cualquier tecnología de terceros de la que dependa sea compatible con .NET Core (o puede ser reemplazada por una tecnología equivalente que sea compatible con .NET Core).

Esas bibliotecas a menudo están fuera del control de las personas y de los presupuestos de tiempo. Incluso las bibliotecas de Microsoft no se actualizan . Estoy luchando contra el equipo de SQL en este momento para actualizar sus paquetes para que funcionen en el nuevo sistema de proyectos porque install.ps1 funciona. Si ni siquiera podemos obtener esas soluciones simples, estamos jodidos con los puertos netstandard .

Recuerde que, si bien su equipo puede verse obstaculizado por dependencias externas o políticas o políticas internas de la empresa o simplemente por inercia, hay cientos de miles, si no millones, de desarrolladores en el mundo que buscan crear aplicaciones, servicios y API utilizando tecnologías modernas. patrones arquitectónicos y nuevas plataformas tecnológicas (nube/borde/IoT/etc), para quienes ASP.NET Core 2.0 encaja perfectamente. Quieren que sea rápido, escalable y multiplataforma; esas cosas son importantes para mucha gente. Pedirle a Microsoft que ignore ese mercado en rápida expansión, solo porque su proveedor de control de terceros o un proyecto de código abierto aún no han portado su código, es una tontería.

Llamarlo tonto es menospreciar, grosero e innecesario. Esta es nuestra vida. Estas son nuestras aplicaciones. Estas son las cosas que hemos pasado años o décadas creando y, de repente, antes del lanzamiento, descubrimos que la perspectiva tiene un límite de tiempo para nosotros, difícil. Se introduce mucha incertidumbre, por decir lo menos. Eso no es realmente algo que quieras en tu carrera.

cada punto tiene sentido, pero recuerda que en este universo todo irá en el estado que requiere menos energía, entonces asegúrate de que ese estado es donde quieres ir, porque iremos allí de una forma u otra.
Entonces, si desea alcanzar un cierto estado, asegúrese de que requiera menos energía que la requerida para permanecer donde estamos ahora.

Acabo de leer este hilo completo después de que alguien lo mencionara como un comentario aparte en IRC (todavía no he visto ningún anuncio oficial al respecto) y estoy completamente decepcionado.

He estado observando .NET Core, involucrándome y convirtiendo pequeños proyectos de .NET Framework a .NET Standard/.NET Core para obtener algo de experiencia con el nuevo SDK y tiempo de ejecución, y para ejecutar estos proyectos en macOS y Linux. .

Mi gran objetivo es un servicio web de gran empresa que utiliza una gran cantidad de componentes que no están disponibles [todavía] en .NET Core 1.0 o 1.1. Esto incluye, justo en la parte superior de mi cabeza:

• Active Directory ( System.DirectoryServices ), utilizado para autenticación y administración de usuarios
• Entity Framework 6 ( EntityFramework ), ya que EF Core aún no admite muchas de las funciones que usamos.
• OData ( Microsoft.Data.Services / System.Data.Services ) v1-3, la biblioteca cliente Javascript que usamos no es compatible con v4 (todavía) y WebAPI OData es mucho más complejo de configurar.
• Administración de IIS ( System.Web.Management ) y .NET Remoting ( System.Runtime.Remoting ) para la capacidad del servicio web de actualizarse a sí mismo, aunque esto podría extraerse a una aplicación independiente.
• SeñalR
• IHttpHandler s y IHttpModule s personalizados, que tendrían que adaptarse a cualquier equivalente de ASP.NET Core, probablemente algún tipo de middleware
• Un montón de cosas personalizadas usando la extensibilidad de ASP.NET WebAPI.
• Creo que incluso podríamos usar Microsoft.TeamFoundationServer.ExtendedClient en el servidor, que solo es compatible con net46, tiene algunos ensamblajes nativos y tiene aproximadamente un 0 % de posibilidades de funcionar en .NET Core 2.0.
• etc

Debido al tamaño y la complejidad de este servicio, cualquier migración a .NET Core tendría que ser gradual y, con toda probabilidad, tendríamos que usar algunas API nuevas en ASP.NET-Core-2.0, no lo sé. sin embargo, no hemos llegado tan lejos.

Eliminar la capacidad de ejecutar ASP.NET Core en .NET Framework significa que las migraciones se deben realizar al estilo big-bang si ASP.NET Core 1.x no es un trampolín viable. Perdemos instantáneamente la etapa de "ejecutar nuevo marco en tiempo de ejecución anterior" antes de "ejecutar nuevo marco en tiempo de ejecución nuevo". Esta es una estrategia de gestión de cambios horrible para cualquier sistema grande.

No me importaría mucho si la compatibilidad con .NET Framework se eliminara una vez que .NET Core estuviera en la paridad o cerca de ella, pero todavía está bastante atrasado para cualquier aplicación lo suficientemente avanzada, y no creo que 2.0 sea el lugar adecuado para hacerlo. un cambio radical.

@davidfowl

Entiendo esto, pero no puedo creer que vayas a convertir todo el desbordamiento de pila en páginas de afeitar solamente. Si ya está usando MVC hoy, ¿por qué no simplemente migrar a vistas regulares y cuando haya más dependencias en línea, migrar a páginas de afeitar? La forma en que se diseñan las páginas de afeitar hace que sea trivial pasar de una acción de controlador a una página de afeitar.

Muchas bibliotecas, etc. compartidas entre aplicaciones están en juego aquí. Stack Overflow es muchas aplicaciones (el sitio web principal es casi en su totalidad una sola aplicación, pero como empresa: tenemos muchas cosas relacionadas que se comunican.

Solo asegúrese de escalar esa lista de dependencias para que sepamos qué es importante.

Sí, estoy haciendo eso. Pero esa no será la última dependencia, solo el mayor bloqueador, ya que ni siquiera podemos iniciar sesión en algunas aplicaciones sin él. Es un interruptor de primera pantalla. Intentaré hacer el analizador de portabilidad completo en nuestras aplicaciones esta semana (después del lanzamiento esta mañana), pero me temo que será más deprimente. Sería útil si el analizador se actualizara incluso para las herramientas actuales antes de que se consideraran movimientos como este.

Los datos ayudan, intentaré obtener más datos, a menos que no haya ninguna posibilidad de que esta decisión cambie. Si ese es el caso, por favor díganos para que no invierta más de mi tiempo en ello.

Solo para que conste: OData es otra biblioteca que aún no es compatible con netcoreapp.

En realidad, aún se basa en System.Web (debe usarlo a través del middleware OWIN en ASP.NET Core) y prometieron soporte (consulte https://github.com/OData/WebApi/issues/939).

Todavía vale la pena mencionar. Sobre todo porque es de Microsoft.

EDITAR: @yaakov-h fue 2 minutos más rápido, así que +1 por su mención de OData

Todavía estoy aquí respondiendo por un par de razones

• Me importa
• El sueño es para los débiles 😆
• Necesito llamar al FUD porque alguien en Internet está equivocado.

@NickCraver

Muchas bibliotecas, etc. compartidas entre aplicaciones están en juego aquí. Stack Overflow es muchas aplicaciones (el sitio web principal es casi en su totalidad una sola aplicación, pero como empresa: tenemos muchas cosas relacionadas que se comunican.

Simplemente significa que no puede usar las páginas de Razor tbh, ASP.NET Core 2.0 tiene muchas cosas pequeñas, pero no hay grandes funciones o correcciones que no se estén transfiriendo a 1.x. Lo de EOL es muy real y personalmente no creo que ASP.NET Core 2.0 sea compatible con .NET Framework durante un año más. Realmente estamos discutiendo un cambio de dirección aquí, ya sea que admitamos .NET Framework para siempre, o no, realmente no hay término medio.

@dustinmoris no es solo eso. También es un problema de expectativas. Su caso de uso puede no ser el mismo de todos los demás.

Estoy desarrollando aplicaciones aspnetcore 1.* y uso el escritorio .NET como tiempo de ejecución (LOB para empresas).

Y entiendo cuál es la diferencia entre .net core runtime, netstandard, etc. (solo para estar seguro de que este no es un comentario sobre un malentendido al respecto)

Mi migración fue primero a aspnet core (destinada a escritorio .net) porque el flujo/visión/etc., consolidarlo y DESPUÉS moverlo a .net core (si es posible), fue el escenario decisivo en la elección de aspnetcore.

Este problema es un poco inesperado, porque aspnetcore 1.* siempre se comercializó como "ejecutarse en ambos marcos", con cero advertencias acerca de dejarlo caer a continuación (versión o año).
Esperaba un ciclo obsoleto -> obsoleto al menos, o simplemente características no compatibles (está bien).

Lo bueno de .net (y aspnet como elección para la pila web) es que puedo aprovechar la base de código y las bibliotecas existentes.
Algunos son internos, sin retorno de la inversión real para migrarlos, cuando el objetivo (.net core/netstandard) es demasiado fluido.
Algunos son externos y son difíciles de cambiar, si no funcionan en el cierre de netcoreapp2, no puedo usarlos.

Además, mi idea era consolidar netstandard2 no netcoreapp2 .
¿Cómo puedo comenzar a evaluar la migración de libs a netstandard2, si aún no está allí? Es difícil evaluar la migración en función de los bits de vista previa y las promesas (y los últimos años redujeron mi confianza en la estabilidad de las promesas)

Entiendo que es un escenario diferente al completamente nuevo, pero también si me gustaría reutilizar algunas librerías, porque necesito interactuar con el sistema existente (excel/pdf/etc), no reescribir todo desde cero.
O agregue microservicios como rpc solo porque es la última tendencia, porque complica las cosas (esa es una elección concisa que quiero evaluar y hacer, no estar obligado a envolver las bibliotecas existentes). Necesito entregar valor (el flujo de desarrollo de aspnetcore es bueno y productivo), no solo cambiar la arquitectura.

En mi evaluación personal del ecosistema, para mi caso de uso, la disponibilidad de .net core y/o netstandard lib es demasiado baja (no todos usan solo nuget.org oss pkgs gratuitos). Entonces, si necesito migrar fuertemente a una nueva pila, necesito evaluar también otras pilas (costo/beneficio/futuro/confianza/etc.)

No solo estoy escribiendo una aplicación web TODO, uso .NET porque tengo muchos años de cosas listas, así que puedo cambiar una cosa (en este caso, aspnetcore, y dejar el resto como está para esta iteración).
Simplemente cambiar todo es una receta para el desastre en mi escenario, y cuando necesito hacer eso, realmente necesito comenzar a evaluar si tiene más sentido migrar a otra pila (como java/nodo) donde existe lib.

Una migración sin problemas lleva tiempo, me gusta la visión del futuro núcleo de aspnet. pero si no tengo un camino claro (o duda al respecto), es difícil vender internamente.

Dicho esto, dejar atrás el escritorio .net puede ser una buena apuesta del equipo de aspnet para moverse más rápido y elegir más usuarios nuevos (o no perder las corrientes hacia node/java).
Pero seguro, va a hacer la vida más difícil para el desarrollador en un anillo más lento, y esta es la llamada del equipo aspnet (su producto).
Mi opinión es que no haga eso y que trabaje duro para admitir fw, porque como desarrollador, necesito confianza y estabilidad, y los últimos años fueron demasiado fluidos en el ecosistema .net (no solo netcore/project.json, sino antes también, y marketing/evangelista no ayudó a disminuir la confianza)

@yaakov-h

Si decide migrar a ASP.NET Core (ya sea 1.x o 2.x), necesitará otro proceso. ASP.NET Core no se ejecuta en System.Web, por lo que no puede realizar una migración gradual en el mismo proyecto.

No me importaría mucho si la compatibilidad con .NET Framework se eliminara una vez que .NET Core estuviera en la paridad o cerca de ella, pero todavía está bastante atrasado para cualquier aplicación lo suficientemente avanzada, y no creo que 2.0 sea el lugar adecuado para hacerlo. un cambio radical.

No hay un momento adecuado para dejarlo. Nunca tuvo la intención de alcanzar la paridad con .NET Framework y es muy posible que haya dependencias que tenga que nunca se portarán. Dado eso, mi pregunta sería, ¿rediseñas la aplicación o realmente necesitas permanecer en .NET Framework para siempre?

@davidfowl que depende completamente de nuestras dependencias ascendentes. En este momento, permaneceríamos en .NET Framework para siempre.

Curiosamente, la mayoría de los de terceros ya tienen lanzamientos netstandard disponibles. Son en gran parte las dependencias de Microsoft las que nos mantienen en .NET Framework, y algunas de ellas parecen estar semi-abandonadas (por ejemplo, OData)

@NickCraver No pretendo menospreciar ni insultar. Aprecio que este es un cambio de última hora, y eso es frustrante para cualquier sección de la comunidad que se vea afectada por él, y si me afectara, probablemente también estaría armando un escándalo. No lo soy (donde trabajo todavía estamos en ASP.NET WebAPI 5.2.3), por lo que mi opinión sobre la situación es menos emocional.

Míralo de esta manera: si tuvieras que empezar desde cero a construir el próximo Stack Exchange (sea lo que sea) hoy, ¿no serían las cosas que están en netcoreapp20 que el equipo de ASP.NET Core quiere usar ( como UTF8Strings y Pipelines y primitivas _rápidas, asincrónicas y de baja asignación (supongo que un poco allí)) ¿lo hacen más atractivo para usted que .NET completo? ¿No tendría .NET Core 2.0 más sentido que .NET 4.7.1 completo? Si estuviera eligiendo entre pilas web que pueden evolucionar y adaptarse a los cambios rápidamente, frente a pilas web que están irrevocablemente vinculadas a una tecnología subyacente de lento movimiento con casi dos décadas de código heredado para preocuparse por el soporte, ¿cuál elegiría?

@ZigMeowNyan

Estoy más preocupado por este movimiento que señala la posible marginación de .NET Standard que por el resto. Inicialmente, .NET Standard parecía algo que acercaría cada vez más las diferentes implementaciones a la paridad de funciones, al mismo tiempo que permitiría a los consumidores migrar a la plataforma en constante evolución y crecimiento. Ahora suena como nada más que un hito de las características de .NET Core. No podrá (ni querrá) apuntar ejecutables hacia .NET Standard, solo bibliotecas. Y parece que habrá una planificación significativamente menor involucrada en .NET Standard y, en su lugar, simplemente se sellará con lo que se haya usado en ASP.NET porque ya es demasiado tarde para cambiar. Después de todo, ya estará en producción.

Esos son realmente buenos puntos y algo que vale la pena considerar. Debe comprender que no tiene nada que ver con que .NET Standard se deje de lado, es solo física. Si cada plataforma .NET se mueve a su propio ritmo, usar el estándar .NET más reciente significa que los marcos de trabajo más lentos obtienen las cosas con menos frecuencia. Eso es algo que todos deberían interiorizar. Eso no lo hace menos útil, es solo la naturaleza de la bestia. La única forma de eliminar esta carga es tener una implementación única y un programa de envío único que reduce en gran medida los lugares en los que .NET podría ejecutarse.

Otros desarrolladores tienen que salpicar el código con directivas de compilación, dividir el código en bibliotecas específicas de la plataforma y compilar con múltiples objetivos. La parte grosera de mí quiere que el equipo de ASP.NET Core lo pruebe, por lo que estará interesado en un mejor tiempo de ejecución y soporte de herramientas para escenarios multiplataforma y de objetivos múltiples. Y si su equipo lo quiere, entonces podríamos conseguirlo. La parte práctica de mí dice que, como mínimo, debe tener versiones periódicas de ASP.NET Core que apunten al estándar .NET. Necesitas hacer lanzamientos estables reales de todos modos. Nadie simplemente va a compilar la rama maestra de git e implementarla en producción. ¿Por qué no hacer iteraciones más pequeñas de .NET Standard y combinarlas con una versión etiquetada de ASP.NET?

Hacemos lo mismo, recuerde, todavía apuntamos a netstandard para un montón de nuestras bibliotecas y esas contienen ifdefs. Otros, sin embargo, apuntan a netstandard para prepararnos para aprovechar las nuevas API en el marco de tiempo 2.x.

En resumen, apoyo lo que estás haciendo y los objetivos que hay detrás. Y sé que es difícil cuando llegamos aquí y nos quejamos de las decisiones que has tomado por una muy buena razón. Pero muchas personas no van a subirse al tren pionero porque no pueden, y otras no lo harán porque no saben a dónde va.

Pregunta honesta (esta soy yo, no Microsoft), ¿prefiere la compatibilidad sobre las nuevas funciones? En caso afirmativo, ¿por qué elegir ASP.NET Core?

Solo otro pensamiento rápido: para cada hilo como este, existe un hilo equivalente pero opuesto donde un grupo de personas diferente, pero igual de grande, se molestó porque se hizo una concesión para admitir .NET "antiguo".

Curiosamente, la mayoría de los de terceros ya tienen versiones netstandard disponibles. Son en gran parte las dependencias de Microsoft las que nos mantienen en .NET Framework, y algunas de ellas parecen estar semi-abandonadas (por ejemplo, OData)

😞

@markrendle

• Muchas de las quejas que veo en este hilo son una variación de "No puedo hacer X en .NET Core 2.0" cuando lo que el escritor realmente quiere decir es "Tengo que cambiar la forma en que hago X en .NET Core 2.0" . Sí, tienes que cambiar. No, eso no es algo malo. Si tiene una pequeña pieza de funcionalidad discreta en su aplicación ASP.NET MVC que hace algo con archivos PDF o DOCX, y realmente no puede encontrar una mejor manera de hacer lo que sea (¿lo ha intentado?), entonces rompa eso la funcionalidad en un microservicio que se ejecuta en .NET completo en Windows Server y llámelo como una API HTTP desde su aplicación .NET Core. Descomponer aplicaciones y mover funcionalidades específicas a servicios pequeños e independientes ni siquiera es una solución alternativa, es una mejor práctica de propósito general.
NB Por lo que puedo decir, los paquetes OpenXML ahora son compatibles con .NET Standard, por lo que trabajar con Word/Excel/lo que sea no debería ser imposible.<<

Como ya han dicho otros, cambiar la arquitectura de nuestro bonito diseño no es un buen plan. En nuestro caso, compartimos código entre nuestra aplicación de prueba WPF y el servidor. Cuantas más diferencias creamos entre los que más complicado es mantener.

Les puedo asegurar que he pasado mucho tiempo investigando las mejores herramientas que podemos usar para la generación de PDF, DocX y no es tan simple como hacerlo con XML abierto. Usamos una biblioteca de terceros porque hay decenas de miles de líneas de código que han desarrollado y no tenemos que desarrollar/mantener/probar. Ese es todo el punto.

El control de versiones de .net se ha vuelto muy complicado. No tengo claro si en algún momento en el futuro ASP.net podrá usarse en el marco completo de .net. Debido a que necesito compartir código entre el servidor y mis aplicaciones de escritorio, ¿eso significa que nunca podré tener la última versión de ASP.Net? Esto no es un problema a corto plazo, pero a largo plazo con mejoras de seguridad, etcétera. No quiero estar demasiado lejos de la última versión. Estoy seguro de que hay muchos otros en mi bote en los que necesita algún tipo de compatibilidad con el marco completo.

Para aclarar lo que hago es que tengo tres de mis propias bibliotecas que se comparten entre varias aplicaciones de WPF y mi servidor. En este momento, no tengo ni idea de qué Apis estoy usando y puede que no esté disponible en el núcleo de .net. Y luego, en esas bibliotecas, uso versiones de escritorio completas de las herramientas WPF de Telerik y SyncFusion para generar docx y pdf. Algunas o todas las funciones que usan esas herramientas pueden o no estar disponibles en .net core. Tratar de desarrollar aplicaciones basadas en mayo o no es extremadamente difícil. Microsoft tiene un marco base brillante en .net, y aunque entiendo el razonamiento detrás de .net core. Microsoft parece haber olvidado la importancia de la compatibilidad con versiones anteriores.

stefano

@markrendle

Oh, lo siento, no me di cuenta de que el tamaño de tu muestra era tan grande. 257 comentarios con un fuerte sesgo hacia las personas a las que no les gusta la decisión? Es difícil discutir con eso. DESCARGO DE RESPONSABILIDAD: No soy un experto en Big Data.

No tengo idea de lo que te hice, pero no hay necesidad de gruñidos o lloriqueos de bajo nivel como este. Sabes muy bien que este hilo es solo un ejemplo.

@stefanolson

El control de versiones de .net se ha vuelto muy complicado

Creo que esta es una de las pocas cosas en las que todos podemos estar de acuerdo.

Estamos buscando portar a .Net Core x.
Nuestros mayores problemas están relacionados con:
NewRelic (sin plan .Net Core, por lo que necesitamos encontrar un alt)
NH (donde EF Core no tiene las características).
ServiceBase (parece que llegará a .Net Core 2 en verano)

Ciertamente parece que tendríamos que apuntar a Core 1.0 en el ínterin y esperar las actualizaciones de NH, EF o ser creativos.

Simplemente significa que no puede usar las páginas de Razor tbh, ASP.NET Core 2.0 tiene muchas cosas pequeñas, pero no hay grandes funciones o correcciones que no se estén transfiriendo a 1.x. Lo de EOL es muy real y personalmente no creo que ASP.NET Core 2.0 sea compatible con .NET Framework durante un año más. Realmente estamos discutiendo un cambio de dirección aquí, ya sea que admitamos .NET Framework para siempre, o no, realmente no hay término medio.

Es un poco más grande que las páginas de Razor, significa que no hay razón para moverse . Simplemente no existe un escenario (actual) en el que ambos existan:

1. Seremos apoyados todo el tiempo.
2. Hay una actualización real en el otro lado

El hecho es que ASP.NET Core no es tan útil sin el ecosistema . Tener un controlador que devuelva el texto es excelente, pero no es útil para tantos escenarios. Necesitamos las API. Necesitamos las bibliotecas. Necesitamos el ecosistema, por eso elegimos .NET en primer lugar .

Este cambio proviene de un marco que admite completamente nuestros casos de uso actuales a uno que claramente no está listo. Ni siquiera está cerca de estar listo. Y una vista previa para probar si está lista ni siquiera está disponible en general. Una migración para averiguar las promesas de lo que estará listo no está disponible. Confiamos en un montón de promesas y muchas se quemarán. Esa es la peor forma posible de comercializar estas cosas: promesas excesivas y entregas excesivas (la experiencia general).

Creo que ASP.NET Core es genial. Ustedes están haciendo cosas increíbles. Tuve la suerte de ayudar con algo de eso. Pero este cambio en este momento es malo. Si todas las cosas que pensamos que se portarán en realidad se portarán en el marco de tiempo 2.x, entonces genial. Realice el cambio en 3.x entonces. Portar antes de que una alternativa esté lista y establecer una fecha límite para eliminar la línea de vida EOL es malo. Decirle a la gente que porte a una versión de mantenimiento -> EOL es malo.

Por favor, no hagas este cambio ahora. .NET es mejor que esto. Muestre que se preocupa por sus usuarios tanto como todos aquí se preocupan por usted. No estaríamos aquí si no quisiéramos ayudar.

@FransBouma Usted (debería) saber muy bien que Microsoft tiene vastas bases de datos de telemetría, comentarios y otros datos sobre lo que las personas están haciendo con su tecnología que brindan una imagen mucho más clara que cualquier número de subprocesos de problemas de GitHub, y no creo que mi señalar eso fue más sarcástico que

Oh, no sé, ¿leyendo las publicaciones en este hilo?

El control de versiones de .net se ha vuelto muy complicado. No tengo claro si en algún momento en el futuro ASP.net podrá usarse en el marco completo de .net. Debido a que necesito compartir código entre el servidor y mis aplicaciones de escritorio, ¿eso significa que nunca podré tener la última versión de ASP.Net? Esto no es un problema a corto plazo, pero a largo plazo con mejoras de seguridad, etcétera. No quiero estar demasiado lejos de la última versión. Estoy seguro de que hay muchos otros en mi bote en los que necesita algún tipo de compatibilidad con el marco completo.

La historia del código compartido entre diferentes tiempos de ejecución de .NET es .NET Standard. Sus bibliotecas deben tratar de apuntar eso al código compartido en .NET Core y .NET Framework.

Microsoft parece haber olvidado la importancia de la compatibilidad con versiones anteriores.

El problema es que ASP.NET Core nunca tuvo la intención de ser compatible con versiones anteriores... Por eso hubo un cambio de paradigma tan grande desde ASP.NET 4.x. Parece que si la compatibilidad con versiones anteriores es el bit de orden superior para usted, sería mejor usar ASP.NET 4.x en .NET Framework. Eso es compatible en el futuro previsible y tendrá parches de seguridad mientras Windows esté vivo.

¡Incluso si no estaba destinado a serlo, sin embargo, 1.0 era muy compatible con versiones anteriores! Apoyó todo el vasto legado del ecosistema, y ​​lo apreciamos. Parecía en ese momento que nadie tenía que regalar su pastel o abstenerse de comerlo.

@NickCraver

Es un poco más grande que las páginas de Razor, significa que no hay razón para moverse. Simplemente no existe un escenario (actual) en el que ambos existan:

¿Puedes elaborar?

El hecho es que ASP.NET Core no es tan útil sin el ecosistema. Tener un controlador que devuelva el texto es excelente, pero no es útil para tantos escenarios.

También puede hacerlo muy rápido 😉

Creo que ASP.NET Core es genial. Ustedes están haciendo cosas increíbles. Tuve la suerte de ayudar con algo de eso. Pero este cambio en este momento es malo. Si todas las cosas que pensamos que se portarán en realidad se portarán en el marco de tiempo 2.x, entonces genial. Realice el cambio en 3.x entonces. Portar antes de que una alternativa esté lista y establecer una fecha límite para eliminar la línea de vida EOL es malo. Decirle a la gente que porte a una versión de mantenimiento -> EOL es malo.

No entiendo por qué 2.x (soporte) y 3.x (drop) es mejor que 1.x (soporte) y 2.x (drop). ¿Puedes por favor explicarme eso? ¿Cómo hace eso alguna diferencia?

Un par de recomendaciones de la sesión //BUILD 2017 para aquellos preocupados por el soporte a largo plazo de las variaciones de ASP.NET:

• Actualizaciones de formularios web T6009 ASP.NET
  
  
  
  • es decir, todavía están desarrollando plataformas web .NET completas
  
  
• T6072 Soporte para ASP.NET Core: ¿Qué es un LTS?
  
  
  
  • Que supongo que se está actualizando frenéticamente en este momento: muecas:
  
  

@davidfowl :

¿Cómo hace eso alguna diferencia?

¿Porque ha prometido enviar algunas de las API faltantes más importantes después de la 2.0?

@yaakov-h

¿Porque ha prometido enviar algunas de las API faltantes más importantes después de la 2.0?

¿Dime cuáles en ASP.NET Core?

@davidfowl System.DirectoryServices, System.Drawing se mencionaron anteriormente.

Pregunta honesta (esta soy yo, no Microsoft), ¿prefiere la estabilidad y la compatibilidad sobre las nuevas características? En caso afirmativo, ¿por qué elegir ASP.NET Core?

Creo que esta es una muy buena pregunta. Si el marco completo de .NET le brinda a uno todo lo que necesita hoy, ¿por qué está tan interesado en migrar a una pila completamente diferente? Si .NET Core y ASP.NET Core hubieran sido nombrados de manera diferente, sin .NET en el nombre, entonces creo que mucha menos gente discutiría sobre problemas de migración. Nadie se queja de que no pueden migrar a una pila web de Go o Node.js más rápida.

@davidfowl ser compatible con versiones anteriores de ASP.NET MVC 5.x es una cosa, ser compatible con versiones anteriores de .NET Framework es otra cosa. Dejar .net framework es una gran cosa...

No entiendo por qué 2.x (soporte) y 3.x (drop) es mejor que 1.x (soporte) y 2.x (drop).

Porque 2.x llegará muy pronto, según entendemos.

@davidfowl System.DirectoryServices, System.Drawing se mencionaron anteriormente.

Esos no tienen nada que ver con ASP.NET Core 1.x o 2.x y se ejecutarán en ambos cuando estén en línea.

Como dije, solo estoy aquí para llamar al FUD y eso es parte de eso. Este hilo se ha vuelto tan grande que nadie puede ver los hechos en algunas de las respuestas.

@FransBouma Usted (debería) saber muy bien que Microsoft tiene vastas bases de datos de telemetría, comentarios y otros datos sobre lo que las personas están haciendo con su tecnología que brindan una imagen mucho más clara que cualquier número de subprocesos de problemas de GitHub, y no creo que mi señalar eso fue más sarcástico que

La telemetría de @markrendle no es mágica. No puede medir por qué las personas/los desarrolladores no están cambiando, o por qué cambiaron otra pila, o la importancia de su proyecto y cuánto les gusta la pila (y ayudar a otros, con consultoría u oss), o lo que están haciendo.

Este hilo es exactamente eso, una retroalimentación.

No entiendo por qué 2.x (soporte) y 3.x (drop) es mejor que 1.x (soporte) y 2.x (drop). ¿Puedes por favor explicarme eso? ¿Cómo hace eso alguna diferencia?

El tiempo de @davidfowl .
hora de acomodarse un poco. hora de evaluar las cosas. hora de cambiar una cosa a la vez. es hora de usar netstandard2 paquetes con algo rtm. es hora de mover nuestras bibliotecas a netstandard2 (más fácil) en lugar de netstandard1 (más difícil). Es hora de cambiar una cosa a la vez, para mí, principalmente.
Usted hace aspnet, pero mi producto no es solo aspnet, es una combinación de muchas libertades y compensaciones y el ecosistema.

Porque 2.x llegará muy pronto, según entendemos.

¿Qué tiene eso que ver con eso? ¿Y si 2.0 llegara a finales de año o en enero? ¿Habría alguna diferencia? ¿Qué hay en 2.0 que hace que 1.x no valga la pena?

@yaakov-h Se mencionaron aquí donde dijo @shanselman (énfasis mío)

AD – Totalmente, esta es una brecha SI desea llamar a LDAP directamente. Ciertamente puede autenticarse contra Windows Auth AHORA. Planeamos tener específicamente el espacio de nombres DirectoryServices para Core 2.0 alrededor del período de verano.
Dibujo – Totalmente, esta es una brecha. Planeamos tener esto para Core 2.0 alrededor del período de verano . Hasta este momento, estas opciones estándar de red también existen ImageSharp, ImageResizer, opciones Mono, etc.

@davidfowl no se trata de la versión, se trata de la fecha y la madurez de .net core y su ecosistema.

@hikalkan

Lo siento, lo entiendo desde un punto de vista de muy alto nivel pero no desde uno técnico. ¿Quizás esto no es una discusión técnica?

@enricosada

hora de acomodarse un poco. hora de evaluar las cosas. hora de cambiar una cosa a la vez. es hora de usar paquetes netstandard2 con algo rtm. es hora de mover nuestras bibliotecas a netstandard2 (más fácil) en lugar de netstandard1 (más difícil). Es hora de cambiar una cosa a la vez, para mí, principalmente.
Usted hace aspnet, pero mi producto no es solo aspnet, es una combinación de muchas libertades y compensaciones y el ecosistema.

¿Qué diferencia hace eso específicamente a ASP.NET Core 2.0? Obtendrá ese beneficio de la plataforma independientemente de lo que decida hacer ASP.NET Core.

@markrendle que alguien me consiga un calendario, porque las estaciones abarcan un trimestre completo (podrían estar a 3 meses de otra cosa en el mismo trimestre) y son especialmente confusos para nosotros, las personas del hemisferio sur.

@enricosada Puede obtener una gran cantidad de información útil de la telemetría y otras fuentes de datos (análisis web, datos de búsqueda, comentarios directos de los clientes). Mucho más de lo que puede obtener de turbas enojadas en GitHub (sin importar cuán justificada sea la ira de cada individuo).

@yaakov-h Bueno, el RTM proyectado actual para .NET Core 2.0 (y, por lo tanto, ASP.NET Core 2.0) es el tercer trimestre del calendario, que es julio/agosto/septiembre, y el verano en el hemisferio norte es principalmente julio/agosto/septiembre , por lo que es básicamente lo mismo.

Puede obtener una gran cantidad de información útil de la telemetría y otras fuentes de datos (análisis web, datos de búsqueda, comentarios directos de los clientes).

Sin embargo, me pregunto qué tan confiable es esta telemetría, al menos la parte automatizada, para implementaciones empresariales. (Dado que de ahí es de donde parece provenir la mayoría de las reacciones negativas).

No entiendo por qué 2.x (soporte) y 3.x (drop) es mejor que 1.x (soporte) y 2.x (drop). ¿Puedes por favor explicarme eso? ¿Cómo hace eso alguna diferencia?

@davidfowl Tiempo. Y un anuncio adecuado. Si el mensaje fuera más claro, la gente no estaría tan sorprendida.

@davidfowl Tiempo. Y un anuncio adecuado. Si el mensaje fuera más claro, la gente no estaría tan sorprendida.

Lo entiendo, pero no creo que haga una diferencia en su capacidad para portar algo realmente. La misma política EOL todavía existe.

Ok, después de tener dificultades para entender este problema, quería brindar algunas ideas para aquellos que luchan como yo y también tienen algunas preguntas.

así que si lo entendemos correctamente, eventualmente tendremos netstandard reemplazando net framework.

Así que supongamos que netcore no existe y aspnet core se basa en netstandard. eso significa que las características vendrán más lentamente.

Ejemplo:
2017 asp.net quiere la función A.
2018 netstandard implementa la Característica A. Obtenemos la Característica A en ns.

Lo que dice el equipo es tener netcore no basado en netstandard, así que:
2017 asp.net quiere la función A
El equipo de aspnet de 2017 implementa la función A. Asp.Net Core obtiene la función A en netcore.
2018 netstandard implementa la Característica A. Obtenemos la Característica A en ns.

Entonces, esta decisión en realidad aporta más "flexibilidad y velocidad" a la ecuación. Lanzamiento más rápido para quién puede usarlos, comentarios, etc. Creo que es una gran adición a la paz lenta de net framework. La función estará realmente madura cuando llegue a NS.

Si tener netcore basado en netstandard 2 significa que las características se lanzan 1 año (o cualquier período de tiempo) más tarde, ¿la gente seguirá argumentando que quieren esto? Este es el escenario al que estamos acostumbrados con NET Framework .

Este es un paraíso para el equipo de aspnet, poder enviar cosas sin depender de otra persona, y también es una gran noticia para los clientes que pueden obtener esas cosas rápidamente. Si no puede ir con las cosas rápidas, apegarse a la versión anterior es una compensación razonable (y una motivación para que usted o sus dependencias actualicen).

Los autores de la biblioteca aún deben apuntar a netstandard, y si puede, no se preocupe en absoluto.
Si necesita algo que no esté en netstandard (tal vez páginas de afeitar (?)), entonces debe apuntar a netcore, en el escenario 1, es posible que las páginas de afeitar ni siquiera existan. No veo cómo esto puede ser malo, yo diría que es justo.

Entonces, la pregunta es, ¿qué dependencia tiene en este momento que lo limita de pasar de NET Framework a Net Core?
Puede que sea el único aquí, pero nunca esperé que aspnet core funcionara en NET Framework para siempre, era obvio para mí que este era un paso de "transición". Todo mi desarrollo que actualmente necesita NET Framework es splited . (y no, esto no son microservicios, es mucho más simple que eso).

la compatibilidad con 2.x y la eliminación de 3.x no es diferente de la compatibilidad con 1.x y la eliminación de 2.x. Adivinaré aquí y diré que la gente no está entendiendo el escenario claramente, así que espero que esto aclare al menos algo.

@NickCraver dijiste que quieres que Microsoft revierta esta decisión. ¿Cuál sería su sugerencia para no tener un netcore aislado y tener lanzamientos de funciones más lentos? (pregunta honesta)

@davidfowl Creo que puede haber un problema oculto sutil con la propuesta actual que preocupa a los desarrolladores.
Si tiene la característica A para asp.net (con netcore), entonces puede comercializar y enviar (y marcar una casilla de verificación de gestión/pm) y ser "perezoso" para implementar en netstandard, si no me equivoco, esto es lo que "apuesta" en incierto se arbitra aquí.
Entonces, en mi ejemplo anterior, netstandard implementa la función A puede estar en 2019 o 2020, o nunca en lugar de 2018. <-- esto parece un posible problema (?) ¿Tengo razón? ¿Puede Microsoft comprometerse con algo aquí?

Si bien todos podemos diferir sobre si nos gusta el anuncio, gracias a @davidfowl @DamianEdwards y @shanselman por dedicar tiempo a discutir. Es una prueba más de un mayor compromiso y apertura.

Estoy seguro de que algunos discutirán sobre el tiempo, etc., pero es un progreso.

Ejemplo:
2017 asp.net quiere la función A.
2018 netstandard implementa la Característica A. Obtenemos la Característica A en ns.

Lo que dice el equipo es tener netcore no basado en netstandard, así que:
2017 asp.net quiere la función A
El equipo de aspnet de 2017 implementa la función A. Asp.Net Core obtiene la función A en netcore.
2018 netstandard implementa la Característica A. Obtenemos la Característica A en ns.

lo que debieron haber hecho es:
El equipo de aspnet de 2017 crea la función necesaria en lib X, que es compatible con netstandard2.0. De esta manera, aspnet funciona en todo lo que se ejecuta en .netstandard, y los usuarios pueden ejecutarlo en .net full, ya que lib X también se puede usar en .NET full (es solo una instalación nuget).

En cambio, no hacen esto, obligan a lib X a ser solo .NET core (de lo contrario, ¿por qué este hilo/decisión en primer lugar). Si lib X es tan superavanzada que necesita funciones de CoreCLR, Microsoft debe preguntarse por qué estas funciones avanzadas no se transfieren a .NET full CLR.

En general, se siente como una política en la que MS necesita un núcleo .NET core/aspnet de movimiento rápido para proporcionar a los clientes de Azure una pila que se puede usar en contenedores en Azure para que compita con los contenedores basados ​​en JVM/NodeJS en AWS o la nube de Google. Desde su perspectiva comercial, incluso puedo entender eso. Pero lo que muestra es que MS no tiene prioridad con respecto a .NET full para avanzar más rápido, ya que no pone suficientes recursos en .NET full para mantenerse al día con .NET core. Mire la cantidad de API agregadas a .NET por completo en los últimos 2 años. ¿Eso te dice que un gran equipo está trabajando en eso?

No.

Microsoft vende un gran sistema de base de datos, SQL Server Enterprise. Viene con características de encriptación de lujo. No compatible con .NET core. Diviértase vendiendo .NET core 2.0 a las empresas que son los clientes potenciales de ese costoso sistema de base de datos.

Es posible que desee moverse 'rápido', pero a menos que comprenda completamente el destino hacia el que se dirige, ayuda tomarse uno o dos minutos para decidir eso primero.

Cuanto más lo pienso, más creo que el problema que tiene la mayoría de la gente es que sienten que estamos cortando el cordón entre .net y asp.net.
Actualmente tenemos asp.net, asp.net core (.net) y asp.net core (core). Así que podías elegir si querías ir sin núcleo, poco o completo.

Dado que el control de versiones está mal comunicado, las personas sienten que solo la última parte está innovando y avanzando, mientras que asp.net y asp.net core (.net) están atascados.
Dado que no tenemos forma de validar si una lib funcionará en netstandard2.0 sin intentarlo, se vuelve muy arriesgado utilizar el núcleo completo en un nuevo proyecto. Entonces terminan con asp.net (antiguo) o asp.net core (también antiguo).
Y dado que ambos son antiguos, tiene sentido simplemente ir con system.web y asp.net antiguo. Ya que saben eso y dado que asp.net core es EOL de todos modos, ¿por qué molestarse?

Así que terminamos con solo los valientes que eligen el núcleo, y el resto se va con system.web antiguo pero estable. Y siempre estaremos atrapados en un ecosistema aún más fracturado.

PD: Estoy redactando esto como con el sentimiento actual. Que asp.net core 1.x es "antiguo y desactualizado" frente a 2.x. No es que sea un hecho, pero eso es lo que la gente está pensando.

@davidfowl

Si cada plataforma .NET se mueve a su propio ritmo, usar el estándar .NET más reciente significa que los marcos de trabajo más lentos obtienen las cosas con menos frecuencia.

Esto ya sucede, y estamos de acuerdo con eso. El documento Versiones normalmente se rellena con _vNext_. Y eso está bien. En lugar de esperar hasta que todas las plataformas estén a la par antes de incrementar el estándar, prefiero ver el estándar definido unas cuantas versiones más adelante y ver cómo las plataformas se ponen al día. Las personas pueden incluso colaborar en la definición e implementación. Y si ASP.NET Core apuntó al estándar para sus lanzamientos, en el momento en que una plataforma y una arquitectura implementaron ese nuevo estándar, el paquete estaría disponible. Las nuevas versiones estándar podrían llegar a través de actualizaciones o paquetes de VS.

La forma en que se presenta, aunque .NET Standard no parece un esfuerzo planificado por la comunidad. Es más como una instantánea de los contratos implementados que pasaron la revisión. Y si los principales proyectos no lo apuntan, no habrá tanta planificación para sus lanzamientos.

hacemos lo mismo

Oh Dios. La miseria compartida es la mejor miseria. Los archivos csproj y sln con las cosas de plataforma/configuración son realmente molestos, por cierto, porque las combinaciones de compilación no siempre se declaran, se infieren. Entonces, VS podría pensar que tengo más combinaciones de compilación de las que realmente existen porque asume que todas las combinaciones posibles son importantes. Y tengo que tener secciones adicionales en el archivo que no serían necesarias si pudiera declarar las combinaciones de plataforma/configuración. Por ejemplo, cómo puede usar funciones como Substring en los elementos csproj PropertyGroup para simplificar las propiedades personalizadas, pero esas condiciones se usan para determinar las configuraciones de compilación, por lo que debe tener los valores de cadena completos allí. Este tipo de cosas no deberían ser tan complicadas como lo son.

Pregunta honesta (esta soy yo, no Microsoft), ¿prefiere la compatibilidad sobre las nuevas funciones? En caso afirmativo, ¿por qué elegir ASP.NET Core?

Personalmente, no. Siempre que haya una manera de hacer lo que necesito hacer, no me importa volver a escribir el código siempre que no sea un gran esfuerzo con pocos beneficios o un PITA para probar. Así que elegiría lo que tenga más impulso y potencial. Pero tengo que trabajar con proyectos en múltiples tecnologías: Win32, COM, CORBA, ADO.NET, varios motores de informes, varias API web, navegadores integrados como CEF/Firefox/IE (sin borde, por supuesto, ya que no es compatible) y múltiples cosas específicas del proveedor que evitaré avergonzar. Implemento lo que puedo como un complemento, pero estoy casado con el mínimo común denominador en el ejecutable del host, en su mayor parte. Tratar con tantas tecnologías es molesto, pero son estáticos. Así son muchas cosas de escritorio/servidor. Siempre que tenga las herramientas para la interoperabilidad, puedo arreglármelas. Pero cuantos menos marcos obsoletos recuerde, mejor.

ASP.NET, sin embargo, es parte de la pila web, y la pila web es algo que creo que debe mantenerse actualizado. Tiene un caso de uso diferente, y hay una expectativa desafortunada de usar la plataforma más nueva para el trabajo web a menos que haya una buena razón para no hacerlo, o una base de código significativamente incompatible. Trato de mantener eso actualizado porque los estándares web cambian rápida y significativamente. La mayoría de las personas que siguen el ritmo de la web se quedan con la tecnología más nueva, y la implementación de las cosas nuevas en las pilas más antiguas puede ser bastante dolorosa. Especialmente en la situación en la que ASP.NET compite con PHP y Node, debo mantener una pila más moderna para atraer talento e interés. Me encantaría hacer menos trabajo web, pero desafortunadamente es la nueva expectativa de la interfaz de usuario. Tenía la esperanza de que cumplir con el estándar me permitiría tener lo mejor de ambos mundos, pero parece una oferta por tiempo limitado.

así que si lo entendemos correctamente, eventualmente tendremos netstandard reemplazando net framework.

No eso no es correcto. No estoy seguro de cómo llegaste a esa conclusión. .NET Standard siempre será un subconjunto de cada uno de los tiempos de ejecución que lo admiten.

Quiero lanzar algunas cosas locas aquí porque se ha mencionado varias veces. Lo que estoy a punto de decir no tiene nada que ver con lo que sucederá, todo es especulación en este momento. Varias personas preguntaron por qué queremos apuntar a .NET Core en lugar de .NET Standard.

• Hemos identificado las cadenas como una de las principales cosas que nos gustaría tratar de abordar en .NET Core, hay muchas ideas, pero una de ellas es que la cadena sea utf8 de forma predeterminada (muchos problemas de compatibilidad, pero síganme aquí).
• Otra cosa que nos gustaría arreglar es la capacidad de tomar porciones baratas de arreglos/cadenas, cualquier pieza de memoria contigua. Agregamos Span<T> y buscamos Buffer<T> para representar esto. Podría significar que String y Array implementan nuevas interfaces que hacen posible tomar un segmento que requiere una asignación 0.
• Esto conduce a nuevos métodos en String que permiten la división que no asigna una matriz cada vez.
• Esto conduce a sobrecargas en Int, UInt, etc. (TryParse) que toman Span<char> y Span<byte> .
• Esto conduce a nuevas rutinas de codificación que toman Span<byte> .
• Buffer<T> y Span<T> le permiten representar la memoria de una manera uniforme y queremos actualizar la pila de redes para permitir el paso de búferes prefijados que toman Span<T> o Buffer<T> .
• Kestrel implementará HTTP2 en el marco de tiempo 2.x (actualmente apunta a 2.1) y eso requiere nuevas API en flujo SSL para hacer ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• Http Client en .NET Core es compatible con la transmisión dúplex, lo que permitirá implementar puntos finales de transmisión a través de http en Signalr a través de una única solicitud de http sin websocket.
• Bifurcamos las implementaciones del analizador de encabezados de HttpClient y System.Net.Http y las renombramos (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) para poder mejorarlas y hacer que admitan tanto .NET Framework como .NET Core. .NET Core tiene una copia de estas mejoras que no se han devuelto porque no hay necesidad de mejorarlas (no pudimos consumirlas).
• Hay un montón de nuevas primitivas de subprocesos que requieren una nueva API que iluminará nuevos escenarios si podemos consumirlos (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl+label%3Aarea-System.Threading), esas son solo algunas de las cosas que he archivado personalmente.

Sin la capacidad de acelerar las primitivas básicas, se nos anima a bifurcarlas y hacer cosas que se parezcan a ellas pero que no lo sean. Es la razón por la que tenemos nuestro propio pequeño BCL dentro de ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Eso fue solo un volcado aleatorio de cosas que puedo ver que haremos en el corto plazo que afecta partes muy fundamentales de .NET.

@FransBouma

NET full para avanzar más rápido, ya que no pone suficientes recursos en .NET full para mantenerse al día con .NET core. Mire la cantidad de API agregadas a .NET por completo en los últimos 2 años. ¿Eso te dice que un gran equipo está trabajando en eso?

Eso no es cierto. Las cosas se transfieren continuamente a .NET Framework pero, como todos sabemos, el riesgo es considerablemente mayor que hacer esos mismos cambios en .NET Core. ¿No odian todos cuando una actualización de .NET Framework rompe su aplicación? Nosotros también lo hacemos, así que inventamos todo tipo de procesos para mitigarlo, no creerías el estrangulamiento que impone a la ingeniería para mantenerlo. Todavía logramos hacer funciones a pesar de todo. Dicho esto, simplemente nunca se moverá tan rápido como .NET Core, es un componente de Windows que se envía según el cronograma de Windows.

Lo entiendo, pero no creo que haga una diferencia en su capacidad para portar algo realmente. La misma política EOL todavía existe.

@davidfowl Correcto. Pero cómo lo enmarcas significa algo. Sin mencionar cuándo se comunica , si es que alguna vez. No necesariamente le dará a la gente más tiempo para hacer el trabajo real, pero les dará más tiempo para pensar y tomar la decisión correcta (para ellos).

Actualmente, si ha comenzado a migrar o usar ASP.NET Core en .NET Framework, parece que tiene tres opciones:

1. Porte todo su código y dependencias a .NET Core y muévase a ASP.NET Core 2.x.
   
   
   
   • Esta sería la solución óptima, pero podría requerir toneladas de trabajo y, para algunos, incluso podría estar fuera de su control debido a las librerías de terceros.
   
   
2. Manténgase en ASP.NET Core 1.x y .NET Framework y espere poder hacer 1. antes de que no sea compatible.
   
   
   
   • Esto es bastante arriesgado. Dentro de un año (¿o dos, o tres? ¿quién sabe?), podría correr el riesgo de ejecutarse en una plataforma no compatible.
   
   
3. Volver a ASP.NET 4.x
   
   
   
   • Si bien esta alternativa lo deja respaldado, estará "regresando" y deshaciendo el trabajo que ya comenzó. Y también, seamos realistas; esta plataforma no recibirá mucho amor en el futuro.
   
   

Si lo hubiera sabido de antemano y pudiera planificarlo, creo que tanto 1. como 2. son alternativas decentes. El tema es que ambas alternativas tienen bastantes incógnitas. ¿Qué pasa con la biblioteca A? ¿Qué pasa con la biblioteca B? ¿Se portará alguna vez la biblioteca A?

En este momento, creo que muchas personas sienten que se ven obligadas a tomar una decisión, sin tener una idea clara de lo que realmente implican las elecciones.

@khellang (en su solución hipotética)

1. Mover a ASP.NET Core 2.0 en .NET Framework
   
   
   
   • Esto es bastante arriesgado. Dentro de un año, podría arriesgarse a ejecutar en una plataforma no compatible.
   
   

@davidfowl

Pregunta honesta (esta soy yo, no Microsoft), ¿prefiere la estabilidad y la compatibilidad sobre las nuevas características? En caso afirmativo, ¿por qué elegir ASP.NET Core?

Respuesta honesta:
Favor: La estabilidad y la compatibilidad son primordiales. Las nuevas características son agradables, pero cuando aterrizan, simplemente no deben romper el ecosistema existente.
Por qué ASP.NET Core: simplemente porque se ejecuta en OS X y Linux.

Las empresas eligen un ecosistema como .NET (antiguo y/o central) o también Java. Y cuando toman su decisión, ponen mucho esfuerzo en desarrollar código para esa plataforma/ecosistema.

Ahora, uno de nuestros clientes, por ejemplo, ya invirtió mucho en ASP.NET Core. Sobre la base de los anuncios anteriores y las ideas vendidas de .NET Core, se escribió el código. Este nuevo código de (ASP.)NET Core que escribimos (dolorosamente) con un equipo en el transcurso del desarrollo inicial de (ASP).NET Core, desde su concepción, es un conjunto de servidores y bibliotecas de clientes, con bastante de lógica empresarial.
Y este código, además de ejecutarse en un servidor Linux y proporcionar servicios, actualmente también se está utilizando en un conjunto de aplicaciones muy antiguas que se comunican con estos servicios, y estas son una mezcla increíble de WPF/Windows Forms/C++/CLI y normal. C++ (incluyendo cosas de DirectX).

Y ahora simplemente está cortando la inversión de nuestros clientes en bastantes años de esfuerzo en el código .NET Core para las aplicaciones existentes, ya que será imposible reutilizar el nuevo código .NET Core en las aplicaciones reales. (para los que se crearon los nuevos servidores y las bibliotecas de lógica empresarial).

Para volver a la pregunta: una empresa elegiría .NET Core como ".NET, ahora también para XPlat", esperando la misma compatibilidad y estabilidad que .NET nos brindó en los últimos 17 años. Y, para ser sincero, esta es la única razón de .NET Core. Si no quisiera eso, usaría Node.js o incluso Java. Ambos son mucho más maduros y XPlat que .NET Core ahora.

Y, solo para elaborar un poco más: .NET Core fue genial y rápido en las primeras etapas con project.json y todo. Y luego, por razones de "compatibilidad con .NET", project.json nos fue quitado a favor de Msbuild y .csproj nuevamente. Y ahora también se eliminan los beneficios de exactamente esta "compatibilidad con .NET", a favor de... ¿qué exactamente?

@gingters

En primer lugar, gran respuesta!

Por qué ASP.NET Core: simplemente porque se ejecuta en OS X y Linux.

Basado en eso, parece que MVC 5 en mono es lo que realmente querías, ¿verdad?

Para volver a la pregunta: una empresa elegiría .NET Core como ".NET, ahora también para XPlat", esperando la misma compatibilidad y estabilidad que .NET nos brindó en los últimos 17 años. Y, para ser sincero, esta es la única razón de .NET Core. Si no quisiera eso, usaría Node.js o incluso Java. Ambos son mucho más maduros y XPlat que .NET Core ahora.

Y, solo para elaborar un poco más: .NET Core fue genial y rápido en las primeras etapas con project.json y todo. Y luego, por razones de "compatibilidad con .NET", project.json nos fue quitado a favor de Msbuild y .csproj nuevamente. Y ahora también se eliminan los beneficios de exactamente esta "compatibilidad con .NET", a favor de... ¿qué exactamente?

Este es básicamente el quid de la cuestión. Según su evaluación:

Este nuevo código de (ASP.)NET Core lo escribimos (dolorosamente) con un equipo durante el transcurso del desarrollo inicial de (ASP).NET Core.

Realmente solo quería el .NET Framework existente en Linux con una buena compatibilidad con ASP.NET 4.x. ¿Es ese un resumen justo?

Favor: La estabilidad y la compatibilidad son primordiales. Las nuevas funciones son agradables, pero cuando aterrizan, simplemente no deben romper el ecosistema existente.

.NET Core es en realidad una plataforma más estable que Desktop, ya que permite la ejecución en paralelo donde Desktop no lo hace.

Si desea usar funciones más nuevas en la próxima versión de Desktop, debe actualizar toda la máquina a esa nueva versión y eso afecta todo en esa máquina, no solo la aplicación que quiere usar las funciones más nuevas. Lo cual está bien si tiene un servidor dedicado para un solo propósito; pero no si tiene muchas aplicaciones ejecutándose en el mismo servidor que se actualizan a diferentes velocidades (¡o nunca se actualizan!)

@davidfowl escribió:

Depende de los marcos decidir si quieren ejecutarse en .NET Framework, UWP, .NET Core, mono, etc. Es una elección. Orleans no incluye .NET Core. ASP.NET Core sí. Esos productos son uno y el mismo.

En el caso de Orleans, admitimos .NET Standard 1.5 en nuestras compilaciones "2.0 Technical Preview", pero hemos estado esperando .NET Standard 2.0 para poder hacer una versión estable. En este momento no veo ningún bloqueo para nosotros; mi preocupación es solo sobre la futura divergencia. Sin embargo, esa divergencia tiene que ocurrir en algún momento.

👍 ¡Muchas gracias por quedarse para responder las preguntas de todos, @davidfowl & co!

NET full para avanzar más rápido, ya que no pone suficientes recursos en .NET full para mantenerse al día con .NET core. Mire la cantidad de API agregadas a .NET por completo en los últimos 2 años. ¿Eso te dice que un gran equipo está trabajando en eso?

Eso no es cierto. Las cosas se transfieren continuamente a .NET Framework pero, como todos sabemos, el riesgo es considerablemente mayor que hacer esos mismos cambios en .NET Core. ¿No odian todos cuando una actualización de .NET Framework rompe su aplicación? Nosotros también lo hacemos, así que inventamos todo tipo de procesos para mitigarlo, no creerías el estrangulamiento que impone a la ingeniería para mantenerlo. Todavía logramos hacer funciones a pesar de todo. Dicho esto, simplemente nunca se moverá tan rápido como .NET Core, es un componente de Windows que se envía según el cronograma de Windows.

eso ignora el hecho de que puede liberar las bibliotecas de las que depende como paquetes netstandard2.0 para que aspnet también pueda ejecutarse en .net completo. Además, hacer cambios en .NET completo no está exento de riesgos, pero no haga que suene como si fuera una pila de código terriblemente organizada donde un cambio puede hacer que todo se derrumbe.

Todavía logramos hacer funciones a pesar de todo.

Sí, también lo hacen todos los demás desarrolladores de .NET;) Una vez que lanzas algo, te quedas con esa API, todos tenemos esto. Sin embargo, desea tomar un atajo (¡como lo ha hecho el equipo de ASPNET muchas veces antes!) y moverse sin esa carga. Pero eso no va a volar al final.

Dicho esto, simplemente nunca se moverá tan rápido como .NET Core, es un componente de Windows que se envía según el cronograma de Windows.

Creo que aquí tenemos el quid de la cuestión, ¿no? El equipo central de .NET puede hacer lo que quiera sin comunicarse con el gigante 'WinDiv'. ¿Por qué Microsoft no resuelve esta mierda de política interna internamente y se asegura de que .NET full + .NET core estén versionados / se muevan correctamente sin la política de Windows?

Por cierto, todavía estoy interesado en cómo vendería la API de cifrado de SQL Server Enterprise a los usuarios de .NET core 2.0.

Además, debo agregar; Estoy bastante impresionado de cuánto ha durado este hilo, con tanta gente involucrada, sin dejar de ser civilizado ❤️ Eso no es algo que se ve todos los días en Internetz 👏 ¿Quizás el ecosistema .NET OSS está creciendo después de todo? 😉

eso ignora el hecho de que puede liberar las bibliotecas de las que depende como paquetes netstandard2.0 para que aspnet también pueda ejecutarse en .net completo.

Además, hacer cambios en .NET completo no está exento de riesgos, pero no haga que suene como si fuera una pila de código terriblemente organizada donde un cambio puede hacer que todo se derrumbe.

Es grande y existe desde hace mucho tiempo. Como cualquier sistema heredado, algunas partes son mejores que otras. No hace que el código sea menos confiable, pero hace que algunas partes sean prácticamente imposibles de cambiar. Hay tantas historias divertidas que los veteranos pueden contarle sobre cómo las correcciones de errores en un área rompieron escenarios oscuros en aplicaciones en otras partes. Está enredado, eso es lo que sucede cuando los límites de dependencia no están bien definidos. Ni siquiera tiene que creerme, simplemente vaya y navegue por referencesource.microsoft.com. Las actualizaciones en el lugar son la razón por la que necesitamos agregar un interruptor de configuración para cada cambio potencialmente importante en .NET Framework. Es física, simplemente no puede moverse tan rápido.

Sí, también lo hacen todos los demás desarrolladores de .NET;) Una vez que lanzas algo, te quedas con esa API, todos tenemos esto. Sin embargo, desea tomar un atajo (¡como lo ha hecho el equipo de ASPNET muchas veces antes!) y moverse sin esa carga. Pero eso no va a volar al final.

¡Nos encantan los atajos! Los desarrolladores son vagos 😄 . También queremos mejorar genuinamente nuestro .NET Core sin interrumpir lo que representa .NET Framework. Tal vez deberíamos haberlo renombrado a algo más, como Sparkle 😄.

Creo que aquí tenemos el quid de la cuestión, ¿no? El equipo central de .NET puede hacer lo que quiera sin comunicarse con el gigante 'WinDiv'. ¿Por qué Microsoft no resuelve esta mierda de política interna internamente y se asegura de que .NET full + .NET core estén versionados / se muevan correctamente sin la política de Windows?

Lee mi otra respuesta sobre física.

Por cierto, todavía estoy interesado en cómo vendería la API de cifrado de SQL Server Enterprise a los usuarios de .NET core 2.0.

Esa no es mi área de especialización, dejaré que alguien más responda eso.

@khellang jajaja, eso se debe a que los problemas de GitHub aún no han atraído a los trolls que odian a MS. Actualmente, Twitter es su medio para eso donde aún no hay votos negativos :)

@davidfowl

Realmente solo quería el .NET Framework existente en Linux con una buena compatibilidad con ASP.NET 4.x. ¿Es ese un resumen justo?

No en realidad no. Nuestro cliente requería servicios completos nuevos/brillantes (micro), para complementar sus aplicaciones de escritorio de Windows .NET 4.x existentes (eran 3.5 cuando comenzamos).

Cuando pasó a la versión beta con todas las cosas brillantes de Core, comenzamos a escribir el nuevo código de servidor para el MVC completamente nuevo sobre ASP.NET Core junto con el DTO, la lógica comercial y las bibliotecas de clientes que lo acompañan, que también están siendo se usa en paralelo en las aplicaciones de escritorio 4.6 existentes para comunicarse con los servidores completamente nuevos.

Además, algunos de los nuevos servidores ASP.NET Core no se ejecutan solo en Linux, sino también como servicios de Windows con Topshelf (además del marco completo 4.6).

Entonces, la cosa es que se hizo una gran inversión, y ahora parece que estamos atascados con .NET Core 1, ya que pasar a 2 (y perder netstandard) también significaría que no podemos reutilizar los ensamblajes en el aplicación de escritorio existente (para los que se crearon los servicios y las bibliotecas correspondientes).

Por lo tanto, lo más importante para nosotros sería poder seguir usando las nuevas bibliotecas (ASP).NET Core que escribimos en las aplicaciones de escritorio .NET 4.6 (porque para eso fueron creadas), al mismo tiempo que podemos permanecer en un sistema compatible. Versión de .NET Core siempre que se admita la versión de escritorio de .NET, donde se puede ejecutar el código.

Por lo tanto, siempre que .NET Core 1. sea compatible como lo es .NET 4.6, y haya una ruta de actualización lineal a .NET Core x cuando salga .NET 5, y el código .NET Core x sea capaz de ejecutarse en . NET 5, entonces estamos bien.

@gingters ¿Está utilizando funciones de .net que no están en netstandard2.0 en los servicios de asp.net?

Si no es así, las bibliotecas deberían funcionar. Pero supongo que estás hablando de cosas que no están en netstandard2.0.

@davidfowl ¿Funcionarán c++/cli dlls en netcoreapp 2.0? Tenemos ensamblajes antiguos de C++/CLI de terceros que no se reemplazarán antes.

@davidfowl escribió:

ASP.NET Core 2.0 honestamente no tiene tantas características nuevas

En cuyo caso, ¿por qué este cambio tan disruptivo ahora?

@qrli C++/CLI no funciona en CoreCLR. Aquí hay algunos antecedentes sobre por qué no será compatible: https://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

Ofrezca 4 años de soporte a 1x (portando tanto como sea posible desde 2x) y siga adelante y rápido con 2x. Un coche de ciudad para el tráfico lento de la ciudad y un Ferrari para las autopistas. Tenemos mucha competencia fuera del mundo .net.
Si ASP.Net Core tiene éxito, estoy seguro de que MS brindará los recursos para admitir 1x durante 4 años. Sobre todo la cultura va a cambiar.

@ idg10 Realmente no lo es. 2.x es más o menos 1.x con cosas de rendimiento que solo están disponibles en el núcleo. Creo que la única característica principal es Razor Pages.

Por lo tanto, estar en la versión 1.x no significa que esté en una versión desactualizada. Pero esto no se ha comunicado muy bien.

En cuyo caso, ¿por qué este cambio tan disruptivo ahora?

Supongo que esto lo resume bastante https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

@hallatore
Sé que funciona, como lo hace _ahora_. Podemos quedarnos en 1 por ahora. El problema va para adelante. Cuando queremos (o peor: necesitamos) actualizar a las bibliotecas (ASP).NET Core 2 (es decir, cuando 1 queda fuera de servicio y se soluciona un problema de seguridad crítico), nos enfrentamos al problema de que no podemos actualizar, ya que esto haría imposible usar nuestras bibliotecas que necesitan los paquetes actualizados en las aplicaciones de escritorio .NET.

Editar/agregar: a menos que haya un nuevo marco completo de .NET que sea capaz de ejecutar las nuevas bibliotecas fijas de .NET Core que se encuentran en una ruta de actualización lineal para la aplicación de escritorio heredada existente.

@gingters No estoy seguro de entender.

Si sus bibliotecas de escritorio funcionan con netstandard2.0, también deberían ejecutarse en el núcleo. (si invocan cosas de wpf, etc., por supuesto que no lo harán)
Si este es el caso, entonces debería poder usar asp.net core 2.0.

Si sus bibliotecas de escritorio fallan en el núcleo porque usan cosas que no están en netstandard2.0. Entonces veo por qué necesitas quedarte en 1.x. Y veo por qué el EOL corto es un problema.

¿Sería 1.x una opción más fácil/mejor si supiera que 2.x solo contiene principalmente cosas de rendimiento central (lo que significa que 1.x no está desactualizado frente a 2.x). ¿Y que 1.x recibirá parches y será compatible durante * años?

@hallatore Es al revés. Aplicación antigua: Mezcla de Windows Forms, WPF, C++/CLI, C++ normal, DirectX, millones de líneas de código, etc. pp, ejecutándose en el marco completo 4.6.

En .NET Core: nuevas bibliotecas de lógica empresarial (usando también otras bibliotecas, es decir, la versión .NET Core de Serilog), bibliotecas de abstracciones + servicios + bibliotecas de clientes para estos servicios. Los servicios deben ejecutarse en Linux y como servicios de Windows (actualmente Topshelf en el marco completo de .NET 4.6, aunque podría cambiarse tan pronto como el soporte del servicio de Windows llegue a Core).

Ahora, las nuevas abstracciones y lógica empresarial, así como las bibliotecas de clientes de servicio, también se consumen desde las aplicaciones .NET 4.6. Esto significa que no somos capaces de actualizarlos, ya que necesitarán ejecutarse en el framework .NET completo siempre que lo haga la aplicación de escritorio (que podemos suponer que será más o menos durante el tiempo que dure un escritorio, a menos que el framework completo desaparece en general).

@gingters Todavía puede tener los proyectos de biblioteca compartida en su solución dirigidos a netstandard _min (usable)_ y consumir esas bibliotecas de su código ASP.NET Core 2.0, así como empaquetarlas para usarlas desde WPF, Xamarin, UWP, lo que sea.

Es realmente triste que ustedes, muchachos de MS, todavía no entiendan el punto. todavía piensas que es solo un problema de brecha de API. Todavía piensas que la gente puede simplemente modificar su código y funcionará en netcoreapp... Pensé que entendías a las empresas mucho mejor que Google.

Basado en eso, parece que MVC 5 en mono es lo que realmente querías, ¿verdad?

@davidfowl Quiero decir, vamos. Esa es una respuesta desdeñosa y francamente insultante. ¿Alguien en MS puede confirmar que un solo desarrollador ya está asignado a Framework ASP? No estoy tratando de ser un idiota aquí, pero parece que a veces se habla mal de la comunidad.

No hay ninguna razón bajo el sol por la que deba considerar .Net Core y ASP.Net Core como el mismo producto. No ha habido ningún mensaje para apoyarlo en absoluto. Especialmente cuando considera que Mono quedó bajo el ala de Microsoft _después_ del anuncio de .Net Core. Siempre ha sido anunciado como la versión xplat más pequeña, ágil y de .Net. No solo eso, sino que todos recordamos los días en que ASP.Net Core era en realidad ASP.Net 5 y funcionaba en todas partes. Diablos, ese cambio es hace poco más de un año y medio.

¿La historia HTTP autohospedada en netstandard20 "usa Kestrel 1.x" de manera efectiva? No estoy seguro de que a la gente de Nancy le importe mucho eso, y a mí tampoco. ASP.Net 2.x puede ser incremental en cuanto a funciones, pero Kestrel 2 tiene un gran beneficio de rendimiento que podríamos usar seriamente el día en que se implemente. sale.

@davidfowl

Es grande y existe desde hace mucho tiempo. Como cualquier sistema heredado, algunas partes son mejores que otras. No hace que el código sea menos confiable, pero hace que algunas partes sean prácticamente imposibles de cambiar. Hay tantas historias divertidas que los veteranos pueden contarle sobre cómo las correcciones de errores en un área rompieron escenarios oscuros en aplicaciones en otras partes. Está enredado, eso es lo que sucede cuando los límites de dependencia no están bien definidos.

Creo que este es un comentario interesante. Recuerdo haber visto una grabación de una sesión de conferencia NDC más antigua con @davidfowl y @DamianEdwards separando el legado en ASP.NET 4 que realmente quería dejar atrás; fue realmente fascinante echar un vistazo dentro de esa caja negra de código.

Pero creo que este comentario también refleja las preocupaciones que muchos de nosotros tenemos con nuestras propias bases de código. Mantenemos grandes sistemas heredados, a menudo no bien diseñados con límites de dependencia deficientes. Es prácticamente imposible reescribir algunos de estos sistemas para .NET Core. El negocio simplemente no permitirá el riesgo de tanto cambio.

No sé cuál es la respuesta correcta. Pero sé que para nuestras propias aplicaciones, usaremos el marco completo y ASP.NET4/MVC5 en el futuro previsible (¡todavía tenemos una parte de WebForms que no se reescribirá por bastante tiempo!). Espero ver que MVC5 obtenga algo de amor ahora que _finalmente_ se mudó a GitHub ; incluso estoy dispuesto a donar mi propio tiempo y esfuerzo para mejorarlo (por ejemplo, mejor soporte asíncrono, mejoras de rendimiento, etc.).

@qrli Enterprises todavía tiene .NET 4.5 completo para ejecutar en sus Windows Server 2008 R2 IIS 7.5 Web Farms. Nadie les quita eso.

@mattnischan

¿La historia HTTP autohospedada en netstandard20 "usa Kestrel 1.x" de manera efectiva? No estoy seguro de que a la gente de Nancy le importe mucho eso, y a mí tampoco.

HttpListener es parte de netstandard20, por lo tanto, netcore20 no se quita nada en ese frente al pasar a netcore20.

HttpListener es parte de netstandard20 por lo tanto también netcore20.

¿Y supongo que puedo esperar las mismas solicitudes por segundo de HttpListener ?

@markrendle Cierto. Por ahora.

Pero, ¿qué sugeriría cuando otra biblioteca utilizada por nuestro material compartido (es decir, serilog, newtonsoft, autofac, etc.) deja de admitir netstandard_min (utilizable), (tal vez solo porque sienten que es demasiado esfuerzo para admitir ambos mundos) y ¿Se ha detectado un problema de seguridad crítico en la última versión que aún es compatible con el marco completo?

@mattnischan

HttpListener es parte de netstandard20, por lo tanto, también netcore20.

¿Y supongo que puedo esperar las mismas solicitudes por segundo de HttpListener?

Entonces, Nancy es .NETStandard 1.6, por lo que puede usarlo en Core 2.0 y usar Kestrel 2.0. ¿Mejor?

@gingters Sugeriría cruzar ese puente cuando llegues a él.

Nunca dejes que el futuro te perturbe. Lo enfrentarás, si es necesario, con las mismas armas de la razón que hoy te arman contra el presente.
_~ Marco Aurelio_

Ese no es un mantra tan útil cuando se entrega software que no tiene presupuesto de mantenimiento y debe usarse prácticamente sin cambios en los años venideros.

Si debe permanecer prácticamente sin cambios en los años venideros, ¿por qué importa lo que suceda con las bibliotecas de las que depende en esos años venideros?

@markrendle Ahora suponga que está obligado, por ley (al menos en algunos países), a proporcionar protocolos de emergencia exactamente para estos casos, antes de que se envíe una versión de la aplicación, ya que podría usarse en entornos donde la vida de las personas podría estar en juego. .

Entonces, ¿quiere un servidor web que sea tan rápido como Kestrel y su único requisito específico es que no sea Kestrel?

Entonces, Nancy es .NETStandard 1.6, por lo que puede usarlo en Core 2.0 y usar Kestrel 2.0. ¿Mejor?

@markrendle @benaadams No, creo que no entendiste, y de nuevo, no intento ser un idiota, solo señalo que hay otros clientes de piezas de ASP.Net Core que no son todo. Me gustaría alojar nuestra plataforma de producción sobre Kestrel 2.0 cuando salga, y nuestra plataforma de producción podría estar en Framework por un tiempo. No puedo orientar netcoreapp20.

Nancy puede ser netstandard16 pero no importa porque no puedo usar Kestrel 2.0 excepto en Core 2.0. Me doy cuenta de que esto es específico, y tal vez la respuesta sea realmente "luego escriba su propio servidor web que funcione en un marco que sea tan rápido como Kestrel 2. Kestrel es solo para ASP.Net". Pero odiaría que ese fuera el mensaje.

@gingters @gulbanana No entiendo cómo se va a romper una aplicación enviada con un conjunto fijo de dependencias porque un proyecto de código abierto deja de admitir una versión arbitraria del marco subyacente en una fecha futura putativa.

@mattnischan Sí, descubrí lo que querías decir y eliminé ese comentario :)

@stefanolson

Debido a que necesito compartir código entre el servidor y mis aplicaciones de escritorio, ¿eso significa que nunca podré tener la última versión de ASP.Net?

Si apunta a .NET Standard con sus bibliotecas, puede usarlas tanto en Desktop como en Core. Para las bibliotecas destinadas a .NET Standard, entonces tiene soporte de plataforma universal: Desktop, Core, Mono, Unity, UWP, Tizen, etc.

Una aplicación ASP.NET es un ejecutable; el punto final, no es una biblioteca. El resultado final, la aplicación/ejecutable ASP.NET debe ejecutarse en una plataforma. Eventualmente, cualquiera de sus bibliotecas de plataforma será consumida por la aplicación ASP.NET, por lo que no hay ninguna ventaja en que no sean el mismo objetivo que la plataforma.

.NET Core es una buena plataforma ya que tiene una amplia cobertura multiplataforma; se puede instalar junto con Desktop y se puede actualizar de forma independiente aplicación por aplicación; en lugar de toda la máquina y cada aplicación.

Algunos artículos tienen usos en el exterior; entonces Wyam usa Razor para la generación de sitios estáticos; Actualmente, Razor es .NET Standard 1.3, por lo que consumirlo fuera de Core no es un problema actualmente.

Hay algunos casos extremos mencionados anteriormente:

Uso de bibliotecas que no admiten el conjunto de características de .NET Standard 2.0. Con suerte, muchas de ellas son brechas que se pueden llenar, y al comienzo de este problema, MS preguntaba cuáles eran esas brechas para poder priorizarlas.

Ejecutar una aplicación web integrada, por ejemplo, en una aplicación para UWP; sin embargo, si Desktop aún fuera compatible pero se cambiara a la versión 4.7.1, aún estaría en la misma situación, ya que UWP actualmente no es compatible con 4.7.1 y, para cuando lo hiciera, ASP.NET requeriría 4.7.2, luego 4.7. 3, etc. Sería una tarea de Sísifo ya que las otras plataformas nunca lo captarían; entonces, ¿sería solo un trabajo ocupado sin mucho sentido?

Sí, me di cuenta de lo que querías decir y eliminé ese comentario :)

No se preocupe, buen señor. 👍

@davidfowl

¿Cómo afectan las versiones aceleradas de ASP.NET Core? Si elimináramos el soporte de .NET Framework en 3.0 (como la gente parece estar eludiendo en este hilo), ¿no estaría usted en el mismo callejón sin salida de todos modos? Tendría su aplicación ASP.NET Core 2.0 portada ejecutándose en el marco durante un año y cuando salga 3.0, no podrá actualizar. Podría hacer esto de todos modos con ASP.NET Core 1.1.x, que se ejecuta en .NET Framework y es compatible incluso cuando ASP.NET Core 2.0 no está disponible.

Solo decir (según tengo entendido) que "en algún momento necesitábamos romper con .net completo, ¿por qué no ahora?" Falta un punto importante. Estoy seguro de que mucha gente estaba esperando el lanzamiento de Core 2.0. Porque se prometió públicamente muchas mejoras en la compatibilidad con .net completo. Muchos autores de bibliotecas también están esperando para comenzar la migración al núcleo. Entonces, supongo que después del lanzamiento de Core 2.0, migraremos muchas más bibliotecas en Core. Y entonces vincular el núcleo de asp.net con el núcleo 3.0 sería mucho menos frustrante para el ecosistema de lo que es ahora. Porque en el momento de 3.0, estos deberían bloquear menos las cosas para que no migren al núcleo.
Ahora mismo es un desastre.

Anteriormente, estaba evaluando iniciar la migración de nuestro marco (una historia muy similar a la que describió @benaadams ) a core/asp.net core en dos pasos: migrar el elemento web (que ahora está en mvc/webapi) a asp.net core y mantenerlo completo .net y luego migre todas las demás cosas en el núcleo cuando todas las dependencias tengan implementaciones correspondientes para el núcleo. Actualmente, lo que nos bloquea es el proveedor Oracle ADO y el proveedor Postgres ADO (podría haber otras incompatibilidades en corefx que aún no investigamos). Ahora este plan está muerto. Así que tenemos que sentarnos y esperar la migración de dependencias abandonando todas las cosas nuevas en Core world. Y todo esto es solo por el hecho de que alguien en MS decidió que necesitamos una plataforma que "se mueva rápido".

@markrendle La aplicación no se va a romper solo por eso. El tema es otro:
Debido a que .NET Core 2 eliminó el soporte para el marco completo (donde funcionó bien en la versión 1, y es de Microsoft donde no espera que se elimine una característica tan básica y elemental al actualizar a una nueva versión), también su las dependencias pueden dejar de admitir este escenario más temprano que tarde.
Alguien encuentra un problema de seguridad crítico en una de las bibliotecas utilizadas y no se emite ninguna actualización para la versión en la que está atascado, ya que las versiones más nuevas ya no son compatibles con su tiempo de ejecución. Ahora, dado que su aplicación se usa en un entorno muy regulado, debe proporcionar un plan de emergencia que explique qué hará exactamente cuando se detecte un problema de seguridad crítico y cómo implementar esa solución para evitar que las personas sufran daños o algo peor. Un "bueno, no podemos hacer nada" resultará en la revocación de su autorización para enviar esa solicitud.

@gingters Mire, el punto es que debe tomar sus decisiones tecnológicas en función de la información que está disponible actualmente y la naturaleza del mercado en el que opera su empresa. Con la mejor voluntad del mundo, no puedes dar cuenta de todas las eventualidades, por mucho que a los burócratas y reguladores del mundo les gustaría pretender que sí puedes. ¿Qué pasa si Apple adquiere Microsoft en una adquisición hostil y .NET se suspende por completo a favor de Swift? ¿Qué pasa si el cifrado fuerte se hace ilegal en uno de los países a los que vende y todas las pilas de software que incluyen SHA256 están prohibidas? ¿Qué pasa si Nicolás o James o _insertar-nombre-del-mantenedor-de-Autofac-aquí_ deciden mudarse a Marte y convertirse en agricultores de humedad? ¿Qué pasa si los polos magnéticos se invierten y se borran todos los bits de datos grabados digitalmente?

Como respuesta real a la pregunta de qué usted, como empresa, dice que hará en caso de que se encuentre un problema de seguridad crítico en JSON.NET (por ejemplo), en ausencia de una actualización oficial disponible, el único La respuesta posible es "bifurcaremos y parchearemos JSON.NET", que supongo que ya es la respuesta a la pregunta de qué haría si James Newton-King se indispusiera por algún motivo. En mi experiencia previa trabajando en ese tipo de mercados, había acuerdos de depósito en garantía para el código fuente en paquetes propietarios para ese tipo de eventualidad; qué hacer con los paquetes de código abierto es trivial en comparación con eso.

Y todo esto es solo por el hecho de que alguien en MS decidió que necesitamos una plataforma que "se mueva rápido".

"moviéndose rápido" podría ser una exageración; siguiendo el cronograma de lanzamiento anterior de Full Framework, podría decirse mejor como "sin agregar un retraso adicional de 1 a 2 años" en el envío. Eso es una cantidad loca de tiempo en el mundo web.

Las cosas están cambiando rápidamente y la plataforma debe seguir siendo relevante.

@davidfowl y @DamianEdwards Creo que toda esta confusión se debió al hecho de que ASP.NET Core 1.x puede ejecutarse en .NET Framework. Esto creó la suposición de que ASP.NET Core era la evolución de ASP.NET 4/MVC5; haciendo que las personas migren pensando que obtendrán todos los beneficios (velocidad y nuevas funciones) manteniendo la compatibilidad con versiones anteriores.

Entonces, tal vez la respuesta a largo plazo/permanente a este problema es volver a promover ASP.NET 4/MVC5 como la respuesta para las personas que buscan compatibilidad con versiones anteriores con soporte a largo plazo (y tal vez ofrecer también pequeñas mejoras).

Entonces, ASP.NET Core puede enfocarse en ser una nueva plataforma que rompe con el pasado para ofrecer enormes beneficios para aquellos que pueden dar el salto.

En ese sentido, (ASP).NET (Framework) y (ASP).NET Core serán dos caminos paralelos e igualmente válidos que los clientes pueden elegir. Y creo que así deberían haber sido las cosas desde el principio.

@markrendle Sí, esto es hipotético, pero lamentablemente la burocracia es algo real. Y sí, no puede (y no necesita) dar cuenta de todas las eventualidades. Solo para los que puedas anticipar.

Y ahora tenemos la situación de que a) la eliminación de una plataforma completa (.NET full framework), que era compatible con .NET Core 1 sin problemas, no era algo que pudiera anticipar. Sin embargo, dado que sucedió ahora, puede b) anticipar la caída del soporte para v1 en sus otras dependencias con un bastante seguro "sí, puedo ver que eso suceda más temprano que tarde".

Y sí, las correcciones de bifurcación y backporting son una de las posibles soluciones, sin embargo, esto es algo que desea evitar tanto como pueda. Si el equipo de .NET Core hubiera dicho algo como "Oye, mira, no pretendemos ejecutar el marco completo, no confíes en eso", o mejor aún, nunca lo hubiera hecho posible en primer lugar, toda esta discusión no sería necesario ya que el cliente simplemente no habría optado por invertir en cosas nuevas además de .NET Core en primer lugar.

@gingters Pensé que estábamos en el punto en el que estaba feliz de ejecutar sus bits web de ASP.NET Core en .NET Core 2.x o posterior, y usar .NET Standard 2.x para compartir bibliotecas entre Core y Full/UWP/lo que sea . Porque si estas bibliotecas dejaran de ser compatibles con .NET Standard 2.x en favor de solo .NET Core 2.x, entonces también dejarían de ser compatibles con .NET completo y, de todos modos, no tendrá más remedio.

@markrendle Hasta el punto en que tenemos un problema crítico en uno de los bits de ASP.NET Core que necesitamos usar en el material compartido después de que 1x ya no sea compatible.

@gingters afortunadamente es de código abierto y puede mantenerse (o pagar a un tercero) si es necesario.

@markrendle no. los proyectos heredados puros son los muertos. Los proyectos empresariales suelen ser una base de código de gran mezcla que contiene código/bibliotecas que datan de hace décadas y son nuevas. ser netcoreapp solo significa que eliminó la capacidad de mezclar. por lo tanto, ya no podemos pasar a su nueva versión elegante, sino bloquear la versión anterior. y los compañeros de trabajo anti-ms felizmente me dirán "te dije..." y luego nos empujarán a migrar a las soluciones de Google.

No estoy defendiendo el apoyo de netfx para siempre. pero creo firmemente que netfx debería ser compatible con asp.net core durante al menos 2 años a partir de ahora. no solo 1.x sino también 2.x.

@qrli Esos "proyectos empresariales... base de código de gran mezcla que contiene código/bibliotecas datan de hace décadas a nuevas". son todo lo que está mal con los proyectos empresariales y debe detenerse. Quejarse de que una nueva tecnología le impide arrojar más trozos de lodo a una gran bola de desesperación unida con cuñas, alambre de balas y negación es como quejarse de que una nueva máquina de corte por láser industrial viene con características de seguridad que evitan que se incline y corte partes importantes de ti mismo.

@benaadams

"moviéndose rápido" podría ser una exageración; siguiendo el cronograma de lanzamiento anterior de Full Framework, podría decirse mejor como "sin agregar un retraso adicional de 1 a 2 años" en el envío. Eso es una cantidad loca de tiempo en el mundo web.

Las cosas están cambiando rápidamente y la plataforma debe seguir siendo relevante.

Esta es una limitación política/organizativa, no técnica. Mira cómo se mueve la JVM/Java. Si se están moviendo en absoluto. Todavía relevante, mucho más de lo que .NET es hoy. Así que "moverse rápido" no es la razón por la que la gente elige Java/JVM. De lo contrario. Eligen Java/JVM porque carece de todas las desventajas asociadas con el "movimiento rápido": es una plataforma estable y confiable, donde su inversión no se desperdicia en 1 o 2 años.

No sé, si MS quiere mover .net rápido, lo hará rápido. Ellos son los dueños, pueden decidir qué hacer. Pero los poderes fácticos realmente no dan mucho al respecto: .net full es 'suficientemente bueno' para donde está ahora.

MS ha dormido al volante durante muchos años y ahora, de repente, cosas como el rendimiento y la presión de la memoria son importantes (lo son, sin duda), mientras que en JVM se han realizado inversiones en esos aspectos particulares de un tiempo de ejecución durante muchos años y eso vale la pena.

No sé cuál es la solución, a corto plazo, pero a largo plazo, dejando a .NET dividido en dos departamentos principales (.NET completo con Windows, .NET Core con devdiv) sin puntos en común/objetivos que no sean los mismos empleador no es un buen augurio para nosotros los extraños.

Si bien hay muchos puntos que se están destacando aquí, y todos están tratando de asegurarse de que entienden los puntos de vista de los demás, las soluciones como "las grandes empresas no deberían ser así" no van a ayudar. Incluso si pudieras convencerlos de eso, les tomaría 20 años dejar de ser así, porque son grandes empresas .

@kolectiv Eso es cierto, pero aceptar que las empresas no van a dejar de ser empresas de repente no significa que deba alentar/habilitar activamente ese tipo de comportamiento.

Tampoco debería significar que _mis_ aplicaciones tienen que ejecutarse más lentamente y costar más alojarlas.

Ejecutando un análisis de portabilidad en nuestras bibliotecas muy utilizadas que aún se dirigen a .NET 4.x en ASP.NET Core 1.x (EF6, NHibernate, NServiceBus) y hombre, estas bibliotecas ni siquiera están cerca de poder apuntar a netstandard20 .

liberación | porcentaje
---------- | ---------
EF6 | 62.74
NHibernate | 67.39
NServiceBus | 65.68

Y todavía hay grandes brechas en las API que faltan. EF Core todavía tiene una gran brecha con EF6, y todavía usamos NHibernate cuando hay funciones importantes que no existen en EF6. NServiceBus que usamos en cualquier proyecto que envíe mensajes.

Uf.

@markrendle

Esos "proyectos empresariales... base de código de gran mezcla que contiene código/bibliotecas datan de hace décadas y son nuevas". son todo lo que está mal con los proyectos empresariales y debe detenerse. Quejarse de que una nueva tecnología le impide arrojar más trozos de lodo a una gran bola de desesperación unida con cuñas, alambre de balas y negación es como quejarse de que una nueva máquina de corte por láser industrial viene con características de seguridad que evitan que se incline y corte partes importantes de ti mismo.

Sí, hombre, digámosles a esas molestas empresas y grandes organizaciones que hagan las cosas de manera diferente, ¡corten el cable! detener la inundación de lodo! Eso hará que se despierten y escuchen. Oh, espera, eso no ayudará, ya que ellos ya lo saben, pero tienen que trabajar con muchas cosas que no te importan o que ignoras para tu propio argumento.

Mira, nadie dice 'nueva tecnología: ¡mala!'. Se trata de buscar nuevas tecnologías sin darse cuenta de las consecuencias que trae consigo. A todos nos gusta trabajar con los bits más nuevos y no tener que preocuparnos por el viejo cruft, ¿quién quiere eso? Sin embargo, la realidad cuenta una historia diferente. Si solo tienes que trabajar con los bits más nuevos y no tienes que preocuparte por la mierda vieja, ¡bien por ti! Lamentablemente, los tristes drones de trabajo en las trincheras tenemos que vivir con una realidad diferente. Te convendría si al menos reconocieras que para MUCHAS personas la realidad es solo eso, no pueden cambiarla, no pueden hacer un futuro diferente, es con lo que tienen que trabajar.

@markrendle No estoy muy seguro de lo que estás sugiriendo. ¿Abandonar nuestros 15 millones de líneas de código C# en funcionamiento y escribirlo todo de nuevo? Estábamos buscando la transición (lenta) a netstandard 2.0 y, con suerte, obtener acceso a cosas como Span, etc. cuando surgiera, pero problemas como este me hacen dudar de que sea inteligente.

Nos gustaría el soporte de Linux, pero esto se siente más como una divergencia. Asumí que netstandard iba a seguir adelante con la implementación más avanzada y luego cosas como el marco se pondrían al día, pero al menos sabríamos que lo haría.

@FransBouma ¿Entonces todos deberíamos sufrir porque las empresas quieren hacer cosas estúpidas? ¿No debería recibir cosas bonitas porque los proyectos multimillonarios del sector público aún no están listos para ellas? ¿Cómo funciona?

@markrendle ¿Qué tiene de estúpido querer seguir trabajando en el código?

Eligen Java/JVM porque carece de todas las desventajas asociadas con el "movimiento rápido": es una plataforma estable y confiable, donde su inversión no se desperdicia en 1 o 2 años.

Y puedes usar System.Web básicamente para siempre; está integrado en Windows, lo que significa que es probable que nunca desaparezca. No obtienes mucho más estable y confiable que eso.

ASP.NET Núcleo 1.x -> ASP.NET Núcleo 2.x; todas las API son prácticamente iguales, el cambio principal es dejar de admitir .NET Framework. Incluso cambia semver para el descanso 😱

ASP.NET Core 1.x se ejecuta en .NET Core 2.x y .NET Framework, es compatible con .NET Standard 2.x (a través de .NET Core 2.x); y tiene las mismas apis que ASP.NET Core 2.x, así que ese es el lanzamiento de trampolín.

ASP.NET Core 2.x es la versión de descanso. Todavía es compatible con .NET Standard 2.x (a través de .NET Core 2.x) y no ha cambiado mucho en cuanto a API entre ASP.NET Core 1.x y ASP.NET Core 2.x; pero deja caer .NET Framework.

Podría ser una alternativa:

• ASP.NET Core siga adelante y trabaje hacia algo como netstandard3.0 (podría ser 2.x) y solo versión netstandard más rápido. Como una vez por trimestre.
• La próxima versión de NetFx podría saltar nuevamente para admitir netstandard3.x cuando sea la próxima versión. Ni siquiera tendría que ser el estándar más nuevo.

Esto podría ser una mala idea porque es posible que todo lo que se use no tenga que ser parte de netstandard, pero al menos ASP.NET Core 2.x apuntaría a un estándar que los otros marcos usarán eventualmente.

Solo escupir bolas. Estoy seguro de que esto ha sido mencionado.

@bencyoung Simplemente estoy sugiriendo que es un poco egoísta insistir en que el mundo entero debería girar en torno a sus 15 millones de líneas de código C# en funcionamiento (que no va a dejar de funcionar, por cierto). Entonces no puede usar ASP.NET Core 2.0. Todavía tiene el marco ASP.NET completo solo para Windows que tiene soporte heredado ejecutándose a través de él como Brighton a través de rock. Así que hay un nuevo juguete con el que no puedes jugar porque no es económicamente viable para ti portar tu código y refactorizar/rediseñar tu aplicación. Eso apesta, pero también muchas cosas. Pero si Microsoft evita todo lo que no va a funcionar para las bases de código heredadas preexistentes de dos décadas de antigüedad que probablemente todavía incluyen componentes COM escritos en VB 6.0, entonces en otros 20 años serán Micro Focus.

@adamhathcock Para eso supuse que era netstandard: un enfoque de unificación, en lugar de un mínimo común denominador. Puede moverse tan rápido como quiera, pero sería un compromiso que el marco .NET finalmente alcanzaría. Eventualmente habría un estándar de red que básicamente era el marco .NET menos las cosas específicas de la plataforma y luego se unificaría

La próxima versión de NetFx podría saltar nuevamente para admitir netstandard3.x cuando sea la próxima versión.

Una actualización de .NET Framework es una actualización forzada para todas las máquinas del planeta que ejecutan Windows (en su mayoría).

Una actualización de .NET Core es una actualización que usted elige para una aplicación individual .

Son bestias muy diferentes.

Bueno, una cosa fácil de hacer sería dejar de vincular a esta página desde la primera página de los documentos de ASP.NET Core .

(O simplemente agregue una línea "¡No elija .NET Framework si desea continuar usando ASP.NET Core!").

serían un compromiso de que .NET Framework finalmente se pondría al día.

Hay https://github.com/aspnet/Home/issues/2022#issuecomment -299609207

nuestra promesa generalmente es: si el tipo se comparte entre .NET Framework y .NET Core, tenemos la intención de transferir los miembros recién agregados a .NET Framework. En casos muy raros, esto podría no ser posible, pero lo que está en juego es que se consideran automáticamente.

Pero para cuando se ponga al día, ASP.NET habrá pasado a la siguiente versión de .NET Standard y nunca será la versión correcta de .NET Framework para ASP.NET; siempre estaría detrás.

@markrendle no, no son una gran bola de barro. gran mezcla no significa que estén mal diseñados. son modulares. es que muchos módulos son códigos probados en batalla escritos hace mucho tiempo por personas realmente inteligentes o comprados a terceros. algunos son de c, otros están en fortran, otros en c++/cli, etc. para migrar o reescribir, necesitamos comprenderlos, leer documentos, recopilar más datos de prueba reales, volver a probar la nueva versión. requiere esfuerzo, pero tales tareas nunca están presupuestadas, sino que depende de nosotros mismos. a la gente de negocios no le importa si usamos .net core o no, pero quieren que se hagan las funciones. y para terceros, tenemos que instarlos o buscar un reemplazo.
por lo tanto, puede tomar algunos años en la práctica.

@benaadams

Y puedes usar System.Web básicamente para siempre; está integrado en Windows, lo que significa que es probable que nunca desaparezca. No obtienes mucho más estable y confiable que eso.

ASP.NET Núcleo 1.x -> ASP.NET Núcleo 2.x; todas las API son prácticamente iguales, el cambio principal es dejar de admitir .NET Framework. Incluso cambia semver para el descanso 😱
ASP.NET Core 1.x se ejecuta en .NET Core 2.x y .NET Framework, es compatible con .NET Standard 2.x (a través de .NET Core 2.x); y tiene las mismas apis que ASP.NET Core 2.x, así que ese es el lanzamiento de trampolín.
ASP.NET Core 2.x es la versión de descanso. Todavía es compatible con .NET Standard 2.x (a través de .NET Core 2.x) y no ha cambiado mucho en cuanto a API entre ASP.NET Core 1.x y ASP.NET Core 2.x; pero deja caer .NET Framework.

Sí, y veamos cuáles son realmente las opciones :) ASPNET Core 1.x es un callejón sin salida: puede migrar a eso, pero su código no puede moverse a .net core si depende de las bibliotecas que están .net llenas hoy y es posible que no se transfiera a .net core/standard cuando finalice el soporte. Elegir ASP.NET core 1.x ahora solo es prudente si sus dependencias ya están en netstandard2.0/.netcore, entonces puede pasar a asp.net core 2.x sin problemas, sabiendo que no se encuentra en un callejón sin salida.

Su sugerencia de elegir system.web como alternativa a nginx y una pila JVM si desea tener estabilidad es un poco débil, ¿no cree? :) Se trata de opciones para una organización grande sobre qué plataforma elegir. A menos que estén creando una aplicación que sea completamente nueva y no tenga que funcionar con dependencias externas (algo raro), es probable que opten por la apuesta segura, ¿y por qué no lo harían? Si luego se reduce a system.web o JVM/nginx, la elección es bastante simple.

Son las cosas pequeñas. Ya lo comenté antes: las características de cifrado de las empresas del servidor sql. No los usará en .net core ya que no están allí. ¿Oráculo? no. Entonces, si desea usar asp.net core y estas funciones, debe usar .net full y asp.net core 1.x. Pero, ¿qué sucede si estas funciones no se transfieren o no están disponibles cuando finaliza el soporte para asp.net core 1.x? (¿y quién quiere apostar la granja en una plataforma que ya está en 'modo QFE'?) ¿Volver a system.web?

Me parece que parte del problema es que ASP.NET está impulsando directamente la evolución de .NET Core. Supongo que eso es algo interno en Microsoft, pero en realidad la plataforma y una biblioteca específica no deberían estar tan estrechamente unidas.

Si es necesario agregar algo nuevo a una versión de .NET, debe estar disponible para todos a través de un aumento estándar de red (con vNext) y luego actualizar ASP.NET para usarlo cuando se publique. Creo que es la posición privilegiada de ASP.NET lo que causa este problema. Esto puede ser inevitable debido a que los grupos de desarrolladores dentro de Microsoft son los mismos...

Como escritor de software HPC que utiliza mucho .NET, también hemos implementado nuestro propio análisis de asignación cero, etc., sin cambios en la plataforma subyacente. ¿Nos beneficiaríamos de Span, etc.? ¡Absolutamente! ¿Podemos cambiar a .NET Core? No por mucho tiempo. ¿Veremos Span, etc. agregados a .NET Framework? Parece difícil de decir ahora sin que sea un compromiso de netstandard...

@markrendle Claro, pero ¿cuál es nuestro plan de transición? No puedo ver uno que no llegue a rutas no admitidas. Si los cambios se realizaron en netstandard y luego ASP.NET Core los usó, al menos sabríamos que finalmente hubo un camino...

@markrendle no estoy seguro de quiénes son los usuarios previstos de asp.net core. pero lo que vi son en su mayoría usuarios de .net que tienen una gran inversión en .net y una gran base de código heredada (no está mal). si no somos los usuarios previstos, no veo que los chicos de node.js/python/go le den una mierda a .net, no importa cuán bueno creamos que es .net.
si no es para la empresa sino para mis propios proyectos, no usaré asp sino nancy en su lugar. las empresas necesitan garantía estable y apoyo. y ellos/nosotros pagamos mucho dinero por ello.

La solución fácil a este problema sería si Microsoft hiciera una distribución de CoreCLR solo para Windows que admita la gama completa de bibliotecas de .NET Framework.

Mi lado personal es genial para jugar con .NET Core en PI en ubuntu, pero el lado comercial ni siquiera consideró .NET Core porque .NET Framework hace todo lo que necesitamos y .NET Core es solo un problema en comparación. La mayor parte de este problema se debió a las herramientas y a la configuración de todos para que esos dolores finalmente desaparezcan, pero aún le faltan muchas características... EF Core ni siquiera está cerca de ser lo suficientemente suave como para sustituir a EF6 o NHibernate y ganaron tampoco se ejecuta en .NET Core 2. La falta de WCF (host) para los servicios SOAP es una gran carga, ya que es lo que hacemos todo el día en la comunicación comercial, pero probablemente podría mitigarse mediante un diseño inteligente y el uso de .NET Core y .NET Framework en varias aplicaciones. AppDomains tampoco se reemplazan fácilmente, aunque ese es el menor de mis problemas. El salto de ASP.NET MVC 5 a MVC Core fue inesperadamente fácil para una reescritura, pero pasar a .NET Core hace que VS deje de cooperar y muestre todos los errores.

Cosas divertidas como hospedar ASP.NET Core dentro de WPF también serán imposibles.

Ni siquiera importaría si la distribución de Windows CoreCLR fuera de código cerrado, ya que no es muy diferente de .NET Framework en la actualidad.

Ahora disculpe mientras lloro en silencio y elimino mis ramas experimentales que se migraron a ASP.NET Core.

Su sugerencia de elegir system.web como alternativa a nginx y una pila JVM si desea tener estabilidad es un poco débil, ¿no cree?

Es el extremo ;)

Si luego se reduce a system.web o JVM/nginx, la elección es bastante simple.

Sí, si puede usar JVM, use ASP.NET Core 2 ya que no tiene bloqueadores y tiene una buena interoperabilidad y p/invocación :)

si las apis son "prácticamente iguales", ¿por qué no mantiene una versión numerada 2x para todas, pero tiene la opción de seleccionar "netstandard" o "netcore"?

Porque son los internos los que están cambiando; y hacer uso de los cambios en las bibliotecas de tiempo de ejecución, jit y estándar. Para un usuario, parecen casi iguales, ya que ahí es donde está la compatibilidad entre ASP.NET 1.x y 2.x; en la superficie api expuesta, no en las partes internas "así es como se hace".

Me parece que parte del problema es que ASP.NET está impulsando directamente la evolución de .NET Core.

Al igual que otras personas. Puede realizar una solicitud de API en dotnet/corefx como lo hice, por ejemplo, para ValueTask ; que luego evolucionó a Task-likes y ahora es parte de C#7.

Tan pronto como su api esté incluida en .NET Core, puede comenzar a usarla (si va por las noches y quiere asegurarse de que la api sea correcta); o en la próxima versión de coreclr/corefx si desea esperar 6 meses.

y luego ASP.NET actualizado para usarlo cuando se lance.

Ahora hay que esperar 2 años. Eso no es realmente práctico; ya que las apis necesitarán refinamiento a través del uso; y a través del uso ocurrirán más descubrimientos. Eso es como agregar un paso de compilación de 2 años a su ciclo de desarrollo.

Como escritor de software HPC que utiliza mucho .NET, también hemos implementado nuestro propio análisis de asignación cero, etc., sin cambios en la plataforma subyacente. ¿Nos beneficiaríamos de Span, etc.? ¡Absolutamente! ¿Podemos cambiar a .NET Core? No por mucho tiempo.

¿Su software de HPC depende directamente de las solicitudes web? Supongo que podría tener colas impulsadas por solicitudes web, pero se ejecuta en un proceso separado, por lo que este cambio no debería afectarlo.

¿Veremos Span, etc. agregados a .NET Framework?

sí

@benaadams

Pero para cuando se ponga al día, ASP.NET habrá pasado a la siguiente versión de .NET Standard y nunca será la versión correcta de .NET Framework para ASP.NET; siempre estaría detrás.

Lo cual está completamente bien y es aceptable, si hay al menos 1 superposición de versiones (es decir, si permanece en el último marco completo, todavía hay al menos una versión oficialmente compatible (ASP).NET Core que se ejecuta en eso).

Microsoft haría una distribución solo para Windows de CoreCLR que admita la gama completa de bibliotecas de .NET Framework.

O un conjunto de bibliotecas .NET Standard 2.0; para que puedan ejecutarse en .NET Core, que solo se ejecuta en Windows que cubre la brecha de API?

@benaadams, sí, esa es la idea, aunque eso no funcionará para nada que arroje PlatformNotSupportedException

@qrli Si es modular, puede actualizar los módulos que se pueden actualizar ahora y dejar el resto para más tarde.

A menos que por "modular" quiera decir "es una aplicación System.Web ASP.NET IIS monolítica masiva que comprende docenas de bibliotecas diferentes que interoperan a través de PInvoke y COM", en cuyo caso, eso es una gran bola de barro.

¿Hay una lista final de qué ensamblajes se ven afectados y cuáles no? Se ha mencionado que Microsoft.Extensions.* es seguro y Microsoft.AspNetCore.Razor.Runtime (supuesto) también, gracias a lo cual Microsoft.AspNetCore.Html.Abstractions también necesita permanecer en netstandard . ¿Hay algo más en Microsoft.AspNetCore.* que permanezca en netstandard ?

@bencyoung Mi plan de transición recomendado es migrar varios componentes a lo largo del tiempo a servicios independientes dirigidos a .NET Core 2.x (o lo que funcione mejor de todo el universo de herramientas de desarrollo para ese componente en particular), consumiendo esos servicios de su código heredado. un límite de API estándar mediante HTTP o un bus de mensajes, hasta que tenga una arquitectura de sistema distribuida adecuada.

@markrendle Sin embargo, no todo pertenece a un sistema distribuido. Como ejemplo concreto: una gran parte de por qué Stack Overflow muestra las páginas tan rápido es porque no se distribuye. Aunque la latencia de nuestra red es de 0,017 ms, eso agregaría bastante costo de red, serialización, deserialización y GC a nuestra aplicación. Dividir un sistema en muchos servicios no es una respuesta universal. Es complicado, costoso y negativo neto para muchos escenarios también. Puede ser algo bueno, pero también puede ser algo malo demasiado complicado.

@markrendle , mi problema no es migrar a servicios, es que algunos de los componentes fundamentales de la infraestructura de servicios usan API que no están en la hoja de ruta para netstandard20 o incluso netstandardbanana . Para nosotros, .NET Core no se trata de aplicaciones nuevas, se trata de sistemas totalmente nuevos. System.DirectoryServices es un ejemplo, pero para otros, es WCF, y más, es System.Data y las cosas de SqlClient, y para nosotros, System.Messaging .

Estoy a favor de usar .NET Core cuando puedo. Hasta ahora, eso ha incluido proyectos de clientes cero, greenfield o no, todos están bloqueados en algo .

@NickCraver No pretendo ser bromista ni nada, y sé que la verdadera razón por la que las páginas SO se procesan tan rápido es que usted y las otras personas que las construyen son increíbles, pero los resultados de búsqueda de Google que incluyen enlaces a sus páginas renderice tan rápido como sus páginas, y _sabe_ que provienen de un sistema distribuido grande y complicado. Las páginas de Amazon se procesan bastante rápido, el mismo trato. Soy optimista de que ASP.NET Core se dirige hacia un futuro en el que se puede usar para construir sistemas de la misma manera que se construyen, con el mismo rendimiento, y creo que tiene más posibilidades de llegar allí si se libera de el ciclo de actualización de .NET completo que convierte una pequeña isla.

@jbogard Veo algo similar, pero será muy diferente cuando salga .NET Core 2.0.

Suspiro.

@jbogard

netstandardbanana

cita del hilo

El problema principal con esto, para mí y mi equipo, es que no había indicios de que este camino fuera el futuro previsto. Entiendo que nadie sabe el futuro, pero escucho que necesitamos desglosar cualquier cosa que se base en el marco completo de .NET (dlls de proveedores de componentes, sdks de servicios de pago, sdks de HSM) en sus propios servicios e introducir ese nuevo salto STINGS. Simplemente no es algo que este sitio necesita y ahora tenemos que introducir más complejidad de operaciones de desarrollo o volver a hacer la parte de la aplicación web en MVC 5.

Optamos por el núcleo de asp.net por la velocidad de Kestrel y la nueva y elegante API. Habría sido bueno poder sopesar con mayor precisión las opciones frente a la falta de una ruta de actualización fácil dadas nuestras dependencias.

Añadiendo a @jabrown85
ASP.NET Core ha sido una montaña rusa de emociones hasta el momento.
Después de que csproj aterrizó, finalmente dije "ya está listo" y consideré que era obvio comenzar algo nuevo y verificar qué se puede actualizar. Después de este anuncio, es más como: "¿.NET Core definitivamente es compatible con el escenario o debemos ir a lo seguro y simplemente quedarnos con MVC5?"

Las bajas son bajas hasta el momento, solo una aplicación escrita en ASP.NET Core que gestiona las tareas administrativas de la aplicación MVC 5 principal, pero permanecerá bloqueada en 1.x para siempre porque la aplicación principal usa NHibernate.

La computadora de @markrendle dice que no

Sería bueno si hubiera alguna hoja de ruta para .NET completo -> netstandard. Algunas de las piezas fundamentales simplemente dicen "No compatible" de ApiPort. Realizaré un análisis más completo de los proyectos del cliente en ASP.NET Core 1.x para ver qué falta.

pero estará atascado en 1.x para siempre porque la aplicación principal usa NHibernate.

No debería ser, NHibernate no está muerto, ¿verdad?

@benaadams sorprendentemente no. Hay algunas cosas que hace que EF6 realmente no tiene ningún equivalente. Por defecto utilizamos EF6, pero hay casos en los que tenemos que ir por la ruta NH.

@benaadams oficialmente no, tiene pausas en las que parece casi muerto, pero generalmente hay una confirmación cada pocos días. ApiPort informa una cobertura del 72,26 % para .NET Standard, pero no estoy realmente convencido de que se transfiera (al menos en un futuro cercano).

Al leer los comentarios, me preocupa la dirección general que está tomando este proyecto. Durante mucho tiempo, ASP.NET fue una buena opción para una tecnología estable y sólida. Sin embargo, ahora no tengo la misma sensación. Hay muchas tecnologías de "moverse rápido y romper cosas", pero esa es una categoría completamente diferente.
Espero que Microsoft pueda abordar esas preocupaciones y alinear las expectativas de todos.

No se trata de software empresarial frente a software no empresarial. Hay muchas aplicaciones de Python 2.x en uso hoy en día y no todas son "empresariales". Además, no todos los proyectos nuevos usan Python 3 (¡casi 9 años después del lanzamiento de Python 3.0!).

¿Alguien puede resumir todo el hilo en una publicación de blog?

He leído los más de 300 comentarios durante el viaje/almuerzo y... parece que todavía no "lo entiendo" por completo.

Lo que obtengo es:

• .NET Framework completo no será compatible con .NET Core 2
• Cada dependencia dependerá de netcoreapp2.0 en lugar de netstandard2.0
• Si quiero algo como DirectoryServices o Drawing, necesito dejar Full Framework y pasar a 2.0

Como que me perdí el resto... agenda apretada y todo.

@MaximRouiller

Si quiero algo como DirectoryServices o Drawing, necesito dejar Full Framework y pasar a 2.0

No, si desea una biblioteca que no admita .net core, no podrá usar AspNet Core 2.0+ en absoluto.

@MaximRouiller , lo que acaban de hacer es que los proyectos centrales de Asp.Net no podrán hacer referencia a ensamblajes completos del marco, lo que lo hace inútil para muchos, si no para la mayoría, dicen que los ensamblajes como system.drawing y Directoryservices se trasladarán al nuevo netstandar o no sé, aún así, los ensamblajes antiguos no funcionarán a menos que alguien los transfiera, por lo que es bastante inútil para muchos porque algunos ensamblajes son heredados y nunca se transferirán. En conclusión, cualquiera que estuviera usando .net core con la versión completa de .NET framework simplemente se arruinó y necesita volver a MVC 5.

@davidfowl Gracias por esta lista por cierto. Ese es el muy importante "entonces, ¿qué estamos sacando de esto?" pieza necesaria para que las personas equilibren el costo/beneficio en sus mentes.

Si aún no lo ha hecho, lea la lista para estar informado en ambos lados. Sigo queriendo que 2.x sea un lanzamiento de transición (con beneficios justificables para el negocio que realmente justifiquen el movimiento), y que 3.x sea donde están las victorias. Incluso si salió 2 días después. Realmente aprecio la perspicacia en todos los lados.

@davidfowl dijiste:

Las bibliotecas se pueden escribir encima del estándar. Cuando las cosas en el estándar en sí necesitan cambiar, llevará mucho más tiempo adoptarlas en todas las implementaciones de .NET y eso incluye .NET Framework. Puede significar un par de cosas:
.NET Standard evolucionará al ritmo de la implementación más lenta
.NET Standard evolucionará a otro ritmo y .NET Framework será el último en ponerse al día.

Pero ¿por qué es ese el caso? ¿No puede lanzar .NET Standard vNext y hacer que .NET lo alcance algún tiempo después (unos meses o un año después)? Eso significa que las personas que están a la vanguardia y quieren el último ASP.NET Core pueden hospedar en .NET Core, y las personas que necesitan .NET para su código heredado pueden eventualmente usar esa versión de ASP.NET Core una vez que .NET se ponga al día. a la versión de .NET Standard que utiliza. No entiendo por qué .NET Standard debe acelerarse tan rápido como la implementación más baja.
También aquí estamos hablando de implementaciones oficiales del estándar, pero habrá otras implementaciones que no se actualizarán junto con el estándar.
De esa manera no dejas a la gente atrás. Claro, tardan un poco más en beneficiarse de las funciones más recientes si están en .NET, pero no se atascan para siempre.

@jdom porque sé la velocidad a la que cambia .NET Framework y por qué tiene que ser lento. Es una distribución diferente y tal vez no hay suficiente aprecio por eso. Cualquier cambio se envía a miles de millones de máquinas. Las capas también son completamente diferentes, por lo que no es algo trivial para razonar.

No entiendo por qué .NET Standard debe acelerarse tan rápido como la implementación más baja.

Si seguimos elevando la marca de agua baja para el estándar .net en ASP.NET Core, anula el propósito y lo deja en la misma situación. Seguro que no se siente abandonado porque existe la promesa de que algún día estas API llegarán a .NET Framework, pero ¿en qué línea de tiempo? .NET 4.7 aún no completa la paridad de funciones con .NET Standard 2.0.

@davidfowl, pero esto traerá de vuelta el mismo problema que con PCL, se convertirá en el mínimo común denominador y será un dolor de usar, el hecho de que ASP.NET abandone su uso ya lo demuestra.

@davidfowl, pero esto traerá de vuelta el mismo problema que con las PCL, se convertirá en el mínimo común denominador y será difícil de usar,

@Suchiman, ¿cómo es eso un problema? El único problema con los PCL era cómo se calculaban y representaban dinámicamente en NuGet, lo que dificultaba predecir lo que se obtendría. ¿De qué otra manera funcionaría netstandard si no fuera un conjunto de API que podría implementarse mediante diferentes implementaciones?

Lo que hizo que los PCL fueran molestos de usar fue el área de superficie API súper pequeña. .NET Standard 1.3-1.4 es suficiente para implementar la API de bibliotecas más básicas.

.NET Standard siempre tuvo que ver con la amplitud.

ASP.NET Core y .NET Core se trataban de una pila de servidor multiplataforma competitiva para crear microservicios livianos. El aliento en este sentido fue un soporte de plataforma más amplio (que se ejecuta en linux, osx, tizen, pi, etc.).

@davidfowl

Hemos identificado las cadenas como una de las principales cosas que nos gustaría tratar de abordar en .NET Core, hay muchas ideas, pero una de ellas es que la cadena sea utf8 de forma predeterminada (muchos problemas de compatibilidad, pero síganme aquí).

Otra cosa que nos gustaría arreglar es la capacidad de tomar porciones baratas de arreglos/cadenas, cualquier pieza de memoria contigua. Hemos agregado Spany están mirando Bufferpara representar esto. Podría significar que String y Array implementan nuevas interfaces que hacen posible tomar un segmento que requiere una asignación 0.

Parece que esto significa que si quiero usar estos nuevos bits en una biblioteca, la biblioteca también deberá apuntar a netcoreapp2.0 en lugar de netstandard2.0 . ¿Es eso correcto?

Es una muy mala idea no admitir más el antiguo marco 4.x. La gente no se actualiza si genera mucho trabajo. Vea el ASP clásico súper antiguo, que está en desuso desde 2002, unos 15 años. ¡Y tenemos aplicaciones antiguas que aún existen en el ASP clásico! ¿Le gusta a Microsoft ver algo similar una vez más? Eliminar el soporte antiguo 4.x es algo que debe hacerse de manera obligatoria, ¡pero a largo plazo! Ahora no. Esta puede ser una opción en algunos años, cuando .NET core sea el estándar de facto y solo las aplicaciones antiguas usen la red 4.x.

La idea detrás de (ASP).NET Core es realmente genial, lo mejor que ha hecho Microsoft desde el lanzamiento de .NET. Pero tal caos embota este bonito concepto. También es muy triste que Microsoft decida cambios tan masivos por su cuenta, ¡sin siquiera discutirlo en la comunidad! Parece que esta empresa aún no ha aprendido completamente cómo manejar proyectos de código abierto.

@davidfowl

.NET Standard siempre tuvo que ver con la amplitud.

¿Amplitud en APIs o plataformas?

¿Cuál es el problema con la evolución .netstandard al mismo ritmo que .netcoreapp ?
¿Alguno de los objetivos de ajuste de BCL es específico para .netcoreapp porque nunca se implementará en los otros marcos?

Lanzar .netstandard2.1 al mismo tiempo que .netcoreapp2.1 no hace una diferencia entre lanzar .netcoreapp2.1 primero y un año después .netstandard2.1 al mismo tiempo que .net50 , excepto que los paquetes dirigidos a .netstandard2.1 comenzarían a funcionar inmediatamente en .net50 pero se bloquearán si apuntan a .netcoreapp2.1

ASP.NET Core es un marco de aplicaciones web de alto nivel creado sobre .NET Core y, en el futuro, apuntará a .NET Core, _sin embargo_ también puede ser un marco de aplicaciones web de alto nivel construido sobre .NET Standard, de modo que se dirija a una interfaz API de referencia en lugar de una implementación específica de la misma.

El posicionamiento público de .NET Standard está siendo un objetivo fácil de construir, dejando de lado los detalles de implementación, con 2 marcos oficiales directamente de Microsoft para cubrir la mayoría de los casos de uso.

¿Por qué cambiar esa historia ahora? Si .NET Framework nunca se pone al día, parece que no viene al caso. Al menos existe la posibilidad de que lo haga, o que otro marco de trabajo de terceros pueda hacerlo. Entonces, ¿qué sucede si solo habrá una única implementación que siga el ritmo de manera realista? Esta es exactamente la razón por la que tenemos interfaces en nuestras aplicaciones, incluso si solo hay una implementación concreta, para que tengamos la flexibilidad y las ventajas que trae.

¿Quizás reducir el alcance en ASP.NET Core 2.0 en línea con .NET Standard 2.0 y luego usar .NET Standard 2.1 para funciones más nuevas? Agregue algunos plazos de soporte decentes y ¿no resolvería eso todo este dilema? Microsoft posee .NET Standard y ambos marcos, por lo que este temor de incrementar las versiones parece completamente infundado...

Supongo que se debe considerar que ASP.NET a ASP.NET Core no es la ruta de migración para todos.

ASP.NET en el marco completo permanecerá y obtendrá funciones, pero no como Core.

La migración será más fácil con el tiempo, pero nunca será una coincidencia del 100 %.

La gente todavía ejecuta ASP clásico. Eso también está bien para ellos.

@davidfowl Tengo un gran respeto por todo el equipo y los avances que están logrando. Así que, por favor, no tome esto como un desprecio por lo que está sucediendo. Ustedes son pioneros y todos los vemos como ejemplos de cómo hacer las cosas bien. Pero no veo muchos de estos puntos como problemas inmediatos de cambio de objetivo, especialmente cuando no se ha comunicado. Puede ser que esté equivocado.

Quiero lanzar algunas cosas locas aquí porque se ha mencionado varias veces. Lo que estoy a punto de decir no tiene nada que ver con lo que sucederá, todo es especulación en este momento. Varias personas preguntaron por qué queremos apuntar a .NET Core en lugar de .NET Standard.

• Hemos identificado las cadenas como una de las principales cosas que nos gustaría tratar de abordar en .NET Core, hay muchas ideas, pero una de ellas es que la cadena sea utf8 de forma predeterminada (muchos problemas de compatibilidad, pero síganme aquí).

Este punto aquí definitivamente cambiaría las reglas del juego, pero en mi opinión, es el único que absolutamente no requiere un marco de orientación, y de todos modos no es para netcoreapp20.

• Otra cosa que nos gustaría arreglar es la capacidad de tomar porciones baratas de arreglos/cadenas, cualquier pieza de memoria contigua. Hemos agregado Spany están mirando Bufferpara representar esto. Podría significar que String y Array implementan nuevas interfaces que hacen posible tomar un segmento que requiere una asignación 0.
• Esto conduce a nuevos métodos en String que permiten la división que no asigna una matriz cada vez.
• Esto conduce a sobrecargas en Int, UInt, etc. (TryParse) que toman Spany lapso.
• Esto lleva a nuevas rutinas de codificación que toman Span.
• Buffery lapsole permite representar la memoria de manera uniforme y queremos actualizar la pila de redes para permitir el paso de búferes prefijados que toman Spano tampón.

Todo esto aún se puede implementar como paquetes además del estándar de red actual. Ni siquiera necesita netstandard20 para esto. Entiendo que no quiera cargar con este equipaje, pero el resto de nosotros en el mundo que no es de MS tenemos que crear implementaciones BCL-esque personalizadas todo el tiempo cuando el caso de uso o el rendimiento no encajan. Sin mencionar que la API Span tampoco está destinada a 2.0 (a menos que eso cambie nuevamente).

Kestrel implementará HTTP2 en el marco de tiempo 2.x (actualmente apunta a 2.1) y eso requiere nuevas API en flujo SSL para hacer ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http Client en .NET Core es compatible con la transmisión dúplex, lo que permitirá implementar puntos finales de transmisión a través de http en Signalr a través de una única solicitud de http sin websocket.

Siento que este es un poco más complicado, pero no tan diferente de Kestrel que lleva libuv. La implementación de CURL de .Net Core se puede incorporar fácilmente a un paquete de extensión netstandard hasta que todos se pongan al día.

• Bifurcamos las implementaciones del analizador de encabezados de HttpClient y System.Net.Http y las renombramos (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) para poder mejorarlas y hacer que admitan tanto .NET Framework como .NET Core. .NET Core tiene una copia de estas mejoras que no se han devuelto porque no hay necesidad de mejorarlas (no pudimos consumirlas).

Correcto, pero podría decirse que esta es la forma correcta de hacerlo en este caso. Es frustrante esperar y aferrarse a las implementaciones, pero nuevamente, no veo cómo esto es diferente de lo que hacen los demás cuando escriben un marco o una biblioteca.

• Sin la capacidad de acelerar las primitivas básicas, se nos anima a bifurcarlas y hacer cosas que se parezcan a ellas pero que no lo sean. Es la razón por la que tenemos nuestro propio pequeño BCL dentro de ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

De nuevo, como el resto de nosotros.

ASP.NET Core y .NET Core se trataban de una pila de servidor multiplataforma competitiva para crear microservicios ligeros.

ASP.Net Core tenía algunos mensajes como ese. .Net Core ha recibido mensajes desde el primer día como un subconjunto de .Net framework del lado del servidor xplat totalmente funcional. Nunca escuché a nadie decir que .Net Core es solo para microservicios. Escuché que puede usarlo con ASP.Net Core si lo desea, pero también con aplicaciones de consola, análisis de datos, servicios de base de datos, etc. ¿La dirección de .Net Core es efectivamente "lo que más desee el equipo de ASP.Net Core"?

ASP.NET en el marco completo permanecerá y obtendrá funciones, pero no como Core.

¿lo hará? Todavía no he visto a nadie de MS confirmar que todavía se está trabajando. Mi instinto dice que no lo es. Lo entiendo. El equipo necesita un momento tipo "muévelo o piérdelo" para liberarse. Simplemente no creo que este sea ese momento todavía.

Suponiendo que tenemos un ensamblado de lógica de negocios 4.6, que usa el controlador Oracle.Net, el NHibernate y el RabbitMQ (todos ellos en 4.6). La interfaz con ASP.Net es solo a través de nuestros objetos comerciales, solicitudes y respuestas. ¿Podemos hacer referencia a este ensamblado en nuestro ASP.Net Core 2, sin volver a compilar?

mi resumen rapido

@ stefan2410 respuesta corta, no, no puede hacer referencia al marco completo, puede hacer referencia a esos ensamblajes solo si se crearon para netstandar 2.0.

@mattnischan

Todo esto aún se puede implementar como paquetes además del estándar de red actual. Ni siquiera necesita netstandard20 para esto. Entiendo que no quiera cargar con este equipaje, pero el resto de nosotros en el mundo que no es de MS tenemos que crear implementaciones BCL-esque personalizadas todo el tiempo cuando el caso de uso o el rendimiento no encajan.

Lo siento, pero realmente no lo es. No puedes imitar los tipos de parches. A menos que esté sugiriendo que agreguemos nuevos tipos y no cambiemos los existentes.

Sin mencionar que la API Span tampoco está destinada a 2.0 (a menos que eso cambie nuevamente).

Span existe en 2.0 como implementación pero no como una API pública. Hacemos cambios importantes en las nuevas versiones principales para que podamos hacer más funciones en las versiones secundarias. Si ASP.NET Core 2.1 tiene como objetivo .NET Standard 2.1, la compatibilidad con .NET Framework se elimina nuevamente.

Siento que este es un poco más complicado, pero no tan diferente de Kestrel que lleva libuv. La implementación de CURL de .Net Core se puede incorporar fácilmente a un paquete de extensión netstandard hasta que todos se pongan al día.

Entonces, lo que está diciendo es que deberíamos cambiar el nombre de todas las clases en BCL para poder usarlas en .NET Standard.

Nunca escuché a nadie decir que .Net Core es solo para microservicios. Escuché que puede usarlo con ASP.Net Core si lo desea, pero también con aplicaciones de consola, análisis de datos, servicios de base de datos, etc. ¿La dirección de .Net Core es efectivamente "lo que más desee el equipo de ASP.Net Core"?

No, .NET Core es un marco de trabajo de propósito general que originalmente no tenía verticales en su núcleo. Es posible que ASP.NET Core debería haber sido simplemente una vertical en lugar de bibliotecas sobre .NET Core, posiblemente habría evitado parte de esta confusión.

¿lo hará? Todavía no he visto a nadie de MS confirmar que todavía se está trabajando. Mi instinto dice que no lo es. Lo entiendo. El equipo necesita un momento tipo "muévelo o piérdelo" para liberarse. Simplemente no creo que este sea ese momento todavía.

Sí, la compatibilidad con HTTP/2 se agregó en la última versión. Hay otro equipo que trabaja en ASP.NET e IIS y realizan mejoras. Sin embargo, no están en la misma escala que lo que está haciendo ASP.NET Core.

No tengo sentimientos muy fuertes sobre esto, ya que he evitado ejecutar mis servicios ASP.NET Core en el marco completo como la peste. Dicho esto, tuve que evitar el uso de algunas bibliotecas agradables y maduras porque no admitían .NET Standard porque estaban esperando netstandard2.0 o simplemente porque no querían.

Mi temor es que eliminar la capacidad de ejecutar ASP.NET Core en el marco completo disuadirá a los usuarios de migrar sus aplicaciones MVC 5/Web API 2 actuales a ASP.NET Core, lo que solo proporcionará otra razón para que los autores de bibliotecas eviten migrar a .NET Estándar. ¿Por qué molestarse en hacer el trabajo de actualización si ninguno de sus usuarios se beneficiará? Se convierte en un problema del huevo y la gallina y me temo que esto dañará el ecosistema en su conjunto justo cuando comenzó a tener algo de tracción. En primer lugar, necesita usuarios de ASP.NET Core y no estoy seguro de que haya tantos como a todos nos gustaría. Ojalá me equivoque.

Si ASP.NET Core 2.1 tiene como objetivo .NET Standard 2.1, la compatibilidad con .NET Framework se elimina nuevamente.

No, solo significa que Net Framework admitirá automáticamente ASP.NET Core 2.1 tan pronto como sea compatible con .NET Standard 2.1, siempre que sea así, incluso si lleva uno o dos años.

Lo mismo para todas las demás plataformas compatibles con .NET Standard (Xamarin/Unity/...).

Construir sobre .NET Standard significa que otras plataformas se encenderán _eventualmente_, construir sobre .NET Core significa que se encenderán __nunca__.

Supongo que el plan sigue siendo que full-fx se ponga al día con netstandard, incluso si con un gran retraso.
(y si no se espera que ninguna otra plataforma, excepto NET Core, implemente .NET Standard 2.1, entonces, ¿por qué tener un .NET Standard?)

Lo siento, pero realmente no lo es. No puedes imitar los tipos de parches. A menos que esté sugiriendo que agreguemos nuevos tipos y no cambiemos los existentes.

Esto último es lo que ya se ha hecho en la mayoría de los casos en 1.x, ¿no? ¿Es que de repente ya no es sostenible?

Span existe en 2.0 como implementación pero no como una API pública. Hacemos cambios importantes en las nuevas versiones principales para que podamos hacer más funciones en las versiones secundarias. Si ASP.NET Core 2.1 tiene como objetivo .NET Standard 2.1, la compatibilidad con .NET Framework se elimina nuevamente.

¿Por qué se dejaría caer? ¿Estás diciendo que Span _nunca_ existirá en Framework?

Entonces, lo que está diciendo es que deberíamos cambiar el nombre de todas las clases en BCL para poder usarlas en .NET Standard.

Vaya, no. Estoy diciendo que si necesito un diccionario con una API diferente, tengo que crear algo más y no llamarlo System.Collections.Generic.Dictionary, como ya hicieron con Microsoft.Net.*

Sí, la compatibilidad con HTTP/2 se agregó en la última versión. Hay otro equipo que trabaja en ASP.NET e IIS y realizan mejoras. Sin embargo, no están en la misma escala que lo que está haciendo ASP.NET Core.

Eso es justo. Yo no estaba al tanto de eso.

Esto último es lo que ya se ha hecho en la mayoría de los casos en 1.x, ¿no? ¿Es que de repente ya no es sostenible?

Crea un desorden. Han tratado de hacer eso lo menos posible. Creo que el diseño y la implementación de la API son mucho más complicados de lo que la mayoría de la gente cree. Y no son los muchachos de Microsoft lo que lo hace así, es la realidad de admitir muchas plataformas y líneas de tiempo. No aprecié esto hasta que estuve en el medio varias veces y hablé de todo. Sin embargo, realmente desearía que el reenvío de tipos estuviera en el nivel de método. Habría resuelto bastantes casos hasta ahora :(

¿Por qué se dejaría caer? ¿Estás diciendo que Span nunca existirá en Framework?

Tendría que eliminarse de ASP.NET Core 2.0 , ya que las líneas de tiempo ya no se alinearían, ya que el marco completo aún no lo tendría.

Tendría que eliminarse de ASP.NET Core 2.0, ya que las líneas de tiempo ya no se alinearían, ya que el marco completo aún no lo tendría.

AFAIK, los intervalos son parte de un paquete netstandard1.x que se puede usar en .NET Desktop (es una implementación portátil, por lo que no tiene el mismo aumento de rendimiento que si estuviera respaldado en CLR, pero es probable suficientemente bueno).

Editar: el paquete System.Memory tiene un TFM netstandard1.0 , por lo que puede usarse incluso en .NET 4.5.

Esto último es lo que ya se ha hecho en la mayoría de los casos en 1.x, ¿no? ¿Es que de repente ya no es sostenible?

Detenemos el trabajo de características en ciertas direcciones hoy debido a eso. Es intencional y nos contenemos y nos negamos a usar nuevas API al copiar y volver a implementar cosas fuera de .NET Standard para que .NET Framework pueda funcionar. Esto no es todo, pero hay algunas piezas fundamentales que nos gustaría tocar en el futuro, después de todo, nosotros (Microsoft) controlamos ambos lados.

¿Por qué se dejaría caer? ¿Estás diciendo que Span nunca existirá en Framework?

Span en sí tiene una versión portátil que se ejecuta en cualquier lugar, no estoy seguro de que la implementación rápida esté alguna vez en .NET Framework. Las API que se agregarán a .NET Framework que aprovechan Span pueden tardar mucho más que Span en sí mismo, es extenso. ¿Cuándo fue la última vez que cambiamos la cadena y la matriz en .NET Framework?

Vaya, no. Estoy diciendo que si necesito un diccionario con una API diferente, tengo que crear algo más y no llamarlo System.Collections.Generic.Dictionary, como ya hicieron con Microsoft.Net.*

Eso es exactamente lo que estás sugiriendo. No queremos tener un Microsoft.Extensions.Collections.Generic. Hacemos todo lo posible para evitar eso y vivimos con las antiguas API y polyfill donde sea posible (https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs). Esto no es sostenible y significa que .NET Core no obtiene los beneficios porque evitamos activamente usarlo.

@PinpointTownes tener tramos no es lo suficientemente bueno, necesitan usarlos en llamadas de métodos a tipos existentes. Ahí es cuando entra en juego el reenvío de tipo de nivel de clase y causa muchos problemas.

@0x53A

Eso es justo. ¿Puede decirme por qué las bibliotecas populares en NuGet no dejan de admitir versiones anteriores de .NET Framework que claramente no son compatibles? Las bibliotecas más populares apuntan a net20, net35, net40, etc. ¿Por qué de repente estaría bien requerir la versión más alta de .NET Framework para seguir usando ASP.NET Core? ¿Crees que eso sería razonable?

Este es un espectáculo. Debo considerar cancelar las migraciones de ASP.NET MVC 5/Web Api 2 a Core. Muchos marcos estables aún no están disponibles para Core. Todavía usamos EF6.x porque EF Core no es lo suficientemente maduro. Comparación de funciones.

@PinpointTownes tener tramos no es lo suficientemente bueno, necesitan usarlos en llamadas de métodos a tipos existentes.

"necesidad" es probablemente un poco excesivo. Los tramos se usan principalmente para el rendimiento, por lo que nada les impide usar las sobrecargas no superperfectivas existentes en .NET Desktop usando ifdefs hasta que .NET Desktop obtenga soporte nativo para tramos.

@davidfowl Creo que el gran problema es emocional. Si apunta a netstandard, sé que eventualmente podré actualizar de 1.x a 2.x (incluso con un retraso). La mayoría de las veces, actualizar netfx no es tan importante para una aplicación (diferente para una lib).

Pero algunas aplicaciones nunca podrán dar el salto netfx -> netcore, por lo que si apunta a netcore, saben que están en un callejón sin salida con 1.x.

En ese sentido, hubiera sido mejor si el núcleo de Asp.net nunca se hubiera ejecutado en netfx, tal como está, esperaban que continuara, y ahora se sienten (con razón, en mi opinión) traicionados. Después de todo, es posible que ya hayan invertido mucho tiempo en esto.

No estoy involucrado personalmente en esto, porque no soy un usuario de asp.net, mi gran pregunta es en realidad solo

Supongo que el plan sigue siendo que full-fx se ponga al día con netstandard, incluso si con un gran retraso.
(y si no se espera que ninguna otra plataforma, excepto NET Core, implemente .NET Standard 2.1, entonces, ¿por qué tener un .NET Standard?)

Con respecto a otras librerías dirigidas a net20, net35, etc., en mi experiencia, la mayoría de los autores intentan apuntar a la versión más baja que pueden y solo cortan plataformas donde no tienen otra opción.

Y __sí, creo que es razonable dejar de admitir versiones anteriores de .NET Framework__, porque todavía hay una ruta de migración clara disponible. Solo actualiza tu versión. La mayoría de las veces ni siquiera necesita cambiar nada, "solo" recompilar y probar.

Creo que ustedes subestiman seriamente la cantidad de aplicaciones que nunca podrán apuntar a netcore: solo una sola dependencia de terceros de código cerrado es suficiente para bloquear eso.

Span en sí tiene una versión portátil que se ejecuta en cualquier lugar, no estoy seguro de que la implementación rápida esté alguna vez en .NET Framework. Las API que se agregarán a .NET Framework que aprovechan Span pueden tardar mucho más que Span en sí mismo, es extenso. ¿Cuándo fue la última vez que cambiamos la cadena y la matriz en .NET Framework?

@davidfowl Creo que esto es quizás parte del problema. Honestamente, he estado jugando un poco al abogado del diablo aquí, porque estamos atrapados en el medio como una aplicación nueva que comenzó justo antes de que .Net Core fuera una cosa, por lo que estamos a ambos lados de la línea.

Nuestro pensamiento siempre ha sido usar las nuevas librerías sofisticadas (como Kestrel) si es posible, pero esperar a que .Net Core se estabilice (y me alegro de haberlo hecho, aunque solo sea por los cambios en las herramientas), _o_ esperar a que Cool Core bits para volver a Framework. Creo que la suposición de la mayoría de la gente ha sido que la mayoría, si no todos, los avances que Corefx ha estado haciendo se convertirían en Framework vNext o vNext+1. Pero, parece (desde nuestra vista de 30k pies) de este y otros cambios que Framework no es una plataforma del futuro.

Supongo que si es así, es así. Nuestro proyecto es enorme, así que confíe en mí cuando digo que entiendo el dolor de tener un montón de impl's personalizados de cosas que están cerca, pero no del todo, del tipo BCL o ifdef spaghetti. Entonces, no estoy sugiriendo cosas por ignorancia de las complicaciones. Definitivamente hay compensaciones.

De hecho, una buena pregunta: ¿qué queda del backporting de las características principales de .NET a .NET completo? Como leí aquí, .NET completo es muy frágil, mover el código toma años (se mueve muy lentamente) y puede romperse en cualquier momento (podría ser, no tengo idea de cuán entrelazado está), así que concluyo que eso no sucederá muy a menudo.

No pueden ser ambas cosas: o la copia de seguridad a .NET completa está bien, simplemente se lanzan con menos frecuencia (por ejemplo, cada 6 meses a un año) o es muy complicado y propenso a errores. Si es lo primero, acelera el paso y no dejes que tus usuarios paguen la factura y deja de usar lo segundo como excusa. Si es lo último, ¿no es la conclusión correcta entonces que netstandard es una falacia, ya que todo lo que importa para el futuro es la API de .netcore de todos modos?

Estoy seriamente preocupado por el futuro de la dirección de .NET. Mi empresa crea herramientas para .NET completo y .NET estándar 1.6. Lo último que queremos es que la fuerza impulsora de la dirección de .NET (las nuevas funciones que están a punto de ser adaptadas a .NET completo, como se dijo en el anuncio de .NET Core hace tantos meses) divida las cosas y el ecosistema de manera efectiva se parte por la mitad, ya que la fragmentación está matando.

Nada en este hilo me ha asegurado que las cosas están bien para el futuro de _all_ .NET y el ecosistema que se necesita para que siga vivo: solo veo dos grupos:

• Personas preocupadas porque las opciones se complican y tienen un problema difícil por delante.
• Microsoft que ve un camino por delante: el camino de .net core.

Estos dos no coinciden en este momento. ¿Puede alguien de Microsoft sacar una historia coherente para que todos podamos ver cuál es el verdadero negocio, cómo son realmente las cosas, es decir, con la transferencia de funciones a .net full, qué se hace con la gran cantidad de cosas que faltan en .net core? (cosas de sqlserver, alcance de transacciones, por nombrar algunos) y cómo Microsoft cree que puede vender esta nueva dirección como una plataforma sólida, confiable y confiable para el futuro, para que las corporaciones y los equipos grandes puedan elegirla sin preocupaciones.

Si bien estoy de acuerdo en que todo esto es algo bueno a largo plazo, también creo que abandonar el soporte para el marco completo con 2.0 es demasiado pronto.

Nos gustaría pasar a .NET Core lo antes posible, pero lamentablemente, nuestros mayores obstáculos en este momento son casi exclusivamente las bibliotecas de Microsoft (por ejemplo, Entity Framework Core aún no es lo suficientemente bueno, Azure Service Bus solo tiene una vista previa muy temprana).

Si bien espero que las bibliotecas de Azure estén listas en las próximas semanas o meses, no parece que EF Core tenga suficientes funciones en el corto plazo.

No sé nada sobre el funcionamiento interno de EF6, pero ¿no sería posible, con un esfuerzo razonable, tenerlo como objetivo de netstandard? Esto eliminaría un gran bloqueador...

"Permanecer en 1.x" no parece una buena alternativa porque seguramente habrá muchas bibliotecas a las que no les importe (o no tengan los recursos o el conocimiento para admitir ambas) y simplemente actualicen su dependencia a 2.0

PD: Estoy muy frustrado con lo complejo que se ha vuelto el ecosistema .NET en los últimos años. He tenido que pasar MUCHO tiempo para entender todas las cosas nuevas y no veo cómo un nuevo desarrollador debería entender nada de esto. Hay tanta información desactualizada en Internet ahora debido a todos estos cambios de última hora bastante extremos.
Además, todas las diferentes versiones del producto (.net core, sdk, .net standard, ...) son extremadamente confusas. Todavía tengo que ver a alguien que entienda la tabla estándar de .NET sin necesidad de una explicación de 20 minutos. 😞

cualquiera que estuviera usando .net core con la versión completa de .NET framework acaba de joderse y necesita volver a MVC 5

Sí. Entiendo el razonamiento, y supongo que podría decir que debería haberlo visto venir, pero es muy frustrante que se nos presente esto sin previo aviso.

Tenemos un ecosistema de aplicaciones, como muchos otros, con bibliotecas compartidas que datan de una década o más, múltiples aplicaciones MVC 3, 4, 5, aplicaciones de consola, servicios de Windows, cientos de miles de líneas de código. Ni siquiera estamos en una situación tan mala para actualizar en comparación con algunos.

Recientemente pusimos en marcha un par de nuevas aplicaciones web que utilizan ASP.Net Core 1.1, necesariamente dirigidas al marco 4.6.2 completo. Estas aplicaciones usan grandes porciones de nuestras bibliotecas compartidas existentes. Hemos gastado una cantidad vergonzosa de tiempo de desarrollo lidiando con project.json, luego con el nuevo .csproj, tratando de mezclar .csproj antiguos y nuevos en la misma solución, regresando a VS15 para hacer las cosas con los tipos .csproj antiguos, rotos Sistema. dependencias y una letanía de problemas de enlace de ensamblaje, problemas de compilación y publicación... la lista sigue y sigue.

Y ahora nos han dejado colgando alto y seco en un callejón sin salida. ¿Desperdiciamos algunos meses-hombre de desarrollo o gastamos muchas veces tratando de determinar primero qué podría y qué no podría funcionar y luego encontrar alguna forma de actualizar, y luego si eso es posible hacerlo?

No puedo decir que no estoy de acuerdo con la dirección y la necesidad de esto, pero se hubiera apreciado una comunicación anterior.

Ah, y por supuesto, las bibliotecas de Azure Service Fabric tampoco se ejecutan en .NET core, que es otro obstáculo para nosotros.

Diría que debe admitir el marco completo de .NET hasta que pueda ofrecer una historia central de .NET adecuada dentro de Microsoft (y especialmente Azure).

@cwe1ss Sin embargo, este cambio reducirá parte de la complejidad del ecosistema .NET. Ya que no tendrás dos formatos diferentes (ASP.NET Core + .NET Full y ASP.NET + .NET Core). Estoy totalmente de acuerdo con la información desactualizada, pero creo que eso no se puede evitar cuando se desarrolla abiertamente como lo hace Microsoft ahora.

@davidfowl

La historia del código compartido entre diferentes tiempos de ejecución de .NET es .NET Standard. Sus bibliotecas deben tratar de apuntar eso al código compartido en .NET Core y .NET Framework.<

Pero el marco completo, según tengo entendido, ni siquiera es compatible con el estándar.net, por lo que realmente no es un estándar útil.

Microsoft parece haber olvidado la importancia de la compatibilidad con versiones anteriores.<<

El problema es que ASP.NET Core nunca tuvo la intención de ser compatible con versiones anteriores... Por eso hubo un cambio de paradigma tan grande desde ASP.NET 4.x. Parece que si la compatibilidad con versiones anteriores es el bit de orden superior para usted, sería mejor usar ASP.NET 4.x en .NET Framework. Eso es compatible en el futuro previsible y tendrá parches de seguridad mientras Windows esté vivo.<

Los parches de seguridad son solo una parte del problema. Los estándares web cambian tan rápido que necesitamos tener algo con lo que podamos usar los estándares más recientes. Entonces, por ejemplo, vi en algún lugar arriba algo sobre HTTPS v2. No tengo idea de lo que eso significa en la práctica, pero el punto es que quiero que mi marco sea capaz de soportar estas cosas. Si me veo obligado a quedarme con una versión anterior del marco, ya sea v4 o v1, no admitirá las cosas que se requieren.

ASP .net Core siempre se comercializó como ejecutándose tanto en .net core como en el marco. Como han dicho otros, no me molesta si tenemos que esperar seis meses o un año hasta que el marco se ponga al día. De todos modos, normalmente estoy atrasado unos seis meses o más. Pero lo que parece estar sucediendo es que nuestra inversión existente se está abandonando por completo, como tantas otras tecnologías de Microsoft en las que muchos de nosotros hemos invertido tiempo.

stefano

@Rutix por "desarrollar al aire libre" este gran cambio se realizó sorprendentemente silencioso sin ningún anuncio ni encuesta (después de todo, este problema fue creado por un miembro de la comunidad que estaba viendo las solicitudes de extracción).

Hacer las cosas en silencio ha mordido a Microsoft en el pasado y parece que no aprenden. Y ni siquiera traten de decirme que no podían ver que dejar el soporte completo del marco perturbaría a la comunidad y dañaría la fe y la inversión en la plataforma.

El último incidente fue https://github.com/dotnet/roslyn/issues/17054 pero lo corrigieron rápidamente, me pregunto cómo terminará esto.

Pero el marco completo, según tengo entendido, ni siquiera es compatible con el estándar.net, por lo que realmente no es un estándar útil.

@stefanolson Eso no es correcto. Las bibliotecas destinadas a .Net Standard 1.x pueden ejecutarse en varias versiones de marco completo en la actualidad. Las bibliotecas que apuntan a .Net Standard 2.0 están programadas para poder ejecutarse en 4.6.1 la última vez que miré.

@Suchiman Estoy totalmente de acuerdo contigo en eso. Estoy un poco decepcionado de que no parezcan aprender a comunicarse y arrojar bombas sobre la comunidad. Podrían haberlo manejado mejor si lo hubieran anunciado primero y tenido una discusión comunitaria.

Pero el marco completo, según tengo entendido, ni siquiera es compatible con el estándar.net, por lo que realmente no es un estándar útil.

@stefanolson Lo hace. Diferentes versiones (existentes) de .NET Framework implementan diferentes versiones del estándar .NET. Consulte https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

Sé que llegué un poco tarde a este hilo, pero aquí hay dos de nuestros casos de uso para usar ASP.NET Core en NetFX en Windows:

Uso de ASP.NET para alojar una API REST para su aplicación

Nuestra aplicación es del tipo de aplicación "API .NET convertida en API REST". Primero se envió como una API de .NET y tiene dependencias en todo tipo de cosas de Windows.

Cuando agregamos una API REST, elegimos ASP.NET Web API para alojarla. Cuando quedó claro que la API web se estaba unificando en ASP.NET vNext/5/Core, __y__ descubrimos que __ASP.NET Core se ejecutaría en NetFX__, tenía sentido usar ASP.NET vNext/5/Core.

Si bien aprovechamos .NET Core para portar (parte de) nuestra aplicación a Linux y macOS, todavía hay dependencias de Windows que no se ejecutan en .NET Core (para obtener una lista de las dependencias que porteamos, consulte la CoreCompat.* paquetes NuGet).

En pocas palabras, ahora nos encontramos bloqueados en ASP.NET Core 1.x, que seguirá siendo compatible durante un período de tiempo limitado. ¿Y entonces que? ¿Volver a ASP.NET 4?

Entiendo todo el trabajo de rendimiento que está haciendo y empujando los límites en otras áreas de .NET Core, pero en mi caso de uso, no estoy alojando un sitio web expuesto a Internet de gran volumen, estoy alojando una API REST que obtener como qué, 10-20 RPS máximo?

Compatibilidad con Visual Studio

Realmente, mi experiencia con Visual Studio 2017 en NET 4.x sigue siendo mucho mejor que .NET Core; un buen ejemplo es la cantidad de tiempo que lleva volver a compilar un proyecto de prueba y mostrar las nuevas pruebas en la ventana de prueba. . Es mucho más rápido en NetFX.

Terminamos con una situación en la que hoy tenemos un proyecto de NetFX y .NET Core en paralelo compilando esencialmente la misma base de código. La única razón por la que nos mantenemos al día con este mantenimiento dual es por el rendimiento de Visual Studio con los proyectos de .NET Core (_especialmente_ las pruebas unitarias y el depurador).

Como idea de último momento, lo que realmente me llama la atención es que este cambio se realiza ahora, un par de días antes del lanzamiento de la versión preliminar. Simplemente parece indicar que aún no hay una razón técnica para hacerlo, entonces, ¿por qué no hacer el cambio en ASP.NET Core v3?

@mattnischan

@stefanolson Eso no es correcto. Las bibliotecas destinadas a .Net Standard 1.x pueden ejecutarse en varias versiones de marco completo en la actualidad. Las bibliotecas dirigidas a .Net Standard 2.0 están programadas para poder ejecutarse en 4.6.1 la última vez que miré.<

Me parece que asp.net core va a ejecutar .net core y no .net standard. Así que todavía no estoy seguro de cuál es el objetivo del estándar .net: si se abandona prácticamente tan pronto como se crea.

Tendría mucho sentido si asp.net core requiriera .net estándar 2.1 porque hay cosas que necesitan que no están en el marco en este momento. Así que tuvimos que esperar hasta que el framework .net completo admitiera esas funcionalidades adicionales antes de poder usar la última versión del núcleo de Asp.net. Eso funcionaría y tendría sentido.

Pero en cambio, simplemente están abandonando el estándar, lo que hace que el estándar sea inútil (si entiendo correctamente esta situación confusa)

Entonces... es Build 2017 a partir de mañana; Imagino que el equipo está muy ocupado preparándose para ello. Tal vez algunos anuncios, tal vez no. ¿Quizás darles un poco de espacio para respirar y volver a reunirse en una semana?

Tal vez ver el programa https://build.microsoft.com/ (miércoles 8:00 PST, 15:00 GMT y jueves similar?)

Podemos saber más; podría no. Las cosas pueden ser más claras, puede que no. Sin embargo, es probable que el equipo de ASP.NET pueda responder un poco mejor y centrarse más en las preocupaciones de todos. ¡Aunque @davidfowl lo ha estado haciendo con valentía!

@stefanolson Pero, en cambio, simplemente están abandonando el estándar, lo que hace que el estándar sea inútil (si entiendo correctamente esta situación confusa)

Creo que el objetivo de .NET Standard es la compatibilidad. Los autores de la biblioteca pueden apuntar a .NET Standard y luego cualquiera puede usarlo, ya sea que estén en .NET Framework, .NET Core o cualquier otra cosa que admita .NET Standard.

Creo que el objetivo de .NET Core es reimaginar .NET Framework. .NET Core es multiplataforma, de alto rendimiento, de código abierto y en rápida evolución.

Cambiar la implementación de string a utf8 de forma predeterminada es enorme y no es algo que esperaría ver en .NET Framework.

Después de leer este hilo, me siento:
.NET Core -> .NET Framework es como ASP.NET MVC -> WebForms.

También me gustaría secundar el aspecto de las herramientas. El rendimiento actual de restauración/construcción/prueba, etc. es muy malo y un dolor real. Si tuviéramos que "permanecer en 1.0", ¿aún podríamos usar SDK más nuevos con (con suerte) un mejor rendimiento o nos quedaríamos atrapados con un SDK 1.x?

La historia de .NET Core es un recorrido maravilloso lleno de altibajos. Recientemente comenzamos a trabajar en ASP.NET Core debido a todos los problemas anteriores (versiones, nombres, transición de project.json a .csproj) y esperaba (y espero) .netstandard 2.0, porque creo este será el primer lanzamiento "real".

Entiendo que ASP.NET Core 1.1 todavía es compatible y se ejecutará durante los próximos 10 años, pero ustedes son muy valientes para moverse __tan__ rápido y eliminar uno de los puntos de venta anteriores de ASP.NET Core.

Si desea saber qué es un bloqueador (además de los servicios de directorio) de nuestro lado: Todavía estamos usando EF6 y aún esperamos un paquete NuGet SDK Open XML oficial que apunte a netstandardwhatever.
La migración del código puede llevar mucho tiempo...

¿Sería posible formalizar algún tipo de proceso para impulsar netstandardXX en función de los cambios que ocurren en Core, lo que implica apuntarlo como parte de una fase de mantenimiento del lanzamiento de la biblioteca Asp.Net Core?

Tal como está, tengo una aplicación WebForms/MVC que estábamos a punto de activar para exponer una API web ANC y llamar desde un SPA (y, en última instancia, desde la aplicación heredada de WebForms), pero no podemos desarrollar en CoreCLR debido a una dependencia en el controlador Sybase (ahora SAP) Ase ADO.NET (si alguien que lee esto pudiera presionar un botón en algún lugar de SAP ... Lamentablemente, parece que no puedo ser escuchado en absoluto sobre esto o sobre errores que he conocido por más de 9 años ahora).

Al leer este número, ya no estoy tan seguro de cuál debería ser mi camino. Lo único que estoy seguro de que puedo planear es que seguirá existiendo un controlador con errores para el marco de escritorio. ¿Se suponía que debía ignorar los cambios en ASP.NET en los últimos años porque iban a ser una pérdida de tiempo y solo debería apuntar a WebApi2? ¿Se supone que debo decir seguir adelante con ANC 1.x sabiendo que probablemente nunca migraré y veré los beneficios de 2.x en una aplicación que creo que será compatible aquí durante los próximos 10 a 15 años (la aplicación WebForms tiene ha migrado y mantenido desde que se lanzó el marco 1.1)?

@davidfowl

Span en sí tiene una versión portátil que se ejecuta en cualquier lugar, no estoy seguro de que la implementación rápida sea alguna vez
en .NET Framework. Las API que se agregarán a .NET Framework que aprovechan Span pueden tardar mucho más que Span en sí mismo, es extenso. ¿Cuándo fue la última vez que cambiamos la cadena y la matriz en .NET?
¿Estructura?

¿Esperar lo?

No todos somos desarrolladores web. Hemos estado esperando ansiosamente un mejor soporte de manejo de cadenas durante años y ahora, de repente, ¿nos está diciendo que somos SOL? ¿Que .NET Framework y las innumerables aplicaciones no web creadas en él nunca tendrán acceso a las bibliotecas de manejo de cadenas basadas en Span?

Esto ya no es solo un problema de ASP.NET. Va al corazón del compromiso a largo plazo de Microsoft con .NET Framework y su biblioteca de clases base.

Sabes, realmente tengo que dárselo a personas como @davidfowl por continuar respondiendo a todos y a todos por contribuir a esta discusión. Tengo mucho con lo que ponerme al día hoy, pero siento que estoy aprendiendo mucho a través de cada comentario en términos de lo que todos usan/para lo que esperan usar .NET.

Creo que, con la ayuda de todos, finalmente conseguiremos enderezar algunos caminos y espero que se tengan en cuenta todas las partes.

Espero con ansias el anuncio oficial.

Si lo entendí bien, net coreapp 2.0 proporcionará una corrección de compatibilidad que permitirá que nuestros proyectos ASP.NET Core 2.0 dependan de nuestras bibliotecas de clases NetFx heredadas (p. ej., net461).
¿Dónde puedo encontrar más información sobre las capacidades/limitaciones planificadas actualmente de dicha compatibilidad?

@dgaspar Eso no es realmente exacto, así es como funciona: netcoreapp2.0 es compatible con la mayoría de las API en net461 . Si su biblioteca está construida para net461 y solo llama a las API que existen dentro del subconjunto que admite netcoreapp2.0 , entonces puede importar la biblioteca de todos modos (piense en ello como anulación, que usted sabe mejor) y haz que se ejecute, ya que todas las clases y métodos que llama deberían estar allí.

Ahora también hay una desventaja: si los métodos no están allí o no son totalmente compatibles de alguna manera, obtienes errores de tiempo de ejecución para los métodos que faltan, etc. Por lo tanto, las comprobaciones en tiempo de compilación no son una buena garantía allí. Es un poco como una espada de doble filo a tener en cuenta, pero hay algunas bibliotecas que nunca se actualizarán pero que están bien con el conjunto de API a las que llaman.

@NickCraver alguien recuerda...

"imports": [ "dnxcore50", "portable-net45+win8" ]

Un comentario relacionado que hice en diciembre. 11 pulgares arriba llevados adelante:

Algo está fuera de los rieles aquí. He estado distribuyendo aplicaciones de C# durante 15 años. Irónicamente, a medida que Microsoft envía abstracciones de mayor nivel, dedico más y más tiempo a profundizar en los aspectos internos de los que nunca antes había tenido que preocuparme. LO ESTÁS HACIENDO MAL.

Si quisiera sorprenderme en tiempo de ejecución con errores aleatorios inducidos por bibliotecas y administración de paquetes que el compilador no detectó, escribiría mis aplicaciones en Ruby.

incluso node.js nos permite llamar fácilmente a todas las bibliotecas netfx.

el código mvc es realmente la parte fácil. puede llevar algunas semanas volver a escribir en node.js o nancy, pero llevará mucho más tiempo migrar el código empresarial y del algoritmo, y demostrar que funciona tan bien como el anterior. por no hablar del caso cuando no tenemos la fuente.

Tome el ejemplo de RyuJit, incluso después del lanzamiento a producción, se encontraron errores importantes de bloqueo y tomó otro año resolverlos por completo. lo mismo para nuestro software, que no son tiendas de mascotas sino herramientas industriales que ayudan a ganar millones de dólares al día.

el marco de la interfaz de usuario cambia rápidamente, de winform a web. pero la lógica/algoritmo empresarial central es mucho más estable y de larga duración. Entonces, para usar el nuevo marco de interfaz de usuario brillante, ¿necesitamos reescribir/volver a probar o abandonar nuestro código de negocio/algoritmo? no, sabemos que el nuevo brillante será reemplazado por algo más moderno en 5 años, pero nuestro código de negocio/algoritmo seguirá siendo utilizado.

@qmfrederik

Como idea de último momento, lo que realmente me llama la atención es que este cambio se realiza ahora, un par de días antes del lanzamiento de la versión preliminar. Simplemente parece indicar que aún no hay una razón técnica para hacerlo, entonces, ¿por qué no hacer el cambio en ASP.NET Core v3?

Estamos haciendo soporte HTTP2 a continuación y requiere nuevas API.

También me gustaría secundar el aspecto de las herramientas. El rendimiento actual de restauración/construcción/prueba, etc. es muy malo y un dolor real. Si tuviéramos que "permanecer en 1.0", ¿aún podríamos usar SDK más nuevos con (con suerte) un mejor rendimiento o nos quedaríamos atrapados con un SDK 1.x?

Sí, eso funcionará.

@davidfowl

Estamos haciendo compatibilidad con HTTP2 a continuación y requiere nuevas API.<

Entonces, ¿el tipo de compatibilidad con HTTP2 que estará disponible en asp.net core 2.0 no estará disponible en 1.x? Este es realmente el tipo de problema que me preocupa en el que no tendremos acceso a la última tecnología porque estamos vinculados al marco completo de .NET por cualquier motivo. Como dije anteriormente, no importa si toma de seis meses a un año para que ese filtro llegue a lo que sea que esté usando, pero en última instancia no quiero estar demasiado atrás. Debido al código compartido y al uso de bibliotecas de terceros en esta etapa, necesito el marco completo de .NET.

Por fin, aclaro algunas cosas:

• cuando digo módulos heredados, son dlls que dependen de netfx o c++/cli dlls, que a su vez pueden activar algunos dlls nativos. son para negocios/algoritmos, sin COM, sin asp.net. no son malos se vuelven heredados principalmente porque .net core no los ejecuta.
• es posible migrar a net core a largo plazo, y realmente lo queremos. pero es realmente difícil presionar para que eso suceda. Tomará algunos años para que nosotros y terceros estemos todos allí.
• las bibliotecas específicas de dominio son mucho más lentas que las bibliotecas principales para los cambios de pila tecnológica. todos conocemos el ejemplo de python 3. esas bibliotecas específicas de dominio son un verdadero negocio.

@danielcrabtree

Creo que el objetivo de .NET Core es reimaginar .NET Framework. .NET Core es multiplataforma, de alto rendimiento, de código abierto y en rápida evolución.<

Lo cual es fantástico. El desafío es cómo lidiar con las bases de código existentes y cómo podemos usarlas con .net core. Si WPF estuviera disponible integrado en .net core, entonces podría usar .net core en todas partes. Pero como no lo es y mi código se comparte entre WPF y ASP.net, necesito una forma de compartirlos. Pero no quiero quedarme demasiado atrás con la tecnología web y las técnicas de seguridad más recientes, la mayoría (¿todas?) de las cuales parece que solo estarán en 2.x y versiones posteriores.

Algunas veces en este hilo y en la documentación en otros lugares, .NET Core se describe como multiplataforma. Esto se anunció como uno de los principales puntos de venta para pasar a la plataforma.

Sin embargo, este no parece ser el caso , como se aclara en esta conversación en Twitter.

https://twitter.com/James_M_South/status/861595907782987776

Y el comentario de arriba; énfasis mío.

Los grandes vacíos restantes que faltan en .NET Core 2 son System.DirectoryServices y System.Drawing. Estamos trabajando para tener un paquete de compatibilidad con Windows que habilitaría ambos en .NET Core en Windows este verano.

He estado trabajando muy duro con .NET Core desde muy temprano tratando de llenar el vacío dejado por System.Drawing con ImageSharp y ahora estoy muy confundido y más que un poco descontento y pregunto:

¿Qué es .NET Core ahora?

Aquí está la descripción de MS Docs .

.NET Core es una plataforma de desarrollo de propósito general mantenida por Microsoft y la comunidad .NET en GitHub. Es multiplataforma, compatible con Windows, macOS y Linux, y se puede usar en escenarios de dispositivo, nube e integrado/IoT.

Ahí está esa declaración multiplataforma de nuevo. ¿lo es o no lo es? Creo que tratar de precisar esto genera mucha confusión en la comunidad de desarrollo.

Cada descripción que leo parece ser diferente.

Podemos:

1. Escriba un mensaje decente y coherente en algún lugar para que podamos tener un objetivo al que apuntar y una mejor comprensión general.
2. Obtenga algo de claridad en la hoja de ruta real para System.DirectoryServices y System.Drawing

System.Drawing en particular es confuso y preocupante. No puedo entender por qué querrías portar esa API a .NET Core en cualquier plataforma. Es difícil trabajar con él, no es compatible con el servidor y carece de muchas características críticas necesarias para el desarrollo moderno (multiprocesos, formatos de píxeles, ICC, EXIF, cuantificación, Png indexado, etc.).

Hay muchos nombres y rostros reconocibles aquí, y sé que solo estoy agregando algo de ruido aquí, pero:

• Directorio de Servicios
• Dibujo (no es que lo necesite)
• FE

Estas parecen ser las tres cosas más críticas que hay que tener al día antes de hacer una ruptura tan grande. Personalmente, casi todo en lo que trabajo está en net4x únicamente gracias a EF6, desde EFCore... bueno... :trollface:

@stefanolson
Creo que se espera que separe el código compartido en una biblioteca estándar de .NET. Entonces se podrá usar desde WPF y ASP.NET en .NET Framework y desde ASP.NET en .NET Core y otras aplicaciones .NET Core.

@JimBobSquarePants
No creo que el paquete de compatibilidad de Windows sea parte de .NET Core. Es una biblioteca específica de Windows que se encuentra sobre .NET Core. Podría imaginarse que hay una biblioteca específica de Linux que expone características exclusivas de Linux.

Creo que el paquete de compatibilidad de Windows trata de simplificar la migración de bases de código de .NET Framework existentes. Obviamente, una vez que alguien haya cambiado a .NET Core, debería considerar migrar a mejores soluciones como ImageSharp.

@stefanolson
Es posible que incluso puedan crear un paquete WPF solo para Windows que le permita crear aplicaciones WPF en .NET Core, pero que solo se ejecute en Windows.

Este problema de GitHub se ha mencionado en un sitio de noticias de TI alemán:
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

Gracias @danielcrabtree , es la primera vez que escucho sobre algún paquete de compatibilidad.

Traducción del enlace de @MJomaa : https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert- net-entwickler-mit-support-entscheidung-1705-127712.htm

Estoy esperando que System.Xaml sea transferido.

@alexwiese no contengas la respiración.

Estoy esperando que System.Xaml sea transferido.

Seguir; Morderé. ¿Cómo está utilizando Xaml en su sitio web?

Seguir; Morderé. ¿Cómo estás usando Xmal en tu sitio web?

Interfaz de usuario multiplataforma (plantillas de pantalla compartidas entre una aplicación de consola de "pantalla verde", la aplicación Xamarin y un SPA angular), también se usa para un motor de reglas comerciales.

Wow, ok, ¿entonces estás transformando el XML de XAML de alguna manera a HTML y Javascript? Bastante justo 😄

No estaba seguro si solo estabas trolleando.

Estoy haciendo lo mismo, pero de manera realista no los veo transfiriendo XAML, considerando que en este punto no se puede analizar sin ejecutarlo también.

Wow, ok, ¿entonces estás transformando el XML de XAML de alguna manera a HTML y Javascript? Bastante justo 😄

Por supuesto que no; Estoy convirtiendo a JSON primero 😉

Otro artículo de noticias sobre este tema con muchos de nosotros citados: https://www.infoq.com/news/2017/05/ASPNET-Core-2

@cwe1ss El autor es @Grauenwolf

@alexwiese @yaakov-h Me encantaría leer una publicación de blog sobre eso; suena bastante interesante y debe venir con un conjunto diferente de desafíos a los que estoy acostumbrado.

Esto es realmente malo. ASP.NET Core fue una venta razonable cuando podía aprovechar las bibliotecas heredadas cuando era necesario. En el caso de que se pueda hacer con las cosas nuevas, modifique algunas cosas y apunte a .NET Core. De lo contrario, solo apunte al marco completo.

Con este cambio, es un salto de todo o nada. Y dado que no siempre comprende todas las dependencias desde el principio, aumenta el riesgo.

Entiendo el deseo de moverse rápido y evolucionar hacia donde deben ir las cosas de todos modos, pero dejará atrás a sus usuarios. La gente tiende a migrar, no a saltar. Un gran número simplemente no se moverá de la corriente. Y luego, cuando lo hagan, bien podrían pasar a una plataforma completamente diferente. En serio, estás subestimando ese riesgo.

Este es un movimiento que eventualmente debería hacerse, pero más como a fines de 2019 o 2020 como muy pronto. Incluso entonces, aún desea un modelo a largo plazo para apoyar a aquellos que han elegido mezclar cosas.

Y no, ASP.NET Core 1.x simplemente no es una respuesta allí. Su inmadurez está bien como una fase de transición con un camino de migración fácil hacia adelante, pero no es adecuado para vivir a largo plazo. Hay una gran diferencia entre la mentalidad de quienes desarrollan una plataforma como esta y la de quienes la usan. Por favor, reconsidere esta dirección.

@davidfowl ¿Qué tal algo como edge.js para netcore? Hace que el consumidor de la API sea responsable de las comprobaciones de la plataforma y una interfaz fuertemente tipada entre netfx y netcore es suficiente para la mayoría de los escenarios.

¿Se eliminará esta plantilla entonces?

Está integrado en VS2017 en este momento.

Qué tontería totalmente inaceptable, nuevamente esto demuestra que es una tecnología de juguete que no está lista para el horario de máxima audiencia y la adopción generalizada.

Realmente aprecio muchachos, tienen un buen viaje y experiencia de codificación, pueden brillar en sus entradas de blog y Twitter (¡hurra!), mejorar sus perfiles de LinkedIn y cvs (hurra ^ 2), todas las fiestas de lanzamiento por delante, chicas, bebidas y las cosas parecen prometedoras, pero... ¿quién las va a usar? ¿Se dirige a empresas y desea una gran adopción y una base de usuarios sólida? o solo algunos hippies de inicio?!?

Ese comentario sobre "Full Span" que posiblemente nunca llegue a .NET Framework me preocupa seriamente. Si el Span completo no está en .NET Framework, supongo que las API que lo usan nunca podrán convertirse en un estándar de red futuro, lo que hace que sea imposible escribir bibliotecas multiplataforma que usen o expongan análisis de alto rendimiento. Lo que significa que estamos atascados con nuestras implementaciones personalizadas inseguras de forma permanente y efectiva...

Usted menciona que si desea que su biblioteca sea multiplataforma, debe apuntar a netstandard, pero ¿qué es ASP.NET Core sino una biblioteca que se usa ampliamente? ¿Recomendaría que otras bibliotecas comenzaran a dejar de admitir netstandard y cambiaran a .NET Core? ¿Debería la próxima versión principal de JSON.NET o lo que sea eliminar netstandard? ¡Ciertamente podría funcionar con un análisis rápido!

Tenga en cuenta que Java logró agregar IO rápido sin copiado, etc. de una manera compatible con versiones anteriores con Netty (https://netty.io/)

Finalmente, quiero agradecer a las personas que están dispuestas a quedarse y responderlas. Agradecemos las respuestas...

@shanselman Moverse rápido es un objetivo noble, especialmente para los equipos que se esfuerzan mucho en la compatibilidad y diseñan las cosas de manera compatible, como el equipo ASP.Net. Sé cuánto les gustaría simplificar el dominio de su problema y lo apoyo, pero...

Moverse rápido y al mismo tiempo "también lejos" de sus clientes tampoco es algo bueno. Ya sabes, tus clientes (incluido yo) tienen un conjunto serio de software heredado e inversión de tiempo en aplicaciones y bibliotecas existentes. No puedes simplemente dejarnos atrás e ir a un lugar donde no podemos seguirte.

Debe tener en cuenta a sus clientes que no pueden ir a .Net core y deben usar Full Framework durante al menos un tiempo más a partir de ahora. Si se aleja de Full Framework, deja a muchas personas atrapadas en versiones anteriores y crea una gran división en el mundo .Net.

@JimBobSquarePants Te apoyo en la parte System.Drawing . Hay algunas discusiones en los otros repositorios sobre la recuperación System.Drawing . Basado en algunos de los comentarios en este hilo, entiendo que primero habrá un "paquete de compatibilidad" en Windows y luego en todos los sistemas operativos por System.Drawing .

Me pregunto cómo se verá y si se basará en libgdiplus de Mono o no (lo que eliminaría algunas de las preocupaciones que tiene con System.Drawing, pero esa es otra historia)

De acuerdo, a mi modo de ver, hay un par de cuestiones en juego:

1. Esto fue comunicado bastante mal.
2. La gente no estuvo involucrada en la decisión. Tenga en cuenta que, por supuesto, Microsoft es libre de elegir la dirección que desee, pero no discutir este tipo de gran cambio con la comunidad no está en el espíritu del desarrollo de código abierto.
3. No existe un "gran esquema" que la comunidad pueda utilizar para examinar este tipo de decisiones. Al principio, .NET Core era una versión recortada y multiplataforma del marco completo. Luego, con .NET Standard 2.0, a muchos les pareció que .NET Core 2 sería como un reemplazo directo del marco completo, dentro de límites razonables, por supuesto (sin UWP, WinForms, etc.).
4. .NET Core 2 perderá varias funciones importantes que se encuentran en el marco completo, como System.DirectoryServices. Por lo que puedo decir, esto se ha reconocido, pero tal vez el camino para agregar estas funciones a .NET Core podría hacerse más explícito.
5. ASP.NET Core 2 no se ejecutará en el marco completo debido a que faltan características más nuevas en el marco completo. De hecho, estoy totalmente de acuerdo con esto. Si agregar las funciones que faltan al marco completo es demasiado difícil, no lo haga. Hacer que ASP.NET Core 2 solo se ejecute en .NET Core 2 en realidad tiene bastante sentido, aunque mencionarlos como un solo producto probablemente no fue la mejor manera de describir su relación.

Lo que creo que a la gente realmente le gustaría ver es una descripción de la visión de la plataforma .NET. ¿En qué dirección irán las cosas? ¿El marco completo solo recibirá correcciones de errores y demás, pero no nuevas características? ¿Qué se está haciendo para agregar funciones faltantes a .NET Core y cuándo podemos esperarlas? Tener esto explicado contribuiría en gran medida a aliviar la ansiedad que la gente siente ahora.

@davidfowl Supongo que no se trata solo de HTTP 2.0; si realmente se trata de HTTP 2.0, ¿no podría tener NetFX objetivo de ASP.NET Core 2.0 con la excepción de la compatibilidad con HTTP 2.0? ¿Quizás incluso un modelo conectable para que la comunidad pudiera hacer HTTP 2.0 en NetFX si realmente quisieran?

@cokkiy @popcatalin81 @xprzemekw Si no tiene nada constructivo que decir, absténgase de comentar, este tipo de comentarios no ayudan a nadie.

Hay razones legítimas por las que hacer el movimiento descrito por @davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

Las razones por las que posponerlo incluyen (por ejemplo, asp.net core 3.0):

• EF Core aún no está listo para reemplazar a EF 6.0 debido a que faltan muchas características
• sin producción lista System.Drawing reemplazo
• sin System.DirectoryServices
• se mencionó office xml sdk , pero parece que ya está disponible en netstandard a partir del 2017-05-01 https://www.nuget.org/packages/DocumentFormat.OpenXml/
• otros paquetes fuera del alcance de MS no están disponibles en .net core (nhibernate, varios proveedores de db, ikvm)

Las razones por las que no hacerlo nunca incluyen:

• Las personas portaron aplicaciones a asp.net core con dependencias heredadas sin intención de pasar a .net core.
• Preocúpate por dejar atrás NetStandard y no preocuparte mucho por ello.
• Es poco probable que algunos paquetes de terceros se transfieran a .net core (lo que podría decirse que los vuelve obsoletos, pero esa podría ser solo mi opinión)

Un ejemplo de comentario constructivo sería agregar la razón por la que le gustaría ver uno de estos tres escenarios o sugerir una solución alternativa. Si solo desea expresar su acuerdo/desacuerdo, utilice los botones de "Reacción".

@Kukkimonsuta

Las personas portaron aplicaciones a asp.net core con dependencias heredadas sin intención de pasar a .net core.

Completamente de acuerdo. Porque Microsoft había anunciado que ASP.NET Core funcionará tanto en .net core como en .net frameworks. Y ahora dejarlos en AspNet Core 1.x no es justo.

El último resumen es bastante bueno. Me gustaría añadir una cosa o dos:

1.) Debería ser posible escribir servicios de Windows con .NET Core (sé que los demonios en las plataformas *NIX funcionan de manera diferente). Por lo tanto, ServiceBase aún sería necesario, y esto es de alta prioridad junto con EF.

2.) Además, debería ser posible escribir servicios independientes con .NET Core y, además , alojarlos dentro de su aplicación .NET basada en un marco completo existente (es decir, un servicio gratuito de su aplicación Windows Forms/WPF) para ampliarlos.

Este último realmente es necesario para escenarios de migración lenta, donde no es posible hacer un corte duro y comenzar de nuevo.

Completamente de acuerdo. Porque Microsoft había anunciado que ASP.NET Core funcionará tanto en .net core como en .net frameworks. Y ahora dejarlos en AspNet Core 1.x no es justo.

También me gustaría enfatizar nuevamente que el gran cambio de regreso a .csproj y msbuild se excusó principalmente con el hecho de que no sería posible hacer referencia a proyectos (ASP).NET Core desde sus proyectos .NET (marco completo) existentes.

Este cambio hace que esto último sea imposible (al menos para la parte más grande de ASP.NET). Entonces, ¿por qué la compatibilidad era primordial en ese entonces (y causaba mucho dolor), pero no lo es ahora (y nuevamente causa mucho dolor)?

Lo siento, también tengo que estresarme. Pero casi 500 comentarios, creo que si estoy involucrado como un chico de Microsoft en este problema, tenía dos opciones:
1: silenciar el problema
2: reconsiderar mi decisión

@gingters Sin embargo, el cambio de csproj fue principalmente para _.net_ core, para que xamarin, asp.net, uwp y todos los demás compartan código y también hagan referencia a otros tipos de proyectos como código nativo.

Además, permite que los proyectos de asp.net core 2 hagan referencia a proyectos de marco completo, nuevamente, a través de la compatibilidad shim

@qmfrederik

¿Quizás incluso un modelo conectable para que la comunidad pudiera hacer HTTP 2.0 en NetFX si realmente quisieran?

Técnicamente podrían. Pero parece que no quieren. Para mí, parece que simplemente no quieren pensar en las necesidades reales de las empresas / grandes empresas, o en la compatibilidad con versiones anteriores o en la necesidad de lidiar con algo más que cosas nuevas.

Y para ser sincero, la gestión de expectativas en el pasado estaba completamente dirigida a empresas que deseaban extender/migrar lentamente sus cosas a multiplataforma, al mismo tiempo que podían extender/migrar lentamente sus aplicaciones existentes. Por lo tanto, este movimiento no está alineado en absoluto con la gestión de expectativas anterior.

@aL3891

para que xamarin, asp.net, uwp y todos los demás compartan código

Si. Exactamente. Y eso también incluye la aplicación WPF/Windows Forms para consumir bibliotecas .NET Core, lo que ahora es imposible cuando desea pasar a .NET Core 2.

¿Alguien podría explicar exactamente por qué diablos estas bibliotecas no pueden apuntar a netstandard2.0 ?

Hasta ahora, he considerado netcoreapp como un apodo para un ejecutable multiplataforma (solo se usa en un proyecto ejecutable csproj), pero nunca lo consideré como una plataforma, ahora, ¿debería considerarse como una plataforma real? ¿Por qué, por qué, y cómo llegamos a esta absurda opción?