Aspnetcore: Discusión: ASP.NET Core 3.0 solo se ejecutará en .NET Core

Creo que ahora esto tiene mucho sentido en el panorama general. Tanto .NET Core como ASP.NET Core han existido durante el tiempo suficiente para que las personas ya tuvieran o aún tengan la oportunidad de cambiar a él, sin causar grandes problemas (en comparación con cuando el soporte se eliminó por primera vez en el pasado con 2.0) .

Sin embargo, estoy triste por las implicaciones para ciertos componentes de ASP.NET Core que actualmente pueden existir como dependencias separadas. Porque esto probablemente significará que los componentes individuales eliminarán el soporte de netstandard, requiriendo netcoreapp3.0 en su lugar; y especialmente con # 3756 esos componentes serían inutilizables fuera de un contexto ASP.NET Core.

Por ejemplo, proyectos como RazorLight se verán obligados a eliminar .NET Framework y, lo que es más importante, la compatibilidad con .NET Standard en general.

Esto dejará a muchas personas que han vendido el cambio al nuevo modelo de programación ASP.NET Core en su organización para permanecer en una plataforma compatible y desarrollada activamente en una plataforma no compatible en menos de 3 años (. NET Core 2.1 LTS).

No estoy seguro de qué análisis ha utilizado para justificar este movimiento, pero para ejecutar ServiceStack ASP.NET Core Apps en .NET Framework , vemos que la plantilla web-corefx más popular para ejecutar el proyecto ASP.NET Core en el .NET Framework tiene más de 1/3 (33,8%) de compartir y luego la misma plantilla web vacía, que es nuestra plantilla de proyecto más popular para ejecutar en .NET Core.

En mi opinión, 3 años no es tiempo suficiente para abandonar a los Clientes que han comenzado o se han mudado al nuevo modelo de programación ASP.NET (para escapar de la plataforma ASP.NET Framework estancada) solo para descubrir ahora que la plataforma que han vendido a su organización para mudarse ha sido abandonado.

Por alguna razón, hay Clientes que no pueden pasar a .NET Core debido a que dependen únicamente de las dependencias de .NET Framework, si MS no desea mantener el soporte para .NET Framework en ASP.NET Core 3.0 en el futuro, en mi opinión, debe extender el soporte para ASP.NET Core 2.1 en .NET Framework a un período extendido como 7 años. Las migraciones de los sistemas de producción existentes pueden llevar años, desde que se inició .NET Core, está claro que ASP.NET Framework se ha estancado con la postura oficial de que ASP.NET Core es el modelo de programación futuro para .NET, ahora los mismos Clientes lo harán pronto comenzarán a descubrir que el nuevo modelo de programación al que se han mudado / se están moviendo no será compatible en unos años. La mejor manera de adaptarse a estos Clientes .NET existentes es admitir .NET 2.1 durante un período adicional de LTS, al menos para parches de seguridad (idealmente para resolver errores también).

"matando .NET Framework", episodio 2: misma historia, mismos personajes : rofl:

Lamentablemente, esto solo resalta una cosa: fallaste por completo en hacer de .NET Standard el vehículo principal del ecosistema .NET . No se mueve tan rápido como debería y no es más que un mínimo común denominador que siempre se actualiza en el último momento, cuando todas las plataformas incluyen (o están a punto de incluir) las nuevas API.

Quizás sea solo yo, pero nunca he entendido por qué no se movió tan rápido como netcoreapp (que es el primero en obtener las nuevas API, por definición).

¿Es autor de paquetes NuGet y desea que utilicen las últimas novedades? Apunte a la versión netstandard reciente: seguro, inicialmente, solo las aplicaciones basadas en netcoreapp podrán usarlas, pero eventualmente otras plataformas, como Xamarin, Mono o .NET Framework, se pondrán al día. y la gente podrá usar sus paquetes sin necesidad de que cambie nada. Así es como deberían funcionar las cosas.

Por supuesto, las plataformas que no son de .NET Core como .NET Framework pueden tardar un tiempo en ponerse al día, ya que las versiones son más raras y la barra de estabilidad es mucho más alta, pero incluso si se necesitan 6, 12 o incluso 18 meses, no lo hago. Creo que es un problema, porque eso es lo que la gente quiere cuando usa .NET Framework: un marco estable, no un objetivo en rápido movimiento.

En mi humilde opinión, sería un enfoque mucho mejor hacer que ASP.NET Core 3.0 apunte a un nuevo netstandard TFM exponiendo todas las API de .NET Core que necesita. Una vez que esté seguro de que las nuevas API son lo suficientemente estables, vuelva a exportarlas a .NET Framework para que sea compatible con el último estándar.

Estoy seguro de que la gente preferiría tener que esperar unos meses antes de poder mover su aplicación .NET Framework a la última versión de ASP.NET Core en lugar de estar bloqueada para siempre en una versión anterior con un soporte súper corto de 3 años.

Haga lo que prometió: haga de .NET Framework un marco estable que evolucione más lento en lugar de un callejón sin salida para aquellos que confiaron en usted al migrar a ASP.NET Core.

No me gusta esto Al comienzo de .net core, Microsoft no eligió mono o .net framework como una plataforma cruzada, y dijiste que hay múltiples tiempos de ejecución .net allí, así que diseñas el .netstandard , ahora todavía hay muchos paquetes nuget que no son compatibles con .net core (razón media) .Muchos desarrolladores se quedarán atrás en el antiguo modelo de programación de asp.net core si asp.net core solo se ejecuta en .net core. entonces .net standard existirá solo en el nombre (al menos para el núcleo de asp.net, la gente comienza a construir paquetes netcoreapp solo).
Tal vez algún día, .net core pueda reemplazar .net framework en Windows, pero ¿qué pasa con mono, y otras plataformas dependen de mono (xamarin, unity3d)?
y otra razón por la que en algún momento prefiero .net framework es que .net core share framework es realmente enorme, ¿qué tamaño tiene tu carpeta C:/program file/dotnet si actualizas tu aplicación de .net core 2.0 a la última .net core 2.1? Hay un archivo de GB en mi carpeta y crece cuando actualizo .net core runtime. pero .net framework simplemente reemplazará la versión anterior.

Haga lo que prometió: haga de .NET Framework un marco estable que evolucione más lento en lugar de un callejón sin salida para aquellos que confiaron en usted al migrar a ASP.NET Core.

FWIW, esta sería la estrategia óptima, mi sugerencia de extender el LTS es la barra mínima para dar más tiempo a los Clientes existentes que se han comercializado agresivamente para migrar a ASP.NET Core que ahora han sido abandonados en una futura plataforma no compatible con esto. anuncio.

¿Entonces .net estándar es una broma? Espero que el equipo mono bifurque los repositorios aspnetcore y cambie el nombre a aspnetmono, de lo contrario, puedo dejar la pila.

Supongo que esto significa que en mi trabajo nunca usaremos ASP.NET Core. Nos quedaremos en ASP.NET para siempre, sin importar la migración de una aplicación a Core, porque eso ahora implicaría aún más cambios.

Claro, si su objetivo es no tener cambios, puede seguir haciendo lo mismo para siempre. Donde trabajo, comenzamos a usar ASP.NET Core hace un par de años, inicialmente ejecutándome en .NET Framework. Con el tiempo, a medida que la plataforma .NET Core maduraba y ganaba funciones, cambiamos nuestros proyectos a netcoreapp. Uno o dos proyectos más antiguos todavía usan ASP.NET, y no tenemos planes de reescribirlos, es código de trabajo. Pero para las cosas más nuevas, esperamos características como Span.

El cambio puede posponerse, pero no es algo que pueda o deba evitar para siempre: la tecnología _es_ cambios y el trabajo de un desarrollador siempre requerirá aprender cosas nuevas. Si está utilizando ASP.NET Core en .NET Framework hoy, es poco probable que lleve tres años de trabajo moverlo a .NET Core.

Ven a .NET Core, el agua está tibia ...

Por alguna razón, hay Clientes que no pueden pasar a .NET Core debido a que dependen únicamente de las dependencias de .NET Framework ...

Más en serio, puede usar las bibliotecas .NET 4.x en .NET Core 2.0 desde .NET Standard 2.0 ; aunque existe la posibilidad de que utilicen algunas características que .NET Core no tiene; aunque existe el Paquete de compatibilidad de Windows para .NET Core que cubre muchos de estos agujeros y muchas más características son compatibles con .NET Core 3.0, incluida la interoperabilidad COM y otros modelos de aplicaciones como WinForms y WPF, etc.

Cualquier bloqueo que impida que una aplicación ASP.NET Core se mueva a .NET Core desde .NET Framework probablemente debería plantearse en dotnet / corefx .

Para Xamarin; Podría estar equivocado, pero supongo que es poco probable que lo use para ejecutar un servidor web en iOS o Android.

Para las aplicaciones cliente Mono, el servidor web podría quedarse sin proceso y ejecutarse en .NET Core mientras la interfaz de usuario se ejecuta en Mono. Kestrel nunca ha podido ejecutarse en una plataforma Big Endian que elimina algunas de las otras plataformas de Mono, aunque los sabores BSD son actualmente una brecha de .NET Core.

Por la unidad; los juegos hacen todo tipo de cosas extrañas, así que tal vez ese sea un escenario no cubierto; si el juego estaba usando el servidor web en el cliente; en lugar de en un servidor o fuera de proceso; cuando .NET Core podría ejecutar esa parte.

Fuera del modelo de aplicación ASP.NET Core; Por ejemplo, para las bibliotecas .NET Standard es más importante ya que ASP.NET Core tiene todo tipo de características útiles, Razor es un ejemplo particular.

No todas las bibliotecas se están moviendo solo a .NET Core (por ejemplo, Microsoft.Extensions.* se quedan como .NET Standard) y probablemente sería útil proporcionar escenarios específicos que se verían afectados como lo ha hecho https: // github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416 para que se puedan tener en cuenta; en cuanto a qué bibliotecas y / o características específicas pueden mantenerse disponibles en .NET Standard en lugar de simplemente un "todo" nebuloso.

ASP.NET Core está impulsando muchos cambios y nuevas apis en .NET Core y puedo entender el deseo de luego usar esas características (ya que ese fue uno de sus casos de uso); de lo contrario, es un poco contraproducente.

Por otro lado, sería bueno si también estuvieran en una versión .NET Standard para que otros tiempos de ejecución pudieran admitir ASP.NET Core 3.0 cuando comiencen a implementarlo. Siendo realistas, eso no sería pronto (ya que .NET Standard 2.1 aún no está finalizado y tendría que ser una versión posterior).

¿Quizás el modelo de aplicación ASP.NET Core volverá a .NET Standard en una fecha posterior cuando las cosas se hayan puesto al día? ¿Aunque siempre se está moviendo demasiado rápido para el proceso de .NET Standard como funciona actualmente?

@gulbanana ¿y si su núcleo asp.net en .net framework usa com? ¿O hay un paquete nuget que solo admite .net framework?

Creo que nunca fue una cuestión de si la mudanza debería hacerse o no, sino sólo cuándo.
La última vez que esto causó una ~ discusión ~ tormenta de mierda, el ecosistema no estaba listo para permitir la portabilidad de aplicaciones existentes.
Ahora están los paquetes de compatibilidad de Windows y WinForms y WPF están llegando a .NET Core.

Creo que los paquetes 2.1 disponibles para .NET Framework proporcionan una buena ruta de migración: migre a 2.1 en netfx y luego a .NET Core.

Esto es similar a AngularJS vs Angular: migre el código existente a los componentes (duro) en la última versión 1. *, luego muévase a la última versión de Angular. Es muy difícil pero factible.

Con nuevas y emocionantes características que se agregan tanto a CoreCLR como a mono (por ejemplo , métodos de interfaz predeterminados o solo Fast Spans) que nunca llegaría a .NET Framework, parece razonable dejar atrás .NET Framework en algún momento.
Eso no significa necesariamente "no admitir" .NET Framework, sino simplemente dejarlo como está.

Todavía hay algunos sitios que usan ASP clásico (no ASP.NET, pero lo que es realmente antiguo). Todavía funciona y se envía en Windows, simplemente no crearía nuevas aplicaciones con él.
Creo que en <10 años, esta puede ser la situación con .NET Framework.

Estoy de acuerdo con el soporte extendido solicitado para 2.1, pero me gustaría que el equipo monitoreara las descargas de paquetes 2.1 para tomar una decisión en 2-3 años si necesitarían brindar soporte (= solucionar problemas de seguridad importantes) por un tiempo poco más de tiempo.

@ John0King COM será compatible con .NET Core 3.0.

Además: tenemos aplicaciones heredadas que usan cosas como .NET Remoting.
Pero esos ya son un legado.

El mundo básicamente funciona con código heredado y seguirá haciéndolo. Es una decisión comercial de si transferir o no algo a algo "compatible" o incluso "nuevo", pero hasta entonces, como dice

Sí, vale la pena mencionar que si algo es "compatible" no es tan relevante: las aplicaciones antiguas en realidad no tienen que ser portadas a un nuevo marco solo porque están disponibles. Los servidores web son un caso un poco especial debido a las amenazas a la seguridad. Un largo período de soporte de parches de seguridad para LTS ayudaría a la gente.

@gulbanana Solo está agregando una barra más alta para portar aplicaciones de System.Web a ASP.NET Core, ya que necesita cambiar el marco web, el marco de la aplicación subyacente y luego actualizar o cambiar cualquier dependencia incompatible (que puede implicar la compra de nuevas licencias).

Si hiciera un análisis de costo / beneficio, no estoy seguro de que sea en beneficio de ASP.NET Core.

Esto es especialmente aplicable cuando desarrolla software sobre la base de un proyecto y, por supuesto, cada proyecto tiene un presupuesto lo suficientemente ajustado, por lo que si bien el mantenimiento regular es, por supuesto, posible, es difícil justificar el cambio de todo el marco sin un beneficio tangible aparente. .

Si hiciera un análisis de costo / beneficio, no estoy seguro de que sea en beneficio de ASP.NET Core.

Así que ... bueno ... ¿dejarlo? Si no necesita migrar a ASP.NET Core, no lo haga.
No intento sonar sarcástico ni nada por el estilo, pero si no hay necesidad comercial de mantener una aplicación con las "últimas novedades", no la transfiera. El beneficio es que .NET Framework / ASP.NET classic sigue siendo compatible y su aplicación se ejecutará como está.

Con frecuencia, la migración es innecesaria, estoy de acuerdo: ASP.NET a ASP.NET Core es un gran cambio, y parte de ese cambio es que Core se mueve más rápidamente (3.0 también tendrá cambios de ruptura de API, al igual que 2.0). Sin embargo, este tema de discusión trata sobre el cambio de netfx a corefx, y para la mayoría de las aplicaciones ASP.NET Core eso ya no es un gran cambio

Esto parece eliminar el punto intermedio "ASP.NET Core en .NET Framework" que haría las migraciones mucho más graduales y fáciles. Después de esto, migrando un ASP.NET MVC / WebAPI / etc. La aplicación a ASP.NET Core será un cambio muy grande, que cambiará tanto el marco web como los tiempos de ejecución subyacentes a la vez.

Para las aplicaciones de grandes empresas, espero que esto sea bastante doloroso. Mi equipo ha estado observando esto de cerca durante uno o dos años, pero:

• EntityFrameworkCore no hace todo lo que necesitamos, y solo ahora con .NET Core 3.0 EntityFramework llega a .NET Core. No creo que se haya comunicado claramente cuánto de eso y en qué plataformas se ejecutará, y probablemente necesitaré probar una compilación de vista previa para verlo.

• La historia de OData parece estar todavía en el aire en términos de aplicaciones a gran escala. Se requiere una cantidad _sustancial_ de (re) trabajo para pasar de OData 3 / System.Data.Services a OData 4 / WebAPI y en adelante. Esto es algo que no se ha resuelto desde hace varios años y, sinceramente, no estoy seguro de que alguna vez lo sea.

Además, ahora tendríamos que recortar todas las otras tecnologías no compatibles (AppDomains, Remoting, etc.) _primero_, en lugar de poder hacer ese trabajo en paralelo o en una etapa posterior.

Además, ahora tendríamos que eliminar todas las otras tecnologías no compatibles (AppDomains, Remoting, etc.) primero, en lugar de poder hacer ese trabajo en paralelo o en una etapa posterior.

¿Por qué no puede migrar a 2.1 primero?

@davidfowl Probablemente podríamos usar eso como intermediario, a menos que encontremos alguna característica nueva en 3.0 / 3.1 / etc. que necesitamos para migrar. Todavía no he hecho un análisis completo, hasta ahora hemos sido bloqueados principalmente en EF y OData.

¿Nueva característica en ASP.NET Core 2.1 que se necesita para migrar? Me refiero a ASP.NET Core 2.1 en .NET Framework.

Cuando surgió este problema hace un par de años, recuerdo que me quejé de que era demasiado difícil portar todo. Aquí hay una cita de un antiguo comentario de github que hice en ese entonces:

Imagine aplicaciones web que usan Active Directory o la automatización de Office COM, o que hacen miniaturas usando alguna biblioteca basada en System.Drawing, o comparten código con una aplicación WPF

Lo bueno es que a partir de .NET Core 3.0, todos esos escenarios son compatibles. Se ha trabajado mucho para hacerlo más fácil.

@davidfowl yo también.

Hipotéticamente, podría haber alguna característica que estamos usando en ASP.NET/MVC/WebAPI que no está implementada en 2.1 pero llega en una versión posterior. En ese caso, 2.1 no sería un trampolín viable.

Sin embargo, tendría que hacer un análisis más exhaustivo para ver si realmente hay algo crítico que necesitemos que no esté en 2.1.

@PinpointTownes

Lamentablemente, esto solo resalta una cosa: fallaste por completo en hacer de .NET Standard el vehículo principal del ecosistema .NET . No se mueve tan rápido como debería y no es más que un mínimo común denominador que siempre se actualiza en el último momento, cuando todas las plataformas incluyen (o están a punto de incluir) las nuevas API.

No se equivoca, pero ignora un poco los objetivos de .NET Standard. El objetivo del estándar nunca ha sido impulsar la innovación, sino impulsar la convergencia. Si lo enfocas desde ese ángulo, es por diseño algo que tiene que quedarse atrás porque tenemos que pensar qué conceptos pueden ser universales o incluso deberían ser universales. Si tiene curiosidad sobre cómo se ve esto, lo invito a echar un vistazo a los más de 35 PR que fusioné durante las últimas tres semanas después de la revisión por parte de todos los propietarios de la implementación.

Vemos .NET Core como la plataforma de vanguardia donde ocurre la innovación. Hemos creado varias capacidades que nos permiten lidiar con la rotación y los riesgos que conlleva, mucho mejor que lo que tenía .NET Framework. Sin embargo, no todas las capacidades que son importantes para el ecosistema .NET forman parte de la experiencia de .NET Core. Por ejemplo, la compilación anticipada es mucho más importante en Xamarin y Unity. Y cuando tomamos las características de .NET Core y las agregamos al estándar, debemos considerar sus entornos de tiempo de ejecución, sistemas operativos y restricciones de hardware.

Quizás sea solo yo, pero nunca he entendido por qué no se movió tan rápido como netcoreapp (que es el primero en obtener las nuevas API, por definición).

La realidad es que "moverse rápido y romper cosas" no es algo que toda nuestra audiencia aprecie. Ya es bastante malo si tenemos que eliminar las API en las versiones principales de .NET Core, pero es prácticamente imposible hacerlo con .NET Standard. Así que tenemos que movernos un poco más lentamente y solo incluir conceptos que creemos que son lo suficientemente maduros para sumarlos.

Haga lo que prometió: haga de .NET Framework un marco estable que evolucione más lento en lugar de un callejón sin salida para aquellos que confiaron en usted al migrar a ASP.NET Core.

Eso sigue suponiendo que .NET Framework eventualmente obtendrá todas las características que tiene .NET Core, pero con un retraso de tiempo. Aprendimos que eso simplemente no es realista. Podemos decidir no innovar drásticamente en .NET Core o aceptar la realidad de la ingeniería de que una buena parte de las nuevas funciones nunca volverán a .NET Framework. Creemos que servimos a nuestros clientes de la mejor manera para preservar la propuesta de valor central de .NET Framework (una plataforma de desarrollo madura y rica) al mismo tiempo que permitimos a los clientes explotar nuevas capacidades en .NET Core. En el futuro, esperaría que estemos más dispuestos a innovar en áreas que requieren cambios en el tiempo de ejecución, la biblioteca y el idioma, como lo hicimos por Span<T> . Si bien estas cosas son costosas, también nos permiten cambiar la forma en que las personas pueden escribir código. Un buen ejemplo de esto son las implementaciones predeterminadas de interfaces, la capacidad de crear código genérico que involucre aritmética, poder usar componentes intrínsecos de hardware, etc. Y esas características probablemente sean exactamente del tipo que no vamos a actualizar a .NET Framework debido al riesgo. .

Creo que tiene mucho sentido que nuestra pila web pueda explotar estas capacidades; y la única forma de hacerlo es eliminar la limitación para que ASP.NET Core se ejecute también en .NET Framework. Tenga en cuenta que la razón original por la que hicimos que ASP.NET Core se ejecutara en .NET Framework fue porque .NET Core simplemente no tenía suficientes API. En .NET Core 3.0 tendremos más de 120k de las API existentes . Eso es más de la mitad de todo el .NET Framework e incluso incluye WinForms y WPF. Sí, todavía faltan una gran cantidad de API, pero hemos logrado grandes avances en la cola larga. Si bien nunca tendremos una paridad del 100%, espero que cerremos esta brecha aún más en el futuro, según los datos del cliente.

@ yaakov-h Me sorprendería si ese fuera el caso. Cuando hagas el análisis, avísame.

No se equivoca, pero ignora un poco los objetivos de .NET Standard. El objetivo del estándar nunca ha sido impulsar la innovación, sino impulsar la convergencia.

Y se dirige exactamente hacia la dirección opuesta: abandona .NET Standard para ASP.NET Core porque no se mueve lo suficientemente rápido, lo que obliga a los paquetes NuGet dirigidos a ASP.NET Core a abandonarlo también. No me hagas pensar que es convergencia, no soy tan ignorante : rofl:

Si lo enfocas desde ese ángulo, es por diseño algo que tiene que quedarse atrás porque tenemos que pensar qué conceptos pueden ser universales o incluso deberían ser universales.

Es una elección, no un problema técnico: nada le impide determinar si una API determinada debe incluirse en una nueva versión de .NET Standard al revisarla para su inclusión en corefx / coreclr.

Si tiene curiosidad sobre cómo se ve esto, lo invito a echar un vistazo a los más de 35 PR que fusioné durante las últimas tres semanas después de la revisión por parte de todos los propietarios de la implementación.

No digo que sea una tarea fácil y demuestra mi punto: estás esperando demasiado para crear nuevas versiones netstandard y las raras veces que lo haces, es un proceso doloroso porque viene con toneladas de nuevas API al mismo tiempo.

La realidad es que "moverse rápido y romper cosas" no es algo que toda nuestra audiencia aprecie.

Sin embargo, así es exactamente como funciona cada iteración de ASP.NET Core: viene con cambios importantes (a veces masivos) que hacen que los paquetes escritos para una versión sean incompatibles con las siguientes. Sin embargo, no nos da muchas opciones: actualizar o permanecer en las versiones heredadas para siempre, con una política de soporte que no tiene nada que ver con lo que solíamos tener (no es solo ASP.NET/.NET, el ciclo de vida de Windows también es mucho más cortos estos días).

En el futuro, espero que estemos más dispuestos a innovar en áreas que requieren cambios en el tiempo de ejecución, la biblioteca y el idioma como lo hicimos para Span. Si bien estas cosas son costosas, también nos permiten cambiar la forma en que las personas pueden escribir código. Un buen ejemplo de esto son las implementaciones predeterminadas de interfaces, la capacidad de crear código genérico que involucre aritmética, poder usar componentes intrínsecos de hardware, etc. Y esas características probablemente sean exactamente del tipo que no vamos a actualizar a .NET Framework debido al riesgo. .

¿Qué le impide introducir una nueva versión de .NET Framework en paralelo (digamos .NET Framework 5) que incluye esos cambios "riesgosos"? Nuevamente, no es un problema técnico.

¿Alguna posibilidad de promover Microsoft.AspNetCore.Razor.Language y Microsoft.AspNetCore.Razor fuera de aspnet o mantenerlo en netstandard wave? Aunque razor es solo para html, hay varias bibliotecas que lo usan para plantillas de correo y sería genial si pudiéramos seguir usándolo como está.

Este movimiento muestra la falta de soporte para netstandard en la hoja de ruta de .NET, al contrario de lo que se dijo antes. Si una de las principales bibliotecas nuevas abandona netstandard, no es un buen augurio para su adopción.

¿Es este un movimiento que ahora los desarrolladores de .NET deberían anticipar para todas las demás bibliotecas nuevas desarrolladas por Microsoft al aire libre? ¿Puede la comunidad obtener una declaración más oficial sobre el futuro de netstandard y su adopción?

@terrajobst Entiendo totalmente que señala con respecto a no agregar a .netstandard esas API que no parecen estar listas para abarcar todas las plataformas (y probablemente nunca lo estarán). Sin embargo, eso no impidió que usted (MS) presentara netstandard2.0 cuando, por ejemplo, UWP no estaba listo para admitirlo. Según tengo entendido, tomó un esfuerzo notable agregar ese soporte algún tiempo después, pero lo hizo. ¿Fue de alguna manera una historia diferente?

Y se dirige exactamente hacia la dirección opuesta: abandona .NET Standard para ASP.NET Core porque no se mueve lo suficientemente rápido.

ASP.NET Core solo tiene sentido en .NET Framework y .NET Core, pero todos deben implementar .NET Standard. Simplemente no tiene sentido, por ejemplo, hacer que Xamarin / Unity proporcione API que son utilizadas predominantemente por una pila web de servidor.

Es una elección, no un problema técnico: nada le impide determinar si una API determinada debe incluirse en una nueva versión de .NET Standard al revisarla para su inclusión en corefx / coreclr.

Eso es lo que hicimos en los días de .NET Core v1. Hemos desacoplado el estándar de .NET Core con v2. Entonces, sí, es una elección, pero no fue arbitraria. El objetivo era poder moverse más rápido con .NET Core. Simplemente lleva más tiempo considerar cómo funcionan las características en el contexto de otros N tiempos de ejecución que uno solo.

es un proceso doloroso porque viene con toneladas de API nuevas al mismo tiempo.

No, es un proceso doloroso porque tiene que revisar el diseño con varios implementadores y varios tiempos de ejecución diferentes. Sin embargo, hacerlo después de un hecho, agregado y empaquetado es mucho más barato que tener que coordinarlo sobre la marcha. El repositorio de CoreFx es un repositorio de alto volumen. Es mucho más fácil para Xamarin y Unity revisar las características agrupadas que beber de la manguera de incendios y suscribirse a todas las discusiones de API en CoreFx.

Sin embargo, así es exactamente como funciona cada iteración de ASP.NET Core: viene con cambios importantes (a veces masivos) que hacen que los paquetes escritos para una versión sean incompatibles con las siguientes.

¿Y como no le gusta esto, quiere imponerlo a todos haciendo que .NET Standard coincida con .NET Core? Lo siento, pero este argumento no tiene sentido para mí.

¿Qué le impide introducir una nueva versión de .NET Framework en paralelo (digamos .NET Framework 5) que incluye esos cambios "riesgosos"? Nuevamente, no es un problema técnico.

¿Qué te hace pensar que no es un problema técnico? El envío de versiones en paralelo de .NET Framework no es una solución viable. En primer lugar, es bastante caro debido al hecho de que es un componente del sistema operativo y, por lo tanto, necesita servicio. No tiene idea de lo compleja que es nuestra estrategia de ramificación / mantenimiento / parcheo para .NET Framework 3.5 y 4.x. Agregar un tercero es casi poco práctico. En segundo lugar, simplemente hacer eso también tiene riesgos, ya que necesitamos realizar cambios en la activación para seleccionar el tiempo de ejecución correcto para cosas como los componentes administrados activados por COM. Y eso plantea la pregunta de si apoyamos o no en proceso de lado a lado también y con cuántas combinaciones. No es una tarea sencilla y tampoco está exenta de riesgos.

No me hagas pensar que es convergencia

@PinpointTownes Es convergencia ... en .NET Core 😉

Simplemente no tiene sentido, por ejemplo, hacer que Xamarin / Unity proporcione API que son utilizadas predominantemente por una pila web de servidor.

Hay personas a las que les gustaría usar ASP.NET Core no solo en .NET Core, sino también en UWP, entonces, ¿por qué no también en Xamarin? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

Hay una diferencia entre algo que no tiene sentido, para ti, y algo que no quieres apoyar.

El repositorio de CoreFx es un repositorio de alto volumen. Es mucho más fácil para Xamarin y Unity revisar las características agrupadas que beber de la manguera de incendios y suscribirse a todas las discusiones de API en CoreFx.

¿Sugerí un enfoque tan extremo? Estoy seguro de que puede encontrar un compromiso, como discutir las nuevas API estándar poco después (es decir, unas semanas) después de que se introduzcan en .NET Core, una vez que el polvo se haya asentado un poco.

¿Y como no le gusta esto, quiere imponerlo a todos haciendo que .NET Standard coincida con .NET Core? Lo siento, pero este argumento no tiene sentido para mí.

Usted asume que no me gusta eso, pero se equivoca: me gustan las cosas que se mueven rápidamente, incluso si, como mantenedor de 60 paquetes NuGet, a veces es bastante doloroso. Lo que no me gusta es obligar a todos a moverse a la misma velocidad, abandonar a la gente en medio de la carretera porque no pueden seguir el ritmo.

No estoy seguro de cómo hacer que .NET Standard se mueva tan rápido como .NET Core puede verse como un castigo: nada te obliga a apuntar al último netstandard TFM. Solo lo hará si necesita el último conjunto de API. Si no lo necesita, elija una versión anterior para que sus paquetes puedan ser utilizados por un conjunto más amplio de plataformas.

Desde la perspectiva del desarrollador promedio, es una ganancia total: puede escribir paquetes utilizando las últimas API brillantes que pueden ser utilizadas por el tiempo de ejecución de .NET Core más nuevo. Cuando las otras plataformas se pongan al día, sus paquetes también se pueden usar allí: no necesita ir con paquetes de orientación múltiple o volver a publicar.

En primer lugar, es bastante caro debido al hecho de que es un componente del sistema operativo y, por lo tanto, necesita servicio. No tiene idea de lo compleja que es nuestra estrategia de ramificación / mantenimiento / parcheo para .NET Framework 3.5 y 4.x. Agregar un tercero es casi poco práctico.

Ciertamente, puedo imaginar que no es ideal para usted, al igual que eliminar la compatibilidad con .NET Framework para ASP.NET Core 3.0 no será ideal para las personas que no pueden pasar a .NET Core. Pero, ¿estoy totalmente equivocado al pensar que usted, Microsoft, tiene muchos más recursos para lidiar con eso de lo que la empresa promedio tiene para cambiar a .NET Core? (Ni siquiera estoy hablando de dependencias externas que no posee y controla).

En segundo lugar, simplemente hacer eso también tiene riesgos, ya que necesitamos realizar cambios en la activación para seleccionar el tiempo de ejecución correcto para cosas como los componentes administrados activados por COM. Y eso plantea la pregunta de si apoyamos o no en proceso de lado a lado también y con cuántas combinaciones. No es una tarea sencilla y tampoco está exenta de riesgos.

Claro, no es fácil. Y es arriesgado. Pero eso es lo que indican las versiones principales: existe el riesgo de que las cosas se rompan. Ahora, entre verse obligado a permanecer para siempre en ASP.NET Core 2.2 y correr el riesgo de pasar a .NET Framework 5 para usar ASP.NET Core 3.0, ¿qué cree que optaría la gente?

Pero, ¿estoy totalmente equivocado al pensar que usted, Microsoft, tiene muchos más recursos para lidiar con eso de lo que la empresa promedio tiene para cambiar a .NET Core?

En mi experiencia, la gente sobreestima constantemente cuántos recursos tenemos y cuánto trabajo tenemos que hacer para apoyar el status quo por sí solos.

Pero en este caso ni siquiera se trata de recursos. Podríamos tener .NET Framework de código abierto y luego todos los RP irían directamente a .NET Framework. Tiene que ver con la complejidad de la maquinaria y los riesgos de compatibilidad. Es un marco centralizado e incluso las versiones en paralelo comparten un conjunto común de recursos, como la activación. Se nos ha demostrado una y otra vez que estamos equivocados, que simplemente podemos asignar personas inteligentes para que salga correctamente.

Ahora, entre verse obligado a permanecer para siempre en ASP.NET Core 2.2 y correr el riesgo de pasar a .NET Framework 5 para usar ASP.NET Core 3.0, ¿qué cree que optaría la gente?

En mi opinión, es mucho más práctico ampliar los límites de las API compatibles en .NET Core para hacer posible que más personas migren sin problemas a .NET Core que intentar exportar las características de .NET Core a .NET Framework. Todo lo que podemos hacer allí es causar dolor. Tenga en cuenta que las versiones en paralelo vienen con otros desafíos, como lograr que TI le permita instalarlo, encadenarlo a instaladores o esperar a que su proveedor de servicios de alojamiento le proporcione máquinas, etc.

¿Se aplica esto a todas las partes de ASP.NET Core, o algunas partes útiles y generalmente reutilizables (como Microsoft.AspNetCore.Http.Extensions ) permanecerán en .NET Standard?

@andriysavin

@terrajobst Entiendo totalmente que señala con respecto a no agregar a .netstandard esas API que no parecen estar listas para abarcar todas las plataformas (y probablemente nunca lo estarán). Sin embargo, eso no impidió que usted (MS) presentara netstandard2.0 cuando, por ejemplo, UWP no estaba listo para admitirlo. Según tengo entendido, tomó un esfuerzo notable agregar ese soporte algún tiempo después, pero lo hizo. ¿Fue de alguna manera una historia diferente?

Si. .NET Standard 2.0 no tenía API nuevas netas. Se definió como la intersección de .NET Framework y Xamarin. Cualquiera que sea el delta, simplemente lo necesitamos para llegar a una barra de compatibilidad razonable con el código existente. El único trabajo fue en UWP y .NET Core. Y esas bases de código fueron diseñadas originalmente para ser un reinicio moderno de .NET, que aprendimos que no era viable. Dado que las API / tecnologías que se agregarán estaban en gran parte maduras y admitidas en entornos restringidos (Xamarin iOS), la complejidad era baja: solo una tonelada de trabajo de migración.

Pero ahora estamos hablando de agregar nuevas capacidades y conceptos y esa es una bestia diferente para conducir.

En mi experiencia, la gente sobreestima constantemente cuántos recursos tenemos y cuánto trabajo tenemos que hacer para apoyar el status quo por sí solos.

En mi experiencia, los Microsoft sobreestiman constantemente cuántos recursos tenemos y cuánto trabajo tenemos que hacer para mantener el statu quo por sí solos. Su argumento realmente funciona en ambas direcciones: sweat_smile:

En mi opinión, es mucho más práctico ampliar los límites de las API compatibles en .NET Core para hacer posible que más personas migren sin problemas a .NET Core que intentar exportar las características de .NET Core a .NET Framework.

Seamos claros: estoy a favor de eso , pero no funcionará hasta que .NET Core se ponga al día e implemente la mayoría / todas las características que tenía .NET Framework. Hasta que lo haga, todavía verá personas bloqueadas por una función faltante o una API faltante. Hay tantas cosas que faltan que no es razonable pensar que las grandes aplicaciones monolíticas heredadas podrán pasar a .NET Core sin problemas.

Definitivamente entiendo tus preocupaciones. Pero, en última instancia, lo que le facilita la vida tiene la posibilidad de hacer la nuestra más dolorosa: no admitir .NET Framework va a ser un PITA para nosotros.

Definitivamente entiendo tus preocupaciones. Pero, en última instancia, lo que le facilita la vida tiene la posibilidad de hacer la nuestra más dolorosa: no admitir .NET Framework va a ser un PITA para nosotros.

Esa parte la entiendo. Pero la alternativa no serían más funciones en .NET Framework, sino simplemente un ASP.NET Core menos potente.

Hemos intentado co-evolucionar .NET Framework y .NET Core en los últimos años. No es como si estuviéramos tratando de evitar el trabajo. Personalmente, pasé un millón de horas hablando con nuestros ingenieros de tiempo de ejecución tratando de arreglar, por ejemplo, la pesadilla de redirección de enlaces. O el soporte roto de .NET Standard 2.0 en 4.6.1. Nosotros tratamos. No es una cuestión de fuerza de voluntad, es una cuestión de practicidad.

no va a funcionar hasta que .NET Core se ponga al día e implemente la mayoría / todas las características que tenía .NET Framework

En mi experiencia, la disponibilidad de algunas API no es aún tan relevante. Lo que importa mucho en los entornos corporativos es la complejidad del soporte y la implementación. Y "admitido, enviado y actualizado automáticamente con el sistema operativo" es mucho más atractivo que el soporte de 3 años que obtenemos de las versiones de .NET Core LTS y la implementación meticulosa que todavía implica. Y seamos honestos aquí: todavía no hay una herramienta estable para .NET Core y ASP.NET Core. Puedo decir con confianza que seguirá siendo el status quo en un año. Tuvimos cambios con cada lanzamiento y quién sabe si la nueva referencia de marco con 3.0 será la solución correcta. Así que definitivamente es un gran problema cuando se trata de empresas en las que no se puede simplemente actualizar las cosas o hacerlo de la manera que debería hacerse; por lo general, quieren que se haga de la forma en que lo han hecho durante los últimos 5 años o más. Están estropeados por el marco y cualquier cosa que no sea tan cómoda para ellos es casi espectacular.

Pero la alternativa no serían más funciones en .NET Framework, sino simplemente un ASP.NET Core menos potente.

Eso es más o menos lo que sugerí el año pasado: paquetes ASP.NET Core que aún funcionan en .NET Framework (por ejemplo, al apuntar a netstandard20 y netcoreapp30 ) pero ofrecen un conjunto de funciones más limitado, con mucho menos actuación interesante. A veces, lo que la gente quiere son cosas que funcionen. No las cosas nuevas y brillantes. No las cosas súper rápidas.

Hemos intentado co-evolucionar .NET Framework y .NET Core en los últimos años. No es como si estuviéramos tratando de evitar el trabajo. Personalmente, pasé un millón de horas hablando con nuestros ingenieros de tiempo de ejecución tratando de arreglar, por ejemplo, la pesadilla de redirección de enlaces. O el soporte roto de .NET Standard 2.0 en 4.6.1. Nosotros tratamos. No es una cuestión de fuerza de voluntad, es una cuestión de practicidad.

Claramente no estamos de acuerdo en todo, pero no hace falta decir que estoy muy impresionado por lo que hicieron (sí, incluso si cosas como el hipo de HttpClient fueron bastante dolorosas de manejar).

Lamento mucho ser ese tipo: sweat_smile:

Hasta ahora, en el frente de ASP.NET Core, he visto a Razor surgir como algo concreto que a la gente le gustaría estar disponible fuera de ASP.NET Core en general. Creo que es razonable y deberíamos identificar más áreas como esa (será una discusión más útil). ASP.NET Core 2.1 y 2.2 seguirán admitiendo .NET Framework, pero no creo que sea razonable admitir .NET Framework para siempre.

@terrajobst

Un buen ejemplo de esto son las implementaciones predeterminadas de interfaces, ... Y esas características probablemente sean exactamente del tipo que no vamos a trasladar a .NET Framework debido al riesgo.

Y con esa declaración murió DIM. Todo su punto es la evolución del legado. Si no se aplica al legado, y ni siquiera se puede aplicar a las bibliotecas que intentan unir el legado y lo nuevo, entonces no ayuda a nadie.

Hasta ahora, en el frente de ASP.NET Core, he visto a Razor surgir como algo concreto que a la gente le gustaría estar disponible fuera de ASP.NET Core en general.

Puede agregar el paquete Microsoft.Owin.Security.Interop backcompat ', ASP.NET Core Data Protection y las dependencias subyacentes a la lista.

Eso es más o menos lo que sugerí el año pasado: paquetes ASP.NET Core que aún funcionan en .NET Framework (por ejemplo, al apuntar a netstandard20 y netcoreapp30 ) pero ofrecen un conjunto de funciones más limitado, con mucho menos actuación interesante. A veces, lo que la gente quiere son cosas que funcionen. No las cosas nuevas y brillantes. No las cosas súper rápidas.

También hemos hablado de esto. El desafío es que no podemos encapsularlo por completo, ya que algunas de las API y capacidades de la plataforma subyacente tendrán que filtrarse en la API pública. Eso significa que las bibliotecas que se integran en el middleware de ASP.NET Core también tendrían que proporcionar múltiples implementaciones. Pero lo que es peor, es posible que ni siquiera sea posible sin crear un cisma, ya que el tipo de intercambio público podría ser solo de núcleo, lo que crearía dos versiones de ASP.NET Core que ya no son compatibles.

@HaloCuatro

Y con esa declaración murió DIM. Todo el punto de evolución del legado. Si no se aplica al legado, y ni siquiera se puede aplicar a las bibliotecas que intentan unir el legado y lo nuevo, entonces no ayuda a nadie.

Creo que está combinando código heredado con instalaciones existentes . Incluso si tuviéramos que portar DIM a .NET Framework, aún tendría que actualizar a una versión más nueva para poder usar la función. Si bien es probable que sea una característica exclusiva de .NET Core, todavía nos permite evolucionar .NET Core sin dejar de poder consumir código que se compiló con .NET Framework.

@terrajobst Sigues mencionando Unity. ¿Tienen su propia implementación CLR? Tenía la impresión de que estaban usando Mono.

Unity tiene varias implementaciones de .NET, incluida su propia versión AOT no mono, IL2CPP. Su biblioteca de clases y las API compatibles también difieren del Mono estándar.

@terrajobst

Creo que está combinando código heredado con instalaciones existentes.

No hay mucha diferencia cuando se trata de aplicaciones "heredadas" que aún se mantienen y desarrollan activamente. Existe una gran diferencia entre actualizar el marco y tener que migrar a .NET Core.

Si bien es probable que sea una característica exclusiva de .NET Core, todavía nos permite evolucionar .NET Core sin dejar de poder consumir código que se compiló con .NET Framework.

¿A que final? Ninguna de esas API "evolucionadas" en .NET Core será aplicable a .NET Standard. Y ningún escritor de bibliotecas lo tocará dado que creará divergencias incompatibles en sus propias API.

Estoy de acuerdo con @HaloFour. Las únicas personas que podrán hacer uso de DIM son los autores de bibliotecas que solo se dirigen a .NET Core ... así que básicamente solo corefx y aspnetcore. No puedo imaginar que nadie más se acerque.

Las únicas personas que podrán hacer uso de DIM son los autores de bibliotecas que solo se dirigen a .NET Core ... así que básicamente solo corefx y aspnetcore.

Bueno, otra forma de redacción sería que la única plataforma en la que no puede usarla será .NET Framework, mientras que sí puede hacerlo en .NET Core, Xamarin, Mono y Unity.

No puedo imaginar que nadie más se acerque.

Me imagino que características como esta tendrán un patrón de adopción de palo de hockey en las bibliotecas, lo cual tiene sentido. Al final, los autores de la biblioteca siempre considerarán el alcance frente al conjunto de características. En el caso de las aplicaciones, es más fácil decidir, porque conoce (y a menudo controla) su entorno de destino.

@ yaakov-h

¿Se aplica esto a todas las partes de ASP.NET Core ...

La lista tentativa de lo que está sucediendo con qué paquete está aquí: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst Pensé que las implementaciones de interfaz predeterminadas serían una característica del lenguaje de C #. Al decir que .NET Framework no lo admitirá, prácticamente está diciendo que .Net Framework se quedará bloqueado para siempre con la versión 7.3 de C # o, como máximo, la siguiente. Esa divergencia no es algo que a nadie le gustaría que ocurriera en el ecosistema.

Ejecutamos algunas cargas de trabajo de .NET Core, pero también ejecutamos proyectos que son .NET FX de varios años.

Actualizar a .NET Core (incluso en .NET Framework para empezar) de forma segura es una tarea muy grande.

¿Hay planes para que Microsoft lance algunas herramientas para ayudar a "actualizar" proyectos de al menos ASP.NET en .NET FX a ASP.NET Core a .NET FX?

Hay artículos de MSDN sobre la creación de nuevos proyectos VS, la importación de vistas y el reajuste de proyectos, pero hay tantas cosas heredadas (asax global, enrutamiento, ...) que desearía que hubiera un lugar central que documentara la forma antigua frente a la nueva de ayudar portando todo.

¿Qué le impide introducir una nueva versión de .NET Framework en paralelo (digamos .NET Framework 5) que incluye esos cambios "riesgosos"?

En ese momento, ¿hay alguna ventaja en que no sea .NET Core 3.0? Ya está uno al lado del otro y tiene los cambios "arriesgados". ¿El siguiente conjunto de características para .NET Core necesitaría un .NET Framework 6, etc.?

Con las apis ya en .NET Core 2.0 y el nuevo conjunto de características que viene a .NET Core 3.0, ¿no cumple .NET Core con ".NET Framework 5" con Framework 4.x siendo la versión LTS extremadamente larga?

En una suposición; En este punto, sería un desafío de ingeniería más pequeño cubrir cualquier brecha específica identificada que .NET Core 3.0 tiene de .NET Framework 4.x en lugar de cambiar .NET Framework para que se comporte como .NET Core.

Sugerencia práctica: ¿Existe alguna posibilidad de que ASP.NET Core 2.2 se convierta en LTS con una duración de soporte _extendida_ superior a los 3 años habituales?

Estoy seguro de que eso satisfaría a aquellos que tienen que seguir con el marco completo por ahora, mientras que también les da (1) tiempo suficiente para migrar a .NET Core y (2) motivación suficiente para migrar de ASP.NET MVC a ASP. .NET Core (cuando no pueden moverse a .NET Core _yet_).

Todavía no creo que esto esté claro, ¿ASP.NET Core en .NET Framework sigue .NET Core 2.1 LTS o sigue el ciclo de soporte de .NET Framework v4.6.1 + (es decir, ya que se ejecuta en .NET FX) donde es compatible en el futuro previsible?

@mythz ASP.NET Core está cubierto por el ciclo de vida de soporte de .NET Core , independientemente de la plataforma en la que lo ejecute.

Creo que el mejor paso aquí sería mantener el estándar .net actualizado para al menos 3.0, 4.0 y 5.0 y comunicar que en algún momento el marco .net se migrará completamente al núcleo .net.
todo lo demás está a medio hornear.

¿Tienen clientes que ya paguen por el soporte de LTS hoy? (Solo una pregunta de sondeo). ¿Cuánto tiempo es suficiente?

@terrajobst Parece que el problema real es que netstandard es monolítico. Parece que no necesitamos netstandard sino conjuntos de API versionados. Esos también serán el TFM, por ejemplo, base2.0 + span serían dos conjuntos de API.

Luego, podría evolucionar el estándar en función de los conjuntos de API y posiblemente solo implementar algunos conjuntos de API en el marco completo. (Esto también facilitaría que otras plataformas implementen netstandard, ya que algunos conjuntos de API pueden quedar fuera).

Con los conjuntos de API en su lugar, se crearía una compilación separada de ASP.NET Core para los objetivos menos compatibles, como el marco completo.

@Sebazzz ese es un tema extremadamente extraño. ¿No podemos descarrilar este hilo con intentos de rediseñar netstandard? Puede presentar un problema en dotnet / standard para eso, pero le diré que esta idea ya fue propuesta y rechazada.

@davidfowl No creo que sea "extraño" o "descarrilamiento" en absoluto. Parece exactamente lo que necesitamos, aunque un poco menos detallado que la forma en que lo propuso. Si el problema con todo esto es que terminaríamos teniendo que calzar todas estas cosas del servidor web en implementaciones como Xamarin y Unity que no se preocupan por los servidores web, entonces IMO crearía un grupo de API ".NET Web Server Standard" separado sería la solución ideal.

@Sebazzz @masonwheeler

@terrajobst Parece que el problema real es que netstandard es monolítico. Parece que no necesitamos netstandard sino conjuntos de API versionados. Esos también serán el TFM, por ejemplo, base2.0 + span serían dos conjuntos de API.

Probamos esto en varios sabores (perfiles, PCL, contratos sueltos y luego conjuntos de contratos versionados que se convirtieron en .NET Standard 1.x). Es demasiado difícil utilizar herramientas y comprender las reglas de compatibilidad a lo largo del tiempo (cuando las versiones de las plataformas y los conjuntos de API evolucionan). El .NET Standard tal como es hoy es lo más cercano que hemos estado a un modelo viable. Si bien no es perfecto, al menos es algo que puedo explicar en minutos y que no explote la cabeza de la gente.

Me complace discutir .NET Standard con más detalle, pero estoy de acuerdo con @davidfowl en que esto no pertenece aquí. Si lo desea, presente un problema en https://github.com/dotnet/standard.

Editar He marcado nuestros comentarios de .NET Standard como fuera de tema.

@ Shayan-To

@terrajobst Pensé que las implementaciones de interfaz predeterminadas serían una característica del lenguaje de C #. Al decir que .NET Framework no lo admitirá, prácticamente está diciendo que .Net Framework se quedará bloqueado para siempre con la versión 7.3 de C # o, como máximo, la siguiente. Esa divergencia no es algo que a nadie le gustaría que ocurriera en el ecosistema.

Es una función que requiere cambios de idioma y cambios de tiempo de ejecución. Es similar a los genéricos, ya que cambia las reglas del sistema de tipos. En términos generales, C # no sabe para qué marco está compilando (solo se le pasa un conjunto de ensamblados de referencia que describen las API que ofrece el marco). Se admitirá cualquier característica de C # que no requiera cambios en la API (por ejemplo, el operador de fusión nula ?. o _ para descartar expresiones). En eso es idéntico a cómo siempre ha funcionado el compilador cuando usó la última versión del compilador y el lenguaje y apuntó a una versión anterior de .NET Framework que carece de las API correspondientes. Por ejemplo, async / await no funcionará si su objetivo es .NET Framework 3.5 o 4.0; debe estar en 4.5 o superior para usar Task .

Hombre, lo siento por ustedes. Pasar de lleno a .net core es, en mi opinión, lo correcto a hacer a largo plazo y prefiero el mayor ritmo de innovación que proporcionará.

Sin embargo, la gente estará molesta por esto. Una parte considerable es la comunicación. Cuando se anunció el LTS 2.1 de 3 años, las personas en fullfx esperaban poder pasar a 3.0 y aún ejecutar fullfx, habrán vendido el núcleo de asp.net a sus empleadores y clientes poniendo su propia reputación en juego, y ahora sentirán como si hubieran quitado la alfombra debajo de ellos. Lo que vendieron como solución a largo plazo, el futuro de asp.net, ahora (perceptualmente) tiene un límite de 3 años de soporte.

No importa que sea más fácil migrar ahora, cambiar de plataforma siempre será un riesgo, y eso será un riesgo y un esfuerzo de desarrollo que estas personas no esperaban, planeaban o presupuestaban.

La mayoría de los desarrolladores _quieren_ pasar a .net core 3, pero además de tener potencialmente dependencias que no pueden cambiar (o implicar un cambio de riesgo) ahora tienen que lanzar una migración _ de nuevo_ y prometer que _ esta vez_ será una inversión a largo plazo. . Puede ser difícil de vender, pero se sentirán obligados a hacerlo debido al ciclo de soporte de 3 años.

Nuevamente, estoy a favor de eliminar fullfx, pero realmente creo que debería considerar extender el LTS para la última versión que lo admita en una cantidad considerable. También comunicando muy claramente, como en blogs, conferencias / sesiones, etc., qué partes seguirán siendo netstandard y cómo las personas que todavía están en 2.1 / full framework todavía pueden aprovecharlas.

De lo contrario, corre un gran riesgo de que la narrativa se convierta en "Microsoft está dejando atrás a sus desarrolladores dedicados una vez más". No digo que sea justo , solo trata de advertirle sobre lo que podría suceder.

¿Qué es un tiempo razonable para el LTS?

¿6 años quizás? Sin embargo, creo que la mensajería va a jugar un papel muy importante en la recepción ... Al final, algunas personas se molestarán sin importar qué: /

@davidfowl @ aL3891

Como referencia, el "Soporte Premier" de Java LTS es de 5 años con el "Soporte extendido" (pagado) de tres años adicionales. Java 11, que es una versión LTS y se lanzó el mes pasado, será compatible hasta septiembre de 2023 y septiembre de 2026 respectivamente.

Estamos investigando una oferta de LTS de "soporte extendido" y brindaremos más detalles cuando los tengamos. Esto podría ofrecer a los clientes que necesitan un ASP.NET Core compatible en la versión de .NET Framework (2.1.x) una opción más larga que el período de soporte actual de LTS.

También para su información, charlé un poco sobre los anuncios de hoy en el Standup de la comunidad ASP.NET: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

Apunte al estándar .net, por favor. asp.net core puede apuntar a .netstandard2.1 o 3.0 y dejar que mono y .netframework se pongan al día más tarde, pero si asp.net core apunta a netcoreapp , entonces cualquier biblioteca intenta acceder a un tipo de esas bibliotecas aspnetcore debe ser una biblioteca .netcoreapp .

y .net core siempre se lanzará más rápido que .net framework y mono ,
mono y .netframework eventualmente consumirán .netcoreapp ensamblados si microsoft start apunta a más frameworks / bibliotecas a netcoreapp (eso causará más biblioteca en nuget target .netcoreapp también)

si es así, .netstandard se convertirá en .netcoreapp 😂

@ John0King , proporcione ejemplos de los tipos que necesita fuera de ASP.NET Core.

1. Razor como mencionó @poke
2. Interfaces / Atributos de filtro MVC (Tengo una biblioteca de clases de ayuda que contiene algunos ActionFilters y TagHelpers y un método estático / de extensión común para string, int, long ect. Yo uso PrivateAssert="All" para hacer referencia a paquetes MVC, así que cuando uso use esto biblioteca en algún otro lugar, ese proyecto no tiene que hacer referencia a ensamblajes MVC, supongo que tengo que separar la biblioteca en dos, uno es .netstandard y otro .netcoreapp )

otra pregunta es: ¿será un problema para qué tipo de biblioteca de clases debo crear? ( .netstandard contra .netcoreapp ). Hoy es bastante simple en asp.net core 2.1. elija .netstandard para la biblioteca de clases, elija .netcoreapp o net461 para el proyecto web.

mono y .netframework eventualmente consumirán ensamblados .netcoreapp si microsoft start tiene como destino más marcos / bibliotecas para netcoreapp (eso también causará más biblioteca en nuget target .netcoreapp)

Esto sucederá si la gente no se esfuerza más por separar lo que debería llegar a una biblioteca .netstandard y lo que debe llegar a una biblioteca .netcoreapp

Interfaces / atributos de filtro MVC (tengo una biblioteca de clases auxiliares que contiene algunos ActionFilters y TagHelpers y un método estático / de extensión común para string, int, long ect. Utilizo PrivateAssert = "All" para hacer referencia a paquetes MVC, así que cuando uso use esta biblioteca en algún otro lugar, ese proyecto no tiene que hacer referencia a ensamblajes MVC, supongo que tengo que separar la biblioteca en dos, uno es .netstandard y otro .netcoreapp)

¿Puedes elaborar? Esto no tiene sentido. MVC es un marco ASP.NET Core y no se puede usar de forma independiente.

@davidfowl esta biblioteca es una biblioteca de clases auxiliares, puedo usar esos filtros cuando trabajo en un proyecto MVC principal de asp.net y solo uso sus métodos de extensión en una aplicación de consola.

@davidfowl esta biblioteca es una biblioteca de clases auxiliares, puedo usar esos filtros cuando trabajo en un proyecto MVC principal de asp.net y solo uso sus métodos de extensión en una aplicación de consola.

Todavía no entiendo ¿Estás hablando de una biblioteca que tiene elementos MVC y otros elementos aleatorios?

Desafortunadamente, ese tipo de cosas es común en el software empresarial: 'bibliotecas auxiliares' que tienen, como, las utilidades de la compañía para MVC + las utilidades de la compañía para WPF + las utilidades de la compañía para telerik ...
Tenía más sentido cuando '.NET' era una única plataforma unificada.

@davidfowl sí. Hay alguna clase / método en la biblioteca auxiliar que puede usar en todas partes. y cuando hace referencia a esta biblioteca en un proyecto mvc, puede usar su clase / método relacionado con mvc.

Oh, bueno, esto solo obliga a tus bibliotecas a tener mejores capas 😉

Desafortunadamente, esto significa que cualquiera que realice implementaciones en las instalaciones aún no puede respaldar su software por más de 3 años. Tan pronto como lanza una aplicación dirigida a .netcore 3.0, por ejemplo, sus clientes tienen 3 años y luego se ven obligados a actualizar. Algunas industrias estarán bien, otras ciertamente no.

Ese es el mayor problema con esto, y me imagino que hace que .net core sea completamente inútil para mucha gente. De hecho, estoy de acuerdo en que al final esta es la dirección correcta a seguir, pero estoy seguro de que esto evitará que muchos lugares vayan al núcleo de .net.

Realmente me gustaría una respuesta del equipo .net sobre esto.

La cuestión es que ASP.NET Core es un marco web. ¿En qué industria es seguro ejecutar un sitio web durante> tres años sin modificaciones? Si no se trata de vulnerabilidades de seguridad, serán los navegadores que desaprueben esa cosa en la que confió, o TLS 1.4, o usuarios que exigen que el sitio funcione en su nuevo watchlet.

Durante ese lapso de tiempo que debe ser capaz de salirse con sólo pequeños ajustes y cambios de menor importancia, pero la dependencia de planificación para no actualizar una aplicación web en absoluto durante años y años es imprudente.

Creo que esto sería más aceptable para la comunidad si solo aumentara el período LTS para ASP.NET Core 2.1 a 5-7 años.

Según nuestra experiencia, el desarrollo empresarial corporativo avanza a un ritmo glacial en comparación con el desarrollo web "moderno" y, sin embargo, aún quieren asegurarse de no realizar nuevas inversiones en plataformas significativamente más antiguas. A menudo, estas aplicaciones tardan más de un año en ejecutarse, y mucho menos en poder realizar una actualización importante en 3 años. Estas aplicaciones web empresariales (generalmente solo para uso interno) a menudo son compatibles durante 7 a 10 años, aunque creo que no es razonable que LTS para ASP.NET Core 2.1 sea de 10 años. 5 años se siente como una mejor solución que 3, siendo 7 años una cifra que seguramente haría que casi todo el mundo se sintiera cómodo.

Y esto solo es necesario porque ASP.NET Core 3.0 requiere un cambio importante que elimina la compatibilidad con .NET Framework. Las versiones futuras de LTS no deben ajustarse a este estándar, asumiendo que los cambios importantes no son tan grandes.

No estoy seguro de cómo hacer que .NET Standard se mueva tan rápido como .NET Core puede verse como un castigo: nada te obliga a apuntar al último netstandard TFM. Solo lo hará si necesita el último conjunto de API. Si no lo necesita, elija una versión anterior para que sus paquetes puedan ser utilizados por un conjunto más amplio de plataformas.

¿Qué pasa si la plataforma nunca se pone al día? Luego, tendrá una biblioteca dirigida a netstandard2.3 que necesita la característica A que solo está disponible en .NET Core y Xamarin, pero imposible para .NET Framework.

Luego sale netstandard2.4 , con algunas Apis nuevas y algunas de estas API se pueden migrar a .NET Framework. ¿Ahora que?

¿Cómo apuntar a una biblioteca que necesita una característica de netstandad2.4 que se ejecuta en .NET Framework, pero netstandard2.4 no puede apuntar a .NET Framework, porque no puede implementar netstandard2.2 ?

Entonces tendrías que realizar una compilación cruzada en tres plataformas:
netstandard2.2 para las plataformas antiguas y net4x para el estándar neto solo para admitir la función que se agregó en netstandad2.4 y que net4x can also implement but not support because of APIs that went into netstandard2.3`.

¿Cómo haría eso más fácil para los autores de paquetes escribir y enviar sus paquetes nugget?

Todo solo puede funcionar cuando el mínimo común denominador que todas las plataformas van a admitir fluya hacia netstandard. A menos que desee que incluso más API arrojen excepciones PlatformNotSupported , de lo contrario, se producirá una fragmentación dentro del estándar de red.

Ciertamente, puedo imaginar que no es ideal para usted, al igual que eliminar la compatibilidad con .NET Framework para ASP.NET Core 3.0 no será ideal para las personas que no pueden pasar a .NET Core. Pero, ¿estoy totalmente equivocado al pensar que usted, Microsoft, tiene muchos más recursos para lidiar con eso de lo que la empresa promedio tiene para cambiar a .NET Core? (Ni siquiera estoy hablando de dependencias externas que no posee y controla).

¿Cuál es el problema real aquí? Las personas que no pueden pasar de ASP.NET Legacy a ASP.NET Core no podrán cambiar si ASP.NET Core tiene como destino .NET Framework o no. La razón más probable por la que no pueden o no lo harán serán las bibliotecas específicas de System.Web , que tampoco funcionarán en ASP.NET Core en .NET Framework. Las personas que tienen sus aplicaciones ahora, obviamente ya tienen el conjunto de trabajo.

Y las personas que ya están en ASP.NET Core 2.1 en .NET Framework, si está funcionando, ¿por qué querer mudarse? Obviamente, todo lo que se necesita ya está allí y es bueno tener todo lo que viene recientemente a ASP.NET Core 3.0.

En cuanto a los demás:
Hay muchas formas de migrar una aplicación a .NET Core, es decir, separando partes de las antiguas aplicaciones monolíticas y reimplementandolas como microservicios, también reducen el riesgo y lo distribuyen a lo largo del tiempo.

¿Qué pasa si la plataforma nunca se pone al día? Luego, tendrá una biblioteca que apunta a netstandard2.3 que necesita la característica A que solo está disponible en .NET Core y Xamarin, pero imposible para .NET Framework.

Si una API no puede ser implementada por la mayoría de las plataformas que soportan .NET Standard, entonces es muy probable que no forme parte del estándar, ¿no? (en la práctica, es muy probable que sea al revés, ya que las plataformas en las que se ejecuta Xamarin generalmente están mucho más restringidas). Esperaría que se detectara este tipo de problema al revisar la API para su inclusión en .NET Standard, pero podría estar equivocado.

Y las personas que ya están en ASP.NET Core 2.1 en .NET Framework, si está funcionando, ¿por qué querer mudarse?

• ¿Apoyo? (un soporte de 3 años es increíblemente corto)
• ¿Una corrección de errores presente solo en 3.0? (Las versiones LTS solo obtienen correcciones para errores críticos y vulnerabilidades)
• ¿Necesita hacer referencia a una biblioteca que solo sea compatible con la última versión de ASP.NET Core?

Hay muchas formas de migrar una aplicación a .NET Core, es decir, separando partes de las antiguas aplicaciones monolíticas y reimplementandolas como microservicios, también reducen el riesgo y lo distribuyen a lo largo del tiempo.

Sí, claro, en teoría esa es la forma ideal de lidiar con eso. Pero:

• Algunas aplicaciones dependen de bibliotecas externas sobre las que no tienes control. Si la biblioteca no funciona en .NET Core y el proveedor no quiere (o no puede) portarla, no tiene suerte.
• La migración a .NET Core puede resultar costosa y llevar mucho tiempo. Si incluso los mejores equipos de Microsoft están luchando con eso, ¿realmente crees que será tan fácil para cualquier equipo promedio? Tendremos que esperar a 3.0 para ver que Entity Framework 6 finalmente sea compatible con .NET Standard.

No malinterprete lo que estoy diciendo: estoy totalmente a favor de usar .NET Core para nuevas aplicaciones. Pero el hecho de que ASP.NET Core fuera compatible con .NET Framework ayudó a muchas empresas a migrar a ASP.NET Core por un costo razonable. Estoy convencido de que nunca hubiera sido tan popular sin esa ruta de migración "no demasiado difícil".

Microsoft, ¿sería demasiado pedir ampliar el soporte 2.1? 2021 no es suficiente para nosotros y no tenemos suficientes recursos / tiempo para realizar esa conversión. ¿Quizás hasta 2022 al menos? Un año más realmente nos daría la oportunidad de hacer los cambios, aunque dolorosos.

Tenga en cuenta que muchos de nuestros proveedores externos aún tienen que migrar sus bibliotecas a la compatibilidad con .Net Core, que es la principal razón de nuestro problema.

FYI https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

Si bien veo la extensión de LTS según sea necesario, en mi opinión también debería tenerse en cuenta la incorporación de ASP.NET Core en .NET FX al ciclo de soporte de .NET FX. Para empezar, es confuso tener diferentes partes de .NET Framework en diferentes ciclos de soporte en los que combinarlo tendría más sentido. En segundo lugar, el código para 2.1 ya está escrito, publicado y se depende de él, por lo que se necesitarán muchos menos recursos para admitir 2.1 que desarrollarlo activamente en tangente con .NET Core 3.0. Si el mismo equipo mantiene ambos, también asumiría que la base de código activa modular ASP.NET Core más reciente y más familiar será más fácil de admitir que la base de código ASP.NET clásica completamente diferente.

Cuando MS anunció la EOL de Silverlight 5 en 2012, todavía lo admiten hasta octubre de 2021 (a pesar de que se eliminó en Chrome en 2015 y Firefox en 2017). Esto es para la tecnología que se ha abandonado por completo, lo que no es el caso aquí, en gran parte el mismo modelo de programación, base de código, el equipo de desarrollo activo todavía está trabajando en ello, solo está ejecutando software existente en .NET Framework que está siendo abandonado.

Antes de este anuncio, la mensajería era sólida, MS nunca abandonaba .NET Framework, que era excelente para cargas de trabajo solo de Windows (a diferencia de .NET Core para cargas de trabajo multiplataforma / de alto rendimiento) y que ASP.NET Core era el futuro modelo de programación que admitiría tanto .NET Framework como .NET Core en el futuro con .NET Standard como solución para el desarrollo de bibliotecas destinadas a múltiples plataformas.

Ahora está claro que .NET Core es el futuro para todos los proyectos nuevos, pero se trata de cómo tratar las inversiones existentes y los Clientes existentes que han tomado decisiones basadas en esta guía hasta ahora. ¿Cómo progresan los equipos de desarrollo de .NET existentes cuando necesitan admitir sistemas existentes? Se verán obligados a permanecer en ASP.NET clásico (donde sus habilidades / conocimientos existentes se están desactualizando día a día) mientras cambian de contexto para desarrollar nuevas aplicaciones. en .NET Core.

Si me viera obligado a mantener los sistemas en .NET Framework, preferiría desarrollarlo en el nuevo modelo de programación ASP.NET con acceso a una base de conocimiento / ecosistema activo y luego verme obligado a volver a usar el antiguo ASP.NET indefinidamente, pero eso no será posible a menos que ASP.NET Core en FX tenga el mismo nivel de soporte que WebForms.

MS también tiene la oportunidad de posicionar ASP.NET Core en FX como un entorno de desarrollo "estable" (es decir, fijo en ASP.NET Core 2.1). No ha sido fácil ser un desarrollador de .NET en los últimos años desde que comenzó .NET Core. Efectivamente, tuvimos que abandonar todos nuestros esfuerzos para intentar migrar a .NET Core <1.x, ya que era difícil mantenerse al día con el flujo constante de cambios importantes, solo hasta que .NET Core 2.x pudimos para admitirlo y migrar las aplicaciones existentes. Por otro lado, los desarrolladores de ASP.NET Framework existentes han visto su plataforma elegida estancada y luego reemplazada por el nuevo modelo de programación ASP.NET Core y, por extensión, erosionando sus habilidades / conocimientos existentes. La terminación del soporte para ASP.NET Core en FX mata una popular estrategia de migración por etapas hacia .NET Core donde corren el riesgo (sin una reserva de contingencia) de ejecutarse en una plataforma abandonada a menos que puedan actualizar todo su sistema a .NET Core (un riesgo que pueden evitar que se consideren los intentos de migración) también mata su oportunidad de poder participar en el futuro modelo de desarrollo de ASP.NET Core si no pueden migrar sus sistemas existentes en los que trabajan día a día, lo que solo será posible si cuenta con el mismo soporte que WebForms, que espero que todavía esté en consideración.

Nadie lo mencionó: en nuestra aplicación principal asp.net necesitamos alojar servicios WCF y este es el único punto débil para migrar desde el marco .net. No veo ninguna noticia sobre el soporte de wcf del lado del servidor en .net core 3, lamentablemente.

@DamianEdwards @davidfowl @natemcmaster Estamos en el mismo barco. Mi empresa tiene varios productos que se ejecutan en ASP.Net Core en .Net Full framework, y los apoyamos durante mucho más tiempo que 3 años, debido a la lentitud con que se mueven las industrias que vendemos. Extender el LTS para .net core 2.2 no tendría sentido en nuestra situación porque tendríamos que trasladar nuestras aplicaciones principales de ASP.net a ASP.Net. ¡Seguramente esto está derrotando a los chicos de punto! ¿Sugeriría simplemente admitir aplicaciones durante períodos de tiempo más cortos? Desafortunadamente, esto también es algo de lo que no tenemos control. Las industrias en las que trabajamos pueden tardar un año en implementar nuestro nuevo software.

Desafortunadamente, esto significa que cualquiera que realice implementaciones en las instalaciones aún no puede respaldar su software por más de 3 años. Tan pronto como lanza una aplicación dirigida a .netcore 3.0, por ejemplo, sus clientes tienen 3 años y luego se ven obligados a actualizar. Algunas industrias estarán bien, otras ciertamente no.

Ese es el mayor problema con esto, y me imagino que hace que .net core sea completamente inútil para mucha gente. De hecho, estoy de acuerdo en que al final esta es la dirección correcta a seguir, pero estoy seguro de que esto evitará que muchos lugares vayan al núcleo de .net.

Realmente me gustaría una respuesta del equipo .net sobre esto.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

Oh, bueno, esto solo obliga a tus bibliotecas a tener mejores capas 😉

¿No funciona este argumento en dirección opuesta?

Lo que no puedo entender es lo que realmente le impide tener una arquitectura de capas adecuada de ASP.NET Core.
Entonces, sí, algunas funciones de tiempo de ejecución no están disponibles en .Net Framework, como Span<T> , pero eso no significa que no esté disponible en absoluto. Está disponible , pero no es tan eficaz como en .Net core. Podríamos lidiar con eso.

Algunas implementaciones de bajo nivel podrían implementarse en variaciones para .net core específicamente y para .net estándar. Y dudo que haya mucho espacio para eso, ya que las API suelen estar disponibles como paquetes NuGet.
Muchos autores de bibliotecas admiten diferentes implementaciones para diferentes plataformas, esto es lo que siempre ha sido.

¿Podría explicar qué le impide exactamente admitir .Net Framework / .Net Standard? Algunos ejemplos simples ¿qué no se puede abstraer para tener implementaciones específicas de la plataforma?

le impide admitir .Net Framework / .Net Standard. Algunos ejemplos simples ¿qué no se puede abstraer para tener implementaciones específicas de la plataforma?

Fuera de mi cabeza, elementos que requieren tiempo de ejecución o cambios en el marco

• Punteros GC interiores; creando un Span seguro a partir de una referencia solo sin un objeto: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Implementaciones de interfaz predeterminadas
• Elementos de trabajo personalizados de Threadpool
• Sobrecargas de tramo en tipos base: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsync Sobrecargas desechables en tipos base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.
• IAsyncEnumeratorsobrecargas en tipos base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.

Artículos extra

• Elementos intrínsecos del hardware (x86, x64, ARM)
• Análisis de escape (nuevas asignaciones para apilar)
• Versiones en tiempo de ejecución en paralelo
• Arreglar redireccionamientos de enlace y control de versiones

No entiendo por qué no podemos tener una versión estándar de red que ya no sea compatible con netframework. Al igual que Windows Phone no tiene soporte estándar de red más allá de 1.2. ¿Por qué no podemos hacer avanzar el estándar y permitir que implementaciones como netcore, mono, xamarin, etc., lo igualen eventualmente o nunca? Luego, depende del creador de la biblioteca decidir qué versión de netstandard quieren implementar para maximizar la cobertura.

Este cambio hace que xamarin y mono ya no puedan usar aspnetcore. Hace que las bibliotecas se vean obligadas a apuntar tanto a netcore como a netstandard o, peor aún, a abandonar netstandard todos juntos y solo apuntar a netcore.

Esto finalmente conducirá a la muerte de netstandard.

le impide admitir .Net Framework / .Net Standard. Algunos ejemplos simples ¿qué no se puede abstraer para tener implementaciones específicas de la plataforma?

Fuera de mi cabeza, elementos que requieren tiempo de ejecución o cambios en el marco

• Punteros GC interiores; creando un Span seguro a partir de una referencia solo sin un objeto: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Implementaciones de interfaz predeterminadas
• Elementos de trabajo personalizados de Threadpool
• Sobrecargas de tramo en tipos base: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsync Sobrecargas desechables en tipos base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.
• IAsyncEnumerator se sobrecarga en tipos base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.

Artículos extra

• Elementos intrínsecos del hardware (x86, x64, ARM)
• Análisis de escape (nuevas asignaciones para apilar)
• Versiones en tiempo de ejecución en paralelo
• Arreglar redireccionamientos de enlace y control de versiones

Sin embargo, los elementos en esa primera lista suenan como cosas que serían candidatos para cambios en netstandard.

La mayoría de ellos no parecen imposibles de llevar a otros tiempos de ejecución, pero parece que nadie quiere acelerar el CLR para una nueva versión para llevar las implementaciones de interfaz predeterminadas a .NET Framework.

Al mismo tiempo, Microsoft no parece querer seguir adelante con una versión de .NET Standard que es para siempre incompatible con .NET Framework. De lo contrario, esto no sería realmente un problema, simplemente siga adelante con netstandard30 o netstandard40 y elimine el soporte de Framework; y tener como destino .NET Core uno de esos estándares más nuevos.

Siento que este hilo, etc., es el resultado de que Microsoft efectivamente se arrinconó.

Al mismo tiempo, Microsoft no parece querer seguir adelante con una versión de .NET Standard que es para siempre incompatible con .NET Framework.

Este falso; .NET Standard 2.1 se está finalizando y tiene 3104 nuevas apis sobre .NET Standard 2.0, incluidas las sobrecargas Span en los tipos de framework base; lo que puede hacer que sea incompatible con .NET Framework.

.NET Standard todavía está avanzando.

De lo contrario, esto no sería un problema, simplemente siga adelante con netstandard30 o netstandard40 y elimine el soporte de Framework; y tener como destino .NET Core uno de esos estándares más nuevos.

El problema es hacer que cada tiempo de ejecución, no solo Framework, sea incomparable con uno de los estándares más nuevos; y luego incomparable con todos los estándares posteriores. Lo que entra en .NET Standard debe ser acordado por los distintos tiempos de ejecución como cosas que se pueden implementar.

¿Los diversos GC de Mono y Unity admitirán punteros interiores pronto? Si no los agrega a .NET Standard, los bloqueará de ese .NET Standard en cualquier futuro .NET Standard hasta que sus GC se cambien para tratar con ellos. Sin embargo; es mejor agregar apis que puedan implementar ahora y guardar las que no pueden para un estándar futuro.

¿Son las apis que se agregan a Core las apis correctas para que se hayan fijado permanentemente para siempre y forzar cada tiempo de ejecución? que quiere ser compatible con el próximo Estándar, ¿implementar?

Algunas de las API de Core 2.1 cambiaron entre la vista previa 1 y la vista previa 2 (debido a los comentarios de uso); por lo que es difícil saber cuáles son las apis que son nuevas en Core X hasta su lanzamiento, momento en el que está escrito en piedra. Luego, ¿cuál de ellos es el conjunto correcto para agregar al Estándar para todos los tiempos de ejecución para implementar (o dejarlo atrás)?

El enfoque de .NET Standard es aún más agresivo que los estándares de navegador cuando dos navegadores deben implementar la función antes de que se acepte un estándar.

Sería bueno si un nuevo .NET Standard pudiera enviarse al mismo tiempo que .NET Core y todos los tiempos de ejecución pudieran implementarlo instantáneamente y ASP.NET Core pudiera usar todas las nuevas apis a través de .NET Standard; pero aunque agradable como ideal, tampoco es práctico. Incluso hay bastantes apis aprobadas que no se han implementado en .NET Core

La pregunta básica es si ASP.NET Core puede usar las apis que ha solicitado y enviarlas en la versión .NET Core que se envía con él (ya que se envían simultáneamente); ¿O solo puede usar las apis que se enviaron en la versión anterior de .NET Core, que por lo tanto tienen la posibilidad de estar en la versión .NET Standard para ese .NET Core? (Como parece, las versiones .NET Standard se retrasarán en la versión apis 1 detrás de .NET Core actualmente; usando el tamaño de muestra de 1)

Si ASP.NET Core puede usar las apis; luego, las apis obtienen pruebas de uso y se evalúan si son buenas; si no lo son, se pueden proponer mejores apis. Si ASP.NET Core no puede usarlos, entonces aún se desconoce si son buenas apis cuando se conviertan en candidatos para .NET Standard.

nadie quiere acelerar CLR para una nueva versión para traer implementaciones de interfaz predeterminadas a .NET Framework.

.NET Core al admitir cargas de trabajo tradicionales de .NET Framework (incluidos WinForms y WPF) es esencialmente la revisión de CLR; pero hecho de una manera más sostenible y preparada para el futuro?

Este falso; .NET Standard 2.1 se está finalizando y tiene 3104 nuevas apis sobre .NET Standard 2.0, incluidas las sobrecargas de Span en los tipos de framework base; lo que puede hacer que sea incompatible con .NET Framework.

¿Incluyendo .NET Framework 4.8 y .NET Framework 4.9?

Siempre existe la posibilidad de que futuras actualizaciones de Framework obtengan estas nuevas API. Por el momento, parece grabado en piedra que .NET Framework nunca obtendrá DIM, por lo tanto, cualquier interfaz con un método DIM _nunca_ podría ser portado a .NET Framework.

.NET Core al admitir cargas de trabajo tradicionales de .NET Framework (incluidos WinForms y WPF) es esencialmente la revisión de CLR; pero hecho de una manera más sostenible y preparada para el futuro?

Y no a prueba de retrocesos. Por mucho que Microsoft mostró cosas como Paint.Net ejecutándose en .NET Core, no puedo ejecutar mis proyectos existentes del lado del servidor en .NET Core, y tampoco la mayoría de la gente.

Sería bueno si un nuevo .NET Standard pudiera enviarse al mismo tiempo que .NET Core y todos los tiempos de ejecución pudieran implementarlo instantáneamente y ASP.NET Core pudiera usar todas las nuevas apis a través de .NET Standard; pero aunque agradable como ideal, tampoco es práctico.

Esto también podría no ser práctico, pero creo que la gente en general estaría un poco más feliz si pudiera haber dos versiones de ASP.NET Core:

• Una versión de vanguardia de rápido movimiento que está vinculada a .NET _Core_ y puede usar cualquier API nueva que desee.
• Una versión LTS de movimiento más lento que está vinculada a .NET _Standard_ y se ejecuta en más lugares; que finalmente se pone al día con las construcciones más antiguas pero siempre se queda atrás.

Al vincularlo a .NET Core, está forzando una compensación con la que no todos están contentos. Entiendo el razonamiento detrás del enfoque de tener que moverse rápido, pero también hay una preocupación legítima por el ecosistema .NET en general.

• Una versión de vanguardia de rápido movimiento que está vinculada a .NET Core y puede usar cualquier API nueva que desee.
• Una versión LTS de movimiento más lento que está vinculada a .NET Standard y se ejecuta en más lugares; que finalmente se pone al día con las construcciones más antiguas pero siempre se queda atrás.

Entonces, si ASP.NET Core 3.0 salió como .NET Core 3.0 solamente; pero en una fecha posterior cuando había un estándar .NET que tenía las apis; se lanzaron paquetes para ASP.NET Core 3.x que también eran .NET Standard (incluso si ASP.NET Core había pasado a 4.0); ¿Cumpliría con sus requisitos?

@ yaakov-h

Una versión LTS de movimiento más lento que está vinculada a .NET Standard y se ejecuta en más lugares; que finalmente se pone al día con las construcciones más antiguas pero siempre se queda atrás.

¿Qué significa esto? Siempre puede usar ASP.NET Core 2.1 con el soporte extendido que mencionó @DamianEdwards . Sin embargo, creo que incluso si ese apoyo fuera de 10 años, no satisfaría a la gente que se queja. El instinto me dice que mientras se desarrollen nuevas funciones, la gente querrá acceder a ellas (incluso las que actualmente están en el tren lento), pero tal vez estoy leyendo demasiado sobre estas respuestas ...

Siempre puede usar ASP.NET Core 2.1 con el soporte extendido que

¡No dividas la comunidad, por favor!
(basado en la votación) ¿Espera que 1/3 del desarrollador permanezca en asp.net core 2.1? ¿O espera 2/3 desarrolladores que crean paquetes nuget que tienen que mantener 2 versiones de su biblioteca?

@benaadams

Entonces, si ASP.NET Core 3.0 salió como .NET Core 3.0 solamente; pero en una fecha posterior cuando había un estándar .NET que tenía las apis; se lanzaron paquetes para ASP.NET Core 3.x que también eran .NET Standard (incluso si ASP.NET Core había pasado a 4.0); ¿Cumpliría con sus requisitos?

Precisamente.

@davidfowl

Siempre puede usar ASP.NET Core 2.1 con el soporte extendido que mencionó @DamianEdwards . Sin embargo, creo que incluso si ese apoyo fuera de 10 años, no satisfaría a la gente que se queja.

Parece haber mensajes contradictorios aquí:

1. Está bien permanecer en 2.1, la versión LTS anterior
2. ASP.NET Core se mueve tan rápido que ni siquiera podemos esperar un ciclo de lanzamiento entre .NET Core y el posterior .NET Standard.

Creo que (2) está causando mucha confusión y miedo a quedarse atrás.

@Juan0King

(basado en la votación) ¿Espera que 1/3 del desarrollador permanezca en asp.net core 2.1? ¿O espera 2/3 desarrolladores que crean paquetes nuget que tienen que mantener 2 versiones de su biblioteca?

Espero que los autores de bibliotecas decidan cuál es la versión mínima de ASP.NET Core que les importa admitir y apunten a eso. Es lo que ya están haciendo hoy. Algunas bibliotecas admiten ASP.NET Core 1.xy 2.x, algunas solo admiten 2.x. Esto no es diferente.

@ yaakov-h

No entiendo muy bien cuáles son los mensajes contradictorios. El 2.1 actual es LTS y se ejecuta en .NET Core y .NET Framework y tiene soporte durante 3 años. Este no es un mensaje nuevo, es el mismo mensaje que hemos tenido desde el principio.

ASP.NET Core se mueve tan rápido que ni siquiera podemos esperar un ciclo de lanzamiento entre .NET Core y el posterior .NET Standard.

Eso es especulación basada en los comentarios hechos aquí. Oficialmente, estamos vinculados al ciclo de envío de .NET Core y ya estamos agregando y consumiendo nuevas API con cada versión. ASP.NET Core que se ejecuta en .NET Framework nunca tuvo la intención de ser algo permanente (incluso se llama ASP.NET Core), siempre se pensó como un trampolín. Solo teníamos que volver a agregar suficientes API principales para que los clientes pudieran escribir aplicaciones que funcionen completamente.

¿Alguna respuesta sobre esto del equipo de ms?

Desafortunadamente, esto significa que cualquiera que realice implementaciones en las instalaciones aún no puede respaldar su software por más de 3 años. Tan pronto como lanza una aplicación dirigida a .netcore 3.0, por ejemplo, sus clientes tienen 3 años y luego se ven obligados a actualizar. Algunas industrias estarán bien, otras ciertamente no.

Ese es el mayor problema con esto, y me imagino que hace que .net core sea completamente inútil para mucha gente. De hecho, estoy de acuerdo en que al final esta es la dirección correcta a seguir, pero estoy seguro de que esto evitará que muchos lugares vayan al núcleo de .net.

Realmente me gustaría una respuesta del equipo .net sobre esto.

Desafortunadamente, esto significa que cualquiera que realice implementaciones en las instalaciones aún no puede respaldar su software por más de 3 años.

eso es una mierda, en realidad puede tener una actualización. el único momento en el que no funciona es dentro de un entorno integrado, pero el software integrado tiene muchos más problemas que una ventana de soporte de 3 años.

@schmitch, ¿no estoy seguro de lo que quieres decir? Obviamente, puede simplemente actualizar, pero para algunas industrias, la actualización a una nueva versión de software se convierte en un proyecto masivo que puede llevar años, dependiendo de los ciclos de lanzamiento y cuán técnicamente progresivas (o no) sean esas industrias.

@davidfowl

Sin embargo, creo que incluso si ese apoyo fuera de 10 años, no satisfaría a la gente que se queja.

No estoy seguro de cómo esperaba que la gente lo tomara, todos los efectos de esta decisión se enfrentan con la plataforma a la que se vendieron para mudarse, no solo no tienen futuro, sino que sus inversiones existentes basadas en el último modelo de programación se dirigen hacia la ejecución una plataforma no compatible (que a partir de este anuncio) en menos de 3 años. Otros que pensaron en una cuidadosa migración por etapas a .NET Core mediante la migración a .NET Framework primero ahora se enfrentan al riesgo de que no haya ninguna contingencia a la que recurrir, es decir, que se ejecute en un nuevo tiempo de ejecución o caída de .NET Core.

Una plataforma de desarrollador no debería ser el objetivo en sí mismo, ya que se está creando un valor exponencialmente mayor en la plataforma, que el valor de la plataforma en sí. Movimientos ciegos como este hacen que parezca que la máxima eficiencia de los recursos para aumentar la velocidad de la plataforma es más importante que las inversiones del ecosistema que se está creando en ella. La tinta en los bits de .NET Core 2.1 aún no está seca, pero los sistemas existentes (en FX) ya se están tratando como una responsabilidad (con el fin de brindar un soporte mínimo) en lugar del activo y el valor que agregan al ecosistema.

Como se ha mencionado, los sistemas empresariales pueden moverse a un ritmo glacial, a menudo equilibrando simultáneamente equipos de desarrolladores que ofrecen mejoras continuas que la cantidad de empleados y clientes necesitan utilizar para obtener un ROI constante de ellos. Muchas migraciones deben realizarse "en vuelo" con una planificación cuidadosa y pruebas rigurosas que pueden llevar años, tiempo que preferirían usar para crear valor y luego luchar para salir de la plataforma que está recibiendo soporte. Los grandes sistemas abandonados no son productos básicos como los iPhones que se pueden descartar fácilmente y actualizar sin problemas cada pocos años, cuanto más antiguos y más largos estén en desarrollo los sistemas, más valor se invertirá en ellos y más difícil será migrar fuera de ellos, lo que se vuelve especialmente difícil de absorber dado que no se crea valor en las migraciones, requiere recursos, absorbe el costo de oportunidad, aumenta el riesgo y lo mejor que pueden esperar es una migración impecable con sus sistemas existentes funcionando exactamente igual que antes.

Cualquiera que sea la fecha de vencimiento que se coloque en el soporte de FX, habrá sistemas existentes que se encuentren en funcionamiento y que se encuentren con obstáculos o que de otra manera no fueran factibles migrar. Entonces, ¿qué se convierte en la guía?

ASP.NET Core 2.1 ya está desarrollado, el esfuerzo por tener ASP.NET Core ejecutándose en FX / .NET Core es un costo irrecuperable ya invertido. Por lo tanto, la decisión debe enmarcarse como una cuestión de recursos de MS para mantener una plataforma ya desarrollada (después de LTS) frente a la cantidad acumulada de costos, mala voluntad e inercia generados por abandonar una plataforma popular.

No estoy seguro de entender qué se pide entonces. El ciclo de vida de LTS no ha cambiado desde que salió 2.1. Si escribió una aplicación en la versión LTS, ya sea .NET Core o .NET Framework, pasarían 3 años hasta que "no se admita". No entiendo bien cómo se quita la alfombra debajo de ti en términos de soporte, eso no ha cambiado. Debería actualizar para obtener actualizaciones de la plataforma.

Ahora entiendo que 2.1 es la última versión de LTS compatible con .NET Framework significa que no hay lugar para actualizar, pero ahí es donde entra la compatibilidad con LTS extendida. Si la aplicación nunca puede pasar a .NET Core incluso después de estos 6 años porque las API son falta, presente los problemas para que comprendamos las lagunas.

No estoy seguro de entender qué se pide entonces.

Este hilo solicita diferentes niveles de compromisos de MS que van desde: seguir desarrollándolo en conjunto con .NET Core, desarrollarlo en un "tren lento", no abandonar ASP.NET Core 2.1 y mantener el mismo nivel de soporte que WebForms, extender LTS . Mi preferencia sería no abandonarlo como una opción de alojamiento para ASP.NET Core (editar: obv cualquier cosa anterior que sería más preferible) que no retendría .NET Core solo v3 + mientras proporciona mucha utilidad para .NET existente Inversiones en divisas.

Ahora entiendo que 2.1 es la última versión de LTS compatible con .NET Framework significa que no hay lugar para actualizar

Lo que significa que se ha convertido en una plataforma sin soporte, cualquiera que esté en ella tiene que tratarla como lava y luchar para salir de ella antes de que llegue a su final de EOL sin soporte.

• Cualquiera que haya pensado en usarlo como una plataforma de prueba para pasar a .NET Core se ha convertido en una opción menos factible, ya que enfrentan el riesgo de quedarse varados en una plataforma no compatible si la migración demora más de lo esperado o encuentran obstáculos si alguna de las dependencias en los que confían no se pueden ejecutar en .NET Core.
• Cualquiera que se vea obligado a usar los servidores .NET Framework de la infraestructura administrada existente de su empresa no puede participar en el uso del nuevo modelo y ecosistema de desarrollo y debe ver que sus conocimientos / habilidades de ASP.NET clásico existentes se vuelven menos valiosos cada día.
• Los equipos no pueden migrar sus sistemas requeridos de .NET Framework existentes y requerirán un cambio de contexto a nuevos proyectos de ASP.NET Core en .NET Core.
• Ninguna organización quiere verse obligada a realizar una migración no planificada porque la orientación en la que se basaron para basar sus decisiones de presupuesto, planificación e inversión ha cambiado.

Una vez más, no es un problema para los proyectos greenfield, para las personas que pueden o estaban planeando migrar a .NET Core de todos modos o para cualquiera que no tenga que mantener sistemas heredados, pero sí impacta el ecosistema existente de .NET FX y ASP.NET Core. se ha vuelto más pobre al no poder considerar utilizar la opción popular de hospedaje en .NET FX.

En un mundo perfecto, todos estarían en .NET Core, pero existe una cantidad considerable de inversión en .NET FX que se está devaluando con esta decisión.

Si la aplicación nunca se puede mover a .NET Core incluso después de estos 6 años porque faltan API,

Hay muchas personas que no pueden o no quieren pasar a .NET Core, quieren que comparta el mismo nivel de soporte que ASP.NET clásico (que la mensajería actual sugiere que es indefinidamente).

La falta de API no es la única razón que impide la migración, por ejemplo, podrían depender de una dependencia donde el equipo de desarrollo la creó ya no existe, es un componente crítico que no se puede cambiar, no se puede refactorizar de forma segura (por ejemplo, tiene sin pruebas), se comparte con otros sistemas .NET FX únicamente, es mantenido por otro departamento que no tiene presupuesto, capacidad para cambiarlo o debido a factores externos como la infraestructura administrada de su empresa que solo admite la ejecución en servidores .NET Framework.

Gracias por matar .NET Standard con este tipo de decisiones.

Hasta ahora hemos ignorado .NET Core porque hay muchos ensamblados de terceros que aún no se dirigen a Core.

Muchos de los proveedores que están dispuestos a admitir Core lo hacen a medias, por ejemplo, Managed ODP.NET sin las API nativas que solo están disponibles en .NET Framework.

Entonces viene con este tipo de decisiones.

No, no adoptaremos .NET Core más rápido solo porque es demasiado trabajo para Microsoft admitir .NET Framework y no puede cumplir con el .NET Standard con el que ustedes presionaron al principio.

@davidfowl Puedo darte 2 ejemplos de lo que dificulta la migración a .NET Core - WCF (muchas aplicaciones empresariales existentes lo usan, creo que otros ya han planteado ese problema) y la falta de biblioteca Adomd en .NET Core / NET Estándar (para comunicarse con SSAS, también utilizado en aplicaciones empresariales, que se rastrea en SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core). Algunos otros (winforms) deberían arreglarse con el paquete de compatibilidad .net core 3 (¡yay!) - Tenemos que esperar y ver cómo funciona realmente.

@mythz

Este hilo solicita diferentes niveles de compromisos de MS que van desde: seguir desarrollándolo en conjunto con .NET Core, desarrollarlo en un "tren lento", no abandonar ASP.NET Core 2.1 y mantener el mismo nivel de soporte que WebForms, extender LTS . Mi preferencia sería no abandonarlo como una opción de alojamiento para ASP.NET Core, que no retendría .NET Core solo v3 + mientras brinda mucha utilidad para las inversiones existentes en .NET FX.

Bueno, actualmente estamos explorando la extensión del soporte LTS, pero no estamos considerando el soporte de .NET Framework de primera clase para ASP.NET Core para siempre (que es lo que está pidiendo). Esta versión de ASP.NET Core que busca para el mismo nivel de soporte que WebForms solo obtendría correcciones de seguridad y correcciones de confiabilidad. Puedo garantizarles que a medida que aparezcan características en las versiones más nuevas de ASP.NET Core, el nivel de satisfacción de quienes usan ASP.NET Core 2.1 bajará (al menos, eso es lo que me dice mi instinto) ya que esos cambios aún estarán fuera de alcanzar.

La falta de API no es la única razón que impide la migración, por ejemplo, podrían depender de una dependencia donde el equipo de desarrollo la creó ya no existe, es un componente crítico que no se puede cambiar, no se puede refactorizar de forma segura (por ejemplo, tiene sin pruebas), se comparte con otros sistemas .NET FX únicamente, es mantenido por otro departamento que no tiene presupuesto, capacidad para cambiarlo o debido a factores externos como la infraestructura administrada de su empresa que solo admite la ejecución en servidores .NET Framework.

Esto es muy común (incluso dentro de Microsoft) y es por eso que agregamos la capacidad de hacer referencia a las DLL de .NET Framework en .NET Core 2.0 porque resulta que la mayoría de los ensamblados son compatibles incluso si no fueron compilados para .NET Core. Ahora hay algunas cosas que nunca funcionarán (como AppDomains ...) pero espero que a medida que agreguemos más superficie de API, el conjunto de bibliotecas que no solo funcionan se reducirá a un número insignificante.

@pjmlp

No veo cómo esto mata a .NET Standard. .NET Standard es mucho más grande que ASP.NET Core. Se trata de crear bibliotecas compartidas reutilizables (como Microsoft.Extensions *) que funcionen en cualquier plataforma .NET compatible.

Hasta ahora hemos ignorado .NET Core porque hay muchos ensamblados de terceros que aún no se dirigen a Core.

¿Cuáles? ¿Son compatibles los que están en camino o esos ensamblados nunca admitirán .NET Core?

Muchos de los proveedores que están dispuestos a admitir Core lo hacen a medias, por ejemplo, Managed ODP.NET sin las API nativas que solo están disponibles en .NET Framework.

Estoy de acuerdo con esto y he visto toneladas de versiones dañadas de bibliotecas en .NET Core (incluso con algunas bibliotecas que envía Microsoft) pero diría que las mareas están cambiando. Algunas de las razones de esto se debieron a que faltaba el conjunto inicial de API que existía en .NET Core 1.0. Con 2.0 y 2.1, hemos visto un gran conjunto de bibliotecas transferirse más fácilmente al núcleo / estándar sin mucha pérdida de funcionalidad.

@voltcode ¡ Gracias por los comentarios concretos! Esperamos que algunos de estos tipos de problemas de compatibilidad desaparezcan o sean mínimos durante el período de tiempo en el que admitimos los proyectos de .NET Core en la actualidad (aproximadamente 3 años).

@davidfowl

....

Hasta ahora hemos ignorado .NET Core porque hay muchos ensamblados de terceros que aún no se dirigen a Core.

¿Cuáles? ¿Son compatibles los que están en camino o esos ensamblados nunca admitirán .NET Core?

En nuestro caso, ODP.NET es el más obvio, ya que Oracle no está transfiriendo el 100% de las funciones del controlador a Core.

Muchos de los proveedores que están dispuestos a admitir Core lo hacen a medias, por ejemplo, Managed ODP.NET sin las API nativas que solo están disponibles en .NET Framework.

Estoy de acuerdo con esto y he visto toneladas de versiones dañadas de bibliotecas en .NET Core (incluso con algunas bibliotecas que envía Microsoft) pero diría que las mareas están cambiando. Algunas de las razones de esto se debieron a que faltaba el conjunto inicial de API que existía en .NET Core 1.0. Con 2.0 y 2.1, hemos visto un gran conjunto de bibliotecas transferirse más fácilmente al núcleo / estándar sin mucha pérdida de funcionalidad.

Sin embargo, no es así como lo ven muchos de nuestros clientes.

Solo para que tenga una idea de cómo este tipo de decisiones afectan el futuro de .NET, en un proyecto reciente el cliente pagó el esfuerzo de desarrollo para mover una aplicación de .NET Framework a Java para la implementación de UNIX, ya que no estaba dispuesto a hacerlo. apueste por .NET Core y la implementación de ODP.NET paralizada, mientras que el controlador JDBC ofrece paridad de características 1: 1 con el controlador .NET Framework ODP.NET.

Otros también pueden elegir otras pilas alternativas.

Hay un montón de dependencias que no pueden ni pueden trasladarse a su aplicación empresarial promedio.

Este problema surgió en la parte superior de HN. Es posible que ustedes (@MSFT) también quieran verificar allí. Solo 1 hora y ya más de 50 comentarios.

@davidfowl

No veo cómo esto mata a .NET Standard. .NET Standard es mucho más grande que ASP.NET Core. Se trata de crear bibliotecas compartidas reutilizables (como Microsoft.Extensions *) que funcionen en cualquier plataforma .NET compatible.

No entiendo qué es ASP.NET Core si no es una biblioteca compartida reutilizable. Si la tendencia de las bibliotecas a ser modernas y rápidas es eliminar el soporte de .NET Standard, entonces es un mensaje complicado. ¿Newtonsoft.Json debería cambiar solo a .NET Core 3, si puede ejecutarse mucho más rápido? ¿Debería Autofac?

Entiendo las razones detrás de esto, ¡pero no estoy seguro de que los argumentos y la evaluación hayan cambiado mucho desde la última vez que surgió esto! Supongo que esperaremos y veremos ...

Voy a lanzar mi caso de uso y dar una perspectiva de cómo se ven las cosas en nuestra tienda en este momento en lo que respecta a esto:

AspNetCore ha sido sorprendente para nuestra pila en términos de autohospedaje (http.sys), una API web y contenido web estático en torno a varios servicios. Venimos de Nancy, que era sólida, pero también tenía muchos defectos desde nuestra perspectiva, por lo que nos cambiamos a AspNetCore hace aproximadamente un año. Hoy, estamos ejecutando cada una de nuestras bases de código en 2.x. En muchos casos, estaríamos perfectamente bien si nos cambiamos a un objetivo de .NET Core puro. Pero también hay muchos servicios que creamos para aprovechar AspNetCore que también dependen de cosas como System.DirectoryServices y System.Drawing . Desde la perspectiva de estos servicios, cambiaríamos la tecnología de alojamiento web antes de dejar .Net Framework. Desafortunadamente, debido a las complejidades de administrar 2 tecnologías de alojamiento web diferentes simultáneamente y al tamaño de nuestro equipo, es probable que también eliminemos AspNetCore del resto de nuestros servicios a favor de algo más compatible en ambos objetivos.

Para decirlo brevemente: esta decisión nos obligará a abandonar completamente AspNetCore en algún momento en el futuro (probablemente cuando LTS expire para 2.x), por lo que no sé en este momento. Si se reduce a eso, probablemente escribiremos nuestra propia solución interna para reemplazar AspNetCore, ya que nuestros casos de uso en términos de número real de características de AspNetCore que se utilizan son bastante estrechos (dicho esto, las características que _hacemos_ apalancamiento proporcionan un gran valor añadido para nosotros hoy).

Otros también pueden elegir otras pilas alternativas.

Eso es justo, pero las pilas alternativas tienen la misma política de soporte. Java se ha movido a un modelo LTS similar (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Hay un montón de dependencias que no pueden ni pueden trasladarse a su aplicación empresarial promedio.

@bencyoung

Es un marco, no una biblioteca. Está compuesto por un gran conjunto de bibliotecas que se envían juntas.

No entiendo qué es ASP.NET Core si no es una biblioteca compartida reutilizable. Si la tendencia de las bibliotecas a ser modernas y rápidas es eliminar el soporte de .NET Standard, entonces es un mensaje complicado. ¿Newtonsoft.Json debería cambiar solo a .NET Core 3, si puede ejecutarse mucho más rápido? ¿Debería Autofac?

No veo cómo es complicado. Estoy 97% seguro de que esas bibliotecas no eliminarán los marcos porque sus clientes se quejarían. La barra es extremadamente alta para eliminar marcos y es la misma razón por la que mantuvimos Microsoft.Extensions. * En .NET Standard 2.0. Estoy de acuerdo en que sería confuso si moviéramos todo allí, pero eso no es lo que está sucediendo aquí.

En cierto modo, esto es solo formalizar la realidad que ya existe en .NET Core. Enviamos ASP.NET Core con .NET Core. En .NET Core ASP.NET Core es un marco compartido, no es solo un conjunto de paquetes. Esos paquetes nunca se envían por separado del producto en general, por lo que los beneficios de hacer referencia a estos paquetes individuales son pequeños (la lista de paquetes también es pequeña por cierto).

@robkeimig

Pero también hay muchos servicios que creamos para aprovechar AspNetCore que también dependen de cosas como System.DirectoryServices y System.Drawing

Éstos existen en el paquete compacto de Windows en .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Para decirlo brevemente: esta decisión nos obligará a abandonar completamente AspNetCore en algún momento en el futuro (probablemente cuando LTS expire para 2.x), por lo que no sé en este momento. Si se reduce a eso, es probable que escribamos nuestra propia solución interna para reemplazar AspNetCore, ya que nuestros casos de uso en términos de número real de características de AspNetCore que se utilizan son bastante estrechos (dicho esto, las características que aprovechamos proporcionan un gran valor añadido para nosotros hoy).

¿Sería ese también el caso si se extendiera el apoyo?

Además, ahora tendríamos que eliminar todas las otras tecnologías no compatibles (AppDomains, Remoting, etc.) primero, en lugar de poder hacer ese trabajo en paralelo o en una etapa posterior.

¿Por qué no puede migrar a 2.1 primero?

La principal razón por la que dudaría es que el límite de soporte de 3 años significa que no puedes quedarte con él. Es un trampolín de migración a corto plazo, no un punto en el que pueda tener una plataforma estable a largo plazo. Lo que significa que debe tomar todo el dolor de la migración hacia adelante de una sola vez porque no puede arriesgarse a ir a la mitad, pausar la migración para crear una serie de nuevas funciones de alta prioridad y luego intentar finalizar la migración solo para encontrar un bloqueo duro y tiene que exportar todas sus nuevas funciones a la antigua base de código.

La principal razón por la que dudaría es que el límite de soporte de 3 años significa que no puedes quedarte con él.

Claro, es por eso que ofreceríamos soporte extendido como mencionó @DamianEdwards .

Solo para mostrar cuántas consecuencias crea esta decisión, ¿qué pasa con Blazor? ¿Dejará de basarse en netstandard? ¿Deberíamos esperar eso también? Blazor se anuncia como la próxima gran novedad. ¿Qué más de github.com/aspnet que actualmente depende de netstandard, lo abandonará y pasará a net core en la próxima versión principal? ¿Cuáles son los planes para otras cosas, en el control de MSFT pero fuera del repositorio de aspnet que compartirá el destino de aspnetcore?

@davidfowl

Otros también pueden elegir otras pilas alternativas.

Eso es justo, pero las pilas alternativas tienen la misma política de soporte. Java se ha movido a un modelo LTS similar (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

El pequeño detalle que está pasando por alto es que Java y otras pilas siguen siendo compatibles en todas las versiones, a diferencia de .NET Framework y .NET Core, sin necesidad de un estándar que solo se implementa parcialmente en las implementaciones en tiempo de ejecución.

Por lo que vale, actualmente estoy trabajando en la implementación de la primera aplicación principal ASP.Net de mi empresa. Tenemos una gran inversión en .NET Framework, por lo que usar ASP.Net Core en .NET Framework en lugar de .NET Core fue el enfoque obvio.

Ahora me pregunto si nos estaré preparando para mucho dolor después.

Aquí hay muchas preocupaciones interconectadas. Usted dice que el núcleo de ASP.Net nunca estuvo destinado a ejecutarse solo en .NET Framework. Los mensajes de Microsoft sobre ASP.Net Core en el pasado no lograron dejar eso muy claro.

De manera similar, muchos desarrolladores de .NET están acostumbrados a la idea de que .NET Framework es la implementación principal y que, en general, los demás son subconjuntos, excepto, por supuesto, para las API específicas del entorno. Esto ha cambiado con .NET Core, pero muchas personas generalmente tenían la impresión de que el .NET Framework "completo" terminaría admitiendo casi todo lo que hace .NET Core (excepto por las herramientas y la compatibilidad multiplataforma, obviamente), pero solo en una escala de tiempo más lenta, esperando que se resuelvan los problemas antes de incluirlos.

Recientemente, se ha sugerido que algunas características realmente importantes podrían no llegar nunca a .NET Framework. (por ejemplo, que los riesgos de compatibilidad del SpanEl tipo considerado demasiado severo para implementar en .NET Framework 4.8 sugiere que es posible que nunca se implementen, ya que ¿por qué esos riesgos serían más bajos en 4.9 ?. Aparentemente, preocupaciones similares rodean a los métodos de interfaz predeterminados. ¡Ese es un cambio de paradigma importante con el que muchos desarrolladores no estarán contentos!

Los mensajes en este mismo hilo sugieren que Microsoft está comenzando a considerar .NET Framework como una característica heredada, algo que recibirá cada vez menos atención de desarrollo con el tiempo, hasta que realmente solo obtenga correcciones de seguridad.

Históricamente, Microsoft ha sido pésimo al tener claro lo que está desarrollando activamente, lo que en su mayoría solo mantiene con solo características nuevas esporádicas, y para qué planean proporcionar solo soluciones de seguridad y estabilidad. Me suena mucho a que .NET Framework no solo está en esa segunda categoría ahora, sino que está muy cerca de estar en la tercera categoría.

Eso es realmente molesto. .NET Core tiene algunos problemas que lo hacen menos que óptimo para algunas aplicaciones empresariales. Seguro que usarlo en aplicaciones que tienen un desarrollo continuo puede estar bien. Pero, por ejemplo, la mayoría de las empresas también tienen algunas aplicaciones que se implementan y solo se tocan una vez cada pocos años. Eso funciona mal con .NET Core. Aquí las empresas tienen que luchar con ciclos de soporte cortos para la mayoría de las versiones. Y en Windows no existe ningún mecanismo para instalar automáticamente las nuevas versiones de parches para obtener las actualizaciones de seguridad, etc.

Así que las empresas que inician nuevos proyectos se preguntan qué hacer. El .NET Framework, más amigable para las empresas, muestra signos bastante claros de estar obsoleto y, por lo tanto, es mejor evitarlo para un nuevo desarrollo. Por otro lado .NET Core existe pero es mucho menos amigable para las empresas.

Así que esto básicamente se convirtió en una perorata, pero espero que esto ilustre mejor las preocupaciones que tienen muchos desarrolladores.

@davidfowl

Pero también hay muchos servicios que creamos para aprovechar AspNetCore que también dependen de cosas como System.DirectoryServices y System.Drawing

Éstos existen en el paquete compacto de Windows en .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

No sabía que el paquete de compatibilidad admitía este caso de uso. Idealmente, nos gustaría mover todo hacia adelante a .NET Core, y esta parece ser una muy buena respuesta (que es posible que hayamos pasado por alto inicialmente). No tenemos planes de trasladar el alojamiento de nuestros servicios a Linux / OSX, por lo que estas piezas podrían encajar muy bien para nosotros.

¿Sería ese también el caso si se extendiera el apoyo?

En términos de soporte, siento que LTS de 2.x en 2021 es razonable, considerando todas las demás restricciones que están involucradas con algo de este gran alcance.

Según lo que entiendo ahora, es probable que nos sintamos cómodos actualizando a AspNetCore 3.x una vez que tengamos la oportunidad de revisar y convertir los proyectos de .NET Framework en proyectos de .NET Core (con el uso del paquete de compatibilidad según sea necesario).

Gracias por su seguimiento.

Escribí en .NET (principalmente C #) durante 15 años en proyectos de alta presión. Perdí tantos años y el dinero de los clientes desperdiciando tiempo usando un marco de ingeniería. Me encantó el concepto de .NET Core. Para mí fue la velocidad de escribir proyectos de NodeJS pero en el increíble ecosistema .NET (incluido todo el contenido). Desafortunadamente, no cumplió con esa promesa, todavía es (incluso con este nuevo anuncio) demasiado complicado para usarlo. Durante los últimos 3 años he estado construyendo en NodeJS, lo siento chicos, simplemente no se compara. Hágalo más simple y fácil de usar y atraerá nuevamente a la amplia comunidad de desarrolladores.

Para proyectos con dependencias de .NET Framework binarias compiladas y complejas (material del proveedor sin código fuente) que se pueden ejecutar en aplicaciones ASP.NET Core 2.1 destinadas a .NET Framework implementadas en Windows, agregar el Paquete de compatibilidad de Windows al proyecto los mantendrá trabajando en Core 3.0 si las dependencias duras hacen referencia a los tipos proporcionados por el paquete?

Existe un ecosistema masivo de bibliotecas comerciales extremadamente maduras que, lamentablemente, dependen de System.Drawing, GDI y, a veces, del Registry (!). Si estos solo ahora funcionan con 2.1 y solo se admiten durante tres años, este es un problema que podría detener la adopción de Core en algunas empresas.

.NET Core está haciendo un círculo completo para llegar al punto de partida.

Sugeriría otro enfoque: deje que .NET Framework incorpore las características útiles de .NET Core y luego elimine .NET Core por completo como una rama experimental sin salida. Deteniendo así la segmentación y guardando la tecnología para mayor beneficio de los clientes. Un enfoque algo controvertido, pero mucho más sensato en cuanto al producto.

@davidfowl

ASP.NET Core que se ejecuta en .NET Framework nunca tuvo la intención de ser algo permanente, siempre fue un trampolín

Eso no es cierto en absoluto. La mensajería en ASP.NET Core siempre ha sido que es compatible con .NET Core y .NET Framework. Incluso los primeros anuncios de .NET Core mencionan ambas plataformas para ASP.NET Core (en ese entonces ASP.NET 5).

La imagen muy conocida que muestra .NET Standard también tiene ASP.NET Core que abarca tanto Core como el marco completo. Y la documentación oficial incluso dice: "No hay planes para eliminar la compatibilidad con la orientación de .NET Framework en ASP.NET Core".

Entonces sí, es obvio que esta decisión ha cambiado a estas alturas , pero decir que siempre fue así es solo una mentira o una muy mala comunicación hecha por Microsoft durante años .

incluso se llama ASP.NET Core

Oh vamos. Después de todo este tiempo, la gente como yo tuvimos que luchar contra la gente para separar .NET Core y ASP.NET Core porque no son lo mismo, no use el nombre similar para su ventaja aquí. Eso no es justo. El cambio de nombre a "Core" ciertamente no fue para vincularlo explícitamente a .NET Core. Además, EF Core también tiene un "Core", pero continuará ejecutándose en netstandard para que ese argumento no funcione.

ahí es donde entra el soporte extendido de LTS. Si la aplicación nunca puede pasar a .NET Core incluso después de estos 6 años […]

¿De dónde vino esto ahora? La última vez, el mensaje seguía siendo "estamos investigando una oferta de LTS de 'soporte ampliado'" . ¿Es esto algo real ahora y tenemos 6 años?

@pjmlp

El pequeño detalle que está pasando por alto es que Java y otras pilas siguen siendo compatibles en todas las versiones, a diferencia de .NET Framework y .NET Core, sin necesidad de un estándar que solo se implementa parcialmente en las implementaciones en tiempo de ejecución.

Es un buen punto, pero no entiendo qué tiene que ver eso con un mejor apoyo. Se hizo la afirmación de que cambiar a Java sería mejor debido a que las bibliotecas están menos dañadas (que es un problema puntual) y el soporte empresarial (ciclo de soporte más largo).

@KevinCathcart

Los mensajes en este mismo hilo sugieren que Microsoft está comenzando a considerar .NET Framework como una característica heredada, algo que recibirá cada vez menos atención de desarrollo con el tiempo, hasta que realmente solo obtenga correcciones de seguridad.

Históricamente, Microsoft ha sido pésimo al tener claro lo que está desarrollando activamente, lo que en su mayoría solo mantiene con solo características nuevas esporádicas, y para qué planean proporcionar solo soluciones de seguridad y estabilidad. Me suena mucho a que .NET Framework no solo está en esa segunda categoría ahora, sino que está muy cerca de estar en la tercera categoría.

Consulte https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

Para proyectos con dependencias de .NET Framework binarias compiladas y complejas (material del proveedor sin código fuente) que se pueden ejecutar en aplicaciones ASP.NET Core 2.1 destinadas a .NET Framework implementadas en Windows, agregar el Paquete de compatibilidad de Windows al proyecto los mantendrá trabajando en Core 3.0 si las dependencias duras hacen referencia a los tipos proporcionados por el paquete?

Sí, es compatible con binarios.

Existe un ecosistema masivo de bibliotecas comerciales extremadamente maduras que, lamentablemente, dependen de System.Drawing, GDI y, a veces, del Registry (!). Si estos solo ahora funcionan con 2.1 y solo se admiten durante tres años, este es un problema que podría detener la adopción de Core en algunas empresas.

Como he mencionado varias veces en este hilo. Agregamos la capacidad de hacer referencia directamente a dependencias compiladas con .NET Framework en proyectos de .NET Core.

@poke Tienes razón sobre los mensajes, no estaba nada claro, mi error.

¿De dónde vino esto ahora? La última vez, el mensaje seguía siendo “estamos investigando una oferta de LTS de 'soporte ampliado'”. ¿Es esto algo real ahora y tenemos 6 años?

Hice 6, no sé cómo será el soporte extendido cuando lo ofrezcamos.

.NET Core siempre iba a reemplazar .NET Framework (originalmente iba a ser .NET Framework 5), pero la reescritura fue tan ambiciosa que ahora se utiliza para admitir aplicaciones de escritorio.

Vaya, ¿alguna vez hay muchos comentarios divertidos aquí? Parece que hay mucha rabia de nerd fuera de lugar, intercalada con gente que no lee el artículo.

colocarse

@edandersen , ¿ejecutó ApiPort en estos archivos
El paquete de compatibilidad de Windows ya proporciona funcionalidad para system.drawing y el registro. ¿Intentó ejecutar estas cosas en .NET Core ya? System.Drawing incluso funciona en * nix usando libgdiplus de mono. Esto nos permite usar ClosedXML en sistemas que no son Windows para trabajar con archivos de Excel.

La mayor dependencia de .NET Framework para aplicaciones "recientes" en nuestra empresa es la funcionalidad WCF.
Las bibliotecas cliente de .NET Core WCF están mejorando. No he verificado el estado actual de qué tan bien funcionan con algunos servicios que consumimos, pero en el pasado, no podíamos hablar con algunos servicios. Pero la funcionalidad faltante ya estaba en su lista de problemas. ¡Los servicios simples funcionan bien por otro lado!
Por otro lado, no hay un reemplazo "directo" para hospedar servicios SOAP en .NET Core. Esto bloquearía la migración de algunas aplicaciones a .NET Core (pero, como se mencionó, no es necesario).
Para una aplicación ASP.NET Core reciente, creamos una aplicación web de proxy ASP.NET adicional que solo aloja un servicio WCF y luego reenvía a la aplicación ASP.NET Core a través de HTTP / JSON. No es muy bonito y agrega complejidad a la implementación, pero permite algunos puntos de integración.

No estoy diciendo que realmente quiera la capacidad de hospedaje WCF en .NET Core, dado que me duele la cabeza configurándolo. Sin embargo, alguna opción para alojar servicios SOAP y generar WSDL sería genial. Ya he visto algunas bibliotecas OSS que intentan hacer eso. Quizás esto sea suficiente.

@ davidfowl

Es un buen punto, pero no entiendo qué tiene que ver eso con un mejor apoyo. Se hizo la afirmación de que cambiar a Java sería mejor debido a que las bibliotecas están menos dañadas (que es un problema puntual) y el soporte empresarial (ciclo de soporte más largo).

El punto es que, si bien las versiones de Java LTS también son de tres años, la compatibilidad entre todas las implementaciones principales es oro, que es algo que ustedes están dispuestos a tirar por la ventana aquí.

Todo este error de .NET Framework, .NET Core, Xamarin, .NET Standard está empezando a parecerse a los buenos viejos tiempos de WinDev vs DevTools, solo dentro de los equipos de .NET para variar.

Entonces, naturalmente, los clientes están dispuestos a mudarse a plataformas que no parecen que los equipos internos estén luchando por las características de la hoja de ruta.

Estas decisiones no inspiran confianza.

Esto realmente se siente como un error por parte del equipo de .NET, ¡particularmente en el contexto del clima actual!

Para aquellos que mencionan Java, ¿realmente han mirado lo que está sucediendo allí recientemente? Entre su demanda absolutamente loca contra Google por usarlo en Android y sus últimas travesuras de licencias, el comportamiento de Oracle parece ser el de una empresa que quiere acabar con un producto no deseado, ¡en lugar de uno que quiere que prospere!

Este es el momento perfecto para que Microsoft aproveche esto con un poderoso marketing que sugiere que están haciendo exactamente lo contrario, y que .NET es el lugar ideal para opciones de desarrollo sanas, estables y seguras. En cambio, obtenemos ... esto. :decepcionado:

@masonwheeler

Nosotros que trabajamos en ambos entornos realmente apreciamos el trabajo que Oracle
ha estado haciendo con Java.

Son aquellos que rara vez usan Java en la producción, desprecian a Oracle, los que obtienen
perdido en argumentos de odio contra ellos.

En lo que respecta a Android, apoyo plenamente la demanda, ya que Google
logró bifurcar la plataforma Java, teniendo éxito donde Microsoft falló
con J ++. Todavía espero con ansias el día en que se garantice que cualquier JAR aleatorio en Maven Central funcione realmente en Android.

En cuanto a .NET, estoy empezando a cansarme de los continuos reinicios de
cómo se supone que debemos apuntar a las plataformas de Microsoft.

Todo WinRT, UAP, UWP, .NET Native soltando F #, XNA, Core 1.0 se ha ido
muchas uvas agrias y esta decisión reciente no mejora las cosas
en general.

.NET es mi plataforma favorita, así que no la estropees aún más.

@mythz

Ahora entiendo que 2.1 es la última versión de LTS compatible con .NET Framework significa que no hay lugar para actualizar

Lo que significa que se ha convertido en una plataforma sin soporte, cualquiera que esté en ella tiene que tratarla como lava y luchar para salir de ella antes de que llegue a su final de EOL sin soporte.

Ese es uno de los puntos que realmente no entiendo en toda la discusión. ¿Qué obtiene realmente del soporte LTS además de las correcciones de seguridad (que podrían cubrirse con el soporte LTS extendido)?

En el soporte estándar de LTS, solo hay dos cosas que esperar:

• Correcciones de seguridad
• Correcciones de errores críticos

La mayoría de los primeros (correcciones de seguridad) se parchearán a través de Windows Update (ya que su objetivo es .NET Framework). Por lo tanto, solo quedan las correcciones de errores críticos y de seguridad en ASP.NET Core.

Digamos que ya se sabe que el soporte finaliza en 2018, no esperaría que nadie comenzara nuevos proyectos en 2020, por lo que (en mi humilde opinión) es poco probable que encuentre un error crítico después de 2021 (o 2026 o cuánto tiempo se entiende el soporte extendido ser - estar).

Eso solo deja abiertos los errores de seguridad, lo cual es razonable cubrir con LTS.

En respuestas anteriores vi mencionar TLS 1.4, etc., de todos modos, estos no estarían cubiertos en un LTS, ya que de todos modos es una característica nueva, que es la misma incluso para Java (Java 6 solo tiene soporte TLS 1.0 - TLS 1.1 si cuenta en el actualizaciones no públicas solo disponibles para los suscriptores de soporte extendido de Oracle).

• Cualquiera que haya pensado en usarlo como una plataforma de prueba para pasar a .NET Core se ha convertido en una opción menos factible, ya que enfrentan el riesgo de quedarse varados en una plataforma no compatible si la migración demora más de lo esperado o encuentran obstáculos si alguna de las dependencias en los que confían no se pueden ejecutar en .NET Core.
  Pero, ¿qué API son las que faltan y que ahora puede usar con ASP.NET Core en .NET Framework, pero no en ASP.NET Core en .NET Framework + paquetes de compatibilidad?

Creo que ese es el punto más crítico aquí, identificar estos y enviar las API que faltan con futuros paquetes de compatibilidad o agregarlas a .NET Core, lo que permite hacer referencia a las bibliotecas de .NET Framework incluso cuando se apunta a .NET Core.

Desde .NET Core, puede hacer referencia (y usar) cualquier biblioteca de .NET Framework en un proyecto de .NET Core siempre que solo use las API disponibles en .NET Standard o .NET Core .

Esto no requiere que el autor de la biblioteca actualice sus bibliotecas para apuntar a netstandard / netcoreapp.

¿Quizás ayudaría si Microsoft extendiera la página web / biblioteca de NuGet mediante una función / enlace junto a cada paquete nuget en nuget.org que muestra un informe si esta biblioteca usa alguna API incompatible que no esté disponible en versiones específicas de .NET Core?

Por ejemplo

'Company.Example.MyLib` mostraría

• .NET Core 2.1: soporte parcial (informe detallado): donde el informe detallado mostraría a las Apis que funcionan y cuáles no
• .NET Core 3.0 :; totalmente compatible

Esto debería ser posible ejecutando .NET Portability Analyzer? Una ventaja sería, si agrega una lista de API públicas que son seguras para llamar (analizando el Código IL y ver qué otras API llama para asegurarse de que sea seguro o no).

Esto al menos facilitaría a los desarrolladores determinar si una biblioteca específica que necesitan para su proyecto puede ejecutarse en .NET Core o no, incluso si no la llama explícitamente.

En este momento, es un poco complicado darse cuenta de que si las API son compatibles o no, necesita la biblioteca, ejecute el analizador localmente en ella. Es posible que muchos desarrolladores no sepan que pueden usar algunas de las bibliotecas que no son compatibles con netstandard oficialmente.

@davidfowl @terrajobst ¿Sería una adición viable a NuGet? ¿Para facilitar y acelerar la detección de las bibliotecas de .NET Framework compatibles con -NET Core?

• Cualquiera que se vea obligado a usar los servidores .NET Framework de la infraestructura administrada existente de su empresa no puede participar en el uso del nuevo modelo y ecosistema de desarrollo y debe ver que sus conocimientos / habilidades de ASP.NET clásico existentes se vuelven menos valiosos cada día.

Eso no es un argumento a favor o en contra del soporte de .NET Framework o no. Las personas que están atrapadas en dependencias heredadas y no pueden migrar a .NET Core (con el paquete de compatibilidad o con las bibliotecas de .NET Framework) no podrán hacer ninguna de las dos cosas después. ¿Cómo cambiaría eso algo?

Aún así, partes de las aplicaciones monolíticas se pueden dividir y mover gradualmente partes de la aplicación heredada a una nueva, pero esa es una historia diferente.

• Ninguna organización quiere verse obligada a realizar una migración no planificada porque la orientación en la que se basaron para basar sus decisiones de presupuesto, planificación e inversión ha cambiado.

Si los beneficios superan a las inversiones, ¿por qué no? es decir, si hay características únicas que le brindan un gran valor a cambio o un gran aumento de rendimiento.

Si no es así, permanezca en el sistema anterior. El desarrollo de software ha sido así desde siempre. Todavía hay empresas que ejecutan software desarrollado en Fortune y Cobol.

Hay muchas personas que no pueden o no quieren pasar a .NET Core, quieren que comparta el mismo nivel de soporte que ASP.NET clásico (que la mensajería actual sugiere que es indefinidamente).

La falta de API no es la única razón que impide la migración, por ejemplo, podrían depender de una dependencia donde el equipo de desarrollo la creó ya no existe, es un componente crítico que no se puede cambiar, no se puede refactorizar de forma segura (por ejemplo, tiene sin pruebas), se comparte con otros sistemas .NET FX únicamente, es mantenido por otro departamento que no tiene presupuesto, capacidad para cambiarlo o debido a factores externos como la infraestructura administrada de su empresa que solo admite la ejecución en servidores .NET Framework.

Sí, pero ¿qué dependencias? Se necesitarían ejemplos concretos para identificar qué API utilizan estas dependencias externas. Esta API se podría agregar a .NET Core 3.0 o una versión futura de .NET Core.

Esto hace posible utilizar esta biblioteca de .NET Framework en proyectos de .NET Core. El único problema es cuando las bibliotecas de .NET Framework usan API que no están disponibles en .NET Standard o .NET Core. Pero para arreglar esa retroalimentación es necesario identificar las bibliotecas.

@pjmlp

@davidfowl

Otros también pueden elegir otras pilas alternativas.

Eso es justo, pero las pilas alternativas tienen la misma política de soporte. Java se ha movido a un modelo LTS similar (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

El pequeño detalle que está pasando por alto es que Java y otras pilas siguen siendo compatibles en todas las versiones, a diferencia de .NET Framework y .NET Core, sin necesidad de un estándar que solo se implementa parcialmente en las implementaciones en tiempo de ejecución.

Eso tampoco es exactamente cierto para las ediciones posteriores de Java. Java 9 agregó el primer paso para modularizar el tiempo de ejecución, que ES un cambio importante . En la Versión 9, esto se ha deshabilitado de forma predeterminada, pero en versiones futuras, la bandera estará habilitada de forma predeterminada (o no se podrá apagar) y esto crea cambios importantes en las aplicaciones heredadas.

Por ejemplo, para las muchas bibliotecas que usan API internas a través de algo de magia de reflexión, puede romper y romperá con ese cambio. Y muchas de estas bibliotecas, como en el mundo .NET, ya no se mantienen, por lo que no se esperan actualizaciones.

@ TsengSR

A pesar de los cambios importantes introducidos en Java 9, el 100% de todos los marcos de Java relevantes funcionan en Java 9, 10 y 11, lo que definitivamente no es el caso en .NET Framework, UWP y Core.

¡Imagínese que incluso hay dos marcos de GUI multiplataforma oficiales, mientras que todavía no tenemos una hoja de ruta oficial para Core!

@pjmlp

@ TsengSR

A pesar de los cambios importantes introducidos en Java 9, el 100% de todos los marcos de Java relevantes funcionan en Java 9, 10 y 11, lo que definitivamente no es el caso en .NET Framework, UWP y Core.

¡Imagínese que incluso hay dos marcos de GUI multiplataforma oficiales, mientras que todavía no tenemos una hoja de ruta oficial para Core!

Lo siento, eso es una completa tontería.

Los módulos internos de Java 9, que evitan reflejarse en estos módulos a menos que se llame a --add-opens (y siempre se supuso que era una solución temporal para que las personas pudieran continuar ejecutando su aplicación heredada y eliminar algunas versiones más adelante).

En caso de que te perdiste el drama y el shitstrom cuando Java 9 estaba a punto de ser lanzado, esta fue la respuesta:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

Para ayudar a todo el ecosistema a migrar a la plataforma modular Java en un
paso más relajado, propongo permitir el acceso reflectante ilegal
del código en la ruta de clases de forma predeterminada en JDK 9, y para no permitirlo enuna versión futura.

Por otra parte, Java EE 9 obsoleto JAX-WS quedó obsoleto y se eliminará en Java EE 11. Eso podría verse aproximadamente como el equivalente de WCF. Cualquier aplicación que lo use no puede ser portado a una versión más nueva ni sin reemplazarlo por otra cosa, que es un proceso de migración. Ni más ni menos diferente que migrar de ASP.NET Core en .NET Framework a ASP.NET Core en .NET Core (o de ASP.NET a ASP.NET Core @ .NET core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Mayor integridad de la plataforma: antes de Java 9, era posible utilizar muchas clases en la plataforma que no estaban destinadas a las clases de una aplicación. Con una encapsulación sólida, estas API internas están realmente encapsuladas y ocultas a las aplicaciones que utilizan la plataforma. Esto puede hacer que la migración de código heredado a Java 9 modularizado sea problemática si su código depende de API internas.

Cualquier aplicación que usó estas API internas (incluidas todas en el espacio sun.* nombres

@TsengSR

Los módulos internos de Java 9, que evitan que se reflejen en estos módulos a menos que se llame a --add-opens (e iirc siempre se supuso que era una solución temporal para que las personas pudieran continuar ejecutando su aplicación heredada y eliminar algunas versiones más tarde).

O puede usar el modo classpath y omitir el lío que son los módulos. Ese modo permanecerá en el futuro previsible. Y si ingresa a los módulos, puede declarar explícitamente dependencias en los paquetes de otros módulos.

Por otra parte, Java EE 9 obsoleto JAX-WS quedó obsoleto y se eliminará en Java EE 11. Eso podría verse aproximadamente como el equivalente de WCF.

Todo J2EE ha quedado obsoleto y eliminado en Java 11, que ya está disponible. Pero J2EE solo define las interfaces, no la implementación. Para continuar usando J2EE, lo que hago, solo necesita cambiar las dependencias. Todas las implementaciones estaban separadas de todos modos y funcionan bien en Java 11.

Cualquier aplicación que usó estas API internas (incluido el espacio de nombres all in sun. * Que sí usaron algunas de las bibliotecas antiguas, o que solían usar cuando Java 9 estaba a punto de ser lanzado) o usa una biblioteca de terceros que depende de estas API u otra biblioteca puede estar sujeta a este cambio importante.

Que siempre ha sido el caso. Eran API indocumentadas. Nadie debería haberlos estado usando y podrían haber cambiado o eliminado en cualquier momento. Muchas de las API internas de uso común (ab) se han dejado para no interrumpir los programas existentes, de modo que puedan migrar a las API adecuadas en el futuro.

Algunas API han quedado obsoletas, pero estamos hablando de API específicas y no de la totalidad del ecosistema JRE o Java. El trabajo necesario para pasar de esas API a API más nuevas, oficiales y documentadas es generalmente mínimo.

Y Java siempre ha estado más dispuesto a romper la compatibilidad con versiones anteriores que .NET. Por ejemplo, en Java ahora es ilegal declarar un tipo llamado var porque está reservado para la inferencia local. En Java, es ilegal nombrar una variable _ porque está reservada para su uso como descarte / comodín. C # tomó la decisión exactamente opuesta en ambos casos, en nombre de preservar la compatibilidad con versiones anteriores.

No me malinterpretes, Java es su propio lío. Entre los módulos, el soporte para Java 8 llegando a su fin y Oracle volviéndose codicioso con las licencias de JRE, Microsoft tiene una gran cantidad de oportunidades para convertir a las personas. Pero eso es muy poco probable que suceda si Microsoft va a enviar mensajes contradictorios sobre el soporte futuro y la evolución de sus plataformas.

@TsengSR

Ese es uno de los puntos que realmente no entiendo en toda la discusión. ¿Qué obtiene realmente del soporte LTS además de las correcciones de seguridad (que podrían cubrirse con el soporte LTS extendido)?

Hay un reloj en ese LTS que terminará sin ningún lugar para actualizar, que es el punto clave que se pasa por alto cuando se lanza Java LTS en comparación. Con Java y .NET Framework siempre ha tenido un alto grado de confianza en que podría actualizar los sistemas existentes con un mínimo esfuerzo dado su fuerte enfoque en la compatibilidad con versiones anteriores. Dado que ya no existe una ruta de actualización, los sistemas existentes se ven obligados a migrar a un nuevo tiempo de ejecución o seguir ejecutándose en una plataforma no compatible. Por diversas razones, habrá sistemas en los que no será factible migrar a .NET Core dejando su futuro (con esta decisión) para mantener la ejecución de sus funciones comerciales críticas en una plataforma no compatible.

No estoy seguro de cuál sería la metáfora más cercana de esta decisión en la tierra de Java, tal vez obligando a los sistemas existentes a migrar para ejecutarse en GraalVM, muchas cosas funcionarán, algunas no, cuanto más grande sea el sistema, menos confianza en poder predecir la compatibilidad / problemas hasta que se intente físicamente una migración.

Estoy de acuerdo en que se ha hecho mucho para que las migraciones a .NET Core sean posibles, pero todavía habrá una serie de factores externos (incluidos fuera del control de MS) que evitarán las migraciones y esta decisión solo se tomará migraciones menos probables que antes de este anuncio ASP.Core / FX era una ruta de migración popular, pero ya no será prudente recomendar que una estrategia de migración general incluya la migración a una futura plataforma no compatible, lo que evitará muchas migraciones de ocurrir, lo que resulta en que más sistemas / desarrolladores existentes se dejen en ASP.NET clásico estancado.

La mayoría de los primeros (correcciones de seguridad) se parchearán a través de Windows Update (ya que su objetivo es .NET Framework). Por lo tanto, solo quedan las correcciones de errores críticos y de seguridad en ASP.NET Core.

Las organizaciones no quieren basar su empresa en una plataforma con soporte parcial con la esperanza de que los errores o problemas de seguridad futuros solo ocurran en las bibliotecas que se han asignado para el soporte. Sería de gran ayuda si ASP.Core / FX estuviera cubierto por el mismo nivel de soporte que el resto de .NET Framework, donde se resolverán las vulnerabilidades de seguridad futuras.

Actualmente, solo MS podrá parchear y lanzar paquetes ASP.Core NuGet actualizados, con el árbol de interconexión de dependencias OSS no ayudará mucho aquí a menos que los 2.1 PR que reciban (post LTS) sean revisados, aceptados y liberado.

Al final, después de que se hayan discutido todos los detalles, la pregunta final que aún importa es:

¿Podemos seguir ejecutando nuestros sistemas existentes en ASP.Core / FX?

Técnicamente será posible, pero sin garantías de que se resolverán los errores críticos / vulnerabilidades de seguridad en el futuro, la recomendación se ha convertido en NO, dejando al ecosistema externo afectado absorbiendo el dolor de esta decisión.

Si ASP.NET Core va a ser solo .NET Core, ¿cómo deberíamos sentirnos acerca de todo el asunto de .NET Standard?

Si Microsoft no está apostando por él por razones (indudablemente válidas), ¿por qué deberíamos hacerlo?

¿Habrá bibliotecas exclusivas de .NET Core de primera clase y de última generación y bibliotecas estándar de .NET menos avanzadas y "más simples"?

Esto parece matar el impulso para mejorar cualquier plataforma que no sea .NET-Core.

Ojalá alguien pueda demostrarme que estoy equivocado y aliviar mis preocupaciones.

Hola,
Veo el valor de seguir adelante y me encanta, pero veo 3 problemas principales sobre esta decisión:
1) netstandard será un ciudadano de segunda clase si nadie dentro de microsoft construye algo difícil con él, si ustedes no hacen la prueba interna, ¿cómo pueden pedirle a otros desarrolladores que lo hagan? Hoy en día, los autores de bibliotecas tienen que trabajar muy duro, el soporte no mejorará si las personas internas no usan el estándar.
2) Es valioso ejecutar aspnet core en otros tiempos de ejecución.
3) Hay un valor en el software que se ejecuta en tiempos de ejecución antiguos (con una dependencia que nunca se tocará) que no debe descartarse a la ligera.

Luego está la comunicación: creo que a todos les encantaría un tiempo de ejecución .net que se ejecute en todas partes, pero eso es una utopía para el futuro previsible y netstandard se creó como sustituto. Desde mi punto de vista, cada proyecto que no tiene como objetivo netstandard sino una plataforma, es un paso que no va en la dirección de esa visión.
Está claro que .net framework está en modo de mantenimiento, .netcore tomará su lugar (dejando un cadáver atrás) y mono se ejecutará en los dispositivos, aot story y CoreRT no buscan avanzar.

Con netcore 3.0 está haciendo dos cosas a la vez: soportar cargas de trabajo de escritorio y "decirle a la gente que salte de inmediato para mantenerse relevante". Creo que esto necesitará un acto de fe por parte de los desarrolladores y es demasiado optimista porque todos saben que muchos proyectos no se migrarán debido a algunas dependencias faltantes, que probablemente se agregarán en futuras versiones 3.1 / 3.2 en 1-2 años ( muy cerca de los 3 años LTS de 2.1). Mientras tanto, los desarrolladores que quieren ser relevantes están bloqueados para usar los bits 3.0 debido a dependencias sobre las que no tienen control.

¿Será posible posponer esta decisión después de que la gente la haya probado y vea las implicaciones reales?
¿Es posible tener aspnet core compilado para netstandard y netcoreapp como está prescribiendo a los autores de bibliotecas? Está bien tener un rendimiento degradado ejecutándose en .net framework 😄

Roslyn ahora se ejecuta en .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

¡Eso ciertamente cuenta como algo difícil!

@davidfowl

Creo que esto va a comenzar a limitar severamente las opciones para el desarrollo futuro de los sistemas .Net Framework que no pueden migrar por varias razones, ya que la comunidad está cambiando sus esfuerzos a ASP.Net Core.

Por ejemplo, Identity Server ya se ha trasladado a ASP.Net Core y la publicación reciente sobre el futuro de SignalR indicó, como era de esperar, que ASP.Net Core SignalR será el enfoque futuro del esfuerzo de desarrollo, con ASP.Net SignalR en modo de mantenimiento, lo que en el momento indicado, admitirá .Net Framework y .Net Core y espero que esta sea una tendencia que seguiremos viendo.

Sé que el soporte LTS para ASP.NET Core ya se estableció en 3 años, pero para la implementación local se necesita un ciclo de vida más largo ya que tenemos que brindar soporte en este sentido (4 años) a nuestros clientes.
Durante este período, necesitamos poder lanzar parches que incluyan correcciones de seguridad sin cambios importantes en la aplicación. Esto es para mantenernos en línea con los procesos de control de cambios de nuestros clientes que requerirían extensas pruebas de aceptación por parte de los usuarios para cambios más importantes y para que no tengamos que hacer cambios importantes, como la migración a una versión más nueva en las versiones que están en modo de mantenimiento. .

¿Existe alguna posibilidad de que cambie la política LTS? algo así como la estrategia de Ubuntu de una versión LTS cada 2 años con 5 años de soporte, aunque pediría 6 para permitir que la versión actual tenga más de 3 años de soporte mientras se realiza el trabajo para migrar a la nueva versión.

Entiendo que se ha mencionado el soporte extendido, pero supongo que esto es algo que cada uno de nuestros clientes tendría que comprar, lo cual no creo que sea aceptable si su instalación inicial (después del desarrollo, proceso de ventas, UAT, etc.) en el mejor de los casos tiene 2 años de soporte.

Además, tengo curiosidad por saber cómo tratar la biblioteca .netstandard en .netcore 3.0 veces.
El lema de .netstandard es "Una biblioteca para gobernarlos a todos".
Antes de esto, parece que significa todo.
Después de esto, parece que significa un poco.

Solo para mostrar cuántas consecuencias crea esta decisión, ¿qué pasa con Blazor? ¿Dejará de basarse en netstandard? ¿Deberíamos esperar eso también?

¿Alguien puede aclarar esto?

Entonces, ¿es la recomendación para bibliotecas como Newtonsoft.Json (que pueden beneficiarse de un alto rendimiento) cambiar a .NET Core en lugar de .NET Standard? No veo mucha diferencia entre ese tipo de biblioteca y ASP.NET Core. Incorporamos servicios REST en aplicaciones más grandes, algunas de las cuales pueden moverse fácilmente a .NET Core y otras no.

Según tengo entendido, la recomendación para las bibliotecas es apuntar a .NET Core 3 y .NET Standard 2.x si desea obtener las ventajas de las nuevas API pero no desea perder audiencias.

Según tengo entendido, la recomendación para las bibliotecas es apuntar a .NET Core 3 y .NET Standard 2.x si desea obtener las ventajas de las nuevas API pero no desea perder audiencias.

Pensé que el camino por delante era estándar en todas partes , y actualmente, estamos en una transición. Pero con un movimiento como este, otros seguirán (o necesitarán) seguir y volvemos a la orientación múltiple.

.NET Framework y .NET Core cumplen la misma función, por lo que creo que se espera que ASP.NET Core no se ejecute en .NET Framework algún día, ya sea ahora o más tarde.

Sin embargo, veo un gran problema al no ejecutarse en .NET Standard X . Para ser honesto, no necesito asp.net core para ejecutar en xamarin o unity, pero es bueno poder decir que podría, es solo otro conjunto de bibliotecas que se ejecuta en la plataforma .NET. Al romper, estamos obteniendo una integración más estrecha entre .NET Core y ASP.NET Core y me temo que por .NET Core 4.5 estamos condenando Microsoft.AspNetCore y @davidfowl iniciando DNX 2.0.

Por otro lado, .NET Standard definitivamente no es un lugar para experimentar y es difícil hacer las cosas correctamente, entonces, ¿podemos conseguir un compromiso? ¿Sería factible tener ASP.NET Core orientado actualmente solo a .NET Core, pero versiones LTS dirigidas a .NET Standard? Si una API no encuentra su camino hacia .NET Standard, ¿realmente vale la pena usarla?

También podríamos ver esto de la manera que probablemente pretenda:

• .NET Core es para consola / web / escritorio de terceros (estándar + api específico web)
• Unity es para juegos (estándar + api específica del juego)
• Xamarin es para dispositivos / escritorio (estándar + dispositivo / api específica de escritorio)

Pero, ¿quién impulsa .NET Standard? Como ha dicho antes, los recursos son limitados, por lo que sin tener una necesidad real de impulsar las cosas (que en mi propuesta recaerían en el equipo central de .net core / asp.net al necesitar cambios para lanzar LTS), me temo. NET Standard quedará obsoleto rápidamente.

Para aquellos que no prestan atención, parece que .NET Standard 2.1 acaba de dejar de admitir .NET Framework.

Dado que muchas de las adiciones de API en .NET Standard 2.1 requieren cambios en el tiempo de ejecución para que sean significativas, .NET Framework 4.8 permanecerá en .NET Standard 2.0 en lugar de implementar .NET Standard 2.1. .NET Core 3.0, así como las próximas versiones de Xamarin, Mono y Unity se actualizarán para implementar .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Por mucho que me duela ver que .Net Framework obtiene Silverlight-ed, lo que me importa con respecto a ASP.NET Core es que debería apuntar a .NET Standard .

Como probablemente sea una de las aplicaciones de referencia más grandes del ecosistema Core / Standard, creo que ASP.NET Core tiene la responsabilidad de ser un campeón de .Net Standard y todas las cosas buenas que representa.

Creo que es razonable que ASP.NET Core solicite cambios en el estándar que luego se implementan en .NET Core.

De la misma manera que Span, etc.está disponible en .Net Framework a través de un paquete nuget, creo que es razonable que si ASP.NET Core necesita / quiere depender de algo que aún no está en .Net Standard, esa dependencia debe incluirse en a través de un paquete nuget.

Finalmente, espero (contra toda evidencia en contrario), que habrá un .Net Framework 5.0 que apuntará a .Net Standard 3.0+ y será una instalación en paralelo con 4.x.

Finalmente, espero (contra toda evidencia en contrario), que habrá un .Net Framework 5.0 que apuntará a .Net Standard 3.0+ y será una instalación en paralelo con 4.x.

Sí exactamente. Esto es lo que he estado diciendo durante años: la arquitectura CLR 2.0 nos ha servido bien durante mucho tiempo, pero está empezando a hacer mucho, y es hora de una actualización fundamental del mismo tipo que lo fue Generics. Puede resultar algo doloroso realizar los cambios necesarios, pero son necesarios; Se necesita actualizar con una funcionalidad nueva y más poderosa de la misma manera que se necesitaban los genéricos, y posponerlo solo empeorará el dolor, no lo disminuirá, cuando finalmente suceda.

Eso es exactamente lo que es .NET Core, y este hilo es el dolor temporal que se experimenta.

@terrajobst dijo que no sucederá: ver hilo: https://twitter.com/terrajobst/status/1059525279431815168?s=19

@gulbanana
Sí, excepto dos cosas.

1. Core no es una actualización de Framework; es un concepto paralelo. Hay tantas cosas realmente fundamentales que no puede hacer, muchas de las cuales, como AppDomains, nos dicen que es poco probable que sucedan. ¡Por el amor de Dios, todavía no tenemos un Reflection.Emit funcione! Teniendo en cuenta lo común que es esto en los compiladores y las herramientas de generación de código, uno pensaría que habría sido literalmente una de las primeras prioridades y, sin embargo, ¡aquí estamos 4 años después y no funciona! Esto hace que sea muy difícil tomar en serio la noción de "Core como reemplazo / actualización de .Net Framework".
2. Core no está actualizando radicalmente el tiempo de ejecución, estilo CLR 2.0. En "¿Qué propuestas de idioma se beneficiarían de los cambios de CLR?" Tenemos una gran lista de la comunidad de funciones faltantes que la gente considera importantes, que CLR no puede soportar (o al menos no puede soportar sin problemas masivos y desagradables para evitar las limitaciones de CLR), generalmente debido a funciones faltantes. en el sistema de tipos. ¿Cuántas de las propuestas en ese tema están siendo tomadas en serio por el equipo Core? ¿Y cuántos de los demás han sido descartados porque las personas que ejecutan el proyecto no quieren tener que actualizar el tiempo de ejecución? Estamos recibiendo DIM y ... ¿algo más? ¿Nada en absoluto?

Entonces no, .NET Core no es un .NET Framework actualizado que realiza las actualizaciones CLR tan necesarias, porque no es un .NET Framework actualizado y el equipo del proyecto está haciendo todo lo posible para evitar actualizar el CLR siempre que sea posible. Es, literalmente, exactamente lo contrario de eso.

Por el amor de Dios, todavía no tenemos ni una Reflexión que funcione. Teniendo en cuenta lo común que es esto en los compiladores y las herramientas de generación de código, uno pensaría que habría sido literalmente una de las primeras prioridades y, sin embargo, ¡aquí estamos 4 años después y no funciona! Esto hace que sea muy difícil tomar en serio la noción de "Core como reemplazo / actualización de .Net Framework".

Sería genial comprender qué no funciona. ASP.NET Core y EF usan la emisión de reflexión en un par de lugares, por lo que no soy consciente de las grandes brechas. ¿Puedes dar más detalles aquí?

Ha estado ahí desde al menos 2.0 .. iirc incluso 1.0 tenía DefineDynamicAssembly, aunque tal vez no todo el conjunto de cosas de emisión.

También me resulta difícil tomarme en serio la idea de que están evitando actualizar el CLR. ¿Has visto el gran volumen de trabajo que se está realizando? https://github.com/dotnet/coreclr/commits/master
Hay características de lenguaje programadas para C # 8 que solo funcionarán en .NET Core debido a los cambios de CLR también. Muchas de estas objeciones parecen ser información antigua (lo cual es bastante justo, ya que los planes de Microsoft han cambiado rápidamente a veces ...)

@davidfowl

Sería genial comprender qué no funciona. ASP.NET Core y EF usan la emisión de reflexión en un par de lugares, por lo que no soy consciente de las grandes brechas. ¿Puedes dar más detalles aquí?

Es cierto que han pasado unos meses desde que verifiqué, por lo que esto podría haber cambiado recientemente, pero hasta donde yo sé, es posible crear un nuevo ensamblaje en la memoria, pero no guardarlo en un disco debido a razones misteriosas que involucran la generación de Archivos PDB, lo que hace que Core sea inútil para los encargados del mantenimiento del compilador como yo.

¿Esto ha sido arreglado? Me encantaría saber que tiene ...

@gulbanna

También me resulta difícil tomarme en serio la idea de que están evitando actualizar el CLR

Lo que dije es que están evitando actualizar radicalmente el CLR de la misma manera que la actualización 2.0 (genéricos).

Específicamente, parecen estar evitando activamente cualquier cambio que agregue nuevos tipos fundamentales de tipos al sistema de tipos (formas, metaclases, DU, etc.) o nuevas instrucciones IL al conjunto de instrucciones.

@masonwheeler

Es cierto que han pasado unos meses desde que verifiqué, por lo que esto podría haber cambiado recientemente, pero hasta donde yo sé, es posible crear un nuevo ensamblaje en la memoria, pero no guardarlo en un disco.

Mirando https://github.com/dotnet/corefx/issues/4491 (donde ha comentado en el pasado), creo que la situación sigue siendo la misma. Aunque creo que faltar una característica específica (incluso si es importante) es bastante diferente de "todavía no tenemos un Reflection.Emit funcione".

lo que hace que Core sea inútil para los mantenedores de compiladores como yo

¿Cómo es Reflection.Emit útil para un escritor de compiladores? Pensé que se limitaba a producir ensamblados para el marco actual, por lo que no se podía usar para crear, por ejemplo, ensamblajes estándar .Net en absoluto, lo que creo que sería una limitación significativa para cualquier compilador.

Lo que dije es que están evitando actualizar radicalmente el CLR de la misma manera que la actualización 2.0 (genéricos).

Creo que ha habido cierta inercia para no cambiar el CLR, aunque también hay muy buenas razones para ello, especialmente si se considera que tales cambios son más útiles y menos dolorosos cuando una plataforma es joven.

Creo que DIM es una señal de que esto podría estar cambiando, pero todavía no esperaría nuevas instrucciones IL cuando los intrínsecos JIT a menudo pueden funcionar igual de bien, o nuevos tipos de tipos cuando se pueden codificar razonablemente en el sistema de tipos existente.

@svick

Aunque creo que faltar una característica específica (incluso si es importante) es bastante diferente de "todavía no tenemos un Reflection.Emit que funcione".

Si tuvieras un editor de texto que te permitiera escribir archivos de texto pero no guardarlos, ¿no dirías que no funciona?

¿Cómo es Reflection.Emit útil para un escritor de compiladores?

Ha funcionado bien hasta ahora. Y hasta donde yo sé, es el único backend del compilador disponible que le permite generar nuevos ensamblados y guardarlos o generar nuevos ensamblados en la memoria y ejecutarlos.

todavía no esperaría nuevas instrucciones IL cuando los intrínsecos JIT a menudo pueden funcionar igual de bien

Claro, pero ¿qué pasa con los casos en los que no lo harán?

o nuevos tipos de tipos cuando se pueden codificar razonablemente en el sistema de tipos existente.

¿Ha visto la propuesta para implementar Shapes dentro del sistema de tipos existente? No tiene nada de razonable; es una tontería grande y fea de principio a fin. (Nada en contra de las personas que lo inventaron; tiene que ser así, dadas las limitaciones con las que trabaja.) ¡Y buena suerte al implementar metaclases sin soporte de nivel CLR!

Necesitamos un CLR actualizado para desarrollar funciones de nivel superior de manera eficiente, y nadie está trabajando para lograrlo en Core.

¿Alguien del equipo de .net puede aclarar cuál es su recomendación para las implementaciones en las instalaciones? ¿Es simplemente "usar asp.net regular"? Me refiero específicamente a los comentarios de

¿Afecta esto a las bibliotecas de soporte Microsoft.Extensions.* ? Específicamente Microsoft.Extensions.Logging y Microsoft.Extensions.Configuration .

Tenemos una gran base de código que comparte una API central común. Algunas son WinForms, otras ASP.NET clásico, algunas WCF, etc. Y las aplicaciones más nuevas son .NET Core (no actualmente, pero eventualmente cuando hemos portado nuestras bibliotecas centrales al estándar .NET)

Hemos elegido basar nuestra API de configuración y registro principal en las abstracciones de las bibliotecas mencionadas anteriormente.

Entonces, me pregunto si es seguro usarlos en una API estándar de .NET a la que hacen referencia tanto .NET Core como .NET Framework (4.7.2+) o si también pueden comenzar a usar características exclusivas de .NET Core.

@mvestergaard Como se menciona en el anuncio en sí :

Los paquetes

Y en el comentario de @benaadams en este hilo :

No todas las bibliotecas se están moviendo solo a .NET Core (por ejemplo, Microsoft.Extensions.* se quedan como .NET Standard)

@mvestergaard, como ya se mencionó, estamos mirando nuestra política LTS para determinar si cosas como soporte extendido, períodos más largos, un período de "modo de mantenimiento", etc. son útiles y cómo se verían. También estamos trabajando para ver si podemos hacer que la sincronización de los nuevos trenes LTS sea más predecible (un modelo que vemos y realmente admiramos de otras pilas que tienen un modelo LTS).

El mayor problema que tengo con esto es no poder usar los paquetes maduros que solo se pueden usar cuando se apunta a .NET Framework o aquellos que simplemente no estaban disponibles fuera de .NET Framework como los que necesitaban System.Drawing y GDI +.

Parece que el último escenario será compatible con .NET Core 3.0, sin embargo, AFAICT, aún nos perderemos el uso de bibliotecas maduras y estables que solo se pueden usar en .NET Framework.

Un ejemplo de eso es Entity Framework . Tendremos que cambiar al EF Core inmaduro, que parece estar muy lejos de manejar todos los escenarios complejos que el EF completo podría y que recurre a la evaluación del cliente en memoria a sus espaldas para ocultar ese problema que causa el rendimiento. problemas .

Un ejemplo de eso es Entity Framework. Tendremos que cambiar al EF Core inmaduro que parece estar muy lejos de manejar todos los escenarios complejos que el EF completo podría ...

EF6 será compatible con .NET Core 3.0 como lo explicó @DamianEdwards en esta semana ASP.NET Community Standup - 6 de noviembre de 2018 - ASP.NET Core 3.0 Features at 19:06

@benaadams ¡ eso es una gran noticia! bastante oscuro para un asunto tan importante! :) Buen trabajo encontrando eso. Encontré otra mención aquí .

@SaebAmini : puede usar System. Sobre la base de .NET Core. Consulte System.Drawing.Common y Scott Hanselmans Blogpost: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ,

Y antes de que existiera CoreCompat.System.Drawing , como un puerto de System.Drawing de Mono.

¿Falta alguna característica para su caso de uso cuando se ejecuta en .NET Core?

@TsengSR mi escenario específico que nos hizo apuntar a .NET Framework fue:

1. La necesidad de utilizar el paquete Microsoft Solver Foundation, solo disponible en .NET Framework.
2. Un paquete de generación de imágenes de códigos de barras que usaba System.Drawing.
3. La necesidad de utilizar EF6.

Eso fue hace alrededor de un año.

@SaebAmini : Como se mencionó anteriormente, la compatibilidad con EF6 viene en .NET Core 3.0, System.Drawing ya está allí (y antes de eso, el paquete CoreCompat existía y puede haber funcionado en su caso) y para Microsoft Solver Foundation Package, después ejecutando Portability API Analyzer:

Vea cómo utilizar el analizador de portabilidad

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (descárguelo y abra el HTML, no encontré otro lugar para colocarlo).

Muestra una compatibilidad del 97,93% con .NET Core 2.0 + Platform Extensions (que se lanzó hace aproximadamente un año) y enumera las API incompatibles, que en su mayoría están relacionadas con System.Web que estaba en desuso y System.ServiceModel / System.Data.Linq .

Ahora, no usé este paquete antes, y no estoy seguro de por qué un solucionador necesitaría acceso a System.Web y HttpContext o System.ServiceModel , pero si no no necesita ninguna de estas tesis (y sabe que su caso de uso no llama a estas API), las posibilidades son bastante altas de que pueda usarlo en .NET Core 2.0 / 2.1 + Platform Extensions o en .NET Core 3.0, incluso si no apunta específicamente al apodo de destino netstandard o netcoreapp20 .

Entonces, técnicamente, las posibilidades eran buenas de que hubiera migrado su aplicación a .NET Core 2.0 + Platform Extensions hace un año, si EF Core 2.0 podría haber cubierto las necesidades de sus aplicaciones (por supuesto, eso requiere algo de trabajo de migración y actualizaciones para funcionar con EF Core 2.0).

Sí, se necesita un poco más de trabajo para analizar las bibliotecas en cuestión o la función para el marco de reemplazo (EF6 -> EF Core 2.0 / 2.1), pero está lejos de ser imposible. No creo que la gente pueda o deba esperar trasladar todo su código 1: 1 a ASP.NET Core sin hacer ningún cambio (fuera de ASP.NET Core).

Solo deseaba que fuera más obvio mostrar la compatibilidad de API, como con una "insignia" (compatible con .NET Core 3.0) y / o un informe detallado de compatibilidad de API en algún lugar de la página de nuget para hacerlo más obvio que tener que descargar el paquete. y luego ejecutarlo a través del analizador de paquetes.

Creo que este anuncio habría sido mejor recibido si enfatizara cuánto más compatible se ha vuelto .NET Core. Hay dos factores que permiten mover ASP.NET Core fuera de .NET Framework:
1) Reducir la necesidad de .NET Framework, hacer que los departamentos heredados estén disponibles y mejorar la interoperabilidad, etc.
2) Aumentar los beneficios de .NET Core, las características y el rendimiento y reducir la carga de mantenimiento

¡El factor 2 ocupa un lugar preponderante en la mente de las personas que tienen que crear ASP.NET! Sin embargo, hay pocas ventajas desde el punto de vista del usuario. La gente tiene algo que funciona y su máxima prioridad es que siga funcionando. La buena noticia es que, en la mayoría de los casos, lo hará.

Estoy de acuerdo con @gulbanana. .NET Core ahora es mucho más compatible con .NET Framework. De hecho, pude lanzar aplicaciones de .NET Framework bastante grandes simplemente cambiando el nombre de .exe a .dll y agregando algunos .DLL faltantes a la ruta de prueba.

El progreso en las herramientas de línea de comandos dotnet es impresionante. Especialmente la adición de herramientas globales de .NET Core. Hacen que el desarrollo sea muy sencillo.

La compilación AOT con crossgen es genial. Puedo seguir y seguir.

tl / dr .NET Core es realmente impresionante hoy en día.

Lo que falta:

• Falta la estrategia actual de comunicación con el cliente. Los clientes se sienten muy decepcionados cuando escuchan que su plataforma .NET favorita está siendo fragmentada por Microsoft. Debería ser más claro aquí. Por ejemplo, sería un enfoque mucho mejor anunciar directamente a las personas la implementación de .NET singular, altamente compatible, rápida y preparada para el futuro. Como .NET Core, el futuro de .NET, va a resolver la mayoría de sus problemas, productividad, creatividad, abrir nuevos nichos de mercado, etc.
• Incluso más estrategias de compatibilidad listas para usar
• Interfaz gráfica del usuario. Me refiero a que las herramientas de línea de comandos dotnet son geniales, pero actualmente tenemos que usar editores de texto y consolas adicionales para trabajar en casi todos los proyectos en formato .NET SDK. La interfaz de usuario de Visual Studio falta a este respecto. Esto pone grandes barreras a muchas personas que tienen el hábito de apuntar y hacer clic. Esto también debería mejorarse
• Soporte LTS

@TsengSR Gracias por tu respuesta detallada, compañero, ¡excelente información! en ese momento, el uso del paquete de código de barras no funcionaría, ya que el proyecto simplemente no compilaría quejas sobre diferentes objetivos. Quizás debería intentarlo de nuevo. (a menos que quisieras compilarlo nosotros mismos y heredarlo un poco)

Realmente no me preocupa el esfuerzo si eso es razonable. Mi principal preocupación era quedarme alto y seco sin opción con EF siendo el principal bloqueador y eso aparentemente no va a suceder. Es bueno ver que ha sido bien pensado. Aunque estoy de acuerdo con @gulbanana en que estos se pueden publicitar mejor.

Aquí hay muchos problemas combinados. Mi 2 centavo personal es que dejar atrás .NET Framework no es tan importante. Sin embargo, lo que es preocupante es la falta total de apoyo aparente para los esfuerzos de estandarización (.NET Standard). Seguro, probablemente no quiera ejecutar ASP.NET Core en, digamos Unity hoy, pero no se trata de hoy. Habrá un año o dos en el futuro, cuando podría llegar otro tiempo de ejecución .NET, me gustaría poder decir "Sí, tan pronto como SuperNetRuntime admita .NET Standard 2.2, podemos ejecutar ASP.NET Core 3 en él". ...

¿Existe alguna posibilidad de "recopilar" al menos todos los cambios necesarios en .NET Core 3 para ASP.NET Core 3 y reenviarlos al grupo de trabajo de .NET Standard como sugerencias?

Hola, los paquetes publicados para .NetStandard 2.0 o .NetCore 2.0 continuarán funcionando con .NetCore 3.0. Por ejemplo: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Si hay compatibilidad con versiones anteriores, entonces pasar a .NetCore 3.0 es adecuado, pero si no hay soporte para versiones anteriores, entonces es realmente inútil a menos que todos se pongan al día.

.NetFramework tiene un historial de compatibilidad, incluso puede usar .NetFramework 2.0 en las últimas versiones, por lo que es necesario mantener algo para .NetCore también al menos 2.0 a 3.0, etc.

Gracias

Hola, los paquetes publicados para .NetStandard 2.0 o .NetCore 2.0 continuarán funcionando con .NetCore 3.0. Por ejemplo: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Sí, .NET Core 3.0 mantiene la compatibilidad con versiones anteriores, por lo que puede usar las bibliotecas .NetStandard 1.0 -> .NetStandard 2.1 y .NetCore 1.0 -> .NetCore 2.2

@benaadams entonces eso es bueno. ¿También funcionará .net framework dll si no usan ninguna api faltante?

Gracias

¿También funcionará .net framework dll si no usan ninguna api faltante?

Sí, aunque es más seguro usar una biblioteca .NET Standard, como sabe, que funcionará en .NET Core (y en Mono, Xamarin, Unity, UWP)

Además, el uso del Paquete de compatibilidad de Windows agrega otras 20.000 API además de .NET Standard 2.0 para acercar .NET Core a .NET Framework (lo que puede hacer con .NET Core 2.1); y .NET Core 3.0 es el más compatible hasta ahora con EF6 (cross-plat), y en Windows: WinForms, WPF, COM Interop, etc.

Hola amigos,
Con el fin de brindarles a los clientes un trampolín razonable en su camino hacia la migración de aplicaciones a ASP.NET Core en .NET Core, ampliaremos el soporte y el servicio para ASP.NET Core 2.1.x en .NET Framework para que coincida con el soporte actual. política para los otros marcos ASP.NET basados ​​en paquetes , por ejemplo, MVC 5.x, Web API 2.x, SignalR 2.x. Esto significa que los paquetes relacionados con ASP.NET Core 2.1.x (lista detallada final por determinar) serán compatibles de forma indefinida, más allá del período LTS de 3 años para el entrenamiento de .NET Core 2.1 en general.

Noticias excelentes. Gracias por escuchar a sus clientes.

Nos llevará mucho tiempo migrar nuestra antigua aplicación MVC, ya que hemos estado en MVC desde CTP3 y hemos utilizado casi todos los puntos de extensión. Esto cubre nuestras preocupaciones.

@DamianEdwards ¡ Qué buenas noticias! Sin embargo, me pregunto, ¿está esto arreglado en 2.1.xo se actualizará a 2.2.x si termina convirtiéndose en una versión LTS? Se ha realizado un gran esfuerzo en la versión 2.2 y aún no se ha lanzado. Y dado que continúa con compatibilidad netstandard y funciona bien en el marco completo, sería una especie de desperdicio omitir esto por completo para el soporte extendido.

@poke, aunque entiendo su preocupación, tenemos que trazar una línea en algún lugar, y en este caso creemos que es mejor mantener la versión alineada con la LTS que la precede. Esta es la compensación que los clientes deben decidir por sí mismos al elegir entre un tren LTS o un tren actual. Las nuevas funciones no llegan a LTS ya que se refieren a la estabilidad. La retroalimentación fue para apoyo a más largo plazo y ya tenemos un tren para eso, así que esta es una extensión del tren. 2.2 no se convertirá en LTS.

@DamianEdwards Sí, lo entiendo, gracias por tu respuesta. Solo estaba preguntando porque el último comentario sobre esto fue que aún no se ha decidido , así que solo quería saber si este soporte extendido continuaría sif 2.2 se convirtiera en LTS.

Y creo que es lo suficientemente importante destacar esto para que las personas no actualicen sus aplicaciones marco a 2.2 si tienen que depender de este soporte extendido. De lo contrario, tendrán que volver a bajar de categoría.

Las nuevas funciones no llegan a LTS ya que se refieren a la estabilidad.

Sin embargo, eso realmente no coincide con las decisiones anteriores de LTS.

@dar un toque

Sin embargo, eso realmente no coincide con las decisiones anteriores de LTS.

Esto me confundió. ¿En qué manera? ¿Se refiere al hecho de que se agregó 1.1 al tren 1.x LTS? Si es así, esa fue una anomalía de nuestro primer tren de lanzamiento que no se repetirá. En el futuro, nuestra intención es ser más coherentes con los lanzamientos que se convierten en LTS frente a los actuales (es decir, de dónde obtengo estabilidad frente a características).

@DamianEdwards Me refería principalmente al hecho de que cada lanzamiento hasta ahora ha sido un lanzamiento de características importantes, y cada decisión de LTS generalmente se tomó en retrospectiva (al menos públicamente).

@poke OK. Bueno, hasta ahora hemos tenido 4 lanzamientos (1.0, 1.1, 2.0, 2.1) y el quinto llegará en breve (2.2). De ellos, solo 1.0 y 2.0 estaban destinados inicialmente a ser LTS, pero debido a una serie de factores (principalmente relacionados con que somos realmente nuevos en hacer ingeniería de esta manera 😉) terminamos con 1.0, 1.1 y 2.1 siendo los trenes LTS. 2.0 y 2.2 son (fueron, serán) versiones actuales. En esta etapa, es casi seguro que 3.0 también será Actual (lo que hará que 2.2 entre en el período de "gracia" actual de 3 meses) antes de que 3.1 se convierta en el LTS del tren 3.x. Nuestra esperanza es que después de eso, el patrón y la cadencia serán más consistentes (nos encantaría) pero hasta ahora nuestra bola de cristal nos ha fallado.

@DamianEdwards ¡ Gracias por las ideas! 😄 (Por cierto. No estaba tratando de discutir sobre esto, solo tenía curiosidad;))

Un problema mayor para nosotros son las nuevas API REST alojadas en proceso por aplicaciones heredadas que no es probable que salgan de .NET Framework en el corto plazo. ¡Al menos sabemos que no debemos avanzar más allá de las bibliotecas compatibles con .NET Standard 2 y ASP.NET Core 2.1 ahora! Es bueno que el período LTS se extienda

Hola a todos, una pregunta rápida: ¿Qué pasa con aquellos de nosotros que consumimos paquetes nativos en forma de C ++ / CLI? ¿Será compatible con .Net Core en el corto plazo, o estamos huérfanos a menos que hagamos una reelaboración masiva para usar P / Invoke?

@lokitoth : esa sería una buena pregunta para la gente de https://github.com/dotnet/core porque es más general que solo ASP.NET Core.

@lokitoth sí, eso será compatible, consulte https://github.com/dotnet/coreclr/issues/18013

oO ¿Cómo me perdí eso?

Bien, entonces no tengo problemas con esto.

@ danroth27 ¿Podría decirnos el impacto de este problema para Client-Side-Blazor?

@Slkebe No espero ningún impacto. Las aplicaciones Blazor del lado del cliente son independientes del tiempo de ejecución o plataforma que decida ejecutar en el servidor.

@ danroth27 Según tengo entendido, Blazor del lado del cliente puede ejecutarse en mono porque los paquetes Microsoft.AspNetCore.* dependientes tienen como objetivo netstandard.
¿Me estoy perdiendo de algo? Blazor tiene que seguir apuntando a Microsoft.AspNetCore.* 2.1.X?

@Slkebe Las bibliotecas Blazor del lado del cliente solo dependen de los componentes que continuarán apuntándose a .NET Standard (como Microsoft.Extensions. * Y amigos). Las partes del lado del servidor de Blazor que dependen de ASP.NET Core se dirigirán a .NET Core como se describe en este número.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

¿Cuál es la decisión ahora? ¿Objetivo en .net estándar 2.1?

@ John0King No hay una nueva decisión.

¡Esto es plátano! Plátanos

Simpatizo con su punto de vista.

Disculpas si esto ya se ha mencionado, pero ¿qué pasa con los casos de uso en los que solo quiero usar Kestrel + algún middleware como parte de una aplicación que no sea ASP.NET? ¿Tendré que extraer todo el árbol 3.0 (lo cual no es ideal, ya que mi caso de uso implica definir un SDK personalizado para los consumidores), o este caso de uso no es compatible con 3.x?

Actualmente estoy desarrollando una aplicación ASP.NET Core que se ejecuta en .NET Framework, debido a las bibliotecas incluidas. Estoy usando ASP.NET Core debido a sus capacidades de autenticación múltiple. Me siento engañado y bloqueado.

Estoy usando ASP.NET Core debido a sus capacidades de autenticación múltiple.

@FlorianGrimm ¿Qué específicamente? Microsoft.Owin proporcionó una funcionalidad de autenticación similar para ASP.NET 4.

Es una aplicación híbrida con un código fuente (.exe) que se ejecuta en las instalaciones y azure, que actualmente usa Windows auth, aad, basic auth y anonymous.

@FlorianGrimm ¿Qué dependencias de la biblioteca le impiden usar .NET Core?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom y Microsoft.SharePointOnline.CSOM.

Espero que el equipo de SharePoint termine
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
y encuentro otras opciones además de ilspy.

De cualquier forma, me gusta ASP.NET Core y espero que los otros equipos de Microsoft proporcionen más ensamblados .NET Core.

Periódicamente cerramos temas de 'discusión' que no se han actualizado en un largo período de tiempo.

Nos disculpamos si esto le causa algún inconveniente. Le pedimos que si todavía tiene un problema, registre un nuevo problema con información actualizada e investigaremos.