Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

10 Diferencias entre .NET Core y .NET Framework

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.

Benchmarks de ASP.NET Core

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?

José María Aguilar José María atesora una amplísima experiencia trabajando en el mundo del desarrollo de software (programador, analista, responsable de informática, consultor, director técnico), principalmente con tecnologías Microsoft. Actualmente trabaja como consultor y desarrollador independiente, ofreciendo servicios tecnológicos a empresas e instituciones.
Es un reconocido experto en desarrollo web en todo el mundo, y es autor del libro de Microsoft Press "SignalR Programming in Microsoft ASP.NET".
Escribe regularmente artículos sobre ASP.NET MVC y otros temas relacionados con el desarrollo de software en su blog.
Puedes seguirlo en Twitter en @jmaguilar. Ver todos los posts de José María Aguilar
Archivado en: Lenguajes y plataformas

Boletín campusMVP.es

Solo cosas útiles. Una vez al mes.

🚀 Únete a miles de desarrolladores

DATE DE ALTA

x No me interesa | x Ya soy suscriptor

La mejor formación online para desarrolladores como tú

Comentarios (18) -

Diego Fernandez
Diego Fernandez

Excelente artículo! Muchas gracias

Responder

Gracias por el articulo, demasiado bueno e interesante

Responder

Sin desperdicios. Excelente!

Responder

crstian villalba
crstian villalba

muy buena gracias

Responder

Erick Aldi
Erick Aldi

Excelente artículo, bien explicado!

Responder

Mil gracias, soy aun estudiante, pero me has depejado muchas dudas.

Responder

Con respecto al punto 9 tengo que decir que disciento en lo que dice. No creo qye alla creado el nuevo framework pensando en tiempos moderno, sino que es el propio Microsoft el que nos hace ir para un rumbo del que no podemos escapar. Los programadores en la mayor parte del tiempo tenemos que adaptarnos a lo que dicen las empresas que desarrollan los frameworks o los distintos lenguajes, que para mi son las que manejan el rumbo de a donde ir en materia de tecnología..

Como ejemplo puedo decir que acá en Argentina las empresas estan usando este y otros framework para crear los microservicios, sitios web y demás (ya no quieren mas usar .NET Framework). Los programadores que no han trabajado antes con este nuevo framework no tienen posibilidad de nada porque las empresas no los llaman si quieren cambiar a otra como pasa siempre. Aunque tengan cursos tampoco te llaman porque siempre piden que se tenga 3+ años de experiancia trabajando con esas tecnologías. Ya la mayoría de las empresa sno desarrollan en WinForms ni WPF, solo desarrollan web, aunque tienen sistemas de esso que mantener, no te llaman.

Responder

Neil Lamas
Neil Lamas

???? comprensión lectora!!!

Responder

alvaro andres garzon
alvaro andres garzon

No entiendo de qué hablas, el artículo dice claramente que trabajar en .net core es totalmente igual a trabajar en .net framework con la diferencia de que .net core es MULTIPLATAFORMA, es decir, no tienes que aprender nada nuevo, sigues desarrollando totalmente igual que cuando lo hacías en .net framework.

Responder

José M. Aguilar
José M. Aguilar

Hola, Alejandro.

Creo que no lo has entendido bien, lo comentado en el punto 9 no tiene nada que ver con Microsoft ni con la decisión de las empresas de adoptar unas u otras tecnologías, sino con el momento en que un framework es conceptualizado y desarrollado.

La nube es un hecho, las necesidades de escalabilidad y alto rendimiento también, como lo son las posibilidades cross-platform y otros muchos aspectos. Y son hechos para todas las tecnologías, marcas y fabricantes. Microsoft lo único que ha hecho es tenerlos en cuenta a la hora de crear un framework que estaba comenzando desde cero, lo cual es, indiscutiblemente, un acierto.

O en otras palabras: con .NET Core, Microsoft no nos está llevando a ningún sitio. Simplemente nos está facilitando herramientas para que podamos crear software cada vez mejor, y acorde a las tendencias y necesidades del mercado. A dónde queramos ir ya es cosa nuestra ;)

Saludos!

Responder

Excelente explicacion, muchas gracias!

Responder

Sobre el punto 2,
Como es el cobro de licencia por el aplicativo que desarrolle?, es similar al de visual studio..?, no hay cobro..?

Es decir me cobraran por licencia cuando explaye mi aplicativo..?

Responder

Hola Mateo:

Lo que desarrolles con .NET o .NET Core o cualquier otra tecnología de desarrollo similar de Microsoft no tiene costes de licencia, así que no te preocupes.

Saludos.

Responder

correcto gracias estimado

Responder

gracias, muy buen articulo

Responder

Muy buen articulo, ayuda en tener mas claro el panorama sobre estas herramientas

Responder

muy buen contenido mi amigo bendiciones °

Responder

Bardcrack
Bardcrack

Excelente articulo, muy completo.

Responder

Pingbacks and trackbacks (1)+

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.