10 Diferencias entre .NET Core y .NET Framework
Tags: csharp, netcore, spanish
Published: 2019-04-15 08:29:27

---
title: 10 Diferencias entre .NET Core y .NET Framework
published: true
tags: CSharp, .NET Core, Spanish
canonical_url: https://www.campusmvp.es/recursos/post/10-diferencias-entre-net-core-y-net-framework.aspx
cover_image: https://www.campusmvp.es/recursos/image.axd?picture=/2019/1T/net-vs-netcore.png
---

>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)

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](https://github.com/dotnet/roslyn), las [bibliotecas de clases básicas](https://github.com/dotnet/corefx) o la [máquina virtual o _runtime_](https://github.com/dotnet/coreclr) 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](https://es.wikipedia.org/wiki/Common_Intermediate_Language) 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_](https://en.wikipedia.org/wiki/.NET_Framework#Licensing), .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](https://dotnetfoundation.org/) 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](https://dotnet.microsoft.com/download) (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](https://www.techempower.com/benchmarks/#section=test&runid=8ca46892-e46c-4088-9443-05722ad6f7fb&hw=ph&test=plaintext) soportando **más de 7 millones de peticiones por segundo** , algo impensable en ASP.NET 4.x.

![Benchmarks de ASP.NET Core](https://www.campusmvp.es/recursos/image.axd?picture=/2019/1T/2019-02-05-16-57-44.png)

## 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](https://dle.rae.es/?id=QgpwJRv)), 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](https://www.campusmvp.es/recursos/catalogo/Product-Desarrollo-Web-con-ASP.NET-Core-2-MVC_227.aspx)** 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