dotnet cli es una de las características más útiles de .Net Core. En este artículo, presentaremos cómo varias herramientas .Net OSS usan dotnet cli y cómo usar la nueva herramienta cli en el desarrollo diario.
Texto
Puntos clave
- dotnet cli hace que la automatización y las secuencias de comandos basadas en proyectos .Net sean muy simples, especialmente en comparación con la tecnología .Net hace más de una década.
- El modelo de escalabilidad dotnet cli crea las condiciones que hacen posible integrar programas de línea de comandos escritos en .NET externo en su compilación automatizada a través de Nuget.
- dotnet cli le permite probar la solución en su script de compilación.
- La salida de prueba de dotnet cli ayuda a utilizar mejor la integración continua (CI).
- Usar tecnología de contenedores como Docker es mucho más fácil que usar dotnet cli.
Con el lanzamiento de .NET Core 2.0, Microsoft tiene la próxima versión principal de la plataforma universal, modular, multiplataforma y de código abierto, que se lanzó originalmente en 2016. .NET Core ha creado muchas API, que están disponibles en la versión actual de .NET Framework. Originalmente se creó para la solución ASP.NET de próxima generación, pero ahora es la fuerza impulsora y la base de muchos otros escenarios, incluidos Internet de las cosas, la nube y las soluciones móviles de próxima generación. En la segunda serie de artículos sobre .NET Core, exploraremos más a fondo las ventajas de .NET Core y cómo beneficia no solo a los desarrolladores de .NET tradicionales, sino también a todos aquellos que necesitan proporcionar al mercado una solución sólida y eficiente Y soluciones económicas para el personal técnico.
Alguien me ha preguntado recientemente, ¿cuáles son las ventajas de elegir .NET Core en comparación con aquellos que dudan o no pueden retirarse del antiguo .NET con todas las funciones? Mencionaré en mi respuesta que .NET Core tiene un mejor rendimiento, un formato de archivo csproj mejorado, una capacidad de prueba ASP mejorada y es multiplataforma.
Como autor de varias herramientas de OSS (Marten, StructureMap y Alba citado como ejemplo en este proyecto), la mayor ventaja para mí personalmente puede ser la aparición de dotnet cli. Personalmente, creo que cuando se usa junto con el nuevo formato de archivo .NET SDK csproj, la herramienta dotnet cli me facilita la creación de proyectos y el mantenimiento de scripts de compilación. Puedo ejecutar pruebas en scripts de compilación más fácilmente, usar y distribuir paquetes Nuget más fácilmente, y el mecanismo de extensibilidad cli es ideal para fusionar archivos ejecutables personalizados distribuidos a través de paquetes Nuget en compilaciones automáticas.
Para comenzar a usar dotnet cli, primero instale .NET SDK en la máquina de desarrollo. Una vez completada la instalación, le daremos algunos consejos útiles:
- Instale la herramienta "dotnet" globalmente en su RUTA para que se pueda usar desde la línea de comandos en cualquier lugar.
- dotnet cli adopta la sintaxis de comandos al estilo Linux, usando "–word [value]" para expresar el parámetro seleccionado, o directamente usando la forma abreviada "-w [value]". Si está acostumbrado a las herramientas de línea de comandos Git o Node.js, no será extraño para dotnet cli.
- "Dotnet --help" enumerará los comandos instalados y algunos usos básicos de sintaxis.
- "Dotnet --info" le dirá qué versión de dotnet cli está utilizando. Puede ser una buena idea llamar a este comando en una compilación de integración continua para trabajar localmente y solucionar problemas cuando falla el servidor de compilación, y viceversa.
- Aunque estoy hablando de .NET Core en este artículo, tenga en cuenta que puede usar el nuevo formato de proyecto SDK y dotnet cli en versiones anteriores del marco completo .NET.
Hola mundo en la línea de comando
Para comprender brevemente algunos de los aspectos más destacados de dotnet cli, supongamos que queremos crear una aplicación ASP.NET Core simple "Hello World". Sin embargo, por diversión, agreguemos algunos trucos nuevos:
1. Nuestro servicio web se probará automáticamente en un proyecto separado.
2. Implementaremos nuestro servicio a través de un contenedor Docker porque esta es una práctica genial (muestra más cli de dotnet).
3. Por supuesto, usaremos dotnet cli tanto como sea posible.
Si desea ver el resultado final de este código, consulte este repositorio de GitHub.
Primero, comencemos con un directorio vacío llamado "DotNetCliArticle" y abra su herramienta de línea de comandos favorita en ese directorio. Comenzaremos usando el comando "dotnet new" para generar archivos de solución y nuevos proyectos. .NET SDK viene con varias plantillas comunes para crear tipos o archivos de proyectos comunes, y otras plantillas que se pueden usar como complementos (más sobre esto más adelante). Para ver las plantillas disponibles en su máquina, puede usar el siguiente comando dotnet new -help, debería dar el siguiente resultado:
Puede notar que hay una plantilla sln, que es para un archivo de solución vacío. Utilizaremos la plantilla y escribiremos el comando dotnet new sln, que producirá el siguiente resultado:
Código de copia
La plantilla "Archivo de solución" se creó con éxito.
Por defecto, este comando nombrará el archivo de solución después del directorio incluido. Como denominé el directorio raíz "DotNetCliArticle", el archivo de solución generado es "DotNetCliArticle.sln".
A continuación, agreguemos el proyecto real de "Hello, World" con el siguiente comando:
Código de copia
dotnet new webapi --salida HeyWorld
El comando anterior significa usar la plantilla "webapi" en el "HeyWorld" seleccionado por el parámetro "output". Esta plantilla generará una estructura de proyecto MVC Core optimizada adecuada para API sin cabeza. Del mismo modo, el método predeterminado es nombrar el archivo del proyecto de acuerdo con el directorio donde se encuentra, por lo que obtenemos un archivo llamado "HeyWorld.csproj" y todos los archivos básicos en el directorio para formar un proyecto mínimo de API ASP.NET MVC Core. La plantilla también configura todas las referencias necesarias de Nuget a ASP.NET Core, que usaremos cuando comencemos un nuevo proyecto.
Desde que lo construí en un pequeño repositorio de Git, después de usar Git add para agregar cualquier archivo nuevo, utilicé el estado de Git para ver los archivos recién creados:
Código de copia
nuevo archivo: HeyWorld / Controllers / ValuesController.cs
nuevo archivo: HeyWorld / HeyWorld.csproj
nuevo archivo: HeyWorld / Program.cs
nuevo archivo: HeyWorld / Startup.cs
nuevo archivo: HeyWorld / appsettings.Development.json
nuevo archivo: HeyWorld / appsettings .json
Ahora, para agregar un nuevo proyecto a nuestro archivo de solución vacío, puede usar el comando "dotnet sln" de esta manera:
Código de copia
dotnet sln DotNetCliArticle.sln agregar HeyWorld / HeyWorld.csproj
Ahora tenemos un nuevo servicio ASP.NET Core API como shell, sin abrir Visual Studio.NET (o JetBrains Rider). Para ir más allá, para comenzar nuestro proyecto de prueba antes de escribir cualquier código real, emito el siguiente comando:
Código de copia
dotnet new xunit --output HeyWorld.Tests dotnet
sln DotNetCliArticle.sln add HeyWorld.Tests / HeyWorld.Tests.csproj
El comando anterior usa xUnit.NET para crear un nuevo proyecto y agregar el nuevo proyecto a nuestro archivo de solución. El proyecto de prueba necesita una referencia al proyecto "HeyWorld". Afortunadamente, podemos usar la excelente herramienta "dotnet add" para agregar la referencia del proyecto de la siguiente manera:
Código de copia
dotnet add HeyWorld.Tests / HeyWorld.Tests.csproj referencia HeyWorld / HeyWorld.csproj
Antes de abrir la solución, sabía que había algunas referencias de Nuget, y quería usarlas en el proyecto de prueba. La herramienta de afirmación que elegí es Shoully, por lo que agregaré una referencia a la última versión de debería emitir otra llamada a la línea de comando:
Código de copia
dotnet agregar paquete HeyWorld.Tests / HeyWorld.Tests.csproj debería
La salida de la línea de comando es la siguiente:
Código de copia
info: Agregar PackageReference para el paquete 'debería' en el proyecto 'HeyWorld.Tests / HeyWorld.Tests.csproj'.
log: Restaurar paquetes para /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/HeyWorld.Tests.csproj ...
info: GET https://api.nuget.org/v3-flatcontainer/shouldly/index.json
info: OK https://api.nuget.org/v3-flatcontainer/shouldly/index.json 109ms
información: El paquete 'debería' es compatible con todos los marcos especificados en el proyecto 'HeyWorld.Tests / HeyWorld.Tests.csproj'.
info: PackageReference para el paquete 'Shouldly' versión '3.0.0' agregada al archivo '/Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/HeyWorld.Tests.csproj'.
A continuación, quiero agregar al menos una referencia de Nuget al proyecto de prueba llamado Alba. Usaré AspNetCore2 para escribir pruebas de contrato HTTP para nuevas aplicaciones web:
Código de copia
dotnet agregar paquete HeyWorld.Tests / HeyWorld.Tests.csproj Alba.AspNetCore2
Ahora, antes de usar el código para verificar, emitiré el siguiente comando en la línea de comando para compilar todos los proyectos en la solución y asegurarme de que todos compilan correctamente:
Código de copia
dotnet build DotNetCliArticle.sln
Debido al conflicto entre las versiones dependientes de diamantes de las referencias entre Alba.AspNetCore2 y ASP.NET Core Nuget en el proyecto HeyWorld, no hay compilación. Pero no se preocupe, porque este problema es fácil de resolver, solo arregle la dependencia de la versión de Microsoft.AspNetCore. Todo Nuget en el proyecto de prueba se ve así:
Código de copia
dotnet add HeyWorld.Tests / HeyWorld.Tests.csproj package Microsoft.AspNetCore.All --version 2.1.2
En el ejemplo anterior, el uso del indicador "--version" con un valor de "2.1.2" arreglará la referencia a esa versión, no solo la última versión encontrada en el feed de Nuget.
Para verificar nuevamente si nuestro problema de dependencia de Nuget ha sido resuelto, podemos usar el siguiente comando para verificar, es más rápido que recompilar todo:
Código de copia
dotnet clean && dotnet restore DotNetCliArticle.sln
Como desarrollador experimentado de .NET, estoy muy preocupado por los archivos que quedan en las carpetas temporales / obj y / bin. Por lo tanto, uso el comando "Solución limpia" en Visual Studio en caso de que trate de cambiar lo que se cae cuando me refiero a él. Ejecutar el comando "dotnet clean" desde la línea de comandos es exactamente la misma operación.
Del mismo modo, para el conocido problema de dependencia de Nuget, el comando "restauración dotnet" intentó resolverlo en la solución. En este caso, el uso de "restauración dotnet" nos permite encontrar rápidamente cualquier conflicto potencial o la falta de referencias de Nuget sin tener que realizar una compilación completa. Utilizo principalmente este comando en mi trabajo. En la última versión de dotnet cli, cuando llama "dotnet build / test / pack / etc", el análisis de Nuget se realizará automáticamente (este comportamiento puede sobrescribirse con etiquetas), que primero requerirá Nuget.
La "restauración dotnet DotNetCliArticle.sln" que llamamos terminó de ejecutarse limpiamente y sin errores, por lo que finalmente podemos prepararnos para escribir algo de código. Abramos el editor de C # de su elección y agreguemos un archivo de código a HeyWorld. El proyecto de prueba contiene una prueba de protocolo HTTP muy simple que especificará el comportamiento que queremos obtener de la ruta "GET: /" en la nueva aplicación HeyWorld:
Código de copia
usando System.Threading.Tasks;
usando Alba;
usando Xunit;
espacio de nombres HeyWorld.Tests
{
public class generate_the_endpoint
{
[Fact]
public async Task check_it_out ()
{
using (var system = SystemUnderTest.ForStartup <Startup> ())
{
await system.Scenario (s =>
{
s.Get.Url (" / ");
s.ContentShouldBe (" Hola, mundo ");
s.ContentTypeShouldBe (" text / plain; charset = utf-8 ");
});
}
}
}
}
El archivo de resultados debe guardarse en el directorio HeyWorld.Tests con un nombre apropiado (como Verified_the_endpoints.cs).
Antes de tener una comprensión profunda del mecanismo de Alba, el enrutamiento de la página de inicio de nuestra nueva aplicación HeyWorld debería escribir "Hey, mundo". Aunque no hemos escrito ningún código real en la aplicación HeyWorld, aún podemos ejecutar esta prueba para ver si se puede conectar correctamente o si falla por alguna "razón razonable".
De vuelta en la línea de comando, puedo usar el siguiente comando para ejecutar todas las pruebas en el proyecto de prueba:
Código de copia
prueba dotnet HeyWorld.Tests / HeyWorld.Tests.csproj
Una de nuestras pruebas fallará porque todavía no se ha implementado nada, nos da este resultado:
Código de copia
La construcción comenzó, por favor espere ...
Construcción completada.
Prueba ejecutada para /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/bin/Debug/netcoreapp2.1/HeyWorld.Tests.dll(.NETCoreApp,Version=v2.1)
Microsoft (R) Test Execution Command Line Tool Version 15.7 .0
Copyright (c) Microsoft Corporation. Todos los derechos reservados.
Iniciando la ejecución de la prueba, espere ...
Total de pruebas: 1. Aprobada: 1. Fallida: 0. Saltada: 0.
Prueba ejecutada con éxito.
Tiempo de ejecución de prueba: 2.4565 segundos
Para resumir el resultado, se ejecutó una prueba, pero falló. También podemos ver la salida estándar de xUnit, que proporciona información sobre por qué falló la prueba. Cabe señalar aquí que el comando "dotnet test" devolverá un código de salida. Si todas las pruebas pasan, devuelve 0, lo que indica éxito; si alguna prueba falla, devuelve un código de salida distinto de cero, lo que indica error. Esto es muy importante para los scripts de integración continua (CI), y la mayoría de las herramientas de CI utilizan el código de salida de cualquier comando para determinar cuándo falla la compilación.
Creo que la prueba anterior falló debido a la "razón razonable", lo que significa que la herramienta de prueba parece ser capaz de guiar la aplicación real, y quiero obtener una respuesta 404 porque todavía no se ha escrito ningún código. A continuación, implementemos un punto final MVC Core para el comportamiento esperado:
Código de copia
public class HomeController: Controller
{
[HttpGet ("/")]
cadena pública SayHey ()
{
return "¡Hola, mundo!";
}
}
(Tenga en cuenta que el código anterior debe agregarse como una clase adicional en el archivo HeyWorld \ startup.cs)
Volviendo a la línea de comando nuevamente, ejecutemos el comando anterior "dotnet test HeyWorld.Tests / HeyWorld.Tests.csproj", esperando ver este resultado:
Código de copia
La construcción comenzó, por favor espere ...
Construcción completada.
Prueba ejecutada para /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/bin/Debug/netcoreapp2.1/HeyWorld.Tests.dll(.NETCoreApp,Version=v2.1)
Microsoft (R) Test Execution Command Line Tool Version 15.7 .0
Copyright (c) Microsoft Corporation. Todos los derechos reservados.
Iniciando la ejecución de la prueba, espere ...
Total de pruebas: 1. Aprobada: 1. Fallida: 0. Saltada: 0.
Prueba ejecutada con éxito.
Tiempo de ejecución de prueba: 2.4565 segundos
Ok, ahora que la prueba ha pasado, ejecutemos la aplicación real. Dado que la plantilla "dotnet new webapi" utiliza el servidor web Kestrel en proceso para procesar las solicitudes HTTP, lo único que debemos hacer para ejecutar la nueva aplicación HeyWorld es iniciarla desde la línea de comandos con el siguiente comando:
Código de copia
dotnet run --project HeyWorld / HeyWorld.csproj
La ejecución del comando anterior debería dar como resultado el siguiente resultado:
Código de copia
Uso de la configuración de inicio de HeyWorld / Properties / launchSettings.json ...
: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager [0]
El perfil de usuario está disponible. Usando '/Users/jeremydmiller/.aspnet/DataProtection-Keys' como depósito de claves; Las claves no se cifrarán en reposo.
Entorno de alojamiento:
Ruta de acceso de contenido de desarrollo : / Users / jeremydmiller / code / DotNetCliArticle / HeyWorld
Ahora escuchando en: https: // localhost: 5001
Ahora escuchando en: http: // localhost: 5000
Aplicación iniciada. Presione Ctrl + C para apagar.
Para probar la nueva aplicación que estamos ejecutando ahora, simplemente navegue en el navegador de la siguiente manera:
El manejo de la configuración HTTPS está más allá del alcance de este artículo.
Tenga en cuenta nuevamente que supongo que todos los comandos se ejecutan con el directorio actual establecido como la carpeta raíz de la solución. Si el directorio actual es un directorio de proyecto y solo hay un * .csproj. Luego, solo necesita escribir "dotnet run" en el directorio. Ahora que tenemos una aplicación web api probada, pongamos HeyWorld en la imagen de Docker. Usando la plantilla estándar para acoplar una aplicación .NET Core, agregaremos un Dockerfile al proyecto HeyWorld con el siguiente contenido:
Código de copia
DESDE microsoft / dotnet: sdk AS build-env
WORKDIR / app
Copie csproj y restaure como capas distintas
COPY * .csproj ./
RUN dotnet restore
Copie todo lo demás y compile
COPY. ./ EJECUTAR dotnet Publique
-c Lanzamiento -o fuera
Cree una imagen en tiempo de ejecución
DESDE microsoft / dotnet: aspnetcore-runtime
WORKDIR / app
COPY --from = build-env / app / out.
ENTRYPOINT ["dotnet", "HeyWorld.dll"]
(Tenga en cuenta que el texto anterior debe guardarse en un archivo de texto llamado Dockerfile en el directorio del proyecto: HeyWorld \ Dockerfile en este ejemplo).
Debido a que este artículo es solo sobre dotnet cli, solo quiero centrarme en dos usos en el Dockerfile:
1. "restauración dotnet": como aprendimos anteriormente, este comando resolverá las dependencias de Nuget de la aplicación.
2. El comando "dotnet Publish -c Release -o out" - "dotnet Publish" construirá el proyecto especificado y copiará todos los archivos que componen la aplicación en la ubicación dada. En nuestro ejemplo, "dotnet Publish" copiará los ensamblados compilados, todos los ensamblados a los que se hace referencia desde las dependencias de Nuget, los archivos de configuración y cualquier archivo al que se haga referencia en el archivo csproj para HeyWorld.
Tenga en cuenta que en el uso anterior, debemos decirle explícitamente a "dotnet Publish" que compile con "Release" utilizando el indicador "-c Release". Esos comandos dotnet cli utilizados para la codificación (como "compilar", "publicar", "paquete") si no se especifican, el valor predeterminado será "Depurar". Preste atención a este comportamiento, si desea liberar Nuget o aplicaciones para producción, recuerde especificar "-c Release" o "-configuration Release". No me culpes por no recordarte.
Para completar todo el ciclo, ahora podemos usar los siguientes comandos para construir e implementar nuestra pequeña aplicación HeyWorld a través de Docker:
Código de copia
Docker build -t heyworld.
docker run -d -p 8080: 80 --name myapp heyworld
El primer comando crea y publica la imagen de Docker localmente para nuestra aplicación "heyworld". El segundo comando realmente ejecuta nuestra aplicación como un contenedor Docker llamado "myapp". Puede abrir el navegador para visitar "http: // localhost: 8080" para verificar.
Resumen
dotnet cli hace que la automatización y las secuencias de comandos basadas en proyectos .NET sean muy simples, especialmente en comparación con la tecnología .NET hace más de una década. En muchos casos, incluso puede evitar cualquier herramienta de script de compilación basada en tareas (Cake, Fake, Rake, Psake, etc.) y elegir scripts de shell simples que solo se delegan a dotnet cli. Además, el modelo de escalabilidad dotnet cli facilita la distribución de aplicaciones de línea de comandos autorizadas externas de .NET a programas de compilación automática a través de Nuget.
Sobre el autor Jeremy Miller (Jeremy Miller) creció en una comunidad agrícola en Missouri, donde hay un grupo de personas "especiales" llamado "Mecánica de sombras". Por lo general, no son las personas más prestigiosas del mundo, pero tienen los conocimientos para resolver problemas mecánicos y son temerarios y temerarios. Si encuentra que dos piernas sobresalen de un automóvil estacionado en la cuadra, debe ser un reparador. Está rodeado de esqueletos, amontonados en su espeso patio lleno de basura. . Los batidores que ves abandonados a su alrededor no son inútiles, son materiales. Hará pequeños ajustes poco a poco y luego encontrará una solución creativa basada en sus necesidades. A pesar de su reputación, un mecánico de sombras sabe cómo hacer funcionar las cosas. Aunque Miller no tiene ninguna capacidad mecánica especial (aunque tiene un título en ingeniería mecánica), le gusta pensar en sí mismo como un desarrollador como un mecánico de sombra. Fragmentos de proyectos de código abierto abandonados deben estar en todas partes en su disco duro. Con el lanzamiento de .NET Core 2.0, Microsoft tiene la próxima versión principal de la plataforma universal, modular, multiplataforma y de código abierto, que se lanzó originalmente en 2016. .NET Core ha creado muchas API, que están disponibles en la versión actual de .NET Framework. Originalmente se creó para la solución ASP.NET de próxima generación, pero ahora es la fuerza impulsora y la base de muchos otros escenarios, incluidos Internet de las cosas, la nube y las soluciones móviles de próxima generación. En la segunda serie de artículos sobre .NET Core, exploraremos más a fondo las ventajas de .NET Core y cómo beneficia no solo a los desarrolladores de .NET tradicionales, sino también a todos aquellos que necesitan proporcionar al mercado una solución sólida y eficiente Y soluciones económicas para el personal técnico.
Si tiene alguna pregunta, comuníquese con: capacitación en comercio electrónico . Hashiguchi Chiyomi