DEV Community: Elena Salcedo

Echo Bot .NET Core 3

Elena Salcedo — Wed, 27 Nov 2019 00:59:09 +0000

Interesting news has come with ASP.NET Core 3.x. This project has been built to take advantage all of them; it allows to start at the typical Echo Bot, this time running already on .NET Core 3.

It's important to keep Visual Studio updated, due to .NET Core 3.x it's only supported starting at Visual Studio 2019 version 16.3

Clone this repo.

As a result, we´ll have a solution like this one:

Let's see every class on it:

1. Program

HostBuilder is created, as always, using startup class; built and run.

public static void Main(string[] args)
{
            CreateHostBuilder(args).Build().Run();
}

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args).ConfigureWebHostDefaults(webBuilder =>
{
            webBuilder.UseStartup<Startup>();
});

2. Startup

A Bot it's an API, thus, the Startup class configures services and the app's request pipeline.

At ConfigureServices method, EchoBot (an IBot implementation) is registered as transient; AdapterWithErrorHandler (an IBotFrameworkAdapter implementation) is registered as singleton.

// Create the Bot Framework Adapter with error handling enabled.
services.AddSingleton<IBotFrameworkHttpAdapter, AdapterWithErrorHandler>();

// Create the bot as a transient. In this case the ASP Controller is expecting an IBot.
services.AddTransient<IBot,Bot>();

We will detailed both implementations later.
Configure method has changed while migrating to ASP.NET Core 3.x, now we use a routing middleware, it is on charge of analysing every route that comes in a http request.
Currently there is no need to use the whole MVC middleware; we can map each endpoint with the action it should run if the http request matches that route.

app.UseRouting();
app.UseEndpoints(endpoints =>
{
    endpoints.Map("api/messages", async context =>
    {
        var bot = context.RequestServices
                    .GetRequiredService<IBot>();
        var adapter = context.RequestServices
                    .GetRequiredService<IBotFrameworkHttpAdapter>();

        await adapter.ProcessAsync(context.Request, context.Response, bot);
    });
});

It is needed to set the endpoint as "api/messages" if we want to use the Bot Service.
When the action runs, the adapter will process the request.

3. Adapter With Error Handler

BotFrameworkHttpAdapter connects Azure Bot Service with our Bot. Azure Bot Service would be the one that communicates with the channels on which the Bot is published.

The implementation AdapterWithErrorHandler of the adapter, extends its functionality to inform the user if an exception has been thrown.

4. Bot

EchoBot inherits ActivityHandler (an IBot implementation).
ActivityHandler allows to override several methods that correspond with different situations on with the bot can interact with the user.

In this sample, we are managing two of these situations:
When someone joins the conversation, if it is not the bot itself (recipient), the bot greets:

protected override async Task OnMembersAddedAsync(
    IList<ChannelAccount> membersAdded, 
    ITurnContext<IConversationUpdateActivity> turnContext, 
    CancellationToken cancellationToken)
{
    foreach (var member in membersAdded)
    {
        if (member.Id != turnContext.Activity.Recipient.Id)
        {
            await turnContext.SendActivityAsync(
                MessageFactory.Text($"Welcome CommitConf2019!"),
                cancellationToken);
        }
    }
}

When a message is received, on this version of Echo Bot, it "Echoes" exactly what the user has said:

protected override async Task OnMessageActivityAsync (
    ITurnContext<IMessageActivity> turnContext, 
    CancellationToken cancellationToken)
{
    await turnContext.SendActivityAsync(
        MessageFactory.Text($"Echo: {turnContext.Activity.Text}"),
        cancellationToken);
}

Echo Bot .NET Core 3

Elena Salcedo — Wed, 27 Nov 2019 00:02:11 +0000

ASP.NET Core 3.x ha llegado con novedades muy interesantes, con el fin de aprovecharlas también en Bot Framework, se ha creado este Echo Bot que nos permitirá comenzar desde el típico Echo Bot ya migrado a la nueva versión del framework.
Es importante que hayamos actualizado recientemente VS, ya que es a partir de la versión 16.3 de Visual Studio 2019 cuando .NET Core 3.x está soportado.

Clona este proyecto.

Como resultado tendremos una solución como la que se muestra abajo. Veremos uno a una las clases que nos vienen dadas.

1. Program

El HostBuilder se crea instanciando la clase startup; se construye y se levanta.

public static void Main(string[] args)
{
            CreateHostBuilder(args).Build().Run();
}

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args).ConfigureWebHostDefaults(webBuilder =>
{
            webBuilder.UseStartup<Startup>();
});

2. Startup

El bot no es más que una API, la aplicación se describe en base a las configuraciones que creamos en la clase Startup.
En el método ConfigureServices se registra como transient el EchoBot como implementación de IBot; y se registra como Singleton el AdapterWithErrorHandler como implementación de IBotFrameworkAdapter.

// Create the Bot Framework Adapter with error handling enabled.
services.AddSingleton<IBotFrameworkHttpAdapter, AdapterWithErrorHandler>();

// Create the bot as a transient. In this case the ASP Controller is expecting an IBot.
services.AddTransient<IBot,Bot>();

Detallamos ambas implementaciones más adelante.
En el método Configure al haber migrado a ASP.NET Core 3.x, ahora se usa el middleware de routing, encargado de analizar la ruta de la petición http que nos llegará.
Actualmente no hay necesidad de cargar el middleware completo de MVC; podremos mapear endpoints, y la acción que se ejecutará cuando la petición http ataque esa ruta.

app.UseRouting();
app.UseEndpoints(endpoints =>
{
    endpoints.Map("api/messages", async context =>
    {
        var bot = context.RequestServices
                    .GetRequiredService<IBot>();
        var adapter = context.RequestServices
                    .GetRequiredService<IBotFrameworkHttpAdapter>();

        await adapter.ProcessAsync(context.Request, context.Response, bot);
    });
});

En este caso, estamos diciendo que cuando recibamos una petición en el endpoint “..api/messages”, pidamos al adapter que procese esa petición.
Es necesario que el endpoint sea api/messages, si queremos utilizar el Bot Service, el endpoint ha de ser exactamente ese.

3. Adapter With Error Handler

El BotFrameworkHttpAdapter es el encargado de interconectar el Bot Service con nuestro bot. A grandes rasgos, será el nexo entre nuestra aplicación de bot y los canales en los que está publicado.
La implementación AdapterWithErrorHandler del adapter, extiende su funcionalidad para informar al usuario de que ha habido un error cada vez que se produzca una excepción no controlada.

4. Bot

EchoBot hereda de ActivityHandler y ésta implementa la interfaz IBot.
El activity handler nos permite sobreescribir varios métodos que se corresponderán con diferentes situaciones con las que nos encontraremos con el usuario.
En este caso, estamos manejando dos de estas situaciones:
Cuando alguien se une a la conversación, si no es el bot (Recipient), se imprime el saludo:

protected override async Task OnMembersAddedAsync(
    IList<ChannelAccount> membersAdded, 
    ITurnContext<IConversationUpdateActivity> turnContext, 
    CancellationToken cancellationToken)
{
    foreach (var member in membersAdded)
    {
        if (member.Id != turnContext.Activity.Recipient.Id)
        {
            await turnContext.SendActivityAsync(
                MessageFactory.Text($"Welcome CommitConf2019!"),
                cancellationToken);
        }
    }
}

Cuando se recibe un mensaje, en esta versión de echo bot, le devolveremos al usuario exactamente lo mismo que ha dicho:

protected override async Task OnMessageActivityAsync (
    ITurnContext<IMessageActivity> turnContext, 
    CancellationToken cancellationToken)
{
    await turnContext.SendActivityAsync(
        MessageFactory.Text($"Echo: {turnContext.Activity.Text}"),
        cancellationToken);
}

Debug .Net Core in Azure App Service from Visual Studio

Elena Salcedo — Thu, 10 Oct 2019 21:56:39 +0000

OK, I must confess, I said: It works on my machine.
When I uploaded my code to DEV environment.. ¡Surprise! It crashes.
After doing some test in both, my local and dev environments, checking App Insights, Google and find out nothing, I decided to attach Visual Studio debugger to the Web App (only after telling my team about it, and only because it was DEV environment).
Thus, make sure that the App Service on Azure has remote debugging enabled.

MyAppService -> Configuration -> General Settings -> Debugging

Let’s attach the debugger from Visual Studio:

Cloud Explorer -> MySubscription -> AppServices -> rightclic en MyAppService -> Attach debugger

Suddenly, a wild Pop Up appears on Visual Studio with something I’ve never ever seen:

Unable to attach to application ‘dotnet.exe’ (PID: 9504) using ‘mywebapp’. The 64-bit version of the Visual Studio Remote Debugger (MSVSMON.EXE) cannot be used to debug 32-bit processes or 32-bit dumps. Please use the 32-bit version instead.

It seems that I’m trying to attach a 64 bit debugger to a 32 bit process. However, my Web App is configured to run on 64 bit:

MyAppService -> Configuration -> General Settings -> Platform Settings

How can the process run on 32 bit? Let’s check KUDU. We now can see that the .NET Core process that runs our application is on 32 bit:

Kudu -> Process Explorer -> rightclick en dotnet.exe(PID:9504)

It turns out that .NET CORE 2.2 SDK available by default at the Azure App Services is for 32bits
Thus, it does not take any effect configuring the Web App in 64 bit on Azure Portal. The IIS Worker Process, even running on 64 bit, will spawn .NET Core on 32 bit (due to .NET Core is only available by default on 32 bit). So the Visual Studio Debugger we should attach is the one on 32 bit as well.
If we configure the WebApp to run on 32 bit, Visual Studio will try to attach the 32 debugger this time:

Azure Portal → MyWebApp -> Configuration → General Settings → Platform Settings — Platform: 32 Bit

Nevertheless, if you want to run your application in 64 bit, you can configure the hosting model as InProcess. More info here.