Post original escrito por José María Aguilar en campusMVP

Seguro que todos los desarrolladores que trabajáis normalmente usando herramientas Microsoft habéis oído hablar bastante de .NET Core en los últimos tiempos. Incluso quizás muchos de vosotros habéis tenido oportunidad de trabajar con este nuevo framework y ya conocéis sus principales características y las bondades (e incluso algún que otro inconveniente) que ofrece sobre el ya clásico .NET Framework.

Pero probablemente sois muchos también los que sólo lo conocéis de oídas, pues vuestro día a día está más enfocado al mantenimiento de sistemas existentes, o quizás trabajáis sobre tecnologías que están ancladas a versiones determinadas del framework .NET, o simplemente el fragor de la batalla diaria no os deja tiempo para explorar nuevos horizontes.

Si este último es tu caso, lo mínimo que debes saber es que .NET Core es una implementación del estándar .NET que , al igual que otras implementaciones como .NET Framework o Mono, incluye todo lo necesario para crear y ejecutar aplicaciones : como los compiladores, las bibliotecas de clases básicas o la máquina virtual o runtime que proporciona el entorno donde se ejecutan las aplicaciones.

En otras palabras, con .NET Core puedes crear una aplicación con lenguajes como C# o VB.NET, utilizar en ella clases básicas como las habituales string, int o List<T>, compilarla a bytecode CIL y ejecutarla en tu ordenador.

Entonces, ¿qué diferencia a .NET Core de .NET Framework? Pues precisamente eso es lo que vamos a ver en este artículo 😉

1. NET Core es nuevo, y escrito prácticamente desde cero

.NET Core es, en muchos sentidos, un reboot de .NET Framework y ha tenido que ser reescrito desde cero. Obviamente se han aprovechado las APIs, ya estandarizadas y conocidas por todos los desarrolladores, pero internamente se han vuelto a implementar muchos componentes para poder lograr los ambiciosos objetivos que se plantearon en su diseño y que veremos en algunos puntos siguientes.

2. .NET Core es open source

Aunque determinados componentes del stack clásico, como ASP.NET MVC o Entity Framework, habían sido publicados bajo licencias open source, .NET Framework no era un marco de trabajo abierto en su totalidad y aún tiene piezas distribuidas bajo licencias propietarias.

.NET Core es un proyecto completamente open source desde sus orígenes. De hecho, aunque dirigido y soportado oficialmente por Microsoft, el proyecto pertenece a la .NET Foundation y en su desarrollo están involucrados activamente cientos de desarrolladores de todo el mundo, que pueden participar en su diseño y realizar contribuciones de cualquier tipo al framework.

3. .NET Core es multiplataforma

Sin duda, una de las características .NET Core que más lo diferencian respecto a sus predecesores es su capacidad real de funcionar en múltiples plataformas , incluyendo algunas impensables hace sólo algunos años, como Linux o macOS.

Los SDK y runtimes están disponibles para una gran variedad de sistemas operativos y distribuciones (Windows, macOS, Ubuntu, RHEL, Debian, Fedora, CentOS...), lo que hace que sea posible desarrollar aplicaciones sobre cualquiera de las plataformas soportadas y ejecutarlas también sobre cualquiera ellas. De esta forma, ahora sería totalmente posible, por ejemplo, programar una aplicación en Windows y ejecutarla en un Mac, o desarrollarla en Mac y ejecutarla en una distribución Debian de Linux.

De la misma forma, es compatible con distintas arquitecturas de procesador , como x64, x86 o ARM, lo que posibilita su uso en diversos tipos de dispositivo.

4. .NET Core es modular

.NET Framework es un bloque monolítico que ha ido creciendo con el tiempo hasta convertirse en algo difícil de manejar. Por ejemplo, las distintas versiones o revisiones actualizan el framework completo, muchas veces sobrescribiendo las versiones anteriormente instaladas (con los problemas que esto podría provocar). También, suelen estar bastante distanciadas en el tiempo, porque se trata de actualizaciones completas del marco de trabajo.

En cambio, .NET Core está formado por distintas piezas distribuidas a través de paquetes NuGet. De esta forma, las correcciones a bugs o mejoras en componentes concretos pueden distribuirse y actualizarse de forma independiente al resto, sólo actualizando el paquete correspondiente. Sin duda, un modelo mucho más ágil y eficiente que el anterior, y que permite un ritmo de evolución mucho más rápido.

5. Las operaciones principales de .NET Core se realizan desde línea de comandos

Para conseguir ser cross platform real, era absolutamente imprescindible que las herramientas de .NET Core estuviesen disponibles en Windows, Linux y Mac. ¿Y cómo conseguirlo de la forma más sencilla? Pues acudiendo al denominador común: la línea de comandos.

A diferencia de .NET Framework, donde a veces nos encontrábamos casi obligados a utilizar Visual Studio, para compilar, ejecutar, testear o publicar aplicaciones .NET Core basta con tener a mano la línea de comandos de cada sistema operativo y utilizar las órdenes de la CLI (Command Line Interface) proporcionada por el framework.

Aquí tienes algunos ejemplos de comandos en acción:

C:\Test>dotnet new console
Preparándose...
La plantilla "Console Application" se creó correctamente.

Procesando acciones posteriores...
Ejecutando "dotnet restore" en C:\Test\Test.csproj...
  Restaurando paquetes para C:\Test\Test.csproj...
  Generación de archivo MSBuild C:\Test\obj\Test.csproj.nuget.g.props.
  Generación de archivo MSBuild C:\Test\obj\Test.csproj.nuget.g.targets.
  Restauración realizada en 147,78 ms para C:\Test\Test.csproj.

Restauración correcta.

C:\Test>dotnet build
Microsoft (R) Build Engine versión 15.9.20+g88f5fadfbe para .NET Core
Copyright (C) Microsoft Corporation. Todos los derechos reservados.

  Restauración realizada en 23,44 ms para C:\Test\Test.csproj.
  Test -> C:\Test\bin\Debug\netcoreapp2.2\Test.dll

Compilación correcta.
    0 Advertencia(s)
    0 Errores

Tiempo transcurrido 00:00:00.52

C:\Test>dotnet run
Hello World!

C:\Test>_

6. .NET Core puede distribuirse de varias formas

Como seguramente sabes ya, .NET Framework se distribuye a través paquetes descargables que se instalan en el equipo de forma única, es decir, sólo puede existir una copia a nivel de equipo. Además, determinadas versiones (principalmente actualizaciones) sobrescriben la versión instalada anteriormente, por lo que puede dar lugar a problemas si tenemos aplicaciones que dependen de versiones específicas.

.NET Core es mucho más flexible en este sentido : el framework puede estar instalado a nivel de equipo, como .NET Framework, pero también podemos hacerlo a nivel de usuario o incluso a nivel de aplicación (es decir, que cada aplicación incluya su propia copia de .NET Core).

Además, distintas versiones y revisiones pueden convivir sin problemas en el mismo equipo. Por ejemplo, la siguiente traza de consola muestra el resultado de invocar el comando dotnet --info, donde aparecen las distintas versiones del SDK y runtimes instalados en mi equipo:

C:\>dotnet --info
SDK de .NET Core (reflejando cualquier global.json):
 Version: 2.2.102
 Commit: 96ff75a873

Entorno de tiempo de ejecución:
 OS Name: Windows
 OS Version: 10.0.17763
 OS Platform: Windows
 RID: win10-x64
 Base Path: C:\Program Files\dotnet\sdk\2.2.102\

Host (useful for support):
  Version: 2.2.1
  Commit: 878dd11e62

.NET Core SDKs installed:
  1.1.11 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.503 [C:\Program Files\dotnet\sdk]
  2.2.102 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

C:\>_

7. .NET Core no soporta todos los modelos de aplicación ni todos los frameworks

Lo más habitual es que a la hora de construir aplicaciones lo hagamos subidos a hombros de gigantes, es decir, utilizamos frameworks que nos ayudan a desarrollar más rápidamente y con menos errores. Por ejemplo, si vamos a crear una aplicación web, lo habitual es usar ASP.NET, si nuestra aplicación es de escritorio podríamos usar WinForms o WPF, o si vamos a acceder a datos, una opción razonable es Entity Framework.

Pues bien, muchos de estos frameworks sólo funcionan sobre las plataformas para las que han sido creados. Por ejemplo, SignalR, ASP.NET MVC o Entity Framework 6 sólo funcionarán sobre .NET Framework porque es el framework para el que han sido construidos.

Como consecuencia, a día de hoy, con .NET Core 2.x sólo podemos crear determinados tipos de aplicaciones : consola, web (ASP.NET Core) y Xamarin. Esto limita algo las posibilidades de uso de este framework, pero, afortunadamente, esto va a cambiar en un futuro próximo: previsto para 2019, .NET Core 3.0 incluirá soporte para WPF y Windows Forms , que se beneficiarán de algunas de las ventajas que aportan este nuevo marco de trabajo.

En definitiva, a la hora de desarrollar con .NET Core debemos utilizar marcos de trabajo específicos para esta plataforma , como ASP.NET Core, Entity Framework Core o SignalR Core.

8. En .NET Core el rendimiento es algo prioritario

Desde sus orígenes, en .NET Core el rendimiento ha sido siempre una prioridad , y esto se pone de manifiesto en los benchmarks que demuestran que este framework supera a su predecesor con creces en este aspecto.

Por dar algunas cifras, algo tan simple y recurrente como utilizar los métodos IndexOf() o StartsWith() sobre una cadena son un 200% más rápidos en .NET Core que en .NET Framework. Un ToString() sobre el elemento de un enum gana un 600% de rendimiento. LINQ es hasta un 300% más eficiente en determinados puntos. Lazy<T> es un 500% más rápido...

Beneficiarios directos de estas mejoras son los frameworks específicos como ASP.NET Core o Entity Framework Core. Por ejemplo, el primero de ellos se ha situado ya sólidamente en los top ten de los marcos de trabajo más rápidos para la web según las pruebas TechEmpower soportando más de 7 millones de peticiones por segundo , algo impensable en ASP.NET 4.x.

9. .NET Core ha sido creado pensando en los tiempos modernos

Cuando se creó .NET Framework, hace más de quince años, una nube era simplemente un agregado visible de minúsculas gotitas de agua, de cristales de hielo o de ambos, suspendido en la atmósfera y producido por la condensación de vapor de agua (RAE dixit), los contenedores se usaban exclusivamente para almacenar cosas diversas, como mercancías o residuos, y probablemente al hablar de microservicios sólo podíamos pensar en cuartos de baño pequeñitos 😆

Hoy en día, el cloud está presente en casi cualquier aspecto del desarrollo, sobre todo en aplicaciones que, de alguna u otra forma, hacen uso de Internet. Los contenedores se han consolidado como una forma simple, ágil y escalable para desplegar aplicaciones, y los microservicios se han demostrado como arquitecturas apropiadas en múltiples escenarios.

.NET Core y los frameworks construidos sobre él han sido creados teniendo en cuenta todos estos aspectos. Sus componentes están diseñados con el enfoque cloud-first en mente, por lo que se integran a la perfección en infraestructuras de nube. Se trata además de una tecnología especialmente recomendada para la construcción de microservicios, entre otros aspectos, por la facilidad con que pueden ser creados y distribuidos en contenedores.

10. Se pueden desarrollar aplicaciones .NET Core con cualquier editor o IDE

Ni a nuestros más acérrimos enemigos le desearíamos algo tan terrible como crear aplicaciones para .NET Framework sin Visual Studio. De hecho, aunque técnicamente era evitable, en muchos modelos de aplicación (por ejemplo, WinForms, WPF o ASP.NET) era prácticamente obligatorio utilizar el IDE de Microsoft.

Por el contrario, con .NET Core tenemos libertad completa a la hora de elegir el editor que utilizaremos en el desarrollo de nuestros proyectos. Si trabajamos sobre Windows, muchos preferimos seguir utilizando Visual Studio en el día a día (al fin y al cabo, es el mejor IDE 😜, pero hay quien prefiere trabajar con Visual Studio Code, o con editores alternativos como Atom, Brackets o Sublime Text. Y si trabajamos desde Linux o Mac, podemos utilizar cualquier editor disponible en dichos entornos.

Corolario: .NET Core es tu próximo framework

Lo queramos o no, .NET Core se convertirá en algún momento en la herramienta que usaremos en nuestro día a día. Aunque en principio .NET Framework seguirá existiendo y Microsoft continuará dándole soporte, la tendencia actual indica que todo está confluyendo en .NET Core : Xamarin, WPF, WinForms, Entity Framework, SignalR o MVC son sólo algunos ejemplos de frameworks que ya están o van a estar pronto basados en la nueva infraestructura.

Además, es lógico pensar que estos marcos de trabajo continuarán evolucionando exclusivamente sobre .NET Core. Sólo hay que mirar un poco hacia atrás y ver que en los últimos dos años han aparecido ya varias versiones completas de frameworks como Entity Framework Core o ASP.NET Core, mientras que EF o ASP.NET MVC "clásicos" apenas han lanzado pequeñas actualizaciones.

En nuestro curso de ASP.NET Core MVC se estudia a fondo la creación de aplicaciones Web con el nuevo framework de Microsoft. ¿A qué esperas para dar el salto?

Post original escrito por José María Aguilar en campusMVP: https://www.campusmvp.es/recursos/post/10-diferencias-entre-net-core-y-net-framework.aspx