Una de las características de ASP.NET vNext son los “comandos K”, es decir aquellos comandos que se invocan desde línea de comandos a través del fichero K.cmd.
Dichos comandos están definidos en el project.json y la idea es que ofrezcan tareas necesarias durante el ciclo de vida de compilación y pruebas. Así podemos tener un comando (p. ej. K run) que nos ejecute el proyecto y otro (K test) que nos lance los tests unitarios. Recordad siempre que ASP.NET vNext se crea con el objetivo de que sea multiplataforma total: no solo que sea ejecutable en Linux o MacOSX a través de Mono, si no que sea posible desarrollar en esos sistemas operativos. Y eso implica “desligarse” de Visual Studio. Por supuesto, eso no quita que VS añada e implemente su propio soporte para el ciclo de vida de compilación y pruebas.
De hecho, incluso actualmente en VS no es nuevo usar comandos para gestionar algunas de las tareas necesarias para el ciclo de vida. Así muchos de vosotros conoceréis el comando Install-Package para instalar un paquete NuGet. Así, a dia de hoy, usamos la “Package Manager Console” que no es más que un wrapper sobre PowerShell. Para algunos comandos (como el citado Install-Package) el propio VS ofrece una alternativa gráfica pero hay otros comandos que solo se pueden lanzar desde dicha consola. El ejemplo más claro son todos los comandos de EF Migrations (p. ej. Update-Database).
La razón de que ASP.NET vNext se “olvide” de los comandos Powershell es que Powershell solo funciona en Windows y recuerda… ASP.NET vNext es multiplataforma de verdad.
Por supuesto nosotros podemos crear nuestros propios “comandos K” para añadir tareas que nos sean necesarias o útiles para el ciclo de vida de compilación y pruebas de la aplicación. Porque básicamente un comando definido en el project.json lo único que hace es invocar a un ensamblado.
Vamos a ver como podemos hacerlo. 🙂
Los comandos residen en un assembly que debe ser compilado con vNext. En nuestro caso vamos a crear una “ASP.NET vNext Console Application” usando VS14 CTP3. En mi caso la he llamado TestCommands.
La verdad es que el template que viene con VS14 CTP3 para dicho tipo de aplicaciones es casi inútil, pero bueno… menos da una piedra. Dicho template genera la clásica clase “Program” con su método Main, útil para ejecutables, pero en nuestro caso nuestra aplicación estará lanzada a través de un comando K, así que será el propio framework de ASP.NET vNext quien invocará nuestra aplicación.
Lo primero es agregar una dependencia a Microsoft.Framework.Runtime.Common en nuestro project.json:
- "dependencies": {
- "Microsoft.Framework.Runtime.Common": "1.0.0-alpha3"
- },
Luego podemos modificar la clase Program para que quede de la siguiente así:
- public class Program
- {
- public Program(IApplicationEnvironment env)
- {
- Console.WriteLine("In Progrm.ctor " + env.ApplicationBasePath);
- }
- public void Main(string[] args)
- {
- Console.WriteLine("In main");
- Console.ReadLine();
- }
- }
Si lo ejecutas con VS directamente verás algo parecido:
Por supuesto puedes ejecutarlo también usando KRE. Para ello asegúrate de tener en el path la carpeta donde está KRE instalado. Puedes tener varios KREs instalados side by side y por defecto se instalan en %HOME%.krepackages. Así p. ej. en mi maquina tengo:
Debes agregar al path la carpeta bin del KRE que quieras usar. Así p. ej. yo tengo agregado al path la carpeta C:Usersetomas.krepackagesKRE-svr50-x86.1.0.0-alpha3bin
Así si navegamos a la carpeta donde está el fichero project.json y ejecutamos “k run”:
En el caso de que os de un error de que no puede encontrar algún assembly lanzando un mensaje de error parecido al siguiente:
System.InvalidOperationException: Failed to resolve the following dependencies:
Microsoft.Framework.Runtime.Common 1.0.0-alpha3
Debes ejecutar el comando “kpm restore”. Eso es necesario cuando la maquina en la que estás ejecutando no tiene alguno de los paquetes marcados como dependencias en el project.json. Si es la propia maquina en la que tienes VS14 eso no te ocurrirá (VS14 se descarga los paquetes) pero, p. ej. yo he copiado el proyecto a otra máquina donde no tenía VS14, pero sí el runtime de vNext y he necesitado ejecutar dicho comando.
Fijate en cuatro detalles:
- Se pasa primero por el constructor de la clase Program
- El framework nos inyecta automáticamente el objeto IApplicationEnvironment
- Luego se llama automáticamente al método Main
- No es necesario que el método Main sea estático.
Si te preguntas como pasar parámetros al método main, pues simplemente añadiéndolos al comando “k run”. Así, si p. ej. tecleas “k run remove /s” el método Main recibirá dos parámetros (“remove” y “/s”). Para pasar parámetros con VS debes usar las propiedades del proyecto (sección Debugging).
Podríamos implementar un comando “list” que listase todos los ficheros del proyecto:
- public class Program
- {
- private readonly string _folder;
- public Program(IApplicationEnvironment env)
- {
- _folder = env.ApplicationBasePath;
- }
- public void Main(string[] args)
- {
- if (args.Length == 1 && args[0] == "list")
- {
- ListFiles();
- }
- Console.ReadLine();
- }
- private void ListFiles()
- {
- var files = Directory.EnumerateFiles(_folder, "*.*", SearchOption.AllDirectories);
- foreach (var file in files)
- {
- Console.WriteLine(file);
- }
- }
- }
Para poder usar la clase Directory debes añadir una dependencia en el project.json al paquete System.IO.FileSystem (recuerda que en vNext todo el framework está fragmentado y dividido en paquetes NuGet).
Bien, ahora ya sabemos que podemos ejecutar este programa con “k run list”, pero a nosotros lo que nos interesa es tener un “comando k” adicional para usar con otro programa vNext.
Para ver como lo podemos montar vamos a agregar otro proyecto de consola de ASP.NET vNext a la solución. Yo lo he llamado DemoLauncher. No es necesario que toques nada del código.
Ahora debes agregar una dependencia desde DemoLauncher al otro proyecto (que en mi caso se llamaba TestCommands):
- "dependencies": {
- "TestCommands": ""
- },
Puedes agregar esta dependencia porque, a pesar de que TestCommands no
está en NuGet está en la misma solución.
Ahora damos de alta el comando. Los comandos se dan de alta en el project.json. Así editamos el project.json de DemoLauncher para añadir una sección de commands:
- "commands": {
- "tc" : "TestCommands"
- }
Con esto le indicamos que cuando se lance el comando “tc” se invoque al ensamblado “TestCommands”.
Ahora puedo ir a la carpeta donde está el project.json de DemoLauncher y si tecleo “k run” se ejecutará DemoLauncher (eso era de esperar):
Pero lo bueno viene ahora. Si desde esa misma carpeta tecleas “k tc list” se te listarán todos los ficheros que haya en la carpeta (y subcarpetas) de DemoLauncher:
Al lanzar “k tc” como en el project.json hay definido el comando “tc” se invoca al ensamblado “TestCommands” y se le pasan los parámetros que se hayan pasado después de tc. Así pues TestCommands recibe el parámetro “list” y lista todos los ficheros. Lo interesante es que TestCommands se ejecuta bajo el contexto de ejecución de DemoLauncher (la propiedad ApplicationBasePath del IApplicationEnvironment apunta al directorio donde está DemoLauncher).
En un escenario final real, tendríamos “TestCommands” publicado a NuGet, pero el resto vendría a ser lo mismo que hemos visto.
La gente de EF ya ha empezado a usar esa táctica para los comandos de Migrations (y así posibilitar el uso de Migrations en entornos no windows al no depender más de Powershell). Y personalmente creo que vamos a ver bastantes de esos futuros comandos.
Un saludo!
Que enterado te veo… efectivamente EntityFramework.Commands es el proyecto con toda la lista de comandos disponibles. Pero no solo es este ejemplo sino además en realidad k web es lo mismo, un programa main que es capaz de hacer un trabajo para alojar una App web.