Azure Functions con .Net 5 – Ejecución en proceso aislado

El pasado 10 de noviembre del 2020 fue liberado el .Net 5. Sin embargo, un elemento que quedó fuera de este lanzamiento fueron las Azure Functions. No fue sino hasta el 10 de marzo del 2021 que fue liberada una versión de las Azure Functions que soporta el .Net 5.

Con este release nos encontramos con un cambio en el modelo de ejecución. Y es aquí donde encontramos con que las Azure Functions ahora son ejecutadas en un proceso aislado.

Pero de qué viene el tema de ejecución en proceso aislado?

Desde sus inicios la aplicaciones de funciones de .Net y .Net Core se han ejecutado en el mismo proceso del host, trayendo consigo ventajas únicas como tener un conjunto de enlaces e inyecciones al SDK. Pero por otro lado, la ejecución de funciones para otros lenguajes es ejecutada en un modelo “out-of-process” (fuera del proceso) que permite ejecutar la funcionalidad en un proceso separado. Esto es, bajo la ejecución de un proceso que a su vez es el encargado de la ejecución de las funciones.

Es así como el equipo de desarrollo y soporte de las Azure Functions decide adoptar este modelo para el soporte en .Net 5. Teniendo así que si deseamos trabajar en esta versión, nos encontraremos con una nueva forma de trabajar.


El primer cambio que vamos a notar es que cuando creamos un nuevo proyecto, digamos en Visual Studio, nos encontraremos con la presencia de la clase Program.cs. La cual es el punto de entrada de la ejecución de las funciones, es decir, el proceso encargado de la ejecución.

Program.cs

Anteriormente, como lo comenta Facu (Facundo La Rocca) en su blog acá, en las Azure Functions para .Net Core 3.1, podíamos crear una clase que heredara de FunctionsStartup para que está fuera ejecutada al iniciar la ejecución.


Otro cambio con el que nos vamos a encontrar es con que los paquetes Nuget base que vamos a usar serán:

Microsoft.Azure.Functions.Worker
Microsoft.Azure.Functions.Worker.Sdk

y los paquetes de extensión de enlace serán:

Microsoft.Azure.Functions.Worker.Extensions.*

En donde * representa el o los paquetes de los trigger que estaremos utilizando en nuestras funciones. Por ejemplo:

Microsoft.Azure.Functions.Worker.Extensions.Http
Microsoft.Azure.Functions.Worker.Extensions.Timer

Por acá una tabla con los cambio o diferencias con Azure Functions para .Net 3.1

Característica/comportamientoEn proceso (.NET Core 3.1)Fuera de proceso (.NET 5.0)
Versiones de .NETLTS (.NET Core 3.1)Actual (.NET 5.0)
Paquetes baseMicrosoft.NET.Sdk.FunctionsMicrosoft.Azure.Functions.Worker
Microsoft.Azure.Functions.Worker.Sdk
Paquetes de extensión de enlaceMicrosoft.Azure.WebJobs.Extensions.*En Microsoft.Azure.Functions.Worker.Extensions.*
RegistroILogger se pasa a la funciónILogger obtenido de FunctionContext
Tokens de cancelaciónCompatibleNo compatible
Enlaces de salidaParámetros de salidaValores devueltos
Tipos de enlaces de salidaIAsyncCollector, DocumentClient, BrokeredMessage y otros tipos específicos del clienteTipos simples, tipos serializables de JSON y matrices.
Varios enlaces de salidaCompatibleCompatible
Desencadenador HTTPHttpRequest/ObjectResultHttpRequestData/HttpResponseData
Funciones duraderasCompatibleNo compatible
Enlaces imperativosCompatibleNo compatible
Artefacto function.jsonGeneradoNo se han generado
Configuraciónhost.jsonhost.json e inicialización personalizada
Inserción de dependenciasCompatibleCompatible
Software intermedioNo compatibleCompatible
Tiempo de arranque en fríoHabitualMás tiempo, debido al inicio Just-in-Time.
Ejecute en Linux en lugar de en Windows para reducir los posibles retrasos.
ReadyToRunCompatibleTBD
https://docs.microsoft.com/es-mx/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions

En algunos próximos posts, estaré hablando de como hacer la inyección de dependencias en este nuevo modelo de Azure Functions, y de que nos espera para nuevas versiones con la llegada de .Net 6. Estén atentos a esta información.

Presentación en la “Gira Speakers Latam”

El próximo viernes 9 de julio estaré participando en la “Gira Speakers Latam” con una plática más sobre Azure DevOps. Los espero en mi plática y a aprovechar las otras platicas que habrá en el evento.

Página del evento: https://giraspeakerslatam.azurewebsites.net/
Título: Azure artifacts en Azure DevOps, un mundo subexplorado
Fecha: 9 de julio
Hora: 5:00 pm (Hora de Mx)

Los espero!!!

‘Usings’ globales en C# 10!!! 😱

Microsoft Build 2021 se ha terminado, y si bien fueron muchas las sesiones, me parece que las opciones para desarrolladores se ven reducidas. en mi opinión personal, a traves de los años este evento se ha convertido más es un acto de promoción más allá que un apoyo para nosotros los programadores.

Pero este post no es sobre mi opinión sobre el Build. Sin embargo si fue necesario para hablar de desde la perspectiva de lo poco con lo que me quedo sobre el evento. Y es aquí donde me gustaría hablar del anuncio que más me ha llamado la atención. Estoy hablando del llamado “global using”.

Esta nueva característica que tendremos presente a partir de C# 10, podremos anteponer la palabra reservada ‘global‘ antes de definir un ‘using‘ para permitir que dicho namespace sea accesible en cualquier clase sin necesidad de volver a escribir el ‘using‘.

global using System.Linq;

Y de que va esto? La premisa es sencilla, si en cualquier archivo .cs que pertenezca a tu proyecto está definido un using de manera global, ya no será necesario volver a escribir ese using en otro archivo .cs.

Para explorar esta nueva característica del lenguaje tendremos que configurar nuestro proyecto para que utilice la version de lenguaje preview.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <LangVersion>preview</LangVersion>
  </PropertyGroup>

</Project>

Y una vez configurado el proyecto podemos, a manera de sugerencia, crear un archivo GlobalUsings.cs en donde estaremos poniendo los using globales para nuestro proyecto

global using System;
global using System.Linq; 
global using System.Threading.Tasks;

Con esto configurado, el mismo Visual Studio nos avisará cuando un using está “globalizado”.

Qué te pareció esta nueva configuración? Será que comenzaremos a utilizarla una vez liberado la versión del lenguaje?

Presentación.- Azure Artifacts en Azure DevOps, un mundo subexplorado

Este sábado 22 de Mayo estaré participando con una sesión en el marco del Azure Days 2021 de ConoSur.Tech que estará sucediendo los días 21 y 22 de Mayo.

Regreso al tema que me apasiona; Azure DevOps. En esta ocasión hablando sobre Azure Artifacts (por su nombre en ingles), un mundo que pocas veces tocamos pero que tiene su potencial en la organización de nuestros proyectos.

La cita es:
Fecha: Sábado 22 de Mayo
Hora: 01:30 PM UTC (Descubre tu horario local aquí)
Transmisión: https://www.youtube.com/watch?v=RifGoBBFt-c

Los espero y deseo sea información de utilidad para ustedes.

#GlobalAzureLatam… desde la trinchera

Este fin de semana pasado (Abril 15, 16 y 17 del 2021) tuve el honor de participar en el equipo de organización del #GlobalAzureLatam. Y que experiencia que me he echado a la bolsa!

Comienzo por comentar que el Global Azure Latinoamérica 2021, aka #GlobalAzureLatam, fue un evento organizado por comunidades tecnológicas en Latinoamérica en el marco del Global Azure 2021. Durante tres días al año, diferentes grupos de usuarios y comunidades alrededor del mundo organizan conferencias y talleres todas ellas relacionadas el tema de Azure. Esto le da un toque especial al evento, ya que son las mismas comunidades quienes dan vida al evento, y no una entidad como tal.

Y es aquí donde entran líderes de 16 comunidades en todo Latinoamérica uniendo esfuerzos para organizar lo que denominamos el #GlobalAzureLatam. Si bien, esto ya se había realizado años anteriores, donde muchas de estas comunidades tenían sus eventos localmente. Este año, convocados y lidereados por Luis Beltrán (@darkicebeam) como parte de la Comunidad Xamarin / .NET MAUI en Español y por el equipo staff de Latino .Net Online se reunieron 16 comunidades en total para llevar a cabo el evento.

Con más de 60 sesiones el evento fue un éxito, en donde incluso pudimos alcanzar el primer lugar en sesiones ofrecidas a lo largo del todo el mundo. Y todas ellas en español. Acá el canal en YouTube creado con todas las sesiones grabadas en vivo.

Pero para mi algo me que dejo el evento, además de grandes conocimientos adquiridos, fue el haber formado parte de un equipo de trabajo excepcional. Comenzando con cada uno de los expositores quienes dieron vida a las sesiones, y sin dejar de lado a los asistentes que se chutaron hasta 10 horas de transmisión al día. Y mención especial a cada uno de los integrantes del ‘staff’ en el cual se formó un ambiente de cooperación que nunca antes había podido observar.

Ya lo expresaba en varias ocasiones durante las trasmisiones, con lo que me quedo yo del evento es con la idea de que en Latinoamérica y desde diferentes partes del mundo podemos hacer grandes cosas si es que hay disponibilidad y respeto por el trabajo del otro. Gracias equipo!!!

Azure Static Web Apps ya soporta repositorios de Azure DevOps

El día de hoy nos encontramos con una super sorpresa que nos regresa la esperanza a lo que nos sentimos muy cómodos con Azure DevOps.

Muchos fuimos felices cuando hace algún tiempo, Microsoft anunció el lanzamiento de Azure Static Web Apps que si bien hasta el día de hoy continua en estado de preview su estabilidad es considerable. Esta característica de Azure nos permitía configurar páginas estáticas o las famosas ‘aplicaciones single-page’ con su muchos sabores de frameworks para el front-end.

Sin embargo, la decepción no tardó mucho en llegar, al enterarnos que solamente eran soportados repositorios GitHub. Dónde quedaba la integración de Azure con Azure? (ok, de Azure con Azure DevOps)

Y bueno, como ya lo había mencionado, hoy nos volvemos a emocionar pues se ha anunciado que a partir de esta fecha las Azure Static Web Pages soporta repositorios en Azure DevOps. Acá la noticia en ingles

Y cómo va la cosa? Pues el truco ahora está en que cuando se configura un pipeline de compilación tipo yaml, podemos ahora utilizar token de desplegado (Deployment Token) el cual obtenemos utilizando la opción correspondiente en nuestro recurso de Azure.

Obtener token para el desplegado

Para finalmente utilizarlo en el código yaml de la definición del pipeline

trigger:​
  - main​
​
pool:​
  vmImage: ubuntu-latest​
​
steps:​
  - task: AzureStaticWebApp@0​
    inputs:​
      app_location: "/" ​
      api_location: "api​"
      output_location: ""
    env:​
      azure_static_web_apps_api_token: $(deployment_token)

En donde debemos definir una variable llamada deployment_token con el valor obtenido de nuestro Portal Azure

Configuración de variable para el archivo yaml

* Podemos encontrar información más detallada en este link (solo en ingles por el momento)

Si bien, la tarea no es trivial y requiere de configuraciones especiales para cada tipo de framework del front-end. Esta información no da pie a comenzar a jugar con este nuevo juguete. Por lo pronto, para mi me sirve de buena excusa para ahora si animarme a adentrarme en Blazor. Así que estén atentos pues de esa exploración pueden salir algunas entradas en este su blog.

Presentación de Azure B2C en la NetCoreConf 2021

Quiero invitarlos a ver la presentación sobre “Configuración e implementación de Azure B2C on .Net Core” que estaré haciendo en el marco de la NetCoreConf 2021 en donde estaré platicando como configurar la propuesta de Microsoft para la solución de administración de acceso de identidad de clientes llamada Azure B2C. También abordaremos el tema de como configurar una aplicación .Net Core para el consumo de esta plataforma.

Pueden conocer más información sobre el evento en la página del evento en https://netcoreconf.com/

La información para la plática es:
– Día: Sábado 27 de Febrero
– Horario: 13:00 hrs (UTC)
* Conoce tu horario local aquí

Azure DevOps ahora permite renombrar el branch principal

Microsoft ahora permite modificar el nombre por default del branch principal para repositorios nuevos de Azure DevOps.

Mas allá del tema sociopolítico que ha generado el tema. Microsoft ahora permite modificar el nombre por default del branch principal para repositorios nuevos de Azure DevOps.

Si bien, anteriormente se podía seleccionar un branch distinto al ‘master’ como principal (o para ser el default) y eliminar el ‘master’. Ahora Azure DevOps permite inicializar repositorios con un nombre distinto al usual como branch por default.

Esta configuración la podemos encontrar en las configuraciones del proyecto (Project settings), en la opción de repositorios (Repositories), en el tab de configuraciones (Settings). Bastará con habilitar la opción de nombre de rama predeterminado para nuevos repositorios (Default branch name for new repositories) y configurar el nombre a elegir.

Nuevamente, más allá de la controversia, bien por ese movimiento por parte de Microsoft.

Jornada 1 de Asp .Net MCV en Español

Desde la comunidad de desarrolladores en facebook ‘Asp.Net MVC (Español)’ [https://www.facebook.com/groups/aspmvc.es] los invitamos a nuestra “Jornada 1 de Asp .Net MCV en Español”. Este próximo Martes 30 de Junio donde tendremos 4 conferencias virtuales sobre el desarrollo web con tecnologías Microsoft.

Desde la comunidad de desarrolladores en Facebook ‘Asp.Net MVC (Español)‘ [https://www.facebook.com/groups/aspmvc.es] los invitamos a nuestra “Jornada 1 de Asp .Net MCV en Español”. Este próximo Martes 30 de Junio donde tendremos 4 conferencias virtuales sobre el desarrollo web con tecnologías Microsoft.

Asp.Net MVC con Arquitectura en Capas de 0 a 100.-

Aprende a crear aplicaciones web con Asp .Net MVC usando la arquitectura en capas. Iremos de 0 a 100 en donde repasaremos los conceptos básicos de MVC aprovechando la oportunidad de construir una aplicación en capas.
Jorge Levy
Martes 30 de Junio, 12:30pm (Horario CdMx : UTC -5) [Encuentra tu horario en: https://bit.ly/2YH3RYr]
Transmisión en Facebook: https://www.facebook.com/groups/aspmvc.es/permalink/3004745839602153/
Transmisión en YouTube: https://www.youtube.com/watch?v=OeAZPR6kZEw

Moviéndonos a Entity Framework Core.-

Muchos proyectos los hemos trabajado usando Entity Framework (tradicional) usando archivos EDMX. Para muchos, la sorpresa fue que EF Core no soporta estos archivos.
La charla se dirige a los developers que no saben o no se han visto en la situación de migrar un modelo EDMX a EF Core, vamos a hacerlo paso a paso.
Pastor Cortés Osorno
Martes 30 de Junio, 2:00pm (Horario CdMx : UTC -5) [Encuentra tu horario en: https://bit.ly/31pC6p3]
Transmisión en Facebook: https://www.facebook.com/groups/aspmvc.es/permalink/3004754766267927/
Transmisión en YouTube: https://www.youtube.com/watch?v=JxqwxUoQc7o

Implementar Azure Cosmos DB en nuestros proyectos Asp .Net MVC.-

Esta charla se basara en explicar de que trata Azure Cosmos DB, comenzaremos, en vivo, un simple proyecto MVC que implemente Azure Cosmos DB como motor de base de datos y como frutilla del postre, publicaremos este sitio en Azure App Service
Lautaro Carro
Martes 30 de Junio, 3:30pm (Horario CdMx : UTC -5) [Encuentra tu horario en: https://bit.ly/2YLOONg]
Transmisión en Facebook: https://www.facebook.com/groups/aspmvc.es/permalink/3004760129600724/
Transmisión en YouTube: https://www.youtube.com/watch?v=PKhbGoBFznQ

Blazor WebAssembly.-

Conoce la nueva propuesta para desarrollo de aplicaciones web interactivas del lado del cliente utilizando C# en lugar de JavaScript.
Miguel Muñoz Serafín
Martes 30 de Junio, 5:00pm (Horario CdMx : UTC -5) [Encuentra tu horario en: https://bit.ly/2BMHQP0]
Transmisión en Facebook: https://www.facebook.com/groups/aspmvc.es/permalink/3004762449600492/
Transmisión en YouTube: https://www.youtube.com/watch?v=QcMxE3Ssxnk

Cobertura de código para pruebas unitarias en C# con Coverlet

Ahora que he estado utilizando la versión Community de Visual Studio, una de las características que considero hacen la diferencia respecto a la versión Enterprise es la falta de Cobertura de Código para las Pruebas Unitarias (Code Coverage en inglés) en la versión community. Esta característica permite medir en porcentaje y visualizar con marcado de líneas toda aquellas líneas de código que son tocadas, o no, con nuestras pruebas.

Es aquí donde Coverlet y ReportGenerator entran en juego permitiendo por medio de paquetes Nugets y otras herramientas del dotnet, realizar dicha tarea. Así pues, en esta entrada, veremos como generar los reportes de cobertura utilizando Coverlet. Y posteriormente se mostrara el uso de la herramienta proveída por ReportGenerator para obtener el reporte visual en formato html.

Configurar el proyecto de pruebas

Lo primero que se necesita realizar es agregar al proyecto de pruebas (puede ser tanto MSUnit como Xunit) el paquete nuget:

Install-Package coverlet.msbuild

* Verificar que el proyecto de pruebas también incluya el paquete coverlet.collector

Una vez configurado el proyecto, los siguientes pasos serán realizados en una Consola de Windows (command prompt en inglés). Recomendando utilizar la terminar proveída por Visual Studio.

Preparación del ambiente

Como preparación del ambiente, será necesario instalar la herramienta dotnet-reportgenerator-globaltool. Aún y cuando esta herramienta es provista por medio de los paquetes nugets, esta debe de ser instalada usando la Consola de Windows.

dotnet tool install -g dotnet-reportgenerator-globaltool

*Con este comando, la herramienta se instalará globalmente. Si el desarrollador así lo desea, puede ser instalado localmente en el directorio de la solución.

Ejecutar las pruebas con recolección de cobertura de código

Una vez posicionados en el directorio de la solución, el primer paso a realizar, será llamar el commando para la ejecución de la pruebas. A este comando se le deberá añadir los parámetros necesarios para la recolección de la cobertura y el directorio de salida donde poner estos resultados.

dotnet test /p:CollectCoverage=true
/p:CoverletOutputFormat=cobertura
/p:CoverletOutput="./../TestResults/"

Generar el reporte html

El siguiente paso consistirá en utilizar la herramienta de generación del reporte que instalamos para el dotnet seleccionando el archivo xml generado en el paso anterior y seleccionando que el reporte sea generado en html.

reportgenerator.exe "-reports:TestResults\coverage.cobertura.xml"
"-targetdir:TestResults\html"
"-reporttypes:HTML;"

Una vez realizado esto, se podrá acceder al reporte html, ejecutando el navegador sobre el archivos generado.

Visualizar el reporte

.\TestResults\html\index.htm

Obteniendo un reporte con las clases que las pruebas unitarias están ejecutando, marcando en verde las líneas de código que si son ejecutadas, mientras las que no se ejecutan marcadas de color rojo.