Remote Debugging .NET Containers

DotnetDockerBanner

You will find several articles that will talk about local debugging .NET container through the magic of Visual Studio or VS Code, but it’s not easy to find the right information for remote debugging.

Local debugging with the different IDEs is much easier because they install the .NET debugger in the container for us without telling us and configure it properly. Compared to traditional remote debugging for .NET Framework, debugging for .NET Core does not require the use of msvsmon.exe. Instead, you need to use vsdbg provided by OmniSharp.

Local debugging requires us to run our container on our machine from the compiled source code. This is convenient during the development phase when we produce our code, but it is less convenient when we need to fix an anomaly that occurs in a subsequent phase of our delivery process. In this case, local debugging of a container can be long and tedious given the time required to retrieve the correct version of the image to be executed and its dependencies.

In this article, we will see how to debug a remote Linux Container that contains an ASP.NET Core application. For reference, here is a Dockerfile generated by Visual Studio for an ASP.NET Core application:

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging. 
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base 
WORKDIR /app 
EXPOSE 80 
EXPOSE 443 

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build 
WORKDIR /src 
COPY ["TestRemoteDebugK8s.csproj", "/src"] 
RUN dotnet restore "TestRemoteDebugK8s.csproj" 
COPY . . 
WORKDIR "/src" 
RUN dotnet build "TestRemoteDebugK8s.csproj" -c Release -o /app/build 

FROM build AS publish 
RUN dotnet publish "TestRemoteDebugK8s.csproj" -c Release -o /app/publish 
FROM base AS final WORKDIR /app COPY --from=publish /app/publish . 
ENTRYPOINT ["dotnet", "TestRemoteDebugK8s.dll"]

 

Build once, deploy everywhere

A simple search will show you several debugging examples that require you to modify the Dockerfile. The simplest approach is to include the .NET Core vsdbg debugger directly in our container image. It is simple to understand, but it complicates the developer’s job because he has to generate a new docker image and redeploy it before he can debug.

In DevOps, we favor the Build once, deploy everywhere principle. The goal here is to minimize the chances of introducing anomalies in our application by recompiling after testing. If all the tests of our application are done on a Debug version that potentially includes the debugger and that must be recompiled in Release before delivering to production, we introduce a risk of failure or we have to redo more tests. This is why we try as much as possible to deliver the binary that was used during the testing phase and, in this case, the image of the container used for the tests.

The approach of modifying the Dockerfile therefore takes us away from our Build once, deploy everywhere approach. Instead, it is possible to use the Release version of our application/image for the first tests, as this configuration includes the debugging symbols by default.

Installing the debugger

The first thing we need to do to be able to debug our application is to install the debugger. As mentioned before, it is not included in the basic container image. This allows us to keep the image size as small as possible. When we debug a Container locally, the IDE associates a volume to our container that contains the .NET Core debugger. When debugging remotely, since the container image is already created, it is preferable to install it manually.

IMPORTANT: Depending on your container base image, the following script may need to be modified. Getting packages under Linux varies from one distribution to another. For the example, I used the aspnet:3.1-buster-slim base image which is based on Debian.

To install the debugger, we must first connect in interactive mode inside the container :

Docker:

docker exec -it remote /bin/bash

Here, remote is the name given to the container at startup.

Kubernetes :

kubectl exec -it remote-7ff879f496-5jvdg -- /bin/bash

Here, remote-7ff879f496-5jvdg is the name of the pod containing the container to be debugged.

Once connected, you need to run the following script:

apt update && \
apt install -y unzip procps && \
curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

Note the following:

  • The first line allows the apt manager package to update its local list of packages without installing them.
  • The second line installs unzip (required by the getvsdbgsh script provided by Microsoft) and procps (required by the IDEs to list the processes running in the container).
  • The last line fetches the debugger installation script and installs it to the /root/vsdbg location inside the container.

You will have noticed that you need to access the container in interactive mode to install what you need.

Attaching to the process

We now have a .NET Core application in a container with a debugger installed right next to it. Since you can’t just press F5 to start debugging, you have to attach to the process running inside the container. A valid approach would be to open an SSH channel to the container, but this is something that can be simplified by using the features of our favorite IDE.

With VS Code, you need to create a debugging launch configuration specific to the runtime context:

Docker

When our container simply runs under Docker, the following configuration can be used:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickProcess}"
        },
        {
             "name": ".NET Core Docker Attach",
             "type": "coreclr",
             "request": "attach",
             "processId": "${command:pickRemoteProcess}",
             "pipeTransport": {
                 "pipeProgram": "docker",
                 "pipeArgs": [ "exec", "-i", "remote" ],
                 "debuggerPath": "/root/vsdbg/vsdbg",
                 "pipeCwd": "${workspaceRoot}",
                 "quoteArgs": false
             },
             "justMyCode":false,
             "sourceFileMap": {
                 "/src/": "${workspaceRoot}"
             }
         }
    ]
}

Launch.json file under .vscode folder

 

The interesting part is in blue. Note the following:

${command:pickRemoteProcess}:
Tells VS Code to open a pick list of the process to be debugged in the container. This is why procps had to be installed previously.

AttachProcess

« pipeProgram »: « docker » and « pipeArgs »: [ « exec », « -i », « remote » ], :
Tells VS Code the command line to execute when starting the debugger.

« debuggerPath »: « /root/vsdbg/vsdbg », :
Indicates where to find the debugger in the container file system. This path is linked to the end of the line seen above :

curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

« sourceFileMap »: {
               « /src/ »: « ${workspaceRoot} »:
This parameter tells the debugger where to find the source files for debugging. Since the default Dockerfile template copies the source files to a src directory in the container, we must indicate that the src directory actually corresponds to our working directory in VS Code.

Breakpoints do not work

If you have copied the configuration mentioned above entirely, you probably won’t have any problems with breakpoints. It is important to mention that, since we are using a Release version of our .NET Core application, the debugger will not be able to load the symbol (pdb) files automatically. You just need to specify the parameter « justMyCode »:false for the magic to work. By doing so, breakpoints will work normally.

Kubernetes

For Kubernetes, it is recommended to use the Kubernetes extension for VS Code. It makes it much easier to connect to a pod to debug it. However, you will still have to install the debugger yourself beforehand. Once this is done, you can use the context menu of a pod from the Kubernetes extension as follows :

VSCodeK8sExtensionDebugAttach
However, the default configuration sets the justMyCode parameter to true. If you want to stay in the same workflow as mentioned at the beginning of the article (Build once, deploy anywhere), you must be able to set this parameter to false. The extension does not yet allow to change the configuration used to attach the debugger. So we have to use our own debug configuration as follows :

{
    "name": ".NET Core K8s Attach",
    "type": "coreclr",
    "request": "attach",
    "processId": "${command:pickRemoteProcess}",
    "pipeTransport": {
        "pipeProgram": "kubectl",
        "pipeArgs": [ "exec", "-i", "remote-75c859fc4c-gcx7d", "--" ],
        "debuggerPath": "/vsdbg/vsdbg",
        "pipeCwd": "${workspaceRoot}",
        "quoteArgs": false
    },
    "sourceFileMap": {
        "/src/TestRemoteDebugK8s/": "${workspaceRoot}"
    },
    "justMyCode":false
}

Launch.json file under the .vscode directory

Note that the name of the pod to be debugged will have to be modified according to your context.

Conclusion

I hope I’ve been able to clearly explain how to remotely debug a .NET Core container. Your environment may be a bit different if you have changed your base image or if your privileges are restricted in the runtime environment. You can always use the above examples to adapt them to your context.

A good application security practice is to use base images that contain only the bare essentials. The distroless images published by Google have been worked to eliminate what is not necessary to run your application. However, these images are problematic for debugging, as they do not contain a Shell that allows tools to be installed after the image is created. In Kubernetes, the use of Ephemeral Containers may help us with the arrival of Kubernetes version 1.18. A good subject for a next article!

 

Prefer reading in French? You can find a french version here : Déboguer les conteneurs .NET à distance

Déboguer les conteneurs .NET à distance

DotnetDockerBanner

Vous trouverez plusieurs articles qui parleront du débogage local d’un container .NET en passant par la magie de Visual Studio ou de VS Code, mais il n’est pas facile de trouver la bonne information pour le débogage à distance.

Le dégage local avec les différents IDE est beaucoup plus facile parce que ces derniers installent le débogueur .NET dans le conteneur pour nous à notre insu et le configurent adéquatement. Comparativement au débogage à distance traditionnel pour .NET Framework, celui pour .NET Core ne nécessite pas d’utiliser msvsmon.exe. Il faut plutôt utiliser vsdbg fournit par OmniSharp.

Le débogage local nous oblige à exécuter notre conteneur sur notre machine à partir du code source compilé. C’est pratique pendant la phase de développement où on réalise nos lignes de code, mais ça l’est moins lorsqu’on doit corriger une anomalie qui survient dans une phase subséquente de notre processus de livraison. Dans ce cas, le débogage local d’un conteneur peut s’avérer long et fastidieux étant donné le temps requis pour récupérer la bonne version de l’image à exécuter ainsi que ses dépendances.

Dans cet article, nous verrons comment déboguer un conteneur Linux à distance qui comporte une application ASP.NET Core. Pour référence, voici un Dockerfile généré par Visual Studio pour une application ASP.NET Core :

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["TestRemoteDebugK8s.csproj", "/src"]
RUN dotnet restore "TestRemoteDebugK8s.csproj"
COPY . .
WORKDIR "/src"
RUN dotnet build "TestRemoteDebugK8s.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "TestRemoteDebugK8s.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "TestRemoteDebugK8s.dll"]

Build once, deploy anywhere

Une simple recherche vous montrera plusieurs exemples de débogage qui nécessitent de modifier le fichier Dockerfile. L’approche simple vise à inclure le débogueur .NET Core vsdbg directement dans notre image de conteneur. Cette approche est simple à comprendre, mais elle complexifie le travail du développeur parce qu’il doit générer une nouvelle image docker et la redéployer avant de pouvoir déboguer.

En DevOps, on privilégie le principe Build once, deploy everywhere. On vise ici à minimiser les chances d’introduire des anomalies dans notre application en recompilant après les essais. Si tous les essais de notre application sont fait sur une version Debug incluant potentiellement le débogueur et qui faut recompiler en Release avant de livrer en production, on introduit un risque de défaillance ou on se doit de refaire plus de tests. C’est pourquoi on tente au maximum de livrer le binaire qui a été utilisé pour faire les essais et, dans ce cas-ci, l’image du conteneur utilisée pour les tests.

L’approche de modifier le fichier Dockerfile nous éloigne donc de notre approche Build once, deploy everywhere. Il est possible d’utiliser la version Release de notre application/image des les premiers tests, car cette configuration inclut par défaut les symboles de débogage.

Installer le débogueur

La première chose que l’on doit faire pour être en mesure de déboguer notre application est d’installer le débogueur. Comme mentionné précédemment, il n’est pas inclus dans l’image de base du conteneur. On peut ainsi garder la taille de l’image la plus petite possible. Lorsqu’on débogue un conteneur en local, l’IDE associe un volume à notre conteneur qui contient le débogueur .NET Core. En débogage à distance, comme l’image de conteneur est déjà créée, il est préférable de l’installer manuellement.

IMPORTANT : Dépendamment de votre image de base pour votre conteneur, le script suivant pourrait devoir être modifié. L’obtention des packages sous Linux change d’une distribution à l’autre. Pour l’exemple, j’ai utilisé l’image de base aspnet:3.1-buster-slim qui est basée sur Debian.

Pour installer le débogueur, on doit d’abord se connecter en mode interactif à l’intérieur du conteneur :

Docker :

docker exec -it remote /bin/bash

Ici, remote est le nom donné au conteneur lors de son démarrage.

Kubernetes :

kubectl exec -it remote-7ff879f496-5jvdg — /bin/bash

Ici, remote-7ff879f496-5jvdg est le nom du pod contenant le conteneur à déboguer.

Une fois connecté, il faut exécuter le script suivant :

apt update && \
apt install -y unzip procps && \
curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

À noter :

  • La première ligne permet au package manager apt de mettre à jour sa liste locale de packages sans les installer.
  • La deuxième ligne installe unzip (requis par le script getvsdbgsh fournit par Microsoft) et procps (requis par les IDEs pour lister les processus en exécution dans le conteneur)
  • La dernière ligne récupère le script d’installation du débogueur et l’installe à l’emplacement /root/vsdbg à l’intérieur du conteneur.

Vous aurez noté qu’il faut avoir accès au conteneur en mode interactif pour installer ce qu’il faut.

S’attacher au processus

Nous avons maintenant une application .NET Core dans un conteneur avec un débogueur installé juste à côté. Comme on ne peut pas simplement appuyer sur F5 pour démarrer le débogage, on doit s’attacher au processus qui s’exécute à l’intérieur du conteneur. Une approche valable serait d’ouvrir un canal SSH vers le conteneur, mais c’est quelque chose qui peut être simplifié avec l’utilisation des fonctionnalités de notre IDE préféré.

Avec VS Code, il faut créer une configuration de lancement du débogage propre au contexte d’exécution :

Docker

Lorsque notre conteneur s’exécute simplement sous Docker, on peut utiliser la configuration suivante :

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickProcess}"
        },
        {
            "name": ".NET Core Docker Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickRemoteProcess}",
            "pipeTransport": {
                "pipeProgram": "docker",
                "pipeArgs": [ "exec", "-i", "remote" ],
                "debuggerPath": "/root/vsdbg/vsdbg",
                "pipeCwd": "${workspaceRoot}",
                "quoteArgs": false
            },
            "justMyCode":false,
            "sourceFileMap": {
                "/src/": "${workspaceRoot}"
            }
        }
    ]
}

Fichier Launch.json sous le répertoire .vscode

 

La partie intéressante se trouve en bleu. Notons les éléments suivants :

${command:pickRemoteProcess} :
Indique à VS Code d’ouvrir une liste de sélection du processus à déboguer dans le conteneur. C’est pour cette raison qu’il a fallu installé procps précédemment.

AttachProcess

« pipeProgram »: « docker » et « pipeArgs »: [ « exec », « -i », « remote » ], :
Indique à VS Code la ligne de commande à exécuter lors du démarrage du débogueur.

« debuggerPath »: « /root/vsdbg/vsdbg », :
Indique où trouver le débogueur dans le système de fichier du conteneur. Ce chemin d’accès est lié à la fin de la ligne vue précédemment : 

curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

« sourceFileMap »: {
               « /src/ »: « ${workspaceRoot} » :
Ce paramètre permet d’indiquer au débogueur où trouver les fichiers sources pour effectuer le débogage. Comme le gabarit par défaut du Dockerfile copie les fichiers sources dans un répertoire src dans le conteneur, il faut indiquer que le répertoire src correspond en fait à notre répertoire de travail dans VS Code.

Les points d’arrêt ne fonctionnent pas

Si vous avez copié intégralement la configuration mentionnée ci-dessus, vous n’aurez sans doute pas de problèmes avec les points d’arrêts. Il est important de mentionné que, puisqu’on utilise une version Release de notre application .NET Core, la débogueur ne sera pas en mesure de charger les fichiers de symbole (pdb) automatiquement. Il suffit de spécifier le paramètre « justMyCode »:false pour que la magie opère. Ce faisant, les points d’arrêt fonctionneront normalement.

Kubernetes

Pour Kubernetes, il est recommandé d’utiliser l’extension Kubernetes pour VS Code. Il facilite grandement la tâche quand vient le temps de se connecter à un pod pour le déboguer. Cependant, vous aurez tout de même à installer le débogueur vous-même auparavant. Une fois que c’est fait, vous pouvez utiliser le menu contextuel d’un pod à partir de l’extension Kubernetes comme suit :
VSCodeK8sExtensionDebugAttach

Cependant, la configuration par défaut définit le paramètre justMyCode à vrai. Si on veut demeurer dans le même flux de travail comme mentionné au début de l’article (Build once, deploy anywhere), il faut être en mesure de passer ce paramètre à faux. L’extension ne permet pas encore de changer la configuration utilisée pour attacher le débogueur. Il faut donc utiliser notre propre configuration de débogage comme suit :

{
    "name": ".NET Core K8s Attach",
    "type": "coreclr",
    "request": "attach",
    "processId": "${command:pickRemoteProcess}",
    "pipeTransport": {
        "pipeProgram": "kubectl",
        "pipeArgs": [ "exec", "-i", "remote-75c859fc4c-gcx7d", "--" ],
        "debuggerPath": "/vsdbg/vsdbg",
        "pipeCwd": "${workspaceRoot}",
        "quoteArgs": false
    },
    "sourceFileMap": {
        "/src/TestRemoteDebugK8s/": "${workspaceRoot}"
    },
    "justMyCode":false
}

Fichier Launch.json sous le répertoire .vscode

Il est à noter que le nom du pod à déboguer devra être modifié en fonction de votre contexte.

Conclusion

J’espère avoir réussi à expliquer clairement comment effectuer du débogage à distance d’un conteneur en .NET Core. Il se peut que votre environnement soit un peu différent si vous avez changé d’image de base où si vos privilèges sont restreints dans l’environnement d’exécution. Vous pourrez toujours vous inspirer des exemples ci-dessus pour les adapter à votre contexte.

Une bonne pratique de sécurité applicative est d’utiliser des images de base contenant le stricte nécessaire. Les images distroless publiées par Google ont été travaillées pour éliminer ce qui n’est pas nécessaire à l’exécution de votre application. Toutefois, ces images posent problème pour déboguer, car elle ne contiennent pas de Shell permettant l’installation d’outils après la création de l’image. Dans Kubernetes, l’utilisation des Ephemeral Containers pourra nous venir en aide avec l’arrivée de la version 1.18 de Kubernetes. Un bon sujet pour un prochain article !

Build 2019 – Jour 1

20190506_104437

De retour avec un article portant sur la conférence Build de Microsoft encore cette année. Avec beaucoup de plaisir, j’ai la chance d’y assister en direct de Seattle avec plusieurs collègues.

La première journée a été marquée par plusieurs annonces importantes au niveau d’Azure et de .NET. Voici ce que j’ai retenu de cette première journée de conférence.

Azure Keynote

20190506_110228.jpg

Scott Guthrie a orchestré le keynote technique portant sur Azure et certains outils de développement. Portant son légendaire polo rouge, il a procédé à plusieurs annonces qui ne sont pas négligeables. Pour les gens qui suivent les nouveautés de manière assidue, rien n’est apparu comme révolutionnaire, mais je pense que c’est du à la cadence de livraison rapide à laquelle Microsoft nous a maintenant habitué. Voyons quand même les éléments dignes de mention.

Annonce de Visual Studio Online

Microsoft fournit maintenant un éditeur web en ligne pour Azure DevOps. Il agira en tant que companion aux éditeurs VS Code et Visual Studio. Des fonctionnalités comme Live Share et IntelliCode sont à prévoir éventuellement.

20190506_112245.jpg

Outillage Azure DevOps

Donovan Brown est revenu sur différents ajouts récents dans l’outillage entourant Azure DevOps comme l’outil Azure CLI qui inclut des extensions pour Azure DevOps. Aussi, l’annonce importante a été celle de pouvoir unifier les pipelines CI/CD dans un seul et même pipeline. Tout ça se fera en YAML. Avec l’ajout récent d’un soutien visuel pour la configuration des tâches, l’expérience devient très intéressante.
Suite à l’acquisition de GitHub, Microsoft continue d’améliorer l’intégration entre GitHub et Azure DevOps en fournissant maintenant des ensembles de licences pour MSDN et GitHub Enterprise ainsi que la possibilité d’utiliser Azure AD pour s’authentifier dans GitHub.

Nouveaux services Azure

Plusieurs services Azure ont été annoncés en aperçu ou en disponibilité générale, mais j’ai noté particulièrement les ajouts à AppService qui disposera d’une intégration VNet pour les applications basées sur Linux. Nos applications .NET Core pourront donc utiliser la même intégration VNet qui est actuellement en aperçu du côté Windows (v2).20190506_113521.jpg

Quelques nouveautés du côté AKS sont aussi digne de mention. Pour commencer, la disponibilité générale des kubelets virtuels. Aussi, il faut voir Kubernetes Event-Driven Auto-scaling (KEDA). Il s’agit de pouvoir gérer l’élasticité des clusters Kubernetes à l’aide des événements disponibles dans Azure et des Azure Functions. Par ailleurs, ces dernières pourront aussi être exécutées sous Kubernetes dans des conteneurs.

20190506_113728.jpg

Plusieurs services de bases de données ont été bonifiés pour offrir des capacités « hyperscale ». Pour les énormes besoins en terme de données ou de performance, les BD opérationnelles pourront utiliser des ressources de grande envergure (Disponible pour SQL Server, MySQL et PostgresSQL).

Power Platform

Microsoft met beaucoup de l’avant les technologies Microsoft 365 dans sa conférence comme les Power Apps, Microsoft Flow et Power BI. Le but de Power Apps est d’offir la possibilité aux organisations de fournir des solutions logicielles sans nécessairement avoir recours à des développeurs. Au minimum, leur tâche sera dramatiquement réduite. Une démo a d’ailleurs été faite démontrant la possibilité de créer une application mobile à partir d’un outil de conception web. Pour en savoir plus, consultez le site PowerApps.

20190506_123049.jpg

.NET Platform Roadmap

20190506_135216

Une session avec les « lower Scotts » avait lieu aujourd’hui au sujet des nouveautés dans le monde .NET. Il faut dire que la grosse nouvelle a été publiée un peu plus tôt dans la journée lorsque .NET 5 a été révélé. Il y aura une seule version de .NET à partir de 2020 pour développer sur toutes les plateformes (Windows, Linux et MacOS). Notons en particulier les possibilités d’interopérabilité avec Java et Swift et les options de compilation JIT et Ahead of Time (AOT). .NET 5 sera la suite de .NET Core. Les applications .NET Framework peuvent donc continuer leur migration vers .NET Core selon les besoins. À noter que la version .NET 4.8 demeurera supportée avec les différentes versions de Windows.

D’autres nouveautés ont aussi été relatées comme ML.NET 1.0 et son Model Builder. Ce dernier permet de créer et entraîner des modèles de machine learning localement sur notre machine. Un assistant facile d’utilisation est rendu disponible directement dans Visual Studio. Les outils .NET pour Apache Spark ont aussi été démontrés de manière complète avec des performances meilleures que Python.

20190506_142125.jpg

Pour ce qui est de .NET Core 3 qui supporte WinForms, WPF et UWP, Microsoft garde le cap et rappel les avantages de migrer nos applications vers .NET Core :

20190506_143501.jpg

Un bref rappel a aussi été fait pour les plus récentes nouveautés de ASP.NET Core 3 comme :

Windows Containers

Pour finir, une session a eu lieu sur l’état des conteneurs dans Windows. C’est définitivement Windows 2019 qui offre le meilleur support pour les conteneurs Windows, mais il m’est apparu assez clair que la maturité n’était pas au rendez-vous. Les tailles d’images demeurent volumineuses et la complexité d’utilisation est plus grande que du côté Linux. Actuellement, il n’est pas possible de récupérer les logs émis par le processus dans le conteneur de manière standard dans StdOut, ce qui limite plusieurs scénarios. À terme, on pourra y retrouver les journaux applicatifs des événements (EventLog) ainsi que certains logs IIS, ce qui est quand même pas mal du tout. Les avancées les plus intéressantes sont du côté de AKS qui permettra d’avoir des noeuds mixtes Windows et Linux.

Conclusion

C’est une première journée très chargée que nous avons eu et nous en attendons une autre semblable demain. Bien qu’il n’y aura pas de keynote à suivre, de multiples présentations très intéressantes tourneront autour d’Azure, .NET et Kubernetes. Stay tuned!

Build 2018 – Bots, Intelligence Artificielle et Développement Windows

Les bots et l’intelligence artificielle sont une belle façon d’intégrer la technologie afin d’augmenter l’efficacité d’une entreprise pour son service à la clientèle. Évidemment, il faut recourir à des outils performants pour y arriver. Microsoft mise beaucoup sur la facilité de développement dans ce secteur. Il veut rendre accessible à tous les développeurs le développement de bots. Dans une autre présentation, on nous a présenté les mises à jour d’UWP qui, quant à elle, continue aussi de recevoir des investissements importants. Voyons un peu ce qui en retourne.

Conversational AI – What’s new?

Pour faire suite à la présentation de la veille principalement sur LUIS, cette présentation était davantage orientée sur les bots et sur l’intégration des différentes services cognitifs qui sont nécessaires pour offrir une expérience de chatbot.

Le Bot Framework a été mis à jour considérablement dans la dernière année. Il est constitué de trois piliers :

  1. BotBuilder SDK v4
  2. Azure Bot Service
  3. Bot Emulator

Le SDK permet essentiellement de créer un service Web API REST qui est appelé par un client bot. Il offre également tous les connecteurs facilitant l’intégration des services cognitifs de Microsoft pour rendre les bots intelligent et l’intégration avec les différents canaux comme Teams, Facebook, Slack et autres.

L’ajout important qui a été apporté est de pouvoir définir des middleware. C’est entre autres ce qui facilite la traduction machine en simultanée. Tous les messages peuvent passer dans un middleware de traduction à l’entrée et à la sortie.

Dispatch

IMG_3362

Dans les annonces dignes de mention, on retrouve l’ajout d’un module de répartition pour faciliter l’aiguillage d’une requête vers le bon service cognitif. Cet outil permet de faire un premier appel à une application LUIS pour qu’il aiguille la requête entre les différentes applications LUIS ou QnAMaker que nous aurions configurés. Voici un tutoriel qui permet de le faire.

Par ailleurs, un outil de ligne de commande est aussi fournit. Il permet de configurer l’application Dispatch et aussi de demander un rapport intéressant. Ce dernier indiquera quels énoncés sont susceptibles d’être ambiguës ou lesquels sont dupliqués dans plus d’un modèle de langage (LUIS vs QnAMaker par exemple). Il devient beaucoup plus facile de combiner les différents outils de langage dans un même bot.

Outillage

Un élément qui n’était pas nécessairement évident auparavant était de gérer les modèles de langage comme du code. Le DevOps étant omniprésent, même le développement d’intelligence artificielle suit la parade. Quatre outils ont été ajoutés pour développer les bots en ligne de commande :

  1. MSBot
    Permet de configurer un bot par ligne de commande
  2. LuDown
    Permet d’écrire nos énoncés en MarkDown. On utilise ensuite la ligne de commande pour mettre à jour LUIS côté serveur.
  3. LUIS CLI
    C’est ce qui permet de gérer les modèles LUIS comme du code. On peut exporter ou importer une application LUIS. Très utile dans un « Release pipeline ».
  4. Az Bot
    Pour contrôler les services bots d’Azure par ligne de commande. Bénéficie de la même intégration de gestion d’identité que les autres services Azure.

 IMG_3363

 

Project Conversation Learner (Research)

ProjectConvLearner

La fin de la présentation a été époustouflante. Un chercheur de Microsoft est venu présenté son projet. Il vise à entraîner les modèles de langage naturel de manière plus efficace. En effet, plutôt que de passer par de la saisie massive d’énoncé qui sont ensuite envoyé à LUIS, on utilise l’interface d’un chat bot pour envoyer nos énoncés. Le bot nous répond du mieux qu’il peut et on corrige les mauvaises réponses dans l’interface visuelle directement. Ce module permet aussi de revisiter les discussions passées et de corrigé les mauvais tirs du bot.

Évidemment, on ne sait pas si ce projet verra le jour et encore moins quand, mais on ne peut qu’espérer vu les possibilités impressionnantes qu’il apporterait.

ProjectConvLearnerCorrection

 

Rapidly Construct LOB Applications with UWP and VS 2017

Depuis plusieurs années, Microsoft fait la promotion de sa plateforme UWP (Universal Windows Applications). L’attrait le plus important de cette technologie est de pouvoir faire des applications qui s’exécutent sur de multiples appareils comme des téléphones, des PCs et aussi sur Xbox. Les efforts ont d’abord été mis sur les outils permettant de faciliter le développement pour les marchés de consommation personnelle au détriment des applications d’entreprise. Microsoft veut maintenant s’assurer que sa plateforme UWP devienne le premier choix de développement d’application Windows.  Si on combine cela avec le support de .NET Core dans WPF et WinForms et l’ajout des XAML Islands, on comprend que la voie est toute tracée pour converger vers le UWP.

Pour faire de UWP la meilleure plateforme de développement Windows, il fallait lui faire quelques modifications.

 

Densité

Par défaut, les layouts UWP sont très espacés. Il est donc difficile d’afficher beaucoup d’éléments dans un même écran. Les nouvelles versions de Windows vont densifier les contrôles visuels d’environ 33% par défaut. Pour ceux pour qui ça ne sera pas assez, un dictionnaire de ressources sera aussi mis à disposition pour densifier davantage. On parle ici du mode compacte.

IMG_3352

 

Gestion des thèmes de couleurs

La gestion des ensembles de couleurs est relativement difficile avec XAML. Il faut connaître les noms des différentes ressources à redéfinir et ne pas en oublier. Par ailleurs, il faut faire beaucoup de tâtonnement pour réussir à uniformiser le tout.

Afin de faciliter cette tâche fastidieuse, Microsoft développera un nouvel outil nommé ColorDemo (nom temporaire, ils sont ouverts aux suggestions :)). Cet outil permettra de changer les couleurs facilement dans une application qui affichera la plupart des contrôles visuels en simultané afin de voir le rendu. Une fois que l’on aura le bon résultat, on pourra exporter les configurations en XAML. Suffira alors d’importer le dictionnaire de ressource généré et le tour sera joué.

ColorDemo

 

Contrôles et validations

Pour faire de vraies applications de ligne d’affaires, il manquait quelques contrôles importants qui seront ajoutés:

  1. DataGrid
    Essentiellement celle qui existait en Silverlight. Elle sera en premier disponible via le Windows Community Toolkit et sera intégrée à la plateforme lorsqu’elle atteindra les standards de qualité.
  2. ComboBox éditable
  3. MenuBar et TreeView
    Ceux-ci seront disponibles via la librairie WinUI annoncée plus tôt durant la conférence.

UWP intégrera le support de l’interface INotifyDataErrorInfo qui était apparue en .NET 4.5 pour WPF. C’est réellement l’interface qui donne le plus de flexibilité pour la gestion des validations en XAML. C’est donc un ajout très important pour faire des formulaires de saisie. Par ailleurs, des gabarits (templates) par défaut seront fournis pour les différents contrôles afin d’afficher les messages d’erreur.

 

Ce qui manque…

J’ai été un peu déçu de voir le peu d’évolution autour de XAML Standard. Xamarin n’a publié qu’une librairie « façade » qui sera intégrée éventuellement. Pour le moment, il n’y a pas beaucoup d’avancé dans ce domaine et mon rêve d’avoir un XAML unifié pour le développement mobile et poste de travail m’apparaît peu réaliste à court ou moyen terme.

 

Varia UWP

SI vous ne connaissez pas Windows Template Studio, vous devez absolument regarder cet outil. Il facilite la création de projets en générant beaucoup de code qu’il faudrait autrement faire manuellement. Il supporte le MVVM avec la plupart des frameworks populaires.

L’application Van Arsdel fournit de bons exemples d’utilisation des contrôles UWP et peut servir d’inspiration pour définir votre propre application.

L’expérience de déploiement sera aussi améliorée avec l’arrivée de MSIX.

 

Conclusion

Encore une journée au Build 2018 qui a été bien replie. D’autres présentations de cette journée sont susceptibles de vous intéresser comme celle sur les Dev Spaces pour le développement microservices et Kubernetes. Je vous encourage à vous promener sur le site Channel9 pour y découvrir ce qui pourrait vous intéresser. Amusez-vous!

Le présent et le futur de la plateforme .NET

net_robot

Hier j’ai assisté à la présentation de Scott Hanselman et Scott Hunter à propos du roadmap de .NET et des outils de développement. Voici les faits saillants

Commençons d’abord par un constat: je ne me souviens pas avoir vu une seule diapositive à propos du Framework .NET. Une version 4.8 est en préparation mais clairement ce n’est plus là que se passe le show. Aujourd’hui j’ai pu m’entretenir de ce point avec Immo Landwerth qui est le Program Manager de .NET. Il m’a confirmé que pour l’instant il n’y avait pas de plan pour une version subséquente mais que cela ne voulait pas dire pour autant qu’il n’y en aurait plus dans le futur. Clairement le focus est sur .NET Core.

Pas de panique, les bonnes nouvelles s’en viennent 🙂

Tout d’abord .NET se porte très bien. Sur la dernière année, Microsoft a mesuré un gain de 1 millions de développeurs .NET actifs supplémentaires. Ce gain impressionnant peut être attribué à plusieurs facteurs:

  • Le succès grandissant de .NET Core et ASP .NET Core
  • La politique d’ouverture menée par Microsoft incluant le virage open source amorcé par la compagnie
  • Le fait que .NET Core et C# est un duo gagnant en termes de polyvalence. Aujourd’hui .NET Core et C# permettent de développer des applications et services web, des applications consoles et de l’IoT. Très bientôt d’autres types de développement seront supportés. Plus à ce sujet dans la suite de ce billet.

.NET Core 2.1

Fraîchement sorti, .NET Core 2.1 apporte son lot d’améliorations dans le framework proprement dit mais aussi à la périphérie avec Entity Framework Core et ASP .NET Core.

Digne de mention:

  • L’introduction de la classe Span<T> permet d’optimiser les scénarios de transformation de sous-ensemble de données stockées dans des zones de mémoires contigües et ce sans compromis sur la performance.
  • Optimisation des communications réseaux. Des améliorations notables ont été réalisées dans l’implémentation des Socket, des classes HttpClient et SslStream qui permettent de gains de 200% sur certains benchmark, principalement sous Linux.
  • Introduction du Windows Compatibilty Pack qui donne accès à quelques 20 000 fonctions API de Windows complémentaires au lot que .NET Standard 2.0 apportait déjà. Ce pack devrait faciliter la migration d’applications à .NET Core.

.NET Core 2.1 s’immisce aussi dans le développement IoT. Tout d’abord il est compatible avec les processeurs ARM32 ce qui lui permet de s’exécuter sur des cartes électronique ou appareils IoT comme le Raspberry Pi. Il peut aussi s’exécuter sur Ubuntu (>= v18.04), sur la distribution Alpine (>= v3.7) et Windows 10 IoT et dans des containers Linux.

Les téléviseurs Samsung qui embarquent l’OS Tizen 4.0 sont maintenant capables d’exécuter des applications .NET Core. Scott Hanselman nous demande de ne pas coller des stickers .NET Core sur les téléviseurs Samsung présents dans les Showrooms de nos magasins favoris 🙂

Le futur

core30.jpg

La prochaine version majeure de .NET Core sera la v3.0. L’intérêt principal de cette version réside dans le fait qu’elle va élargir notre terrain de jeu puisqu’il sera dès lors possible de développer des applications de bureau (UWP, WinForms et WPF) et des applications d’intelligence artificielle grâce au support du framework ML .NET

Les applications de bureaux

Revenons au support des applications de bureau. C’est une annonce majeure. Non seulement nous pourrons porter nos applications Winforms et WPF vers .NET Core mais aussi nous pourrons les améliorer en exploitant les nouveaux contrôles UWP Fluent Design au travers des XAML Islands. Cela permettra de rendre les applications patrimoniales plus attractives, plus conviviales et mieux intégrées à Windows 10.

Mais ce n’est pas tout: .NET Core offre des gains de performances qui rendent les applications de bureau jusqu’à 2.5x plus rapides. Durant la démo, une application Winforms a été exécuté à la fois en .NET 4.x et en .NET Core 2.1. La différence de performance était clairement perceptible. Cette vélocité accrue pourrait être un autre incitatif à convertir une application de bureau vers .NET Core.

Cerise sur le gâteau, Microsoft planche aussi sur un moyen d’empaqueter une application .NET Core dans une sorte de conteneur applicatif (rien à voir avec les conteneurs Docker je précise) Le conteneur prendra la forme d’un exécutable qui contiendra l’application elle-même, les parties de .NET Core nécessaires à son exécution ainsi que les librairies externes utilisées. L’objectif est de permettre l’exécution côte-à-côte de plusieurs applications utilisant des versions différentes de .NET Core. Dans sa version finale, l’outil de packaging sera capable d’identifier les espaces de noms et références externes qui ne sont pas exploités afin de réduire au maximum la taille du conteneur.

Machine Learning .NET (ML .NET)

ML .NET est un framework de machine learning utilisé en interne depuis plusieurs années chez Microsoft qui se trouve maintenant être out-sourcé. .NET Core permettra d’en tirer parti. Voici l’URL officielle du site collaboratif qui vous permettra d’en savoir plus.

Les outils

Microsoft veut clairement offrir les meilleurs outils de développement quelques soient les langages et plateformes utilisés. 3 IDE sont offerts: Visual Studio, Visual Studio Mac et VS Code.

Voici quelques améliorations de Visual Studio à venir:

  • Amélioration du fonctionnement du test runner de Visual Studio avec des mises à jour asynchrones des résultats de l’exécution des tests alors que ceux-ci sont en cours d’exécution.
  • Possibilité de faire du pas à pas dans le code de librairies Nuget en allant directement télécharger le source correspondant dans le répo Git d’où est issus le composant. Cela est rendu possible par l’introduction de l’URL du répo et de l’identifiant du commit ayant servi à la création du paquet Nuget directement dans le fichier .nuspec
    nuspec_git
  • Prise en charge des fichiers .editorconfig dans lesquels il est possible de définir ses conventions d’écriture de code. Le compilateur Roslyn interprète les paramètres présents dans ces fichiers et vérifie que les conventions sont respectées. Pour chaque règle il est possible d’indiquer le niveau de sévérité associé: ne rien faire, générer un avertissement ou générer une erreur.
  • Les développeurs Web vont finalement pouvoir profiter de fonctions de ré-usinage de code à l’intérieur de pages aspx et razor.
  • VS permettra de construire des images Docker en se passant du projet Docker-compose
  • Une extension de Visual Studio va permettre le support de Kubernetes et le déploiement d’images dans AKS.

La vidéo de cette présentation est maintenant disponible sur Channel 9