• Artículo

Abril de 2016

Volumen 31, número 4

.NET Core: .NET se convierte en multiplataforma con .NET Core

Por Phillip Carter | Abril de 2016

En Microsoft, estamos creando una nueva implementación de .NET, denominada .NET Core, que permite escribir código multiplataforma para cargas de trabajo optimizadas para la nube. Muchos están entusiasmados con este desarrollo de código abierto, pero ¿qué significa eso realmente? Este artículo debería ayudar a aclarar qué es .NET Core en la actualidad y cuáles son los objetos, qué relación tiene con Microsoft .NET Framework y los aspectos fundamentales de la herramienta de línea de comandos que puede usar para comenzar a usar .NET Core.

¿Qué es .NET Core?

Para comprender qué es .NET Core, conviene entender .NET en sí. Muchas personas se refieren a ".NET Framework" cuando hablan sobre".NET", pero va mucho más allá; .NET es un estándar de ECMA que tiene distintas implementaciones: .NET Framework, Mono, Unity y, ahora, .NET Core. Esto significa que muchas de las experiencias se comparten entre .NET Framework y .NET Core. Sin embargo, .NET Core es nuevo, con algunos principios distintos en su planteamiento.

En primer lugar, .NET Core es multiplataforma. Se ejecuta en Windows, OS X y en varias distribuciones de Linux. También admite distintas arquitecturas de CPU. Estamos agregando compatibilidad con más distribuciones de Linux y arquitecturas de CPU con el objetivo final de que .NET Core se ejecute en el mayor número de sitios posibles.

Al mismo tiempo, .NET Core es fundamentalmente modular en su diseño y arquitectura. Los componentes del compilador, el tiempo de ejecución y la biblioteca son entidades independientes que se comunican a través de interfaces adecuadamente diseñadas. Esto permite que se incorporen o quiten componentes según las necesidades concretas. Las propias bibliotecas son modulares y se distribuyen mediante NuGet, lo que permite usar solamente lo necesario para que se pueda optimizar la superficie de .NET Core en cualquier sistema determinado.

Además, el código escrito para .NET Core es portable y se puede ajustar para que se ejecute en diferentes plataformas admitidas. En función de los destinos de los proyectos, es posible ejecutar el código de .NET Core en plataformas .NET Framework, Mono y Xamarin, en Windows 8 y Windows Phone, y en la Plataforma universal de Windows (UWP). Para saber más, eche un vistazo al Estándar de la plataforma .NET (bit.ly/1Of6W1r).

Por último, .NET Core seguirá un modelo "pay-for-play" y tendrá un buen rendimiento. Un objetivo de los esfuerzos empleados en .NET Core es dejar claro el costo de abstracción a los desarrolladores, mediante la implementación de un modelo pay-for-play que permita que los costos de emplear una abstracción de mayor nivel para resolver un problema estén claros. Las abstracciones no son gratuitas y ese hecho no se debe ocultar a los desarrolladores. Además, .NET Core mejorará el rendimiento con una biblioteca estándar que minimiza las asignaciones y la superficie de memoria general del sistema.

Escenarios para .NET Core

Actualmente, existen cuatro escenarios en los que puede escribir código para .NET Core: aplicaciones web de ASP.NET multiplataforma, aplicaciones de consola multiplataforma, marcos y bibliotecas multiplataforma, y aplicaciones para UWP.

Creada en pro de la velocidad, ASP.NET Core 1.0 es la pila web multiplataforma para .NET Core. Si alguna vez ha querido hacer algo como implementar una aplicación web de ASP.NET en un contenedor en Linux, ahora puede hacerlo. Para saber más sobre las amplias funcionalidades que ofrece ASP.NET Core, consulte la documentación que puede encontrar en bit.ly/1TqPcIo.

El ámbito de las aplicaciones de consola multiplataforma es en realidad bastante mayor de lo que muchos desarrolladores podrían esperar. Por ejemplo, una aplicación web de ASP.NET Core es, en esencia, una aplicación de consola que lee y escribe información en puertos; simplemente resulta que hace muchas otras cosas. Un conjunto de microservicios que forman el back-end de un sistema entero podrían escribirse de forma separada como aplicaciones de consola.

La diferencia entre los marcos y las bibliotecas multiplataforma reside en la escala. Las bibliotecas son uno de los candidatos más naturales para crear cosas en .NET Core. Pero a una escala mucho mayor, otras opciones como los marcos para la computación distribuida son también buenos candidatos.

Por último, las aplicaciones para UWP que tienen como destino la familia de dispositivos de Windows 10 se ejecutan en .NET Core. Puede crear una aplicación para UWP con todas las características que incorpore bibliotecas de .NET Core para ayudar a crear sofisticadas aplicaciones de Windows 10.

En otras palabras, actualmente hay una gran cantidad de cosas que puede escribir para .NET Core. A medida que las herramientas maduren y se amplíen, habrá todavía más cosas que podrá crear en el futuro.

Si tiene recursos de .NET Framework que entren en uno de estos cuatro escenarios o quiere comenzar a utilizar una nueva tecnología, visite bit.ly/1Q1Q18q para comenzar a escribir código en .NET Core.

Comparativa entre .NET Core y .NET Framework

La versión de .NET que la mayoría tiene y con la que están encantados se conoce como .NET Framework. Por tanto, ¿en qué se diferencian y en que se parecen .NET Core y .NET Framework? Lo primero que hay que tener presente es que se usan las mismas tecnologías (C#, F#, Visual Basic) para escribir todo el código. La experiencia al escribir código debería ser muy similar. Sin embargo, .NET Core es una nueva pila, no un subconjunto de .NET Framework. Es mejor pensar en .NET Core y .NET Framework como dos pilas que coinciden y evolucionan a la par.

.NET Framework es y seguirá siendo la pila que se debe usar al escribir aplicaciones de escritorio de Windows 7 a Windows 10. De hecho, es posible tener código de .NET Core y .NET Framework coexistiendo en la misma solución. Por ejemplo, considere un escenario en que una GUI de .NET Framework (como por ejemplo Windows Forms) consume servicios escritos en .NET Core.

Resulta útil pensar en las similitudes y diferencias entre .NET Core y .NET Framework desde dos perspectivas: el área expuesta de las API y las funcionalidades de tiempo de ejecución. La Figura 1 ayuda a ilustrar el solapamiento de las API entre las dos plataformas.

.NET Framework y .NET Core comparten un subconjunto de API
Figura 1. .NET Framework y .NET Core comparten un subconjunto de API

Existen API de .NET implementadas tanto en .NET Core como en .NET Framework (aunque algunas veces con implementaciones subyacentes distintas). Al mismo tiempo, .NET Core tiene API y funcionalidades que .NET Framework no tiene y viceversa. Por ejemplo, .NET Framework tiene varios marcos de GUI y API específicas de Windows que no existen en .NET Core. De la misma manera, .NET Core tiene API y funcionalidades multiplataforma que faltan en .NET Framework.

Además, .NET Framework es un componente de Windows que se ofrece a través de Windows Updates. .NET Core emplea un modelo completamente distinto en cuanto a dónde se ubica y cómo se proporciona. .NET Core está compuesto por paquetes NuGet, con App-Local instalado en tiempo de ejecución. Esto significa que las aplicaciones pueden "llevar consigo" .NET Core, lo que permite que existan en paralelo con otras instancias de .NET Core en una máquina o un dispositivo. El servicio se puede ofrecer entonces por aplicación y a través de un administrador de paquetes, en lugar de globalmente mediante actualizaciones del sistema operativo.

Una pregunta muy práctica es: si se escribe algo en una pila, ¿se ejecutará en la otra? Como casi todas las respuestas en la vida, depende. Si las API que use están implementadas en las dos plataformas, debería ser posible ejecutar el código en .NET Core y .NET Framework con relativamente poco trabajo por su parte. Sin embargo, si adopta dependencias en el entorno en ejecución o usa API que no estén disponibles en una pila (como la biblioteca para trabajar con interfaces de usuario basadas en XAML), el código no se ejecutará en las dos pilas. El analizador de portabilidad de .NET, disponible como una herramienta de la línea de comandos (bit.ly/1Sd8oIK) o como una extensión de Visual Studio (bit.ly/1LqX0aF), es una herramienta que analizará los archivos .dll y generará un informe que indicará cómo de portable es el código de .NET Framework a .NET Core. Se publicarán más herramientas para ayudar con la migración en el futuro.

La línea de comandos: el punto de entrada a .NET Core

.NET Core incluye un nuevo conjunto nuevo y modernizado de herramientas fundamentales que se usará para desarrollar aplicaciones. Ese conjunto de herramientas se denomina CLI de .NET Core, que es la forma abreviada de interfaz de la línea de comandos de .NET Core. Como sucede con otras partes de .NET Core, también es de código libre (consulte GitHub.com/dotnet/cli) y tiene una comunidad de código abierto muy activa que está totalmente implicada en este desarrollo.

Existen varios motivos para presentar un nuevo conjunto de aplicaciones al mundo. En primer lugar, es necesario admitir escenarios de desarrollo principales en todas las plataformas que .NET Core admite. Dado el conjunto diverso de plataformas, una buena experiencia de la línea de comandos constituye unos buenos cimientos a partir de los cuales construir lo demás; al fin y al cabo, la línea de comandos es lo que todas estas plataformas incluyen de forma predeterminada.

Como una prolongación lógica, queremos admitir las mismas experiencias de usuario en las plataformas admitidas. Podrá moverse entre Linux, Windows y OS X y no tener que volver a aprender las herramientas, su sintaxis ni su semántica. Son iguales en todas las plataformas. Los patrones de uso son los mismos e incluso las sintaxis también lo son.

Esta idea de que exista un conjunto de herramientas que pueda usar en las plataformas también se extiende a las herramientas de mayor nivel, en concreto, Visual Studio Code y Visual Studio. Estas herramientas de mayor nivel se sobrepondrán encima de la CLI de .NET y se usarán para dar soporte a los proyectos de .NET Core para que sigan avanzando. Esto significa que cuando se compile la aplicación de .NET Core desde Visual Studio, se invocarán las herramientas de la CLI de .NET para realizar la compilación.

Probar la interfaz de la línea de comandos de .NET Core

La manera más fácil de comenzar a trabajar con la CLI de .NET Core es seguir la guía de introducción (aka.ms/dotnetcoregs). En resumen, consiste en descargar un instalador para una plataforma (o registrar una nueva fuente de apt-get en el caso de Ubuntu), instalar las herramientas y todo estará listo para comenzar. Los instaladores se ocuparán de configurar la carpeta de instalación en la ruta de acceso del sistema de todos los sistemas operativos admitidos, así como cualesquiera otras variables de entorno que la CLI necesite.

Después de esto, puede comenzar invocando el controlador "dotnet" y pasándole un comando (que también se conoce como "verbo"). El controlador se ocupa de iniciar el comando y de pasarle los argumentos. En el momento en que escribo esto, el paquete de CLI incluye los comandos de la Figura 2. Por supuesto, cuando esté leyendo esto, probablemente ya se habrán agregado más comandos que aumentarán su productividad.

Figura 2. Algunos comandos de la CLI de .NET habituales que puede usar actualmente

Comando Descripción
dotnet new Inicializar un proyecto válido para una biblioteca de clases o una aplicación de consola con C# como lenguaje.
dotnet restore Restaurar las dependencias definidas en el archivo project.json de un proyecto determinado. Las dependencias normalmente son paquetes NuGet que se usan en la aplicación.
dotnet build Compilar el código. Este comando generará un binario de lenguaje intermedio (IL) del proyecto. Si el proyecto es una aplicación de consola, el resultado generado será un ejecutable que podrá ejecutar inmediatamente. De manera predeterminada, el comando build colocará los ensamblados y ejecutables (si es el caso) resultantes en el directorio bin del directorio donde se invoque.
dotnet test A ninguna buena herramienta le puede faltar la compatibilidad para ejecutar pruebas. Este comando permite ejecutar un conjunto de pruebas con un ejecutor que se puede especificar en el archivo project.json. Actualmente se admiten los ejecutores de pruebas xUnit y NUnit.
dotnet publish Publicar la aplicación para que se ejecute en la máquina de destino.
dotnet pack El comando pack empaquetará el proyecto como un paquete NuGet. El resultado será un conjunto de paquetes NuGet que podrá cargar en sus fuentes o usarlos en la operación de restauración mediante el reemplazo de carpeta local.
dotnet run El comando run compilará y ejecutará la aplicación. Puede considerarlo como una acción similar a Ctrl+F5, pero sin Visual Studio.

Además de los comandos que se incluyen con el paquete, también tiene la opción de agregar comandos adicionales como herramientas en el archivo project.json y después restaurarlos. Se empaquetan como un paquete NuGet, que ofrece un modelo de extensibilidad fácil de usar y entender.

Resumen

Esperamos que haya aprendido mucho sobre .NET Core y que le entusiasme la idea de escribir código de .NET que puede ejecutarse de manera multiplataforma. Al ser una nueva pila, ofrece algunas funcionalidades muy interesantes que antes no eran posibles con .NET Framework. La CLI de .NET también introduce una estupenda experiencia de la línea de comandos que será la base de la experiencia de desarrollo y se integrará en otras herramientas, como Visual Studio y Visual Studio Code.

Por último, sabemos que dispone de una gran cantidad de recursos escritos para .NET Framework, y nos encantaría que esos recursos sigan creciendo a medida que .NET Framework evoluciona. Imaginamos un mundo donde .NET Framework y .NET Core se usen conjuntamente en sistemas que aprovechen los puntos fuertes de ambas pilas.

Si quiere saber más y, tal vez, involucrarse en el proyecto, a continuación se muestran algunos recursos para obtener información básica:

Tenemos muchos más proyectos de código abierto de .NET en los que estamos trabajando. Si le interesa obtener más información sobre ellos, eche un vistazo a .NET Foundation, una organización independiente que fomenta el desarrollo abierto y la colaboración en torno a .NET. Microsoft ha aportado varios proyectos a .NET Foundation, así como otras compañías como Xamarin, Umbraco, Salesforce y la comunidad de .NET. Obtenga más información sobre ellos y contribuya en DotNetFoundation.org/projects.

Phillip Carteres director de programas en el equipo de .NET en Microsoft. Es un amante de los sistemas y la teoría de los lenguajes de programación, y no es extraño ver a Carter a altas horas de la madrugada hablando sobre modelos de simultaneidad con amigos. Espera que algún día el comportamiento del tiempo de ejecución de todos los sistemas se pueda expresar en sistemas de tipo y, de esa manera, la raza humana se elevará a un estado de razonamiento superior. Puede ponerse en contacto con él en phcart@microsoft.com.

Zlatko Knezevices director de programas (PM) en el equipo de .NET en Microsoft. En 2005, se unió a Microsoft, donde primero trabajó en CEE como experto de desarrollo y más tarde pasó a ser PM en SQL Server. Allí trabajó en un amplio abanico de proyectos, desde agregar nuevos índices al motor central a crear servicios butt que trabajan con macrodatos, detección de datos, etc. En 2015, se unió al equipo de .NET como PM y desde entonces ha estado trabajando en experiencias multiplataforma de .NET Core. Puede ponerse en contacto con él en Zlatko.Knezevic@microsoft.com.

Gracias a los siguientes expertos técnicos de Microsoft por revisar este artículo: Immo Landwerthy y el equipo de administración del programa .NET Core y Framework