Etiqueta: aspnet vnext

Primeros pasos con ASP.net vNext

Desde hace pocas horas podemos acceder al código de las primeras demos de ASP.net vNext. En este artículo veremos cómo configurar nuestro entorno para usar kvm y además veremos qué trae el código de pruebas.

KVM y KRE

Uno de los grandes cambios a partir de esta versión es que ya no hablamos de un único .NET framework, sino de múltiples versiones que existen de manera concurrente (como ocurre con los paquetes de nuget) y para la gestión de estas versiones tenemos el K Version manager que gestionará la K Runtime Environment, que es lo primero que debemos obtener.

Para su instalación necesitamos clonar el repositorio que aloja la solución en github:

git clone https://github.com/aspnet/home.git

Una vez descargado, el siguiente paso es ejecutar kvmsetup.cmd para agregar kvm a nuestro path. Para finalizar esta fase, necesitamos obtener la versión del KRE con la que vamos a trabajar, en este caso la 0.1 alpha.

kvm install 0.1-alpha-build-0421

Al finalizar contaremos con los siguientes ficheros:

Capture_alpha

Descargando el código de ejemplo

Ya con todo listo para empezar a «cacharrear» podemos obtener el código del bugtracker:

git clone https://github.com/aspnet/BugTracker.git

Y justo a continuación movernos a la rama «dev», que es la más actualizada.

git checkout dev
git pull origin dev

Una vez descargado, el siguiente paso es ejecutar el comando kpm restore desde la carpeta \src\BugTracker para que configure nuestro entorno. Este comando descargará los componentes de .NET y las librerías de terceros que necesite nuestra aplicación:

Capture_restore

Estos requisitos vienen definidos en un nuevo fichero, llamado project.json, que incluye por una parte dependencias, acciones permitidas, y configuraciones soportadas. Hasta ahora esta información solamente la encontrábamos o bien en el proyecto, o en fichero packages.config de nuget, pero ahora se unifican.

Una vez que el proceso de «restore» finalice, tenemos varias opciones para arrancar la solución, en mi caso he optado por arrancar un IIS Express mediante el comando Helios.cmd, y he aquí el resultado:

Capture_hosting

Cosas que han cambiado

Además de la gestión de dependencias, tenemos más novedades, si echamos un vistazo a la carpeta src, como que no encontramos fichero Global.asax, y que el fichero Startup.cs contiene toda la información de inicialización (que estamos acostumbrados si hemos trabajado con SignalR o Web API).

Tanto si ejecutamos la app como aplicación web como aplicación de consola usando el código de Program.cs, ambos buscarán la configuración en el fichero Startup.cs, el primero por convención y el segundo por la línea services.GetService()

Otro gran cambio, que empezó con SignalR y Web API, es que la dependencia de System.Web desaparece por completo, siendo sustituida para MVC por Microsoft.AspNet.Mvc

Conclusiones

Puede que sacar conclusiones para un primer vistazo sea algo precipitado, aunque resulta interesante el concepto y cómo se ha planteado la manera de modularizar el .net framework, y vemos cómo van tomando forma y convergiendo iniciativas como owin, katana, web api, signalR o el propio NuGet. Queda mucho por llegar…

Más información: