Docker para el desarrollador de asp.net (iii)

En el post anterior vimos como empaquetar y desplegar en Docker una sencilla aplicación (un hello world) en asp.net core. En este post vamos a ver como desplegar en Docker una aplicación asp.net core (con sus controladores y vistas) y también ver como lo podemos usar usando una imagen base que no tenga el SDK, solo el runtime.

¡Vamos allá!

Continúa leyendo Docker para el desarrollador de asp.net (iii)

Docker para el desarrollador asp.net (ii)

Seguimos con esta sobre el uso de Docker desde el punto de vista de un desarrollador asp.net (core). En este caso vamos a construir nuestra primera imagen Docker.

Nota: Visual Studio 2017 incorpora de serie las Docker Tools que automatizan todo lo que veremos en estos artículos. Tiempo tendremos, más adelante en esta serie, de hablar de las Docker Tools. La razón de hacerlo primero todo “manual” es porque el objetivo de esta serie es ayudarte a que entiendas Docker, no presentarte el “botón mágico” que se encarga de todo. Yo, es que soy de la vieja escuela: me gusta entender las cosas (al menos hasta donde puedo).

Continúa leyendo Docker para el desarrollador asp.net (ii)

Docker para el desarrollador asp.net (i)

Buenas! Vamos a empezar una serie de posts dedicadas a Docker desde el punto de vista de un desarrollador asp.net. Empezaremos por lo más básico pero nos iremos adentrando un poco en el mundo de Docker. El objetivo es que terminemos teniendo unos conocimientos medios que nos permitan entender que es Docker, como funciona, qué ventajas tiene y como usarlo (y cuando) en arquitecturas más complejas donde haya más de un contenedor. Pero… empecemos por el principio.

Continúa leyendo Docker para el desarrollador asp.net (i)

MVC6–Recibir un GUID en el cuerpo de la petición

Hoy me he encontrado un controlador MVC6 con la siguiente acción:

[HttpPut]
[Route("{userid:int}/faceprofile")]
public async Task<IActionResult> SetFaceProfileId(int userid, [FromBody] Guid id)

Claramente su autor esperaba que pudieramos poner un Guid en el cuerpo de la petición y eso funcionaría… Pero, ¿como debe mandarse?

Continúa leyendo MVC6–Recibir un GUID en el cuerpo de la petición

Creando formateadores de salida en asp.net core

Cuando salió WebApi lo hizo con la negociación de contenido incorporada de serie en el framework. Eso venía a significar, básicamente, que el framework intentaba suministrar los datos en el formato en que el cliente los había pedido. La negociación de contenido se basa (generalmente) en el uso de la cabecera accept de HTTP: el cliente manda en esa cabecera cual, o cuales, son sus formatos de respuesta preferidos. WebApi soporta de serie devolver datos en JSON y XML y el sistema es extensible para crear nuestros propios formatos.

“MVC clásico” (es decir hasta MVC5) no incluye soporte de negociación de contenido: en MVC si queremos devolver datos en formato JSON, debemos devolver explícitamente un JsonResult y si los queremos devolver en XML debemos hacerlo también explícitamente.

En ASP.NET Core tenemos a MVC6 que unifica a WebApi y MVC clásico en un solo framework. ¿Como queda el soporte para negociación de contenido en MVC6? Pues bien, existe soporte para ella, pero dependiendo de que IActionResult devolvamos en nuestros controladores. Así, si en WebApi la negociación de contenido se usaba siempre y en MVC clásico nunca, en MVC6 la negociación de contenido aplica solo si la acción del controlador devuelve un ObjectResult (o derivado). Esto nos permite como desarrolladores decidir sobre qué acciones de qué controladores queremos aplicar la negociación de contenido. Es evidente que aplicarla siempre no tiene sentido: si devolvemos una vista Razor su resultado debe ser sí o sí un HTML que se envía al cliente. No tendría sentido aplicar negociación de contenido sobre una acción que devolviese una vista. De hecho la negociación de contenido tiene sentido en APIs que devuelvan datos (no vistas) y en MVC6 para devolver datos tenemos a ObjectResult, así que es lógico que sea sobre este resultado donde se aplique la negociación de contenido.

En WebApi la negociación de contenido estaba gestionada por los formateadores (formatters). Básicamente a cada content-type se le asociaba un formateador. Si el cliente pedía datos en un determinado content-type se miraba que formateador podía devolver datos en dicho formato. Si no existía se usaba por defecto el formateador de JSON. En MVC6 se ha mantenido básicamente dicho esquema.

Continúa leyendo Creando formateadores de salida en asp.net core

Middlewares de autenticación en asp.net core

La autenticación y autorización de peticiones es una de las funcionalidades que más quebraderos da en el desarrollo de aplicaciones en ASP.NET. Además es que ha ido cambiando con el tiempo… En un escenario de internet, en ASP.NET clásico, ya fuese Webforms o MVC usábamos FormsAuthentication. Por otra parte cuando apareció WebApi, incorporó sus propios mecanismos de autenticación y autorización, generalmente basados en la implementación de MessageHandlers.

Continúa leyendo Middlewares de autenticación en asp.net core

Autenticación por AAD en ASP.NET Core

Este es un post introductorio, de una serie de posts, donde veremos como podemos integrar ASP.NET Core y Azure Active Directory (AAD). En este primer escenario el objetivo es tener una aplicación web, donde se requiera hacer login contra AAD para autenticarse.

Nota: El post está basado en la RC1 de ASP.NET Core… Lo digo porque bueno, a saber que romperán mejorarán en futuras versiones, pues igual algo cambia 🙂

Continúa leyendo Autenticación por AAD en ASP.NET Core

Creating middlewares de asp.net core

Asp.net core se basa en el concepto de middleware. En este modelo la petición web viaja a través de un conjunto de componentes. Cada componente recibe la petición y puede:

  1. Modificar la petición y enviarla al siguiente componente
  2. O bien, generar una respuesta y enviarla de vuelta al componente anterior.

Continúa leyendo Creating middlewares de asp.net core

Routers en asp.net core

Cuando hablamos del routing solemos referirnos al proceso por el cual una petición es enrutada hacia una acción concreta de un controlador. Esa definición es cierta en el contexto de una aplicación ASP.NET MVC (y/o WebApi) pero en ASP.NET Core, el concepto de routing es una parte integral del framework.

Por ello, en ASP.NET Core entendemos el routing como el proceso mediante el cual una petición web es enrutada hacia donde tenga que ser tratada. El destino puede ser una acción de un controlador, pero no tiene por qué (el middleware de MVC6 podría no estar instalado en el pipeline de la aplicación). En este post vamos a ver como funciona este proceso de enrutado.

Continúa leyendo Routers en asp.net core

Como depurar fácilmente el código de ASP.NET5

¡Muy buenas! Para los que andamos trasteando con versiones alfas y betas con nula o poca documentación, poder depurar el código fuente de las librerías es una manera muy buena de ver qué hace y como lo hace. Cierto, solo leyendo el código fuente se puede aprender mucho, pero poder depurarlo paso a paso es todavía más útil.

El primer paso es, por supuesto, disponer del código fuente. En según que librerías eso no es posible, aunque siempre se podía tirar de los desensambladores (por más que eso pueda no ser legal). El problema de usar los desensambladores es que el código fuente obtenido no siempre es muy legible y que por otro lado no puedes depurarlo a no ser que tu desensemblador soporte la creación de PDBs.

Depurar ASP.NET MVC nunca ha sido un problema importante, en tanto el código fuente estaba disponible. Podías descargarte el código fuente de ASP.NET MVC, compilarlo en alguna carpeta local, pongamos c:mvc, junto con sus PDBs. Luego tenías que modificar tu proyecto web, quitar las referencias a ASP.NET MVC reales y sustituirlas por las versiones locales con PDBs. Con eso, podías depurar ASP.NET MVC sin muchos problemas. Pero era un poco peñazo el tener que sustituir las referencias reales por las tuyas compiladas, lo que podía redundar en algún cambio adicional de configuración (por estar firmadas las reales y no estarlos, o estarlo con otra clave, las locales).

En ASP.NET5 el proceso se ha vuelto ridículamente simple. El proceso es como sigue:

  1. Clona los repositorios de ASP.NET5 que quieras. P. ej. yo he clonado algunos de ellos en la carpeta c:tfsaspnet5.
  2. Crea un proyecto web con VS2015 que use ASP.NET5. O abre un proyecto existente, eso es lo de menos.
  3. Abre el fichero global.json que está en Solution Items

Este fichero contiene en “projects”, la lista de carpetas en las que VS2015 sabe que hay código que debe incorporar como parte de tu proyecto (por defecto las carpetas src y test). Añade la carpeta base en la cual has clonado los repos de aspnet5 que quieras depurar:

  1. {
  2.   "projects": [ "src", "test", "c:/tfs/aspnet5/mvc/src" ],
  3.   "sdk": {
  4.     "version": "1.0.0-beta8"
  5.   }
  6. }

En mi caso en c:tfsaspnet5mvc he clonado el repo de ASP.NET MVC6 así lo añado en projects (debo añadir el /src final que es donde hay los proyectos). Eso automáticamente me añade los proyectos de ASP.NET MVC6 a mi solución:

image

Además en el solution explorer VS2015 nos indica, con un icono distinto, qué referencias ha cargado en local:

image

Ahora puedes navegar por el código fuente y colocar breakpoints sin ningún problema… ejecutar tu aplicación y ¡depurar!

image

Eso sí, la clave para que te funcione es que tengas los repos sincronizados con la versión que estás usando. P. ej. si en el project.json estás referenciando la versión 1.0.0-beta8 debes tener los repos con el código fuente que se corresponda a dicha versión (todas las versiones tienen un tag de Git asociado, así que puedes obtener la que quieras). También que estés usando el entorno de ejecución correspondiente (no te funcionará si intentas depurar beta8 usando el dnx de beta5).

Observa que no es necesario cambio alguno en nuestro proyecto. Cuando hayas depurado, basta con que elimines del global.json el directorio con los fuentes y tu aplicación pasará a referenciar los paquetes NuGet oficiales.

Más fácil, ¡imposible!

Saludos!

PD: Antes de que me deis las gracias, se las dáis a Hugo Biarge (@hbiarge) que fue quien me lo contó. En este post hay más info (un poco desactualizada, ojo): http://blogs.msdn.com/b/webdev/archive/2015/02/06/debugging-asp-net-5-framework-code-using-visual-studio-2015.aspx