Frameworks

Qué es .NET Core y cómo evolucionó hacia .NET

.NET Core nació como una implementación multiplataforma y open source de .NET, diferenciada de .NET Framework. Permitió ejecutar aplicaciones en Windows, Linux y macOS y sentó la base de la plataforma que Microsoft continúa desarrollando actualmente.

La principal fuente de confusión es el nombre. Después de .NET Core 3.1 no apareció .NET Core 4: Microsoft pasó directamente a .NET 5 y eliminó “Core” de la denominación principal. El cambio reflejaba la continuidad de esa línea tecnológica, no el nacimiento de una plataforma completamente distinta.

Qué significa .NET Core hoy

¿.NET Core sigue existiendo? Como nombre principal, no. Las versiones que utilizaron oficialmente esa denominación llegaron hasta .NET Core 3.1. A partir de .NET 5, la evolución de esa línea pasó a llamarse simplemente .NET.

Esto explica por qué conceptos, herramientas y arquitecturas asociadas originalmente a .NET Core siguen formando parte del desarrollo actual. También es habitual encontrar Core en documentación histórica, repositorios antiguos o conversaciones técnicas aunque el proyecto utilice una versión moderna de .NET.

Sin embargo, el cambio de nombre no se aplicó a todo el ecosistema. ASP.NET Core y Entity Framework Core conservaron Core en su denominación para distinguirse de tecnologías anteriores con nombres similares. Encontrar esa palabra en una dependencia no significa, por tanto, que el proyecto utilice una versión antigua de .NET Core.

De .NET Core 3.1 a .NET 5 y versiones posteriores

.NET Core 3.1 fue la última versión que utilizó Core en el nombre de la plataforma. Microsoft explica en la documentación de .NET 5 que esta release fue la siguiente versión principal después de 3.1 y que se descartó tanto Core como la numeración 4.x para evitar confusiones con .NET Framework 4.x.

Desde entonces, la numeración continúa como .NET 5, .NET 6, .NET 7 y versiones posteriores. Para un desarrollador, la consecuencia práctica es que el cambio fue nominal: muchos conceptos y APIs de .NET Core continuaron evolucionando dentro de .NET.

Esta continuidad tampoco significa que .NET Framework se transformara en .NET moderno. Sigue siendo una implementación distinta del ecosistema, con su propio ciclo de mantenimiento y una fuerte vinculación con Windows. Esa diferencia es la que conviene entender antes de evaluar un proyecto existente o plantear su modernización.

.NET Core, .NET moderno y .NET Framework: diferencias prácticas

Los nombres pueden parecer etapas sucesivas de una misma tecnología, pero no conviene interpretarlos así. .NET Core y .NET moderno pertenecen a una misma línea de evolución, mientras que .NET Framework continúa como una implementación diferenciada con su propio ciclo de mantenimiento.

La elección tampoco se reduce a “nuevo frente a antiguo”. Un proyecto puede depender de tecnologías específicas de Windows, bibliotecas disponibles solo para .NET Framework o decisiones arquitectónicas que condicionen una modernización. Por eso, distinguir las plataformas sirve para entender tanto proyectos nuevos como aplicaciones que siguen en producción.

Qué cambia entre .NET moderno y .NET Framework

¿.NET Core y .NET Framework son lo mismo? No. Microsoft identifica actualmente .NET, antes denominado .NET Core, como su implementación principal. Es open source y está diseñada para múltiples plataformas y cargas de trabajo. .NET Framework, en cambio, es la implementación original y está vinculada a Windows.

Plataforma	Qué representa	Plataformas	Situación actual
.NET Core	Nombre utilizado hasta .NET Core 3.1	Windows, Linux y macOS	Línea histórica que continuó como .NET
.NET moderno	Evolución de .NET Core desde .NET 5	Multiplataforma, con cargas también específicas de cada sistema	Implementación principal y en desarrollo activo
.NET Framework	Implementación original de .NET	Windows	Continúa soportado y en mantenimiento

Que .NET moderno sea multiplataforma no significa que todas sus aplicaciones puedan ejecutarse en cualquier sistema. Tecnologías como Windows Forms y WPF también están disponibles en .NET actual, pero siguen siendo específicas de Windows. Del mismo modo, una aplicación puede utilizar APIs o dependencias que limiten las plataformas compatibles.

.NET Framework tampoco debe interpretarse como una plataforma abandonada. Microsoft mantiene versiones soportadas y no exige migrar una aplicación únicamente por utilizar .NET Framework. Para nuevo desarrollo, sin embargo, recomienda utilizar .NET.

Cómo interpretar estos nombres en proyectos y documentación

Cuando aparece .NET Core en un repositorio, una oferta técnica o una documentación antigua, el nombre por sí solo no basta para identificar la situación real del proyecto. Conviene comprobar la versión o el target framework antes de decidir si estamos ante una aplicación histórica o ante una referencia informal al .NET moderno.

También hay que separar el nombre de la plataforma del de sus tecnologías. Un proyecto que utiliza ASP.NET Core sobre una versión moderna de .NET no está ejecutándose sobre una versión antigua de .NET Core simplemente porque el framework web conserve Core en su nombre.

Esta distinción resulta especialmente importante al evaluar aplicaciones legacy. Pasar de .NET Framework a .NET moderno puede implicar revisar APIs, formato de proyecto, bibliotecas de terceros o tecnologías que no tengan equivalente directo.

Por eso, antes de plantear una actualización conviene identificar la plataforma y versión que utiliza la aplicación. A partir de ahí pueden evaluarse soporte, dependencias y compatibilidad sin tomar decisiones basadas únicamente en que el proyecto incluya las palabras .NET, Core o Framework.

Qué revisar en proyectos .NET Core y aplicaciones legacy

Cuando un proyecto utiliza una versión antigua de .NET Core o .NET Framework, el nombre de la plataforma no basta para decidir qué hacer con él. Antes de plantear una actualización conviene identificar qué ejecuta la aplicación, qué dependencias necesita y hasta qué punto esas piezas siguen teniendo soporte.

También hay que separar mantenimiento y modernización. Un proyecto puede seguir funcionando correctamente y, aun así, acumular riesgo por versiones sin soporte, bibliotecas abandonadas o tecnologías difíciles de evolucionar. La decisión debe partir del estado técnico real, no de que aparezca .NET Core o .NET Framework en el repositorio.

Target framework, dependencias y soporte

El primer dato que conviene revisar es el target framework declarado por el proyecto. Permite saber para qué implementación y versión fue compilada la aplicación y orienta la revisión posterior de SDK, paquetes y compatibilidad.

A partir de ahí, un diagnóstico básico debería comprobar:

• El target framework y, si procede, los distintos targets utilizados por la solución.
• Qué versiones de SDK y runtime necesita el proyecto para compilarse y ejecutarse.
• Las dependencias NuGet y si mantienen versiones compatibles con el destino previsto.
• Si existen APIs específicas de Windows que puedan condicionar una modernización hacia .NET.
• El estado de soporte de la versión y de los componentes críticos.
• Qué cobertura ofrecen pruebas, despliegue y observabilidad para detectar problemas durante una actualización.

Todas las versiones que conservaron la denominación .NET Core, incluida .NET Core 3.1, están actualmente fuera de soporte. Encontrar uno de estos targets debería activar una revisión de mantenimiento, dependencias y posible ruta de modernización.

El soporte cambia con el ciclo de releases. A septiembre de 2026, la política oficial de soporte de .NET sitúa .NET 10 como LTS activa hasta noviembre de 2028, mientras .NET 8 y .NET 9 finalizan soporte el 10 de noviembre de 2026. Si un proyecto sigue en esta última versión, la pieza sobre novedades de .NET 9 permite contextualizar qué aportó esa release y su siguiente paso dentro del ciclo de soporte.

Cuándo mantener, modernizar o migrar un proyecto

¿Hay que migrar siempre una aplicación antigua? No necesariamente. Mantenerla temporalmente puede ser razonable si cumple sus requisitos operativos, sus dependencias siguen siendo viables y el coste de cambiar supera el riesgo de permanecer como está.

La modernización gana peso cuando aparecen versiones sin soporte, dependencias obsoletas, dificultades para desplegar o mantener el sistema, o limitaciones que frenan nuevas necesidades. En proyectos .NET Framework, la complejidad depende además del modelo de aplicación y de las tecnologías utilizadas.

Antes de decidir, conviene seguir una secuencia práctica:

1. Identificar plataforma, versión y target framework.
2. Revisar el soporte de runtime y dependencias.
3. Comprobar incompatibilidades y cambios necesarios.
4. Comparar el esfuerzo de modernización con el riesgo operativo de permanecer como está.
5. Preparar pruebas y rollback antes de modificar producción.

Para proyectos basados ya en .NET moderno, actualizar entre versiones suele concentrarse en target framework, dependencias y breaking changes. Pasar desde .NET Framework puede exigir además revisar el modelo de aplicación y tecnologías sin equivalencia directa. Esa diferencia debe marcar la estrategia de modernización.

Conclusiones

Entender qué es .NET Core hoy exige separar el nombre histórico de la plataforma actual. La línea que llegó hasta .NET Core 3.1 continuó como .NET a partir de .NET 5, mientras .NET Framework mantiene una evolución y un ciclo de mantenimiento propios.

Para interpretar un proyecto existente no basta con fijarse en que aparezcan las palabras Core, .NET o Framework. Conviene revisar target framework, runtime, dependencias, soporte y tecnologías específicas antes de decidir si mantener la aplicación, actualizarla o plantear una modernización más profunda.

Esa lectura evita decisiones basadas solo en nomenclatura o antigüedad y permite valorar cada proyecto por su situación técnica real, su horizonte de soporte y el coste de evolucionarlo.