Cómo garantizar el soporte a largo plazo de tu aplicación .NET

15/10/2020Artículo original

Con la aparición de versión 5 de .NET es un buen momento para reunir en un solo artículo toda la información sobre las versiones de .NET, la cadencia con la que aparecerán y las políticas de soporte que ofrece Microsoft para cada versión.

El sistema de versiones de .NET Core tiene una manera muy diferente de funcionar respecto a lo que era .NET Framework, así que si vienes del desarrollo de aplicaciones con .NET “clásico” o si estás empezando con .NET Core o .NET, te resultará de mucha ayuda comprender la periodicidad de los lanzamientos del framework, los tipos de soporte que existen y su ciclo de vida, para poder tomar las decisiones correctas sobre qué versión utilizar en cada caso, sobre todo si trabajas en una empresa u organización donde la estabilidad de soporte es importante.

Si necesitamos soporte técnico con .NET, tenemos dos opciones:

  • Soporte de la comunidad: básicamente documentación, foros, Stack Overflow, etc… El búscate la vida de siempre en el que nadie te garantiza una solución ni tampoco una respuesta, pero que la realidad es que es, el que utiliza casi todo el mundo.
  • El soporte oficial de Microsoft: Microsoft pone a tu disposición todo su poder de recursos humanos técnicos para ayudarte a solucionar el problema, con garantía de respuesta. Generalmente este es el que escogen las empresas y las corporaciones cuando el anterior no les da una solución.

Aunque solo vayas a utilizar el soporte de la comunidad, te interesa conocer los ciclos de vida de soporte de .NET, a pesar de pienses que no va contigo. El motivo es que no sólo se regula el soporte técnico directo que recibes de Microsoft, sino también el soporte que obtiene la propia plataforma para recibir actualizaciones y parches de seguridad.

En la propia página de descargas de .NET te indican siempre qué nivel de soporte tiene cada versión y hasta qué fecha dura, pero conviene conocer bien qué significa cada caso:

Vamos a verlo…

Tipos de versiones de .NET y su soporte técnico

Las versiones de .NET “tradicional” han utilizado lo que Microsoft denomina ciclo de vida fijo que, como su nombre lo indica, proporcionan un período fijo de soporte, que suele ser largo. Por ejemplo, 5 años de soporte estándar (incluidas las revisiones de seguridad y las que no están relacionadas con la seguridad) y otros 5 años de soporte extendido (solo correcciones de seguridad).

.NET Core y .NET adoptan lo que Microsoft llama ciclo de vida moderno , que es muy diferente ya que adoptan un modelo de soporte más corto y más frecuente.

Así, .NET Core / .NET incluye versiones principales (major), versiones secundarias (minor) y actualizaciones de servicio (parches/patches). Así, por ejemplo:

  • .NET Core 3.0 es una versión principal del producto.
  • .NET Core 3.1 es la primera versión secundaria después de la versión principal de .NET Core 3.0.
  • .NET Core 3.1.7 tiene una versión principal de 3, una versión secundaria de 1 y una versión de parche de 7, es decir, es el séptimo parche para .NET Core 3.1.
  Solución a la conexión sin identificar y pública en Windows Server

Desde una perspectiva del soporte oficial que da Microsoft al framework, existen 2 “pistas” de soporte para las versiones de .NET Core.

  • Las versiones “actuales” (current): estas versiones de .NET Core y de .NET tienen soporte oficial tan solo durante un período de 3 meses tras haberse lanzado la siguiente versión principal o secundaria.
  • Las versiones LTS (Soporte a largo plazo): a estas se les da soporte durante un mínimo de 3 años, o 1 año después de que se envíe la próxima versión LTS (lo que sea más tarde).

Vamos a verlo con ejemplos concretos:

Cuando salió .NET Core 3.0 en septiembre de 2019, se trataba de una versión “current”. En diciembre de ese mismo año salió .NET Core 3.1, una versión secundaria de la anterior, así que el soporte de .NET Core 3.0 dura hasta marzo de 2020, o sea, 3 meses después y se supone que deberías migrar a 3.1 lo antes posible para tener soporte, lo cual, al no ser una versión que rompa la compatibilidad, no debería suponer problema alguno.

Un ejemplo de LTS sería .NET Core 2.0, que se designó como LTS en agosto de 2018, así que se soporta durante 3 años como mínimo, es decir, hasta agosto de 2021. La siguiente versión LTS que apareció fue .NET Core 3.1, en diciembre de 2019 y se garantiza el soporte hasta al menos un año después, o sea, diciembre de 2020. Así que como agosto de 2021 es más tarde que diciembre de 2020, la fecha efectiva de fin de soporte de .NET Core 2.0 será agosto de 2021.

La finalización del soporte significa que, después de la fecha oficial de fin, Microsoft ya no lanzará más actualizaciones, parches ni dará asistencia técnica oficial para esa versión de .NET. Así que hay que tenerlas presentes porque antes de esta fecha tenemos que haber pasado nuestra aplicación a una versión que esté soportada.

Frecuencia de versiones en .NET Core/.NET

Las versiones de .NET Core y de .NET siempre alternan entre las versiones LTS y Current, por lo tanto, .NET Core 3.1 es una versión LTS, pero la siguiente versión .NET 5 es una versión “current” y su soporte oficial durará menos tiempo que el de .NET Core 3.1.

La siguiente versión LTS será .NET 6 en noviembre de 2021, y así sucesivamente: .NET 7 será current, .NET 8 será LTS…

  Mapbox: el SDK de mapas abierto

Las actualizaciones de mantenimiento, que se envían (casi siempre) cada mes, incluyen correcciones de seguridad, estabilidad, confiabilidad y compatibilidad y se adhieren a la versión menor anterior. Es decir, .NET Core 3.1.7 es a efectos de soporte lo mismo que .NET Core 3.1, por poner un ejemplo.

Así que, si vas a crear una aplicación nueva que quieres que esté varios años soportada en cuanto a problemas de seguridad, estabilidad, etc.., es mejor hacerla con .NET 3.1 que con .NET 5 si quieres tener ese soporte oficial y conseguir este tipo de actualizaciones.

¿Qué versión utilizan las aplicaciones cuando hay una versión nueva del runtime de .NET?

Las actualizaciones principales y secundarias se instalan en paralelo a las versiones anteriores. Las aplicaciones siempre quedan atadas a una combinación de versión mayor/menor específica, la utilizada durante el desarrollo. Es decir, si instalamos una versión nueva del runtime que, entre otras cosas, soluciona un bug o mejora una característica, no quiere decir que nuestra aplicación la empiece a usar automáticamente. O sea, la aplicación no usa automáticamente la versión principal/secundaria más reciente.

Por ejemplo, una aplicación que se compiló para .NET Core 3.0 no comienza a ejecutarse automáticamente en .NET Core 3.1 cuando lo instalamos, a pesar de que estén dentro de la misma versión principal. Lo que tendrías que hacer es volver a compilar la aplicación contra la nueva versión para asegurarte de que todo funciona correctamente. Una vez recompilada, entonces sí que usará la nueva versión.

Sin embargo, las actualizaciones de “parche”, sí que se tratan de manera diferente a las versiones principales y secundarias. Una aplicación creada para .NET Core 3.1 se dirige al tiempo de ejecución 3.1.0 de forma predeterminada, pero avanza automáticamente para usar una versión 3.1 más reciente. De esta manera tendremos un entorno de ejecución más seguro porque esas versiones de “parche” incluyen siempre correcciones de problemas de seguridad y de estabilidad, como ya hemos dicho.

Cómo funcionan las versiones del SDK de .NET

Ahora vamos a ver otro pequeño giro de tuerca…

Una cosa es el runtime de .NET, lo que se usa para ejecutar las aplicaciones, y otra diferente pero relacionada es el SDK de .NET, que es lo que se utiliza para crear las aplicaciones. Lo que comentábamos en el apartado anterior se refiere al runtime.

El control de versiones para el SDK de .NET (o sea, el Kit de desarrollo de software) funciona de manera algo diferente al del runtime de .NET.

Las actualizaciones del SDK de .NET a veces incluyen nuevas características o nuevas versiones de componentes como MSBuild o NuGet para alinearse con las nuevas versiones de Visual Studio. Estas nuevas funciones o componentes pueden ser incompatibles con las versiones que se envían en actualizaciones anteriores del SDK para el mismo valor de versión principal/secundario.

  C es el lenguaje de programación 'más verde', seguido de cerca por Rust: son los que consumen menos energía al ejecutar algoritmos

Así que, para versionar los SDK, existen lo que se llaman bandas de características, como una forma de diferenciar entre las actualizaciones de SDK. Las bandas de características se definen en el tercer número de sección y siempre van en alguna centena.

Por ejemplo, el primer SDK de .NET Core 3.1 fue 3.1.100. Esta versión corresponde a la banda de características 3.1.1xx. Así, las versiones 3.1.101 y 3.1.201 del SDK tienen dos bandas de características diferentes, mientras que 3.1.101 y 3.1.199 están en la misma banda de características.

Cuando tenemos instalado en la nuestra máquina el primer SDK de .NET Core 3.1, que es el 3.1.100, cuando sale la siguiente versión dentro de esa banda, la 3.1.101, la versión anterior de la misma banda se elimina automáticamente de la máquina porque son totalmente compatibles. Sin embargo, cuando sale el SDK 3.1.200, que es de otra banda diferente y por lo tanto incompatible, el anterior no se quita y coexisten los dos para poder crear aplicaciones para cada una de las bandas.

¿Y qué pasa con .NET “clásico”?

Como ya sabrás si sigues el blog de campusMVP, .NET 4.8 es la última versión importante que va a salir de la plataforma .NET “clásica”.

Si tiene aplicaciones creadas con .NET “clásico”, salvo que quieras sacar partido a alguna característica específica de .NET (como el hecho de que es multiplataforma) no merece la pena en general que intentes migrarla a .NET Core/.NET y te garantizas que va a funcionar durante muchos años en Windows ya que Microsoft la va a incluir con el sistema operativo en el futuro previsible, y por lo tanto seguirá dando soporte, correcciones y actualizaciones de seguridad. Así que su funcionamiento está garantizado.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad