.NET Core: Guía rápida

.NET Core es la última plataforma de desarrollo de propósito general mantenida por Microsoft. Funciona en diferentes plataformas y ha sido rediseñado de forma que .NET sea rápido, flexible y moderno. Esta es una de las principales contribuciones de Microsoft. Los desarrolladores ahora pueden crear aplicaciones para Android, iOS, Linux, Mac y Windows con .NET, todo en código abierto.

En este tutorial, cubriremos .NET Core y algunas innovaciones nuevas, incluidas las actualizaciones de .NET Framework, .NET Standard y las actualizaciones de la Plataforma universal de Windows, etc.

Características de .NET Core

Las siguientes son las principales características de .NET Core:

Fuente abierta

  • .NET Core es una implementación de código abierto que utiliza licencias MIT y Apache 2.

  • .NET Core es un proyecto de .NET Foundation y está disponible en GitHub.

  • Como proyecto de código abierto, promueve un proceso de desarrollo más transparente y promueve una comunidad activa y comprometida.

Multiplataforma

  • La aplicación implementada en .NET Core se puede ejecutar y su código se puede reutilizar independientemente de la plataforma de destino.

  • Actualmente es compatible con tres sistemas operativos principales (SO)

    • Windows

    • Linux

    • MacOS

  • Los sistemas operativos (SO), las CPU y los escenarios de aplicaciones compatibles crecerán con el tiempo, proporcionados por Microsoft, otras empresas y personas.

Despliegue flexible

  • Puede haber dos tipos de implementaciones para aplicaciones .NET Core:

    • Implementación dependiente del marco

    • Despliegue autónomo

  • Con la implementación dependiente del marco, su aplicación depende de una versión de .NET Core para todo el sistema en la que están instaladas su aplicación y las dependencias de terceros.

  • Con la implementación autónoma, la versión de .NET Core utilizada para compilar su aplicación también se implementa junto con su aplicación y las dependencias de terceros, y puede ejecutarse en paralelo con otras versiones.

Herramientas de línea de comandos

  • Todos los escenarios de productos se pueden ejecutar en la línea de comandos.

Compatible

  • .NET Core es compatible con .NET Framework, Xamarin y Mono, a través de .NET Standard Library

Modular

  • .NET Core se lanza a través de NuGet en paquetes de ensamblado más pequeños.

  • .NET Framework es un ensamblado grande que contiene la mayoría de las funcionalidades principales.

  • .NET Core está disponible como paquetes más pequeños centrados en características.

  • Este enfoque modular permite a los desarrolladores optimizar su aplicación al incluir solo los paquetes NuGet que necesitan en su aplicación.

  • Los beneficios de una superficie de aplicación más pequeña incluyen una seguridad más estricta, un servicio reducido, un rendimiento mejorado y una reducción de los costos en un modelo de pago por uso.

La plataforma .NET Core

.NET Core Platform contiene las siguientes partes principales:

  • .NET Runtime - Proporciona un sistema de tipos, carga de ensamblaje, recolector de basura, interoperabilidad nativa y otros servicios básicos.

  • Fundamental Libraries - Un conjunto de bibliotecas de marcos, que proporcionan tipos de datos primitivos, tipos de composición de aplicaciones y utilidades fundamentales.

  • SDK & Compiler - Un conjunto de compiladores de lenguaje y herramientas SDK que habilitan la experiencia de desarrollador base, disponible en .NET Core SDK.

  • ‘dotnet’ app host- Se utiliza para iniciar aplicaciones .NET Core. Selecciona el tiempo de ejecución y aloja el tiempo de ejecución, proporciona una política de carga de ensamblado y lanza la aplicación. El mismo host también se usa para lanzar herramientas SDK de la misma manera.

En este capítulo, discutiremos las diversas dependencias que necesita para implementar y ejecutar. Estos incluyen las aplicaciones .NET Core en máquinas Windows que se desarrollan con Visual Studio.

Versiones de Windows compatibles

.NET Core es compatible con las siguientes versiones de Windows:

  • Windows 7 SP1
  • Windows 8.1
  • Windows 10
  • Windows Server 2008 R2 SP1 (servidor completo o núcleo del servidor)
  • Windows Server 2012 SP1 (servidor completo o núcleo del servidor)
  • Windows Server 2012 R2 SP1 (servidor completo o núcleo del servidor)
  • Windows Server 2016 (servidor completo, Server Core o Nano Server)

Dependencias

  • Si está ejecutando su aplicación .NET Core en versiones de Windows anteriores a Windows 10 y Windows Server 2016, también necesitará Visual C ++ Redistributable.

  • Esta dependencia se instala automáticamente si usa el instalador de .NET Core.

  • Debe instalar manualmente Visual C ++ Redistributable para Visual Studio 2015 si está instalando .NET Core a través del script de instalación o implementando una aplicación .NET Core autónoma.

  • Para máquinas con Windows 7 y Windows Server 2008, debe asegurarse de que la instalación de Windows esté actualizada y también incluya la revisión KB2533623 instalada a través de Windows Update.

Requisitos previos con Visual Studio

  • Para desarrollar aplicaciones .NET Core con .NET Core SDK, puede usar cualquier editor de su elección.

  • Sin embargo, si desea desarrollar aplicaciones .NET Core en Windows usando Visual Studio, puede usar las siguientes dos versiones:

    • Visual Studio 2015

    • Visual Studio 2017 RC

  • Los proyectos creados con Visual Studio 2015 estarán basados ​​en project.json de forma predeterminada, mientras que los proyectos creados con Visual Studio 2017 RC siempre estarán basados ​​en MSBuild.

En este capítulo, analizaremos la configuración del entorno de .NET Core. Es un rediseño significativo de .NET Framework. Para usar .NET Core en su aplicación, hay dos versiones que puede usar:

  • Visual Studio 2015
  • Visual Studio 2017 RC

Visual Studio 2015

Para usar Visual Studio 2015, debe haber instalado lo siguiente:

  • Microsoft Visual Studio 2015 Actualización 3
  • Microsoft .NET Core 1.0.1 - Vista previa 2 de herramientas de VS 2015

Microsoft proporciona una versión gratuita de Visual Studio que también contiene SQL Server y se puede descargar desde https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx y Microsoft .NET Core 1.0.1 - VS 2015 Tooling Preview 2 se puede descargar desde https://www.visualstudio.com/downloads/

También puede seguir las pautas de instalación en la siguiente URL https://www.microsoft.com/net/core/#windowsvs2017

Instalación de Visual Studio 2015

Siga estos pasos para instalar Visual Studio 2015:

Step 1- Una vez que se complete la descarga, ejecute el instalador. Se mostrará el siguiente cuadro de diálogo.

Step 2 - Click Install para iniciar el proceso de instalación.

Step 3 - Una vez que se complete la instalación, verá el siguiente cuadro de diálogo.

Step 4 - Cierre este cuadro de diálogo y reinicie su computadora si es necesario.

Step 5- Abra Visual Studio desde el menú Inicio; recibirá el siguiente cuadro de diálogo. Puede que tarde unos minutos en cargarse y finalmente utilizarse por primera vez.

Step 6 - Una vez que esté cargado, verá la siguiente pantalla.

Step 7 - Una vez finalizada la instalación de Visual Studio, cierre Visual Studio e inicie Microsoft .NET Core - VS 2015 Tooling Preview 2.

Step 8 - Marque la casilla de verificación y haga clic en Instalar.

Step 9 - Una vez que se complete la instalación, verá el siguiente cuadro de diálogo.

Ahora está listo para iniciar su aplicación con .NET Core.

Visual Studio 2017

En este tutorial, usaremos Visual Studio 2015, pero si desea usar Visual Studio 2017, se incluye una versión experimental de las herramientas .NET Core para Visual Studio en Visual Studio 2017 RC y puede ver las pautas de instalación aquí. https://www.microsoft.com/net/core/#windowsvs2017

Visual Studio 2015 proporciona un entorno de desarrollo con todas las funciones para desarrollar aplicaciones .NET Core. En este capítulo, crearemos un nuevo proyecto dentro de Visual Studio. Una vez que haya instalado las herramientas de Visual Studio 2015, puede comenzar a crear una nueva aplicación .NET Core.

En el New Project cuadro de diálogo, en la lista Plantillas, expanda el nodo de Visual C # y seleccione .NET Core y debería ver las siguientes tres nuevas plantillas de proyecto

  • Biblioteca de clases (.NET Core)
  • Aplicación de consola (.NET Core)
  • Aplicación web ASP.NET Core (.NET Core)

En el panel central del cuadro de diálogo Nuevo proyecto, seleccione Aplicación de consola (.NET Core) y asígnele el nombre "FirstApp", luego haga clic en Aceptar.

Visual Studio abrirá el proyecto recién creado y verá en la ventana del Explorador de soluciones todos los archivos que se encuentran en este proyecto.

Para probar que la aplicación de la consola central de .NET está funcionando, agreguemos la siguiente línea.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace FirstApp { 
   public class Program { 
      public static void Main(string[] args) { 
         Console.WriteLine("Hello guys, welcome to .NET Core world!"); 
      } 
   } 
}

Ahora, ejecute la aplicación. Debería ver el siguiente resultado.

.NET Core admite las primitivas numéricas estándar integrales y de punto flotante. También admite los siguientes tipos:

  • System.Numerics.BigInteger que es un tipo integral sin límite superior o inferior.

  • System.Numerics.Complex es un tipo que representa números complejos.

  • Un conjunto de tipos de vectores habilitados para datos múltiples de instrucción única (SIMD) en el espacio de nombres System.Numerics.

Tipos integrales

.NET Core admite enteros firmados y sin firmar de diferentes rangos de un byte a ocho bytes de longitud. Todos los números enteros son tipos de valor.

La siguiente tabla representa los tipos integrales y su tamaño;

Tipo Firmado / Sin firmar Tamaño (bytes) Valor mínimo Valor máximo
Byte No firmado 1 0 255
Int16 Firmado 2 −32,768 32,767
Int32 Firmado 4 −2,147,483,648 2,147,483,647
Int64 Firmado 8 −9,223,372,036,854,775,808 9.223.372.036.854.775.807
SByte Firmado 1 -128 127
UInt16 No firmado 2 0 65.535
UInt32 No firmado 4 0 4.294.967.295
UInt64 No firmado 8 0 18,446,744,073,709,551,615

Cada tipo integral admite un conjunto estándar de operadores aritméticos, de comparación, de igualdad, de conversión explícita y de conversión implícita.

También puede trabajar con los bits individuales en un valor entero utilizando la clase System.BitConverter.

Tipos de coma flotante

.NET Core incluye tres tipos de punto flotante primitivos, que se muestran en la siguiente tabla.

Tipo Tamaño (bytes) Valor mínimo Valor máximo
Doble 8 −1,79769313486232e308 1.79769313486232e308
Soltero 4 −3,402823e38 3.402823e38
Decimal dieciséis −79,228,162,514,264,337,593,5 43,950,335 79,228,162,514,264,337,593,543,9 50,335
  • Cada tipo de punto flotante admite un conjunto estándar de operadores aritméticos, de comparación, de igualdad, de conversión explícita y de conversión implícita.

  • También puede trabajar con los bits individuales en valores Double y Single utilizando la clase BitConverter.

  • La estructura Decimal tiene sus propios métodos, Decimal.GetBits y Decimal.Decimal (Int32 ()), para trabajar con los bits individuales de un valor decimal, así como su propio conjunto de métodos para realizar algunas operaciones matemáticas adicionales.

BigInteger

  • System.Numerics.BigInteger es un tipo inmutable que representa un entero arbitrariamente grande cuyo valor en teoría no tiene límites superiores o inferiores.

  • Los métodos del tipo BigInteger son muy paralelos a los de los otros tipos integrales.

Complejo

  • El tipo System.Numerics.Complex representa un número complejo, es decir, un número con una parte de número real y una parte de número imaginario

  • Admite un conjunto estándar de operadores aritméticos, de comparación, igualdad, conversión explícita y conversión implícita, así como métodos matemáticos, algebraicos y trigonométricos.

SIMD

  • El espacio de nombres de Numerics incluye un conjunto de tipos de vectores habilitados para SIMD para .NET Core.

  • SIMD permite paralelizar algunas operaciones a nivel de hardware, lo que resulta en enormes mejoras de rendimiento en aplicaciones matemáticas, científicas y gráficas que realizan cálculos sobre vectores.

  • Los tipos de vectores habilitados para SIMD en .NET Core incluyen lo siguiente:

    • Tipos System.Numerics.Vector2, System.Numerics.Vector3 y System.Numerics.Vector4, que son vectores de 2, 3 y 4 dimensiones de tipo Single.

    • La estructura Vector <T> que le permite crear un vector de cualquier tipo numérico primitivo. Los tipos numéricos primitivos incluyen todos los tipos numéricos en el espacio de nombres del sistema excepto Decimal.

    • Dos tipos de matrices, System.Numerics.Matrix3 × 2, que representa una matriz de 3 × 2; y System.Numerics.Matrix4 × 4, que representa una matriz de 4 × 4.

    • El tipo System.Numerics.Plane, que representa un plano tridimensional, y el tipo System.Numerics.Quaternion, que representa un vector que se utiliza para codificar rotaciones físicas tridimensionales.

En este capítulo, cubriremos el concepto de recolección de basura, que es una de las características más importantes de la plataforma de código administrado .NET. El recolector de basura (GC) administra la asignación y liberación de memoria. El recolector de basura sirve como administrador de memoria automático.

  • No es necesario saber cómo asignar y liberar memoria o administrar la vida útil de los objetos que usan esa memoria.

  • Se realiza una asignación cada vez que declara un objeto con una palabra clave "nueva" o un tipo de valor está en un cuadro. Las asignaciones suelen ser muy rápidas

  • Cuando no hay suficiente memoria para asignar un objeto, el GC debe recolectar y eliminar la memoria basura para que la memoria esté disponible para nuevas asignaciones.

  • Este proceso se conoce como garbage collection.

Ventajas de la recolección de basura

La recolección de basura proporciona los siguientes beneficios:

  • No necesita liberar memoria manualmente mientras desarrolla su aplicación.

  • También asigna objetos en el montón administrado de manera eficiente.

  • Cuando los objetos ya no se utilicen, los recuperará al borrar su memoria y mantendrá la memoria disponible para futuras asignaciones.

  • Los objetos administrados obtienen automáticamente contenido limpio para empezar, por lo que sus constructores no tienen que inicializar todos los campos de datos.

  • También proporciona seguridad en la memoria al asegurarse de que un objeto no pueda usar el contenido de otro objeto.

Condiciones para la recolección de basura

La recolección de basura se produce cuando se cumple una de las siguientes condiciones.

  • El sistema tiene poca memoria física.

  • La memoria que utilizan los objetos asignados en el montón administrado supera un umbral aceptable. Este umbral se ajusta continuamente a medida que se ejecuta el proceso.

  • los GC.Collectse llama al método y, en casi todos los casos, no es necesario llamar a este método, porque el recolector de basura se ejecuta continuamente. Este método se utiliza principalmente para situaciones y pruebas únicas.

Generaciones

El recolector de basura .NET tiene 3 generaciones y cada generación tiene su propio montón que se utiliza para el almacenamiento de objetos asignados. Existe un principio básico de que la mayoría de los objetos son de corta o larga duración.

Primera generación (0)

  • En la Generación 0, los objetos se asignan primero.

  • En esta generación, los objetos a menudo no viven más allá de la primera generación, ya que ya no están en uso (fuera de su alcance) cuando ocurre la siguiente recolección de basura.

  • La generación 0 se recopila rápidamente porque su montón asociado es pequeño.

Segunda generación (1)

  • En la Generación 1, los objetos tienen un espacio de segunda oportunidad.

  • Los objetos que tienen una vida corta pero sobreviven a la colección de la generación 0 (a menudo se basan en tiempos coincidentes) pasan a la generación 1.

  • Las colecciones de generación 1 también son rápidas porque su montón asociado también es pequeño.

  • Los dos primeros montones siguen siendo pequeños porque los objetos se recopilan o se promocionan al montón de próxima generación.

Tercera generación (2)

  • En la Generación 2, todos los objetos largos están vivos y su montón puede crecer hasta ser muy grande.

  • Los objetos de esta generación pueden sobrevivir mucho tiempo y no existe un montón de próxima generación para promover aún más los objetos.

  • El recolector de basura tiene un montón adicional para objetos grandes conocido como montón de objetos grandes (LOH).

  • Está reservado para objetos de 85.000 bytes o más.

  • Los objetos grandes no se asignan a los montones generacionales, sino que se asignan directamente a la LOH

  • Las recopilaciones de Generación 2 y LOH pueden llevar un tiempo considerable para los programas que se han ejecutado durante mucho tiempo o que operan con grandes cantidades de datos.

  • Se sabe que los grandes programas de servidor tienen montones de decenas de GB.

  • El GC emplea una variedad de técnicas para reducir la cantidad de tiempo que bloquea la ejecución del programa.

  • El enfoque principal es realizar la mayor cantidad posible de trabajo de recolección de basura en un subproceso en segundo plano de una manera que no interfiera con la ejecución del programa.

  • El GC también expone algunas formas en que los desarrolladores pueden influir en su comportamiento, lo que puede ser bastante útil para mejorar el rendimiento.

En este capítulo, comprenderemos el proceso de ejecución de .NET Core y lo compararemos con .NET Framework. El proceso de ejecución gestionada incluye los siguientes pasos.

  • Elegir un compilador
  • Compilando su código en MSIL
  • Compilar MSIL en código nativo
  • Ejecutando código

Elegir un compilador

  • Es un entorno de ejecución en varios idiomas, el tiempo de ejecución admite una amplia variedad de tipos de datos y características de idioma.

  • Para obtener los beneficios que proporciona Common Language Runtime, debe utilizar uno o más compiladores de lenguaje que tengan como destino el Runtime.

Compilando su código en MSIL

  • La compilación traduce su código fuente a Microsoft Intermediate Language (MSIL) y genera los metadatos necesarios.

  • Los metadatos describen los tipos en su código, incluida la definición de cada tipo, las firmas de los miembros de cada tipo, los miembros a los que hace referencia su código y otros datos que utiliza el tiempo de ejecución en el momento de la ejecución.

  • El tiempo de ejecución ubica y extrae los metadatos del archivo, así como de las bibliotecas de clases de marco (FCL) según sea necesario durante la ejecución.

Compilar MSIL en código nativo

  • En el momento de la ejecución, un compilador Just-In-Time (JIT) traduce el MSIL en código nativo.

  • Durante esta compilación, el código debe pasar un proceso de verificación que examina el MSIL y los metadatos para averiguar si se puede determinar que el código es seguro para los tipos.

Código de ejecución

  • Common Language Runtime proporciona la infraestructura que permite que se lleve a cabo la ejecución y los servicios que se pueden utilizar durante la ejecución.

  • Durante la ejecución, el código administrado recibe servicios como recolección de basura, seguridad, interoperabilidad con código no administrado, soporte de depuración en varios idiomas y soporte mejorado de implementación y control de versiones.

Proceso de ejecución de código de .NET Core

Ahora relacionemos cómo se ejecuta el código con .NET Core en comparación con .NET Framework. En .NET Core hay muchos reemplazos de estos componentes que forman parte de .NET Framework.

  • En .NET Core ahora tenemos una nueva serie de compiladores, como tenemos Roslyn para C # y VB.

  • También puede hacer uso del nuevo compilador F # 4.1 si desea usar F # con .NET Core.

  • En realidad, estas herramientas son diferentes y podemos usar Roslyn con .NET Framework también si usamos C # 6 o posterior, porque el compilador de C # solo puede admitir hasta C # 5.

  • En .NET Core, no tenemos bibliotecas de clases de marco (FCL), por lo que se usa un conjunto diferente de bibliotecas y ahora tenemos CoreFx.

  • CoreFx es la reimplementación de las bibliotecas de clases para .NET Core.

  • También tenemos un nuevo tiempo de ejecución con .NET Core conocido como CoreCLR y aprovecha un compilador JIT.

  • Ahora la pregunta es por qué tenemos la reimplementación de todos estos componentes que ya tenemos en .NET framework.

  • Entonces, la respuesta es la misma que por qué Microsoft implementó .NET Core.

Otra consideración de .NET Core es crear e implementar aplicaciones que sean modulares. En lugar de instalar todo el .NET Framework, su aplicación ahora solo puede instalar lo necesario. Vayamos al estudio visual y veamos la modularidad.

Aquí está nuestra sencilla aplicación .NET Core, en el Explorador de soluciones. Permítanos expandir Referencias y verá una referencia a .NETCoreApp

Dentro de .NETCoreApp, verá la referencia del paquete a NuGet; vamos a ampliarlo.

Verá toda la serie de referencias de paquetes NuGet. Si ha trabajado en .NET Framework, muchos de estos espacios de nombres le resultarán familiares, porque está acostumbrado a usarlos en .NET Framework.

.NET Framework se divide en muchas partes diferentes y se vuelve a implementar con CoreFx; estas piezas se distribuyen además como paquetes individuales.

  • Ahora, si expande NETStandard.Library, verá referencias adicionales. Incluso notará System.Console que estamos usando en esta aplicación.

  • Ahora no tiene que traer todo dentro de .NET Framework, solo traer lo que necesita para su aplicación.

  • También hay otros beneficios; por ejemplo, estos módulos se pueden actualizar individualmente si se desea.

La modularidad genera beneficios de rendimiento y su aplicación puede ejecutarse más rápido, especialmente la aplicación ASP.NET Core.

En este capítulo, analizaremos los archivos de proyecto .NET Core y cómo puede agregar archivos existentes en su proyecto.

Entendamos un ejemplo sencillo en el que tenemos algunos archivos que ya están creados; tenemos que agregar estos archivos en nuestro proyecto FirstApp.

Aquí está la implementación del Student.cs archivo

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace FirstApp { 
   public class Student { 
      public int ID { get; set; } 
      public string LastName { get; set; } 
      public string FirstMidName { get; set; } 
      public DateTime EnrollmentDate { get; set; } 
   } 
}

Aquí está la implementación del Course.cs archivo.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace FirstApp { 
   public class Course { 
      public int CourseID { get; set; } 
      public string Title { get; set; } 
      public int Credits { get; set; } 
   } 
}

Guardemos ahora estos tres archivos en su disco y la carpeta de origen de su proyecto.

  • Ahora bien, si está familiarizado con .NET y esta era una aplicación de consola de .NET Framework tradicional, es importante comprender cómo agregar estos archivos en su proyecto en Visual Studio.

  • Primero debe arrastrar los archivos al explorador de soluciones para copiarlos en la carpeta de su proyecto, porque su proyecto necesita hacer referencia a estos archivos.

  • Uno de los beneficios de .NET Core es el enfoque adoptado con el archivo del proyecto (project.json); simplemente podemos colocar archivos en la raíz de nuestro proyecto y luego estos se incluirán automáticamente en nuestro proyecto.

  • No tenemos que hacer referencia a archivos manualmente como lo hicimos en el pasado para la aplicación tradicional .NET Framework en Visual Studio.

Permítanos ahora abrir la raíz de su proyecto.

Copiemos ahora los tres archivos en la raíz de su proyecto.

Ahora puede ver todos los archivos copiados en la carpeta raíz.

Vayamos ahora a Visual Studio; recibirá el siguiente cuadro de diálogo.

Hacer clic Yes to All para recargar tu proyecto.

Ahora verá que los archivos se incluyen automáticamente en su proyecto.

En este capítulo, analizaremos cómo agregar paquetes en su aplicación .NET Core y cómo encontrar un paquete específico. Podemos ir directamente a NuGet y agregar el paquete, pero aquí veremos algunos otros lugares.

Vayamos ahora al código fuente de .NET Core que se encuentra aquí: https://github.com/dotnet/corefx

En el repositorio de CoreFx, abra el src carpeta -

Y verá la lista completa de carpetas que corresponden a diferentes paquetes. Busquemos ahora Json -

Hay otra forma de encontrar su paquete, probablemente conozca varios tipos si está familiarizado con .NET Framework, pero el ensamblaje de paquetes en .NET Core es totalmente diferente y no sabrá dónde están esos paquetes.

Si conoce el tipo, puede buscar para invertir la búsqueda de paquetes utilizando https://packagesearch.azurewebsites.net/

Aquí puede ingresar cualquier tipo de paquete que le gustaría encontrar. Luego, este sitio escaneará NuGet y encontrará los paquetes relevantes para usted.

Busquemos ahora DataContractJson.

Ahora verá que obtenemos el mismo paquete; hagamos clic en el paquete.

Ahora verá la página NuGet; debe confirmar que necesita este paquete. Puede agregar esto en su aplicación usando algunos métodos.

Abramos el archivo project.json.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      } 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "dnxcore50" 
      } 
   } 
}

Este es el nuevo formato del proyecto y dentro de este archivo verá la sección de dependencias. Agreguemos una nueva dependencia como se muestra a continuación.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      }, 
      "System.Runtime.Serialization.Json": "4.0.2" 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "dnxcore50" 
      } 
   } 
}

Ahora, si miras tus referencias, verás que System.Runtime.Serialization.Json el paquete se agrega a su proyecto.

Otra forma es ir al NuGet Manager y buscar el paquete que desea agregar.

En este capítulo, analizaremos cómo crear una aplicación para UWP usando .NET Core. UWP también se conoce como aplicación Windows 10 UWP. Esta aplicación no se ejecuta en versiones anteriores de Windows, solo se ejecutará en versiones futuras de Windows.

A continuación, se muestran algunas excepciones en las que UWP se ejecutará sin problemas.

  • Si desea ejecutarlo localmente, debe tener Windows 10, también puede desarrollar en Windows 8 y luego deberá ejecutarlo en Emulator, pero se recomienda usar Windows 10.

  • Para la aplicación para UWP, también necesitará Windows 10 SDK. Abramos la configuración de Visual Studio 2015 y luego modifiquemos Visual Studio.

  • En la página de características seleccionadas, desplácese hacia abajo y verá Herramientas de desarrollo de aplicaciones universales de Windows, marque esa opción como se muestra a continuación.

Aquí puede ver las diferentes versiones de SDK y también la última actualización de Herramientas, haga clic en Siguiente.

Ahora, haga clic en el Install botón.

Una vez finalizada la instalación, deberá reiniciar su sistema.

Implementemos ahora la UWP siguiendo estos pasos.

  • Primero, inicie Visual Studio 2015.

  • Haga clic en el menú Archivo y seleccione Nuevo → Proyecto; Aparecerá un cuadro de diálogo Nuevo proyecto. Puede ver los diferentes tipos de plantillas en el panel izquierdo del cuadro de diálogo.

  • En el panel izquierdo, puede ver la vista de árbol, ahora seleccione Plantilla universal en Plantillas → Visual C # → Windows.

  • En el panel central, seleccione la plantilla Aplicación en blanco (Windows universal).

  • Dale un nombre al proyecto escribiendo UWPFirstApp en el campo Nombre y haga clic en Aceptar.

  • Aparece el cuadro de diálogo versión de destino / versión mínima. La configuración predeterminada está bien para este tutorial, así que seleccione Aceptar para crear el proyecto.

  • Aquí, tenemos un solo proyecto que puede apuntar a todos los dispositivos Windows 10, y notará que tanto .NET Core como UWP son una simplificación de la orientación múltiple.

  • Cuando se abre un nuevo proyecto, sus archivos se muestran en el lado derecho del panel Explorador de soluciones. Es posible que deba elegir la pestaña Explorador de soluciones en lugar de la pestaña Propiedades para ver sus archivos.

  • Aunque la aplicación en blanco (ventana universal) es una plantilla mínima, todavía contiene muchos archivos. Estos archivos son esenciales para todas las aplicaciones para UWP que usan C #. Cada proyecto que crea en Visual Studio contiene los archivos.

  • Para ver el ejemplo en ejecución, abramos MainPage.XAML y agreguemos el siguiente código.

<Page 
   x:Class = "UWPFirstApp.MainPage" 
   xmlns = "http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   xmlns:x = "http://schemas.microsoft.com/winfx/2006/xaml" 
   xmlns:local = "using:UWPFirstApp" 
   xmlns:d = "http://schemas.microsoft.com/expression/blend/2008" 
   xmlns:mc = "http://schemas.openxmlformats.org/markup-compatibility/2006" 
   mc:Ignorable = "d">  
   
   <Grid Background = "{ThemeResource ApplicationPageBackgroundThemeBrush}"> 
      <StackPanel HorizontalAlignment = "Center"> 
         <TextBlock Text = "Hello, world!"  
            Margin = "20" 
            Width = "200" 
            HorizontalAlignment = "Left"/> 
         <TextBlock Text = "Write your name." 
            Margin = "20" 
            Width = "200" 
            HorizontalAlignment = "Left"/> 
         <TextBox x:Name = "txtbox"  
            Width = "280" 
            Margin = "20" 
            HorizontalAlignment = "Left"/> 
         <Button x:Name = "button" Content = "Click Me" 
            Margin = "20" 
            Click = "button_Click"/> 
         <TextBlock x:Name = "txtblock"  
            HorizontalAlignment = "Left" 
            Margin = "20"/> 
      </StackPanel> 
   </Grid> 

</Page>

A continuación se muestra el evento de clic del botón en C #.

using System; 
using System.Collections.Generic; 
using System.IO; 
using System.Linq; 
using System.Runtime.InteropServices.WindowsRuntime; 

using Windows.Foundation; 
using Windows.Foundation.Collections; 

using Windows.UI.Xaml; 
using Windows.UI.Xaml.Controls; 
using Windows.UI.Xaml.Controls.Primitives; 
using Windows.UI.Xaml.Data; 
using Windows.UI.Xaml.Input; 
using Windows.UI.Xaml.Media; 
using Windows.UI.Xaml.Navigation;  

// The Blank Page item template is documented at 
// http://go.microsoft.com/fwlink/?LinkId=402352&clcid=0x409  

namespace UWPHellowWorld { 
   /// <summary> 
   /// An empty page that can be used on its own or navigated to within a Frame. 
   /// </summary> 
   public sealed partial class MainPage : Page { 
      public MainPage() { 
         this.InitializeComponent(); 
      }  
      private void button_Click(object sender, RoutedEventArgs e) { 
         if (txtbox.Text != "") 
            txtblock.Text = "Hello: " + txtbox.Text; 
         else 
            txtblock.Text = "You have not write your name"; 
      } 
   } 
}

Ejecutemos ahora el código anterior en la máquina local y verá la siguiente ventana. Ahora escriba cualquier nombre en el cuadro de texto y presione elClick Me botón.

En este capítulo, analizaremos qué es MSBuild y cómo funciona con .NET Core. MSBuild es la plataforma de compilación para Microsoft y Visual Studio. En la aplicación para UWP, si abre la carpeta del proyecto, verá los archivos project.json y * .csproj.

Pero si abre nuestra aplicación de consola .NET Core anterior, verá los archivos project.json y * .xproj.

  • El sistema de compilación .NET Core o el sistema de compilación project.json no es suficiente para las necesidades de UWP; esta es la razón por la que UWP todavía usa el sistema de compilación * .csproj (MSBuild).

  • Pero project.json se moverá en lo que respecta al sistema de compilación.

  • Ahora, si desea agregar algunos archivos existentes a su aplicación para UWP como lo hemos agregado en la aplicación Consola, entonces debe agregar esos archivos en la carpeta del proyecto. Además, también deberá incluirlo en su proyecto en el Explorador de soluciones.

Consideremos ahora los siguientes archivos; copie estos archivos en la carpeta de su proyecto.

Regresemos a Visual Studio y abramos el Explorador de soluciones.

  • Ahora puede ver que solo copiar archivos no es suficiente en el caso de aplicaciones para UWP, porque en el Explorador de soluciones, no podemos ver esos archivos.

  • Ahora debemos incluir esos archivos también haciendo clic en el Show All Files icono como se resalta en la captura de pantalla anterior y ahora verá todos los archivos en la carpeta del proyecto.

Estos dos archivos todavía no están incluidos en nuestro proyecto. Para incluir estos archivos, seleccione estos archivos y haga clic con el botón derecho en cualquier archivo y luego seleccioneInclude in Project.

Ahora estos archivos también están incluidos. Una cosa buena que se puede prever es el enfoque project.json de eliminar archivos para * .csproj en la versión futura de las herramientas SKD y también en Visual Studio.

En este capítulo, analizaremos las referencias entre nuestra aplicación de consola y nuestra aplicación para UWP. Si observa las referencias en el Explorador de soluciones de su aplicación de consola, verá .NETCoreApp como se muestra a continuación.

.NETCoreApp es un nuevo marco dirigido a la aplicación .NET Core. Ahora, si miras debajo de Referencias de la aplicación UWP, se verá un poco diferente como se muestra a continuación.

  • La razón principal de esto es que aquí en UWP tenemos el * .csproj, por lo que volvemos al estilo antiguo de referencias y podemos apuntar solo a un marco con este tipo de proyecto.

  • Sin embargo, las referencias son similares. Ahora puede ver que en la aplicación para UWP, la referencia del paquete NuGet de Miscrosoft.NETCore.UniversalWindowsPlatform es similar a la referencia NuGet de Microsoft.NETCore.App en la aplicación de consola.

  • Tanto Miscrosoft.NETCore.UniversalWindowsPlatform como Microsoft.NETCore.App son metapaquetes, lo que significa que están compuestos por otros paquetes.

  • En la aplicación de consola, podemos profundizar y ver otros paquetes dentro de Microsoft.NETCore.App, pero no podemos hacer lo mismo Miscrosoft.NETCore.UniversalWindowsPlatform en el Explorador de soluciones.

  • Sin embargo, podemos usar otra herramienta, el Explorador de paquetes NuGet, para ver esto. Abramos ahora esta URL en el navegador:https://npe.codeplex.com/downloads/get/clickOnce/NuGetPackageExplorer.application y verá una pequeña descarga de utilidad.

  • Una vez que se complete la descarga, haga doble clic en ese archivo.

  • Hacer clic Install para iniciar la instalación en el Explorador de paquetes NuGet.

  • Cuando finalice la instalación, verá el siguiente cuadro de diálogo.

  • Hagamos ahora clic en el Open a package from online feed opción.

  • De forma predeterminada, buscará el feed de nuget.org. Busquemos ahora Microsoft.NETCore.UniversalWindowsPlatform en el cuadro de búsqueda y verá 1 resultado como se muestra a continuación.

  • Haga clic en el open enlace y abrirá las dependencias de nivel superior de este metapaquete.

  • Abramos ahora el metapaquete .NETCore para la aplicación .NETCore y el metapaquete para la aplicación UWP en paralelo.

  • Ahora puede ver que cada metapaquete está compuesto por diferentes conjuntos de paquetes.

  • .NET Core es un subconjunto de las clases disponibles en .NET Framework al menos en este momento, pero está creciendo y será según las clases base de .NET Framework.

  • La UWP se basa en .NET Core, es un superconjunto de las API disponibles para el desarrollo de la Tienda Windows.

Ahora tenemos más API disponibles para desarrollo gracias a .NET Core.

Los componentes de Windows Runtime son objetos independientes que puede crear instancias y usar desde cualquier lenguaje, incluidos C #, Visual Basic, JavaScript y C ++. Además del metapaquete .NET Core que vimos en el capítulo anterior, la aplicación para UWP también tiene una referencia predeterminada a un SDK universal de Windows.

Universal Windows es la referencia a Windows Runtime y se ha incluido en una serie de contratos de API.

El conjunto de API dentro de una familia de dispositivos se divide en subdivisiones conocidas como contratos de API. Puede encontrar una lista de diferentes contratos de API aquíhttps://msdn.microsoft.com/en-us/library/windows/apps/dn706135.aspx

La mayoría de esas API dentro del tiempo de ejecución de Windows se incluyen en un solo contrato. Busquemos ahora la palabra clave Universal en la página de Contratos de API.

Puede ver enlaces a varias API y también puede ver que la familia Universal es tan grande que tiene 12 páginas de documentación.

También puede buscar contrato de API de teléfono en esta página.

Hagamos ahora clic en el Windows.Phone.PhoneContracty desplácese hacia abajo; ahora verá la información de la batería del teléfono o del dispositivo móvil.

Si desea agregar esta información además de la que ya tiene, debe agregar las referencias manualmente. Vayamos ahora a Visual Studio y hagamos clic derecho en Referencias en el Explorador de soluciones.

Seleccione Add References…

Ahora puede ver la nueva categoría de referencia para Universal Windows; bajo esta categoría está Core, que se refiere a los contratos básicos de la API universal de Windows

  • Las Extensiones nos permiten extender la funcionalidad y verá diferentes referencias Mobile, Desktop y otras Extensiones.

  • Hay diferentes extensiones SKD y puede agregar en la parte superior para obtener más API.

  • También puedes ver diferentes versiones. Por lo tanto, asegúrese de obtener la última versión para obtener las API actualizadas y luego haga clic en Aceptar.

Ahora puedes ver eso Windows Mobile Extensions for the UWP se agrega como referencia.

Una biblioteca de clases define los tipos y métodos que se pueden llamar desde cualquier aplicación.

  • Una biblioteca de clases desarrollada con .NET Core es compatible con .NET Standard Library, lo que permite que cualquier plataforma .NET que admita esa versión de .NET Standard Library llame a su biblioteca.

  • Cuando termine su biblioteca de clases, puede decidir si desea distribuirla como un componente de terceros o si desea incluirla como un componente que se incluye con una o más aplicaciones.

Comencemos agregando un proyecto de biblioteca de clases en nuestra aplicación de consola; haga clic derecho en elsrc carpeta en el Explorador de soluciones y seleccione Add → New Project…

En el Add New Project cuadro de diálogo, elija el nodo .NET Core, luego elija la plantilla de proyecto Biblioteca de clases (.NET Core).

En el cuadro de texto Nombre, ingrese "UtilityLibrary" como el nombre del proyecto, como muestra la siguiente figura.

Haga clic en Aceptar para crear el proyecto de biblioteca de clases. Una vez creado el proyecto, agreguemos una nueva clase. Haga clic derecho enproject en el Explorador de soluciones y seleccione Add → Class...

Seleccione la clase en el panel central e ingrese StringLib.cs en el nombre y campo y luego haga clic en Add. Una vez agregada la clase, reemplace el siguiente código en el archivo StringLib.cs.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace UtilityLibrary { 
   public static class StringLib { 
      public static bool StartsWithUpper(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
         return false; 
         Char ch = str[0]; 
         return Char.IsUpper(ch); 
      } 
      public static bool StartsWithLower(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
         return false; 
         Char ch = str[0]; 
         return Char.IsLower(ch); 
      } 
      public static bool StartsWithNumber(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
         return false;  
         Char ch = str[0]; 
         return Char.IsNumber(ch); 
      } 
   } 
}
  • La biblioteca de clases UtilityLibrary.StringLib, contiene algunos métodos como, StartsWithUpper, StartsWithLowery StartsWithNumber que devuelve un valor booleano que indica si la instancia de cadena actual comienza con mayúsculas, minúsculas y un número respectivamente.

  • En .NET Core, el Char.IsUpper El método devuelve verdadero si un carácter está en mayúsculas, el método Char.IsLower devuelve verdadero si un carácter está en minúsculas y, de manera similar, el método Char.IsNumber devuelve verdadero si un carácter es numérico.

  • En la barra de menú, elija Generar, Generar solución. El proyecto debería compilarse sin errores.

  • Nuestro proyecto de consola .NET Core no tiene acceso a nuestra biblioteca de clases.

  • Ahora, para consumir esta biblioteca de clases, necesitamos agregar una referencia de esta biblioteca de clases en nuestro proyecto de consola.

Para hacerlo, expanda FirstApp y haga clic con el botón derecho en Referencias y seleccione Add Reference…

En el cuadro de diálogo Administrador de referencias, seleccione UtilityLibrary, nuestro proyecto de biblioteca de clases, y luego haga clic en OK.

Ahora abramos el archivo Program.cs del proyecto de la consola y reemplacemos todo el código con el siguiente código.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
using UtilityLibrary; 

namespace FirstApp { 
   public class Program { 
      public static void Main(string[] args) { 
         int rows = Console.WindowHeight; 
         Console.Clear(); 
         do { 
            if (Console.CursorTop >= rows || Console.CursorTop == 0) { 
               Console.Clear(); 
               Console.WriteLine("\nPress <Enter> only to exit; otherwise, enter a string and press <Enter>:\n"); 
            } 
            string input = Console.ReadLine(); 
            
            if (String.IsNullOrEmpty(input)) break; 
            Console.WriteLine("Input: {0} {1,30}: {2}\n", input, "Begins with uppercase? ", 
            input.StartsWithUpper() ? "Yes" : "No"); 
         } while (true); 
      } 
   } 
}

Ejecutemos ahora su aplicación y verá el siguiente resultado.

Para una mejor comprensión, hagamos uso de los otros métodos de extensión de su biblioteca de clases en su proyecto.

En este capítulo, discutiremos qué es PCL (Portable Class Library) y también por qué necesitamos PCL. Para entender este concepto, abramos la carpeta del proyecto de la biblioteca de clases que hemos creado en el capítulo anterior.

En esta carpeta, puede ver que, además de los archivos project.json y CS, también tenemos el archivo * .xproj, y eso se debe a que Visual Studio configuró el tipo de proyecto .NET Core como * .xproj en lugar de * .csproj.

Como mencionó Microsoft, * .xproj desaparecerá, pero todavía está aquí en las herramientas de vista previa 2. Como hemos cubierto, la aplicación para UWP usa * .csproj.

Ahora, en realidad, no es posible hacer que * .csproj haga referencia y * .xproj y esa funcionalidad no se implementará porque * .xproj se moverá.

Entonces, en su lugar, necesitamos una biblioteca de clases que se pueda compartir entre la aplicación de consola y la aplicación para UWP y aquí viene PCL.

Que es PCL

Entendamos ahora qué es PCL:

  • El proyecto Biblioteca de clases portátil le permite escribir y crear ensamblados administrados que funcionan en más de una plataforma .NET Framework.

  • Puede crear clases que contengan código que desee compartir en muchos proyectos, como la lógica empresarial compartida, y luego hacer referencia a esas clases desde diferentes tipos de proyectos.

  • También puede ayudarlo a crear aplicaciones y bibliotecas multiplataforma para plataformas Microsoft de forma rápida y sencilla.

  • Las bibliotecas de clases portátiles pueden ayudarlo a reducir el tiempo y los costos de desarrollo y prueba de código.

  • Use este tipo de proyecto para escribir y compilar ensamblados de .NET Framework portátiles y luego hacer referencia a esos ensamblados desde aplicaciones que tienen como destino múltiples plataformas, como Windows y Windows Phone, etc.

Eliminemos ahora la biblioteca de clases que hemos creado desde el Explorador de soluciones. Al mismo tiempo, elimínelo de la carpeta Solución y agregue un nuevo elemento de proyecto.

Selecciona el Visual C# → Windows plantilla en el panel izquierdo y seleccione Biblioteca de clases (portátil) en el panel central.

Ingrese StringLibrary en el campo de nombre y haga clic en OK para crear este proyecto.

Ahora tenemos que seleccionar los marcos de destino para hacer referencia. Seleccionemos Windows Universal y ASP.NET Core por un momento y luego lo reorientaremos. Hacer clicOK.

Puede ver que ha creado un nuevo proyecto en formato PCF. Ahora hagamos clic con el botón derecho en el proyecto StringLibrary en el Explorador de soluciones y seleccione Propiedades.

Haga clic en Target .NET Platform Standard.

Haga clic en Sí; ahora es la misma biblioteca de clases con una pequeña diferencia. La diferencia es que UWP también puede usarlo, porque contiene el archivo * .csproj en lugar de * .xproj.

Agreguemos ahora una nueva clase; para esto, debe hacer clic derecho en el proyecto en el Explorador de soluciones y seleccionarAdd → Class...

Seleccione clase en el panel central e ingrese StringLib.cs en el campo de nombre y luego haga clic en Add. Una vez agregada la clase, reemplace el siguiente código en el archivo StringLib.cs.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 
  
namespace StringLibrary { 
   public static class StringLib { 
      public static bool StartsWithUpper(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
            return false; 
         Char ch = str[0]; 
         return Char.IsUpper(ch); 
      } 
      public static bool StartsWithLower(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
            return false; 
         Char ch = str[0]; 
         return Char.IsLower(ch); 
      } 
      public static bool StartsWithNumber(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
            return false; 
         Char ch = str[0]; 
         return Char.IsNumber(ch); 
      } 
   } 
}

Construyamos este proyecto de biblioteca de clases portátil y debería compilarse sin errores. Ahora necesitamos agregar una referencia de esta biblioteca de clases portátil en nuestro proyecto de consola. Entonces, expanda FirstApp y haga clic derecho en Referencias y seleccioneAdd Reference…

En el cuadro de diálogo Administrador de referencias, seleccione StringLibrary, que es nuestro proyecto de biblioteca de clases portátil, y luego haga clic en OK.

Puede ver que la referencia StringLibrary se agrega al proyecto de la consola y también se puede ver en el archivo project.json.

Ahora puede ejecutar la aplicación nuevamente y verá el mismo resultado.

Usemos ahora los otros métodos de extensión de su biblioteca de clases portátil en su proyecto. La misma biblioteca portátil también se consumirá en su aplicación para UWP.

En este capítulo, discutiremos cómo agregar referencias a su biblioteca. Agregar referencias a la biblioteca es como agregar referencias a sus otros proyectos, como el proyecto de consola y el proyecto de UWP.

Ahora puede ver que el proyecto PCL tiene algunas referencias por defecto. También puede agregar otras referencias según las necesidades de su aplicación.

En la biblioteca PCL, también puede ver el archivo project.json.

{ 
   "supports": {}, 
   "dependencies": { 
      "NETStandard.Library": "1.6.0", 
      "Microsoft.NETCore.Portable.Compatibility": "1.0.1" 
   }, 
   "frameworks": { 
      "netstandard1.3": {} 
   } 
}

Un método para agregar referencias a su biblioteca es escribirlo directamente en el archivo project.json. Como puede ver, hemos agregado algunas referencias en la sección de dependencias como se muestra en el siguiente código.

{ 
   "supports": {}, 
   "dependencies": { 
      "NETStandard.Library": "1.6.0", 
      "Microsoft.NETCore.Portable.Compatibility": "1.0.1", 
      "System.Runtime.Serialization.Json": "4.0.3", 
      "Microsoft.EntityFrameworkCore": "1.1.0" 
   }, 
   "frameworks": { 
      "netstandard1.3": {} 
   } 
}

Guardemos ahora este archivo y verá que ahora se agregan referencias a su biblioteca.

El otro método para agregar referencias a su biblioteca es el Administrador de paquetes NuGet. Hagamos ahora clic derecho en elStringLibrary (Portable) proyecto y seleccione Mange NuGet Packages…

En la pestaña Examinar, puede buscar cualquier paquete NuGet; digamos que queremos agregar el paquete "System.Runtime.Serialization.Primitives".

Haga clic en el Install , que mostrará la siguiente pantalla.

Ahora, haga clic en el OK botón.

Finalmente, haga clic en el I Acceptpara iniciar la instalación de este paquete NuGet. Una vez finalizada la instalación, verá que el paquete NuGet “System.Runtime.Serialization.Primitives” se agrega a su biblioteca.

En este capítulo, analizaremos cómo compartir su biblioteca como NuGet Packagepara que se pueda consumir dentro de otro proyecto. La creación de un paquete comienza con el código que desea empaquetar y compartir con otros, ya sea a través de la galería pública de nuget.org o una galería privada dentro de su organización. El paquete también puede incluir archivos adicionales como unreadme que se muestra cuando se instala el paquete y puede incluir transformaciones en determinados archivos del proyecto.

Consideremos ahora un ejemplo simple en el que crearemos un paquete NuGet desde nuestra biblioteca. Para hacerlo, abra el símbolo del sistema y vaya a la carpeta donde se encuentra el archivo project.json de su proyecto de biblioteca.

Ejecutemos ahora el siguiente comando.

dotnet help

Al final, puede ver diferentes comandos como nuevo, restaurar y compilar, etc.

El último comando es pack;esto creará un paquete NuGet. Ejecutemos ahora el siguiente comando.

dotnet pack

Ahora puede ver que los paquetes NuGet se generan en la carpeta bin; abramos la carpeta bin \ Debug.

Ahora la pregunta es qué hay dentro de los paquetes NuGet, para ver que podemos usar NuGet Package Explorer. Abramos ahora el Explorador de paquetes NuGet.

Seleccione la primera opción Open a local package.

Selecciona el StringLibrary.1.0.0.nupkg y haga clic en Open.

Puede ver que en la sección Contenido del paquete solo tenemos StringLibrary.dll. En la sección de metadatos del paquete, verá un poco de información sobre esta biblioteca, como Id, Versiones y todas las dependencias.

Abramos ahora el StringLibrary.1.0.0.symbols.nupkg.

En este paquete de NuGet, verá los archivos de origen y el *.pdbarchivo también. Si hace doble clic en elStringLib.cs archivo, verá el código fuente también.

Aquí la pregunta es, cómo se pueden configurar los metadatos como versión, autores y descripción, etc.

El archivo project.json se usa en proyectos .NET Core para definir los metadatos, la información de compilación y las dependencias del proyecto. Abramos ahora el archivo project.json y agreguemos la siguiente información adicional.

{ 
   "authors": [ "Mark Junior" ], 
   "description": "String Library API", 
   "version" : "1.0.1-*", 
   "supports": {}, 
   
   "dependencies": { 
      "Microsoft.EntityFrameworkCore": "1.1.0", 
      "Microsoft.NETCore.Portable.Compatibility": "1.0.1", 
      "NETStandard.Library": "1.6.0", 
      "System.Runtime.Serialization.Json": "4.0.3", 
      "System.Runtime.Serialization.Primitives": "4.3.0" 
   }, 
   "frameworks": { 
      "netstandard1.3": {} 
   } 
}

Ahora puede ver información adicional como el nombre del autor, la descripción y la versión agregada aquí. Guardemos este archivo, construyamos el proyecto de la biblioteca y luego ejecutemos el comando "dotnet pack" nuevamente.

Dentro de la carpeta bin \ Debug, puede ver que los paquetes StringLibrary NuGet se producen con la versión 1.0.1; vamos a abrirlo en NuGet Package Explorer.

Verá los metadatos actualizados. La pregunta ahora es cómo podemos usarlo en otro paquete.

Necesitamos comenzar publicando en algún lugar de la fuente de NuGet y luego podemos consumirlo en otro proyecto.

Hay dos opciones para publicar los metadatos actualizados:

  • Publicarlo en nuget.org
  • Envíe los metadatos a una fuente NuGet privada

Aquí usaremos el feed privado de NuGet porque es mucho más fácil que configurar una cuenta en nuget.org. Para saber cómo publicar su paquete en nuget.org, puede seguir todas las pautas especificadas aquíhttps://docs.microsoft.com/en-us/nuget/create-packages/publish-a-package.

Siga estos pasos para enviar los metadatos actualizados a una fuente NuGet privada.

Step 1- Para empezar, necesitamos la utilidad de línea de comandos nuget y tenemos que instalarla. Ahora abramos NuGet Package Manager y busquemos nuget.commandline.

Step 2 - Seleccione Nuget.Commandline y haga clic en Install.

Step 3 - Click OKpara instalar Nuget.Commandline. También puede instalarlo manualmente descargándolo de la siguiente URLhttps://dist.nuget.org/index.html y luego configure la variable de entorno.

Step 4 - Una vez finalizada la instalación, volvemos a abrir el símbolo del sistema y vamos a la bin\Debug carpeta donde se encuentran los paquetes NuGet y especifique el siguiente comando:

nuget add StringLibrary.1.0.1.nupkg -Source D:\PrivateNugetPackages

Step 5 - En el comando anterior, agregamos el paquete StringLibrary.1.0.1.nupkg a nuestro feed privado y la ubicación es D:\PrivateNugetPackages, -Source especifica el origen del paquete.

Step 6 - Puedes ver que el StringLibraryesta instalado; laStringLibrary se puede agregar más al feed privado.

Step 7 - Vayamos a esa carpeta.

Step 8 - Dentro del stringlibrary carpeta, verá otra carpeta con el nombre de la versión y aquí está 1.0.1.

El paquete NuGet se encuentra aquí.

En este capítulo, analizaremos cómo consumir el paquete NuGet que hemos creado y publicado en una fuente privada de NuGet. Entonces, primero crearemos un proyecto Xamarin.Forms. Primero debemos comprender qué es Xamarin.Forms.

  • Xamarin.Forms es un marco que permite a los desarrolladores crear rápidamente interfaces de usuario multiplataforma.

  • Xamarin.Forms es una abstracción de kit de herramientas de interfaz de usuario con respaldo nativo multiplataforma que permite a los desarrolladores crear fácilmente interfaces de usuario que se pueden compartir en Android, iOS, Windows y Windows Phone.

  • Las interfaces de usuario se representan mediante los controles nativos de la plataforma de destino, lo que permite que las aplicaciones de Xamarin.Forms conserven el aspecto y la sensación adecuados para cada plataforma.

Para iniciar Xamarin.Forms, necesitamos algunas características adicionales en Visual Studio 2015. Permítanos modificar su Visual Studio 2015 y asegúrese de que la siguiente opción de desarrollo móvil multiplataforma esté seleccionada.

Una vez finalizada la instalación, actualice el Xamarin seleccionando Tools → Options…

Desplácese hacia abajo y expanda Xamarin en el panel izquierdo y luego seleccione Other. En la esquina superior derecha del cuadro de diálogo, haga clic enCheck Now para ver si hay actualizaciones disponibles.

Puede ver que hay actualizaciones disponibles, hagamos clic en el Downloadpara iniciar la descarga. Una vez finalizada la descarga, se le notificará para instalar las actualizaciones.

Abramos de nuevo Visual Studio y seleccionemos el File → New → Project… opción de menú.

En el panel izquierdo, seleccione el Visual C# → Cross-Platform plantilla y en el panel central, seleccione Blank Xaml App (Xamarin.Forms Portable). Ingrese el nombre en el campo Nombre y haga clic en Aceptar.

Seleccione la Versión de destino y la Versión mínima y haga clic en Aceptar.

Verá una serie de proyectos; en la parte superior tenemos la biblioteca PCL que se compartirá entre todas las plataformas como Android, iOS, UWP, Windows 8.1 y Windows Phone 8.1.

Aquí, nos centraremos en la biblioteca PCL y traeremos algo de código aquí. Expandamos el código.

En esta plantilla de Xamarin.Forms, puede ver App.xaml genérico y MainPage.xaml, usa el marco XAML de Xamarin.Forms que funciona en estas plataformas.

Necesitamos importar nuestros códigos y también necesitamos el feed NuGet privado que configuramos en el último capítulo.

Abramos ahora el Administrador de paquetes NuGet. Haga clic en la rueda junto a la lista desplegable Origen del paquete.

Necesitamos agregar nuestro feed privado aquí, hagamos clic en el plus (+) button.

Verá que se agrega otra casilla de verificación en el Available package sources sección, especifiquemos un nombre y una ruta de origen y haga clic en OK.

Vayamos ahora a la pestaña Examinar y seleccione PrivateSource de la lista desplegable Fuente del paquete y verá el paquete StringLibrary NuGet. Seleccione StringLibrary y haga clic enInstall.

Haga clic en Aceptar y verá un error.

No podemos usar la biblioteca con el perfil .NETPortable versión 259, solucionaremos este error en el próximo capítulo.

En este capítulo, corregiremos el error que obtuvimos al instalar el paquete NuGet desde nuestro feed privado en el proyecto Xamarin.Forms.

Entenderemos mejor el problema en breve. Para empezar, hagamos clic derecho en la biblioteca PCL y seleccione Propiedades.

En esta página, verá toda la serie de marcos específicos. Desde el error, puede ver que el perfil .NETPortable 259 no es compatible con nuestro StringLibrary 1.0.1. Sin embargo, está intentando hacer referencia a la biblioteca .NET Standard 1.1.

Veamos ahora la biblioteca estándar de .NET e identifiquemos qué plataforma no es compatible con nuestra biblioteca.

Puede ver que Windows Phone Silverlight 8 es compatible con .NET Standard 1.0. Si abre la siguiente página web, verá que Profile259 solo admite .NET Standard 1.0.

Desmarquemos ahora Windows Phone Silverlight 8.

Haga clic en el OK botón.

Ahora para solucionar este problema, haga clic en Aceptar y cancele el cuadro de diálogo Cambiar destinos y luego abra la Consola del Administrador de paquetes y ejecute el siguiente comando.

PM > Uninstall-Package Xamarin.Forms

Vayamos ahora a la biblioteca Propiedades de PCL. Haga clic en el botón Cambiar.

Desmarque Windows Phone Silverlight 8 y haga clic en Aceptar.

Ahora puede ver que Windows Phone Silverlight 8 ya no está disponible en Targeted framework. También puede ver el perfil que es el objetivo ahora. Para ver esto, descarguemos la biblioteca PCL y editemos el archivo XamarinApp.csproj.

Ahora puede ver que TargetFrameworkProfile ahora es Profile111.

Si abre la documentación, verá que Profile111 es compatible con .NET Standard 1.1.

Ahora recarguemos el PCL nuevamente y abramos el Administrador de paquetes NuGet e intentemos instalar el paquete StringLibrary desde una fuente privada.

En la lista desplegable Comportamiento de dependencia, seleccione Ignorar dependencias y luego haga clic en Install.

Puede ver que el paquete StringLibrary ahora está instalado desde el feed privado. Si expande las referencias de PCL, verá que la referencia de StringLibrary también se agrega como se muestra a continuación.

Habíamos desinstalado Xamarin.Forms para el problema de Windows Phone Silverlight 8. Es necesario volver a instalar Xamarin.Forms. Se recomienda instalar la misma versión.

Una vez que se complete la instalación, permítanos usar la funcionalidad StringLibrary en su aplicación.

En este capítulo, discutiremos cómo crear un proyecto de prueba usando .NET Core. La prueba unitaria es un proceso de desarrollo para el software que tiene las partes comprobables más pequeñas de una aplicación, que se denominan unidades. Se examinan de forma individual e independiente para comprobar su correcto funcionamiento. Las pruebas unitarias se pueden automatizar o realizar manualmente.

Abramos ahora el cuadro de diálogo Nuevo proyecto y seleccionemos Visual C# → .NET Core modelo.

En este cuadro de diálogo, puede ver que no hay una plantilla de proyecto para las pruebas unitarias. Para crear un proyecto de prueba unitaria, debemos usar la utilidad de línea de comando. Vayamos a la carpeta Solución que creamos; cree una carpeta de prueba y dentro de la carpeta de prueba cree otra carpeta y llámelaStringLibraryTests.

Usemos ahora la utilidad de línea de comandos dotnet para crear un nuevo proyecto de prueba ejecutando el siguiente comando:

dotnet new -t xunittest

Ahora puede ver que se crea un nuevo proyecto C #; echemos un vistazo a la carpeta ejecutando elv comando y verás project.json y Tests.cs archivos como se muestra a continuación.

Aquí está el código en el archivo project.json.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "debugType": "portable" 
   }, 
   "dependencies": { 
      "System.Runtime.Serialization.Primitives": "4.1.1", 
      "xunit": "2.1.0", 
      "dotnet-test-xunit": "1.0.0-rc2-192208-24" 
   }, 
   "testRunner": "xunit", 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { 
            "Microsoft.NETCore.App": { 
               "type": "platform", 
               "version": "1.0.1" 
            } 
         }, 
         "imports": [ 
            "dotnet5.4", 
            "portable-net451+win8" 
         ] 
      } 
   } 
}

A continuación se muestra el código del archivo Test.cs.

using System; 
using Xunit; 
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void Test1() { 
         Assert.True(true); 
      } 
   } 
}

Para obtener las dependencias necesarias de NuGet, ejecutemos el siguiente comando:

dotnet restore

Podemos ejecutar la prueba cuando se restablezcan las dependencias necesarias.

Puede ver que la compilación se realizó correctamente; a medida que baja podrá ver información sobre la prueba ejecutada.

Actualmente tenemos 1 prueba ejecutada, 0 error, 0 fallidos, 0 omitidos y el tiempo que tarda el proceso de ejecución también se menciona como información.

En este capítulo, discutiremos cómo ejecutar pruebas en Visual Studio. .NET Core se ha diseñado teniendo en cuenta la capacidad de prueba, por lo que la creación de pruebas unitarias para sus aplicaciones es más fácil que nunca. En este capítulo, ejecutaremos y ejecutaremos nuestro proyecto de prueba en Visual Studio.

Abramos la solución FirstApp en Visual Studio.

Puede ver que solo tiene dos proyectos y no podrá ver el proyecto de prueba porque no hemos agregado ese proyecto en nuestra solución.

Primero agreguemos una carpeta y llamémosla test.

Haga clic derecho en el test carpeta.

Seleccione project.json archivo y haga clic en Open.

La siguiente captura de pantalla muestra el código en Tests.cs archivo como salida.

Es la implementación predeterminada y solo está probando que True es igual a true. Es el marco de prueba de xUnit y verá el atributo Fact que anota y denota el método de prueba.

using System; 
using Xunit; 
  
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void Test1() { 
         Assert.True(true); 
      } 
   } 
}

A continuación se muestra la implementación de project.json archivo.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "debugType": "portable" 
   }, 
   "dependencies": { 
      "System.Runtime.Serialization.Primitives": "4.1.1", 
      "xunit": "2.1.0", 
      "dotnet-test-xunit": "1.0.0-rc2-192208-24" 
   }, 
   "testRunner": "xunit", 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { 
            "Microsoft.NETCore.App": { 
               "type": "platform", 
               "version": "1.0.1" 
            }
         }, 
         "imports": [ 
            "dotnet5.4", 
            "portable-net451+win8" 
         ] 
      } 
   } 
}

En project.json, la dependencia más importante del marco de prueba es xunit, que incluye el atributo Fact. Trae el marco de prueba y las API para probar con xunit.

Tambien tenemos el dotnet-test-xunit, este es un adoptador para que xunit pueda trabajar con .NET Core, específicamente con dotnet testutilidad de línea de comandos. Entonces verás eltestRunner que ejecutará xunit y también puede ver el netcoreapp1.0 marco de referencia.

Verá la dependencia .NETCore.App a continuación.

Para ejecutar la prueba en Visual Studio, abramos el Explorador de pruebas desde el Test → Window → Test Explorer opción de menú.

Y puede ver que Visual Studio detecta automáticamente la prueba. El nombre de la prueba consta denamespace.className.TestMethodName. Hagamos clic ahora enRun All button in Test Explorer.

Primero construirá el código y ejecutará la prueba y verá el tiempo total que tomó la prueba. Cambiemos el método de prueba para que podamos ver el resultado cuando falla la prueba.

using System; 
using Xunit; 
  
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void Test1() { 
         Assert.True(false); 
      } 
   } 
}

Ejecutemos la prueba nuevamente haciendo clic en el Run All enlace de botón.

Ahora puedes ver el test fracaso.

En este capítulo, probaremos nuestro StringLibrary y para hacerlo, necesitamos reorganizar nuestros proyectos para que podamos seguir la convención predeterminada.

Abramos el global.json archivo.

{ 
   "projects": [ "src", "test" ], 
   "sdk": { 
      "version": "1.0.0-preview2-003131" 
   } 
}

En la parte superior de este archivo, verá la configuración del proyecto y configura una carpeta como src y test por defecto.

Como por convención debemos tener proyectos en estas carpetas, esta es la nueva convención y se usará como parte de .NET Core.

En el Explorador de soluciones, puede ver que tanto el proyecto de la consola como el proyecto de la biblioteca están dentro del src carpeta mientras el proyecto de prueba está dentro test carpeta.

Y la estructura de proyectos en el Explorador de soluciones no representa dónde existen físicamente los proyectos en el disco. Ahora abramos la carpeta Solución y verá queStringLibrary el proyecto no está dentro del src carpeta.

Puedes ver que ambos src y test carpetas se asignan a la convención especificada en el global.jsonarchivo. Sin embargo, tenemos un proyecto StringLibrary que está fuera de la convención. Agreguemos ahora elStringLibrary proyecto dentro del src carpeta.

En la carpeta src, tenemos dos proyectos y necesitamos solucionar el problema para poder usar todos los proyectos correctamente. Regresemos a Visual Studio, hagamos clic derecho en el proyecto StringLibrary y seleccionemos la opción Eliminar. No lo eliminará, pero solo eliminará el proyecto.

Ahora haga clic derecho en la carpeta src y seleccione Add → Existing Project…

Busque el proyecto StringLibrary que ahora está dentro del src carpeta, seleccione la StringLibrary.csproj archivo y haga clic en Open.

Ahora tenemos que eliminar la referencia de StringLibrary desde el project.json archivo de la aplicación de consola.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      }, 
      "NuGet.CommandLine": "3.5.0", 
      "System.Runtime.Serialization.Json": "4.0.3" 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { }, 
         "imports": "dnxcore50" 
      } 
   } 
}

Guarde los cambios y luego agregue una referencia de StringLibrary nuevamente en su proyecto de consola.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      }, 
   "NuGet.CommandLine": "3.5.0", 
      "System.Runtime.Serialization.Json": "4.0.3" 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { 
            "StringLibrary": { 
               "target": "project" 
            } 
         }, 
         "imports": "dnxcore50" 
      } 
   } 
}

Ahora todo debería funcionar de nuevo y puedes construir StringLibrary y entonces FirstApp(proyecto de consola) sin ningún error. Probemos ahora la funcionalidad StringLibrary usando xunit. Necesitamos agregar una referencia de StringLibrary en nuestro proyecto de prueba. Haga clic con el botón derecho en el proyecto Referencias de StringLibraryTests y seleccione Agregar referencia ...

Hacer clic OK que agregará una referencia de StringLibrarya nuestro proyecto de prueba. Reemplacemos ahora el siguiente código en elTests.cs archivo.

using System; 
using Xunit; 
using StringLibrary; 
  
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void StartsWithUpperCaseTest() { 
         string input = "Mark"; 
         Assert.True(input.StartsWithUpper()); 
      } 
      [Fact] 
      public void StartsWithLowerCaseTest() { 
         string input = "mark"; 
         Assert.True(input.StartsWithLower()); 
      } 
      [Fact] 
      public void StartsWithNumberCaseTest() { 
         string input = "123"; 
         Assert.True(input.StartsWithNumber()); 
      } 
   } 
}

Puede ver que tenemos tres métodos de prueba que probarán la funcionalidad de StringLibrary. Hagamos clic en elRun All enlace y verá el siguiente resultado en Test Explorer.

También puede ejecutar las pruebas desde la línea de comandos. Abramos el símbolo del sistema y ejecutemos eldotnet test mando.

En este capítulo, analizaremos el marco de extensibilidad administrado (MEF). MEF se puede utilizar para la extensibilidad de complementos de terceros, o puede aportar los beneficios de una arquitectura similar a un complemento de acoplamiento flexible a las aplicaciones habituales.

  • MEF es una biblioteca para crear aplicaciones ligeras y extensibles.

  • Permite a los desarrolladores de aplicaciones descubrir y utilizar extensiones sin necesidad de configuración.

  • MEF es una parte integral de .NET Framework 4 y está disponible dondequiera que se utilice .NET Framework, lo que mejora la flexibilidad, la capacidad de mantenimiento y la capacidad de prueba de grandes aplicaciones.

  • Puede utilizar MEF en sus aplicaciones cliente, ya sea que utilicen Windows Forms, WPF o cualquier otra tecnología, o en aplicaciones de servidor que utilicen ASP.NET.

  • MEF se ha portado como Microsoft.Composition a .NET Core también, pero parcialmente.

  • Solamente System.Composition es portado, y System.ComponentModel.Compositionaún no está disponible. Esto significa que no tenemos los catálogos que pueden cargar tipos de ensamblados en un directorio.

En este capítulo, solo aprenderemos cómo podemos usar MEF en la aplicación .NET Core.

Entendamos un ejemplo simple en el que usaremos MEF en la aplicación de consola .NET Core. Creemos ahora un nuevo proyecto de consola .NET Core.

En el panel izquierdo, seleccione Templates → Visual C# → .NET Core y luego en el panel central, seleccione Aplicación de consola (.NET Core).

Ingrese el nombre del proyecto en el campo Nombre y haga clic en Aceptar.

Una vez creado el proyecto, necesitamos agregar la referencia de Microsoft.Composition para que podamos usar MEF. Para hacerlo, hagamos clic derecho en el proyecto en el Explorador de soluciones yManage NuGet Packages…

Buscar Microsoft.Composition y haga clic en Install.

Haga clic en el OK botón.

Haga clic en el I Accept botón.

Cuando se complete la instalación, encontrará un error en Referencias.

Abramos el project.json archivo.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
  
   "dependencies": { 
      "Microsoft.Composition": "1.0.30", 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      } 
   }, 
  
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "dnxcore50" 
      } 
   } 
}

Puedes ver que el Microsoft.Composition Se agrega dependencia, pero el problema es que este paquete no es compatible con dnxcore50. Entonces necesitamos importarportablenet45+win8+wp8+wpa81. Permítanos ahora reemplazar suproject.json archivo con el siguiente código.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.Composition": "1.0.30", 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1"
      } 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "portable-net45+win8+wp8+wpa81" 
      } 
   } 
}

Guarde este archivo y verá que el error se corrige.

Si expande las Referencias, verá una referencia de Microsoft.Composition.

Primero necesitamos crear una interfaz que se va a exportar e implementar la interfaz y decorar la clase con el atributo de exportación. Agreguemos ahora una nueva clase.

Ingrese el nombre de su clase en el campo Nombre y haga clic en Add.

Agreguemos el siguiente código en el PrintData.cs archivo.

using System; 
using System.Collections.Generic; 
using System.Composition; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace MEFDemo { 
   public interface IPrintData { 
      void Send(string message); 
   } 
   [Export(typeof(IPrintData))] 
   public class PrintData : IPrintData { 
      public void Send(string message) { 
         Console.WriteLine(message); 
      } 
   } 
}

Como se mencionó anteriormente, los catálogos no están disponibles en el espacio de nombres Microsoft.Composition. Por lo tanto, cargará todos los tipos del ensamblado con el atributo de exportación y se adjuntará al atributo de importación como se muestra en el método Compose en el archivo Program.cs.

using System; 
using System.Collections.Generic; 
using System.Composition; 
using System.Composition.Hosting; 
using System.Linq; 
using System.Reflection; 
using System.Threading.Tasks; 
  
namespace MEFDemo { 
   public class Program { 
      public static void Main(string[] args) { 
         Program p = new Program(); 
         p.Run(); 
      } 
      public void Run() { 
         Compose(); 
         PrintData.Send("Hello,this is MEF demo"); 
      } 
      [Import] 
      public IPrintData PrintData { get; set; } 
      
      private void Compose() { 
         var assemblies = new[] { typeof(Program).GetTypeInfo().Assembly }; 
         var configuration = new ContainerConfiguration() 
            .WithAssembly(typeof(Program).GetTypeInfo().Assembly); 
         
         using (var container = configuration.CreateContainer()) { 
            PrintData = container.GetExport<IPrintData>(); 
         } 
      } 
   } 
}

Ejecutemos ahora su aplicación y verá que se está ejecutando al crear una instancia del PrintData clase.

Para obtener más información sobre MEF, visite la siguiente URL https://msdn.microsoft.com/en-us/library/dd460648%28v=vs.110%29.aspx para más detalles.

En este capítulo, comprenderemos las próximas características de .NET Core. Comenzaremos con las herramientas de línea de comandos de .NET abriendo la siguiente URL en el navegadorhttps://github.com/dotnet/cli

Para saber más sobre el progreso, puede descargar la última versión de .NET Core SDK desplazándose hacia abajo y verá la sección Instalador y binarios.

Puede ver la última versión de las herramientas de vista previa para diferentes sistemas operativos, permítanos seleccionar el instalador según su sistema operativo.

Estamos trabajando en la versión preliminar 1 de .NET Core 2.0.

Veamos ahora nuestras herramientas actuales abriendo el símbolo del sistema y ejecutando el siguiente comando.

dotnet --info

Verá información sobre la versión actualmente instalada de .NET Command Line Tools en su sistema, como se muestra a continuación.

Puede ver que actualmente tenemos una vista previa de 2 herramientas. Ejecutemos ahora el siguiente comando para ver acerca delnew mando.

dotnet help new

Para el nuevo lenguaje de comandos del proyecto, puede seleccionar como C # y F # y el tipo de proyecto, etc.

Veamos ahora los cambios en la última versión de .NET Core. Una vez descargado el instalador, haz doble clic en él para instalarlo. Haga clic en Instalar.

La siguiente captura de pantalla muestra el proceso de instalación.

Comenzará el proceso de instalación. Una vez finalizada la instalación, cierre este cuadro de diálogo.

Abra el símbolo del sistema y ejecute el siguiente comando.

dotnet --info

Verá información de la versión actualmente instalada de .NET Command Line Tools en su sistema como se muestra a continuación.

Ahora puede ver que tenemos herramientas de vista previa1 de .NET Core 2. Ejecutemos ahora el siguiente código en el símbolo del sistema para ver sobre el nuevo comando en .NET Core 2 vista previa1.

dotnet help new

El comando le ayuda a descargar paquetes también a la caché de paquetes.

El comando abre la siguiente página web que contiene información sobre el nuevo comando en .NET Core 2 preview1.

Desplácese hacia abajo, ahora puede ver que podemos crear la aplicación .NET Core con más plantillas.

Ahora podemos crear mstest, web, mvc y webapi proyectos también usando la línea de comando.

.NET Core ha decidido eliminar project.json y volver a MSBuild y * .csproj. Esto es algo que ya sucedió en las herramientas de vista previa1 .Net Core 2.0 recién lanzadas. Esto es bastante decepcionante, porque el project.json fue un soplo de aire fresco. Sin embargo, es comprensible y también tiene muchas ventajas.

Analicemos ahora las ventajas que aporta el cambio:

  • Haría sencilla la transición de las soluciones de Visual Studio existentes a .NET Core.

  • Es un cambio enorme y también permitirá aprovechar la inversión existente en CI / RM basada en MSBuild.

  • Durante la compilación en MSBuild, podemos pensar en la compilación incremental, la resolución de dependencias del tiempo de compilación, la gestión de la configuración, etc.

  • Se requiere mucho trabajo para enviar dotnet cli a tiempo, porque ya no se trata solo de ASP.NET Core, sino también de aplicaciones de consola, aplicaciones para UWP, etc.

A continuación se muestran los cambios en MSBuild y * .csproj:

  • El archivo Project.json (* .xproj) será reemplazado por MSBuild (* .csproj).

  • Las características en project.json comenzarán a fusionarse nuevamente en el * .csproj.

  • Todavía no está claro qué van a hacer con la lista de paquetes, pero se mencionó que podrían mantenerla como json en nuget.json o fusionarlo en el *.csproj.

  • Supuestamente, esa transición debería ser suave y potencialmente automática si se usa Visual Studio.

Ventajas de MSBuild

  • MSBuild es de código abierto y está disponible en GitHub y está destinado a convertirse en una plataforma completamente cruzada.

  • MSBuild simplificará y recortará drásticamente la estructura del *.csproj.

  • Microsoft también está presentando un nuevo sistema de proyectos que permitirá muchos escenarios sin la necesidad de Visual Studio y los detalles se dan en esta URL. https://github.com/dotnet/roslyn-project-system/.

  • El objetivo es que incluso con la configuración de MSBuild, trabajar con compilaciones y proyectos sea tan fluido en Visual Studio IDE como fuera de él.

MSBuild vs project.json

Creemos ahora un nuevo proyecto de consola con las herramientas de .NET Core preview2 ejecutando el siguiente comando.

dotnet new -t console

Para ver todos los archivos creados dentro de este proyecto, ejecute el dir mando.

Puede ver que se crean dos archivos, Program.cs y project.json archivo.

Creemos ahora una aplicación de consola con las herramientas de .NET Core 2 preview1 ejecutando el siguiente comando.

dotnet new console

Para ver todos los archivos creados dentro de este proyecto, ejecute el dirmando. Puede ver que se crean tres archivos,Program.cs, NuGet.config y MSBuild.csproj en lugar del archivo project.json.

Ahora comparemos project.json y MSBuild.csproj archivos uno al lado del otro.

A la izquierda, tenemos el archivo en formato json mientras que a la derecha, el archivo está en formato XML. Puede ver que en el archivo project.json, dentro de la sección de dependencias, haynetcoreapp1.0, mientras que en el archivo MSBuild.csproj, verá el netcoreapp2.0.

En este capítulo, discutiremos cómo restaurar y construir su archivo MSBuild (* .csproj) usando la utilidad de línea de comandos. Para ver qué comandos están disponibles en la vista previa 1 de .NET Core 2.0, ejecutemos el siguiente comando.

dotnet help

Verá todos los comandos como nuevo, restaurar, construir, etc.

A continuación se muestra la implementación predeterminada en Program.cs archivo.

using System;  
namespace MSBuild { 
   class Program { 
      static void Main(string[] args) { 
         Console.WriteLine("Hello World!"); 
      } 
   } 
}

Ejecutemos ahora el siguiente comando para ver el progreso.

dotnet build

Verás muchos errores. Estos errores deben rectificarse.

Ejecutemos ahora el siguiente comando.

dotnet restore

Puede ver que todos los paquetes están restaurados. También se han generado algunas carpetas y archivos nuevos.

Para ver la estructura del directorio, ejecutemos el siguiente comando.

tree /f

A continuación se muestra la estructura del directorio:

Reconstruyamos ahora el proyecto ejecutando el siguiente comando nuevamente.

dotnet build

Ahora su proyecto se compilará con éxito sin ningún error y también se creará MSBuild.dll.

Para ver el resultado, ejecutemos el siguiente comando:

dotnet run

Puede ver el siguiente resultado en su consola.

En este capítulo, migraremos la aplicación de consola que contiene el project.json sistema de construcción de archivos en lugar de MSBuild (*.csproj). Entonces, tenemos un proyecto antiguo que contiene los siguientes archivos.

Ahora la pregunta es, ¿por qué necesitamos la migración? Este proyecto se crea utilizando las herramientas .NET Core 1.0 Preview 2 y ahora hemos instalado las herramientas .NET Core 2.0 Preview 1. Ahora, cuando cree esta aplicación con la utilidad de línea de comandos .NET Core 2.0, verá el siguiente error.

Esto es porque el project.jsonEl sistema de compilación ya no está disponible en .NET Core 2.0, por lo que necesitamos una migración para que funcione correctamente. Para ver los comandos disponibles, ejecutemos el siguiente comando.

dotnet help

En la sección de comandos, puede ver los diferentes comandos y también puede ver el migrate comando que migrará un proyecto basado en project.json a un proyecto basado en MSBuild.

Ejecutemos ahora el siguiente comando.

dotnet migrate

Verá un resumen del proceso de migración y aquí también podrá ver que un proyecto se migró correctamente.

Veamos ahora la estructura del directorio usando el siguiente comando.

tree /f

Ahora verá el archivo * .csproj junto con el archivo Program.cs en el directorio raíz del proyecto y project.json se mueve a la carpeta de respaldo.

Abramos el console.csprojarchivo. Ahora puede restaurar y construir este proyecto usando el sistema MSBuild ejecutando el siguiente comando.

dotnet restore

Ahora puede ver que todos los paquetes están restaurados.

Ahora puede construir su proyecto con el siguiente comando.

dotnet build

Ahora puede ver que el proyecto se ha creado correctamente con MSBuild y que también se genera console.dll en ..\bin\Debug\netcoreapp1.0 carpeta.

La siguiente captura de pantalla muestra la estructura del directorio y los archivos.