Remote Debugging .NET Containers


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 to understand how Visual Studio uses this Dockerfile to build your images for faster debugging. 
FROM AS base 

FROM AS build 
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 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 | /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:


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:
    "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
             "sourceFileMap": {
                 "/src/": "${workspaceRoot}"

Launch.json file under .vscode folder


The interesting part is in blue. Note the following:

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.


« 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 | /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.


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 :

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}"

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.


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


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 to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM AS base

FROM AS build
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
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 | /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 :


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:
    "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
            "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.


« 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 | /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.


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 :

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}"

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.


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 !

Building ASP.NET Core docker image on Azure DevOps : no such file or directory


When you try to build a docker image for a default ASP.NET Core project template on Azure DevOps for the first time, you should encounter the following error :

Step 6/26 : COPY [« TestClassicApp.Api1/TestClassicApp.Api1.csproj », « TestClassicApp.Api1/ »]

COPY failed: stat /var/lib/docker/tmp/docker-builder260812138/TestClassicApp.Api1/TestClassicApp.Api1.csproj: no such file or directory

##[error]COPY failed: stat /var/lib/docker/tmp/docker-builder260812138/TestClassicApp.Api1/TestClassicApp.Api1.csproj: no such file or directory

##[error]/usr/bin/docker failed with return code: 1

From Azure DevOps logs.

It will be the case if you have a hierarchy in your solution folder where your projects are placed in subfolders.


The problem comes from the fact that, by default, the docker build task run with the buildContext set to ** (equivalent to the Dockerfile directory). If your project is placed in a subfolder like the sample above, it won’t work.

If we look closer at the Dockerfile instruction, we’ll see that the COPY operation use the full path to the csproj : COPY [« TestClassicApp.Api1/TestClassicApp.Api1.csproj », « TestClassicApp.Api1/ »]. Since we are in the context of the Dockerfile location, there’s no subfolder TestClassicApp.Api1 as the Dockerfile is currently in this folder.


The simple fix is to specify a parameter to the Docker build task named buildContext :

task: Docker@2
displayName: Build and push an image to container registry
  command: buildAndPush
  repository: $(imageRepository)
  dockerfile: $(dockerfilePath)
  containerRegistry: $(dockerRegistryServiceConnection)
  buildContext: .
  tags: |
Hope this will help other people !

Exécution de code natif dans le navigateur. Tsunami en vue

Web Assembly, Blazor and Co.

Lors de cette édition 2019 de la conférence Build, l’exécution de code natif dans le navigateur a été un bon sujet de discussion. Plusieurs grosses sessions y ont été consacrées. J’ai participé à plusieurs d’entre elles et vous fait un petit retour sur ce que j’ai appris et ce que je pense. N’hésitez pas à me partager vos remarques et commentaires.

WebAssembly (Wasm) est une specification qui définit un format de représentation binaire de code exécutable optimisé et ouvert pour le web. Pour les développeurs .NET ou Java que nous sommes, c’est l’équivalent du IL ou du ByteCode. L’objectif visé est de permettre l’exécution de code natif sur le web.

Aujourd’hui les principaux navigateurs PC ou mobiles du marché implémentent déjà WebAssembly 1.0. Et si vous avez un doute sur les capacités de la technologie, jetez un oeil à la capture d’écran suivante dans laquelle un système d’exploitation Windows 2000 complet tourne à l’intérieur d’une page web. Bluffant!

20190508_084109 (2)
Windows 2000 Professionnel s’exécute à l’intérieur du page HTML!

Pourquoi Web Assembly pourrait être la prochaine révolution du Web?

Voici les principales raisons pour lesquelles WebAssembly a toutes ses chances de percer.

Il offre des performances qui dépassent de loin ce que peut faire Javascript. Il utilise des interfaces qui lui donnent accès aux ressources matérielles communes aux différents types d’appareils. Javascript est interprété et n’exploite pas le multithreading à l’intérieur du navigateur. WebAssembly a moins de limitations de ce côté.

Il offre les mêmes garanties d’isolation (sandboxing) que Javascript. Le code binaire se voit contraint aux mêmes limitations que les scripts (pas d’accès aux systèmes de fichiers, aux processus, à la mémoire etc.). Donc on fait du natif au moins aussi secure que Javascript.

L’exécution de code WebAssembly est disponible par défaut car il fait partie du navigateur. Nul besoin de télécharger des runtimes. C’est un bon avantage par rapport à certaines technologies comme Silverlight ou encore Flash. On se facilite grandement la vie pour le déploiement, la disponibilité et la gestion des versions.

Il garantit une portabilité du code à travers les plateformes. Le même fichier binaire s’exécute dans tous les navigateurs sans adaptation. Il faut savoir que Wasm n’est pas limité à s’exécuter dans des navigateurs. Il est déjà aujourd’hui utilisé dans d’autres contextes comme dans le Blockchain par exemple. C’est juste qu’aujourd’hui l’engouement a pas mal pris du côté de la communauté Web qui y voit de l’intérêt. À terme, Wasm devrait même devenir une cible de compilation dans votre IDE préféré au même titre que x86, x64 ou ARM!

Wasm est un standard du W3C. Le groupe de travail est composé entre autres de représentants des principaux navigateurs du marché. Nul doute que cela contribuer positivement à son adoption, à sa compatibilité et à sa pérennité.

Comment exploiter Web Assembly ?

Aujourd’hui des langages comme C/C++/RUST et Go possèdent déjà du tooling pour produire du binaire au format Wasm. Ce sont des langages qui sont des citoyens de premières classes pour Web Assembly.

WebAssembly Studio vous permet de compiler et d’exécuter du code C dans votre navigateur.

Mais qu’en est-il du C# et du code .NET ?

C’est là que les équipes Xamarin et .NET Core entrent en jeux.

L’équipe Xamarin a produit une version du runtime Mono au format Wasm qui fonctionne dans le compilateur et qui est capable de transformer à la volée du code IL .NET vers WebAssembly. Pour ceux qui ne sont pas familier avec Mono, il s’agit d’une implémentation alternative du Framework .NET qui tourne sous Mac, Linux, iOS et Android. Elle est conforme .NET Standard 2.0. Mono est donc le socle technique qui permet l’exécution de code .NET à l’intérieur du navigateur.

20190508_085124 (2)

Du côté de l’équipe ASP.NET Core, on s’est penchés sur la faisabilité et l’opportunité de proposer un rendu client basé sur une réutilisation de certaines technologies disponibles. Elle a donc démarré un projet expérimental dont le nom de code est Blazor. Objectif: proposer les vues Razor de ASP.NET dans le navigateur. Sur les derniers mois, les livraisons à la communauté ont été très fréquentes pour partager les avancées réalisées et récolter du feedback. Après 9 itérations, l’intérêt et la faisabilité ont été prouvées. L’équipe ASP.NET vient d’officialiser sont support.

20190507_142801 (2)
Blazor offre deux modes de fonctionnement pour le rendu. Aujourd’hui, seul le rendu server-side est supporté. Le client-side nécessite encore quelques optimisations.

Je suis allé voir la session de Daniel Roth durant laquelle il a démontré une application web réalisée avec Blazor. C’est durant cette présentation que j’ai vraiment pu prendre la mesure de l’intérêt de cette technologie:

  • Tout d’abord Blazor et le support de .NET en général dans le navigateur permet de réutiliser du code qu’on a déjà éventuellement écrit comme des contrôles utilisateurs, des routines de validation, de la logique d’affaire.
  • On peut utiliser toutes les librairies disponibles sur qui sont compatibles .NET Standard 2.0. C’est un gros plus.
  • On peux valoriser nos connaissances du langage C# et de .NET pour faire du code client! Pas de nécessité de se développer une seconde expertise dans un langage Javascript.

Je trouve que ce dernier point est important pour les entreprises qui ont fortement investi dans la formation de leurs employés ces dernières années.

20190507_142715 (3)
L’application Blazzing Pizza exploite pleinement Blazor pour le rendu. Tapez le lien dans votre navigateur pour accéder au code et aux explications.

La plateforme Uno

La compagnie nventive, basée à Montréal, a développé une plateforme qui s’appelle Uno et qui elle aussi offre une option d’exécution dans le navigateur.

Uno propose d’utiliser la technologie XAML introduite par WPF pour concevoir l’interface de votre application quelque soit la plateforme sur laquelle elle doit fonctionner ultimement. Elle s’appuit sur un tooling de conversion qui va produire un rendu équivalent, mais en utilisant des fonctionnalités natives aux plateformes cibles. Ainsi, par exemple, le Button XAML deviendra un DIV dans votre navigateur.

Uno possède déjà une bonne maturité et une notoriété grandissante. nventive l’utilise depuis longtemps pour développer des applications mobiles pour de grandes entreprises partout dans le monde (UPS, Red Bull etc). C’est assez récemment que l’équipe a développé le support pour Web Assembly.

En conclusion

En revenant du Build, je suis pas mal convaincu que nous allons beaucoup entendre parler de Web Assembly dans les mois qui viennent. Le tooling autour de C# et de .NET va certainement évoluer rapidement et cela va valoir la peine de se pencher sur cette technologie qui a tellement à offrir.

Je retiens aussi que pour les entreprises qui veulent préserver leurs investissements dans le temps que c’est une technologie qui offre des perspectives uniques en terme de réutilisation de code et de réutilisation des connaissances des développeurs.

I believe

Build 2019 – Jour 3 – Azure Functions, Windows Terminal & Web Assembly


Cette dernière journée a été marquée par quelques présentations un peu moins intéressantes, mais je traite dans cet article des sujets qui sont en plein effervescence. Alors au menu : Azure Functions, Windows Terminal et Web Assembly (Wasm).

Azure Functions

Les Azure functions sont au coeur de l’offre de service serverless de Azure. Elles offrent la possibilité d’exécuter du code sans se soucier de l’infrastructure sous-jacente. L’élasticité (scaling) et la gestion des ressources est la sous la responsabilité d’Azure. Suffit de fournir un script ou un bout de code et Azure nous permet de l’exécuter.

Les gros avantages de cette plateforme sont son modèle de micro-facturation et son architecture pilotée par les événements (Event-driven architecture, EDA). Vous êtes facturés seulement lorsque le code s’exécute. C’est l’avantage que propose la plupart des plateformes serverless. Pour ce qui est de l’EDA, elle est facilitée, car Azure permet de déclencher des functions à partir d’une multitude d’événements déjà pré-configurés. Il peut s’agir d’un message qui a été ajouté dans une file de messages ou encore d’un changement de données dans CosmosDB. Bref, les possibilités sont grandes et les coûts sont presques négligeables dans certains cas.

Durable functions

J’ai appris durant la conférence que l’offre des Durable Function n’était pas seulement pour permettre l’exécution plus longue de certaines fonctions. En fait, ce modèle de programmation ouvre la porte à différents scénarios d’orchestration ou de coordination entre les éléments serverless. Certains patrons sont intégrés de belle manière au langage de programmation et permettent de définir des workflows simples à l’aide seulement d’Azure Functions. C’est donc une alternative simple aux applications Logic Apps.


Pour plus de détails


La plus grande nouveauté est sans doute KEDA qui permet, entre autres, de déployer des Azure Functions dans Kubernetes directement. Le projet permettra de tirer profit de plusieurs événements provenants de Kubernetes ou de l’extérieur des clusters pour effectuer la gestion automatique du scaling et de l’exécution de nos Azure Functions.

Par ailleurs, certaines fonctionnalités sont très récentes pour les Azure Functions comme l’ajout d’un plan Premium, le support du langage PowerShell et le support de l’injection de dépendances.


Windows Terminal


Microsoft a annoncé qu’il travaillait sur un nouveau terminal et sur une nouvelle console de ligne de commande qui sera aussi open-source. C’est littéralement du code de Windows qui se retrouve sur GitHub! À titre d’exemple, voici les principaux ajouts qui seront fait prochainement :

  1. Ctrl+Scroll : Ajuster le zoom
  2. Ctrl+Shift+Scroll : Ajuster la transparence de la fenêtre
  3. Amélioration du copier-coller
  4. Fichier de profil en JSON pouvant être partagés et distribués pour conserver nos personnalisations
  5. Support des onglets

Le code est déjà disponible sur GitHub et ils accepteront les Pull Requests éventuellement, ce qui veut dire qu’on peut tous participer au développement de Windows ! Après seulement 48 heures, le dépôt comptait déjà plus de 25 000 étoiles. Je prévois un problème de capacité du côté de Microsoft quand viendra le temps de gérer les demandes. Pour vous mettre l’eau à la bouche, voici le vidéo qui a été présenté pour illustrer la direction qu’ils veulent prendre.

Web Assembly

Ça fait déjà un petit moment que je tente de créer un buzz dans ma région autour de cette nouvelle technologie qui, selon moi, va littéralement révolutionner plusieurs paradigmes dans le web et même dans d’autres sphères de l’informatique.

Jérome Laban est le CTO de la plateforme Uno et travaille pour nventive à Montréal. Il nous présentait les dernières avancées de Web Assembly (WASM) dans le monde .NET. Microsoft travaille à créer un framework SPA en .NET avec Blazor, mais d’autres initiatives sont en cours également comme Uno et Ooui.

Il existe deux façons d’afficher des éléments visuels dans le navigateur présentement :

  1. Utiliser les canvas HTML 5 pour dessiner des pixels
  2. Générer du HTML

Dépendemment des scénarios d’utilisation, une approche peut être plus adaptée que l’autre. Avec l’utilisation des canvas, il a été possible d’exécuter une version de Windows 2000 dans le navigateur (lien). Du côté de Uno platform, ils ont optés pour l’approche de génération HTML.


Pour ceux qui veulent tester WASM avec un projet .NET, le paquet nuget Uno.Wasm.Bootstrap vous permet d’ajouter des outils de compilation qui génèrent des artéfacts permettant d’exécuter votre application .NET dans le navigateur.


La démo de la fin qui générait du code à l’aide de Roslyn directement dans la navigateur était aussi très impressionnante. Une petite application console qui utilisait EF Core et SQLite a été compilée dans le navigateur pour ensuite être exécutée localement.

Pour ceux qui n’ont pas encore regardé les possibilités de WASM, vous devez absolument le faire!


C’est ce qui met fin à mon aventure à la conférence Build 2019. Encore une fois, une expérience incroyable qui s’est terminée avec un party dans le stade de football des Seahawks de la NFL.

Microsoft continue sa stratégie d’être de plus en plus ouvert afin d’être le plus inclusif possible en intégrant des produits open-source de plus en plus et en continuant d’être transpartent sur ses projets comme c’est le cas avec Windows Terminal. C’est aussi un élément qui ressort de manière générale quand on discute avec les gens des équipes de réalisation. Ils veulent avoir du feedback sur ce qu’ils développent. On voit bien qu’ils ont pris le virage agile et DevOps très au sérieux. Ce sont tous ces types de rétroactions qui leur permettent de demeurer au devant des autres compagnies.

Comme dirait le monsieur avec le polo rouge : There’s never been a better time to be a developer.

Build 2019 –Top 5 des petits outils innovants pour les dev

All developer things with Scott Hanselman

J’ai assisté à cette session qui avait pour but de donner un peu de visibilité à certains projets ou expérimentations qui n’étaient pas encore suffisamment finalisés ou positionnés pour avoir leurs propres sessions à la conférence Build. C’est Scott Hanselman qui a eu cette bonne idée pour les faire connaitre et récolter rapidement du feedback. Pour certains d’ailleurs, l’engouement de la communauté sera clé pour leur survie.

Voici donc mon top 5 coup de cœur. N’hésitez pas à me partager vos avis et commentaires.

No 1: Try .NET

L’objectif de Try .NET est de vous permettre de proposer du contenu interactif dans lequel le lecteur peut interagir avec du code .NET, le modifier et l’exécuter directement depuis son navigateur. On parle ici d’une exécution locale qui ne requiert pas de communications vers un quelconque serveur qui exécuterait le code et retournerait les résultats! Ce projet utilise la technologie Blazor.

Cela peut sembler anodin écrit aussi simplement mais cette technologie rend possible certains scénarios d’utilisation très intéressants. En voici deux exemples:

  1. Vous vous apprêtez à donner un atelier ou un dojo de formation sur C#. Vous devez prévoir des machines pour les participants, installer Visual Studio sur chacune d’elles, s’assurer que vous avez des licences etc. Avec Try .NET, les choses sont beaucoup plus simples. Tout ce qu’il vous faut, c’est un navigateur web. Les participants l’utilisent pour visualiser le contenu de la formation et écrire les bouts de code qui correspondent à ce qui est demandé dans les exercices. Ils peuvent éditer le code, l’exécuter et valider qu’ils obtiennent bien les résultats attendus.

  2. Vous fournissez une librairie de code via Nuget et vous désirez publier une documentation interactive qui permet à vos futurs consommateurs de découvrir des exemples d’utilisation qu’ils peuvent exécuter live sans avoir à installer ou configurer quoi que ce soit. Mieux encore, ils peuvent modifier les codes exemples et expérimenter votre librairie directement à partir de la page de documentation!

Comment ça fonctionne ?

En tant que fournisseur de contenu, vous écrivez vos documents au format Markdown (MD). Ceux-ci mélangent habillement le texte et des sections de code délimitées par une succession de trois accents graves (« `). Vous pouvez déposer ces fichiers dans un repo Git pour les rendre accessibles à vos consommateurs. Bien que cela n’a pas été explicitement dit lors de la session, j’imagine qu’il sera possible aussi d’exposer ce contenu sur un site. Ci dessous

Une section de code imbriquée dans le texte explicatif

En tant que consommateur, vous téléchargez le contenu sur votre poste de travail (git clone par exemple), ensuite vous lancez une invite de commandes, vous vous déplacez dans le répertoire qui contient les fichiers MD et vous exécutez la commande dotnet try. Votre navigateur démarre, effectue son rendu et vous pouvez commencer à lire le contenu et surtout expérimenter le code.

Version interactive de la documentation de Newtonsoft.Json dans laquelle vous pouvez directement essayer des codes exemples qui utilisent la librairies!

Comment puis-je l’essayer ?

Try .NET est un projet open source disponible sur Github à l’adresse suivante :

Si vous voulez l’essayer, il y a déjà trois exemples de contenus interactifs. Clonez le repo à l’adresse suivante

En conclusion

Je trouve que c’est un outil fabuleux qui ouvre des perspectives très intéressantes pour offrir du contenu interactif dont le but est d’apprendre, de parfaire sa connaissance ou d’expérimenter .NET. C’est un outil idéal pour les équipes dont la mission est de former, soutenir ou outiller d’autres équipes de développement.

Microsoft va mesurer l’engouement de la communauté pour ce projet. N’hésitez pas à l’essayer et à y contribuer.

No 2 : Le retour (timide) des Windows Powertoys

Si par le passé, vous avez déjà utilisé des Powertoys sur d’anciens systèmes d’exploitation comme Windows 95, NT ou Windows XP, il est probable que vous en gardiez un excellent souvenir. Les powertoys sont de petits outils qui améliorent votre productivité ou votre efficacité. Le genre d’outils pour lesquels on développe rapidement une addiction.

Windows 10 n’a jamais eu de Powertoys officiels… jusqu’à maintenant

Deux premiers ont été présentés. Il n’y a pas encore de quoi pavoiser mais c’est une excellente nouvelle et un bon début.

Le premier se nomme MTND (Ugh!) et permet de déplacer une fenêtre dans un nouveau bureau créé à la volée. Il suffit de laisser le pointeur de la souris au-dessus de l’icône qui permet de maximiser une fenêtre. Après une fraction de seconde, un bouton apparait. Si vous cliquez dessus, la fenêtre est déplacée vers un nouveau bureau et occupe le plein écran.

Permet de déplacer votre fenêtre

Le second se nomme Windows Key Shortcut Guide et permet d’afficher une carte des raccourcis Win + touche du clavier disponibles sous Windows 10. Super utile si on tient compte que la plupart d’entre nous ne connait pas 10% des raccourcis disponibles!

La liste des raccourcis Windows apparaît en plein écran

Ils seront open source et disponibles sur Github à l’été 2019 à l’adresse suivante :

Actuellement la page README.MD du repo liste les prochains powertoys qui sont au carnet de produit. Je vous laisse le soin de les découvrir!

No 3 : DOS but not DOS

DOS but not DOS est une réécriture complète de l’invite de commandes CMD que nous avons depuis la nuit des temps sous Windows.

Vous allez me dire : « Pourquoi une nouvelle version ? » Hé bien en voici les motivations principales

  • La vitesse d’affichage a été grandement améliorée par l’utilisation de DirectX/DirectWrite. Vous bénéficiez maintenant de l’accélération matérielle de votre carte graphique. À première vue, cela semble étrange d’améliorer la vitesse d’affichage d’une boîte DOS. Mais finalement pas tant que cela: il se trouve que le défilement de texte est pour beaucoup responsable de la lenteur d’exécution de scripts en mode interactif. Pour s’en convaincre il suffit de visualiser l’exécution d’un dir /s sur un répertoire volumineux! Le temps d’exécution dans la nouvelle fenêtre de commande est visiblement plus rapide.
  • L’utilisation de DirectX permet de proposer une fenêtre de commandes avec un look et des fonctions plus modernes : possibilité de zoomer sur le contenu, effets de transparence pour le fond de fenêtre. Rien d’essentiel mais c’est visuellement plus attrayant. Durant la démo, le présentateur a aussi annoncé la venue prochaine d’une nouvelle police de caractères à taille fixe dont le nom est Cascadia Code. La mise à disposition d’une nouvelle police de caractère un événement assez rare qui mérite d’être souligné.

  • Elle s’intègre parfaitement au nouveau Windows Terminal qui propose des onglets dans lesquels on peut ouvrir simultanément plusieurs fenêtres de terminal de types différents comme Powershell, Ubuntu ou encore Azure Cloud Shell

Pour démontrer la vitesse d’affichage, l’équipe a développé une version de Pong en mode texte avec des émojis

No 4 : Exécutables .NET autoportants

Cette fonctionnalité avait déjà été présentée l’année dernière mais ne s’est toujours pas rendue entre nos mains depuis. Le principe est de produire un exécutable .NET qui contient toutes les dépendances nécessaires à son exécution en ce compris le framework .NET ciblé. L’énorme intérêt est clairement la portabilité de votre application qui s’exécutera aisément sur n’importe quelle machine Windows.

L’inconvénient par contre est que l’exécutable a une taille considérable (168Mb durant la démo). Scott a expliqué que certaines optimisations de type Tree Shaking devaient encore être faites pour éliminer de l’EXE les DLLs du framework qui ne sont pas utilisées par l’application.

Quoi qu’il en soit c’est une fonctionnalité intéressante qui va permettre aux entreprises qui ont de grosses applications Windows Forms ou WPF, de continuer à les distribuer aisément sous Windows 10.

No 5 : Configuration des préférences de nettoyage du code par profil.

Visual Studio 2019 va permettre la configuration de profil de nettoyage dans lequel vous allez pouvoir indiquer quels types de nettoyage de code doivent être exécutés dans tel ou tel contexte. C’est une addition intéressante qui permettra d’adapter le ré usinage en fonction d’un projet, en fonction du fait que vous travaillez sur un projet professionnel ou personnel etc.

L’écran qui permet de configurer les options de nettoyage pour chaque profils

Build 2019 – Jour 2

Écrire un article résumant une journée complète de conférences qui n’aurait pas l’air de sauter du coq à l’âne n’est pas une tâche facile. Pourtant, je pense que l’information recueillie aujourd’hui est très pertinente. C’est pourquoi je vous propose des résumés des différentes présentations intéressantes auxquelles j’ai assisté aujourd’hui à la deuxième journée de la conférence Build 2019 de Microsoft.

Productivité avec Visual Studio 2019

20190507_153018 (2).jpg

Le but n’était pas de vous énumérer toutes les améliorations de VS 2019 comme une liste d’épicerie, je mentionnerai seulement celles qui m’apparaissent plus pertinentes. Pour la liste complète, vous pouvez consulter les notes de livraison.

Depuis la version 2017, Visual Studio améliore sans cesse ses performances. Il gère de mieux en mieux les solutions de grande taille et la nouvelle expérience de démarrage ainsi que les filtres de solutions sont dans cette lignée.

Les Code lens sont maintenant offertes dans la version Community et sont aussi extensibles. Il est maintenant possible de créer ses propres Code lens!!!

On peut aussi voir ou éditer les fichiers de projet avec un banal double-clique. Know it, learn it, love it!

Aperçu de certaines fonctions

Dans les versions Preview, certaines fonctions sont disponibles pour recueillir le feedback. L’ajout de l’auto-complétion dans les chaînes de caractères RegEx a notamment retenu mon attention.

Aussi, IntelliCode a été livré formellement, mais certaines nouvelles fonctionnalités sont déjà en route.

Pour rappel, IntelliCode permet d’utiliser le Machine Learning pour améliorer l’expérience des développeurs. Entre autres, les éléments d’intellisense les plus populaires, dans le contexte de notre curseur, apparaîssent en premier.

Il sera prochainement possible d’entraîner le modèle d’IntelliCode avec notre propre code pour qu’il soit en mesure de nous aider avec les classes que nous développons nous-mêmes. L’exécution se fait localement pour plus de confidentialité. Il sera également possible de partager le modèle ainsi généré avec nos collègues au besoin.

Toute les équipes finissent par avoir une convention de style pour le code. Le fichier .editorconfig permet aux utilisateurs de VS de personnaliser cette expérience. Toutefois, il peut être difficile de répertorier toutes ces conventions. IntelliCode viendra à la rescousse et permettra de générer un fichier .editorconfig basé sur les conventions informelles de notre base de code.

JAM Stack + Azure Functions

Cette présentation était constituée d’une série de démos pour montrer l’intégration des différents outils de la JAM Stack telle que vue par John Papa et Matt Hernandez. Cet acronyme sert à désigner un ensemble de technologies qui fonctionnent bien ensembles. On parle ici de Javascript, APIs et Markup.


Les démos ont servi à montrer comment il était facile de développer une application Angular dans VS Code qui repose sur un back-end Azure Functions écrit en TypeScript dans le même répertoire que l’application Angular. En plus des capacités formidables d’édition web, VS Code est un excellent outil pour développer et déboguer les Azure Functions localement sur notre poste. La démo utilisait NodeJS pour l’exécution locale et les présentateurs ont montré comment démarrer l’Azure Function et l’application web dans le navigateur en même temps en appuyant sur F5. L’utlisation du fichier launch.json étant la clé.

Les présentateurs ont aussi utilisé les extensions VS Code pour déployer leur application dans Azure directement, ce qui procure une expérience très intuitive et une boucle de rétroaction rapide. Ils ont terminés en montrant comment Azure DevOps pouvait être utilisé simplement pour assembler des artéfacts de déploiement et ensuite les déployer vers les ressources Azure. Dans le pipeline de build, l’utilisation des tâches npm permet de réutiliser le même outillage que l’environnement local pour la partie Angular. Bref, l’intégration est très intéressante et semble assez mature.

Windows Subsystem for Linux v2 (WSL2)

Microsoft a annoncé la nouvelle version de son Windows Subsystem for Linux : WSL 2. Les deux principaux avantages sont la performance et la compatibilité avec les fonctionnalités natives des distributions Linux. Le tout repose sur l’utilisation de la virtualisation légère qu’ils appellent Lightweight utility VM qui est rendu possible avec les travaux qui ont été faits pour le support des conteneurs dans Windows. Une VM Linux est donc démarrée par la couche WSL 2 qui s’occupe d’abstraire les détails pour nous. C’est pourquoi Microsoft distribuera les versions du noyau Linux via les Windows Update. Qui aurait dit que cela se produirait un jour? Toutes les distribution de Linux seront exécutées dans une seule VM en utilisant les fonctionnalités natives qui soutiennent les technologies des conteneurs sous Linux. Il est donc possible d’accéder aux fichiers Windows à partir de WSL et aussi d’accéder aux fichiers de la VM Linux à partir de Windows comme si de rien n’était. Les avancées de WSL 2 permettent aussi l’utilisation de Docker dans WSL directement.


À la fin de la présentation, un rappel a été fait sur le mode « remote » de VS Code. Ce dernier permet d’exécuter l’interface utilisateur sous windows, mais de déléguer l’ensemble de l’exécution au WSL. Pour en savoir plus

Développement de microservices avec AKS, GitHub et Azure Pipelines

Microsoft est sérieux pour ce qui est de l’intégration de Kubernetes dans ses différentes plateformes. En plus de l’expérience du portail Azure en constante amélioration, les outils de développement demeurent une priorité. Dans une présentation comportant plusieurs démos, nous avons vu à quel point il est facile d’itérer rapidement dans un contexte AKS avec Visual Studio. Le débogage d’un conteneur dans AKS est possible directement à partir de notre IDE favori. Une possibilité incroyable est aussi de pouvoir modifier notre application sans avoir à regénérer notre image de conteneur et à la publier dans AKS. L’exécution se fait localement et AKS route les appels vers notre machine de développement, ce qui accélère grandement le développement. Tout cela est rendu possible grâce à DevSpaces : des espaces de développement isolés dans un cluster partagé. Un développeur peut alors modifier un composant et le tester sans impact sur les autres personnes qui effectuent des essais dans le même environnement.


Des outils de ligne de commande ont été ajoutés à la CLI Azure pour faciliter le démarrage. Par exemple,  pour configurer notre espace, les lignes de commande suivantes sont suffisantes :

az aks use-dev-spaces -g [resourceGroupName] -n [clusterName]

az azds prep

az azds up

Il est donc facile de démarrer rapidement avec AKS dans Azure.

Des ajouts intéressants ont été fait dans Azure DevOps qui permettent de voir nos environnements Kubernetes directement dans le portail Azure DevOps.

Screenshot_20190507-225111_Chrome (2).jpg

Toujours dans le but d’accélérer le démarrage avec AKS, Azure DevOps fournit maintenant un assistant de création de pipeline pour AKS. Ce dernier automatise la création des fichiers azure-pipelines.yaml et des manifestes requis par Kubernetes pour déployer notre application. Le tout est alors archivé dans notre dépôt de code pour être modifié comme du code par la suite.

Un scénario qui est vraiment intéressant avec tous ces ajouts est celui de pouvoir effectuer des tests manuels dans un espace DevSpaces AKS basé sur une Pull Request. En détectant qu’un pipeline de déploiement a été déclenché à partir d’une Pull Request, on peut concevoir notre pipeline de sorte qu’il crée un espace DevSpaces à la volée pour nos tests. Toutes ces étapes sont intégrées également dans GitHub.


En plus des nouveautés mentionnées plus haut, une foule d’autres sujets ont capté mon attention comme l’annonce de l’API Management d’Azure qui permettra de fédérer des gateways on-prem avec Azure à l’aide de conteneurs.

De plus, les discussions avec les équipes des différentes produits sont très intéressantes pour obtenir des réponses détaillées sur une foule de sujets.

Encore une autre belle journée en perspective demain. Au menu, Web Assembly et plus!


Build 2019 – Jour 1


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


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.


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.


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.


.NET Platform Roadmap


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.


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 :


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.


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!

Azure DevOps Wiki + VS Code : Super!

Depuis quelques semaines, je rédige de la documentation pour mon travail autour du DevOps. Nous avons cru bon en équipe d’appliquer ce que l’on prône comme pratique : « Everything as Code ». C’est pourquoi nous avons choisi une approche qui vise à considérer la documentation comme du code. Pour ce faire, nous avons bien entendu opté pour la syntaxe Markdown. Ce « langage » est relativement simple et portable si on utilise les fonctionnalités de base. Pas que je n’ai pas envie de parler de la documentation en tant que code, mais je trouvais intéressant de plutôt partager la démarche qui m’a amené à choisir un ensemble d’outils comme Azure DevOps Wiki et VS Code pour accélérer la mise en place de notre documentation.

Comparaison des plateformes évaluées

L’idée n’est pas d’écrire le résultat complet de l’analyse par laquelle je suis passé, mais je pense que les faits saillants de la comparaison sont intéressants. En effet, différents outils sont disponibles pour rédiger, héberger et publier votre documentation. Certaines plateformes sont Open Source et d’autres sont payantes.


On m’avait déjà parlé de cette plateforme dans le passé. Il s’agit d’une boîte à outils qui permet de générer un site de documentation à partir de fichiers Markdown. Le HTML ainsi obtenu doit alors être publié à l’aide d’un hébergeur ou d’un serveur web quelconque. L’idée n’est pas mauvaise et offre la possibilité de personnaliser l’aspect final et général du site de documentation. Toutefois, il faut être un peu à l’aise en Python ou être prêt à l’apprendre. Comme c’est un des langages les plus populaires dans le monde, ce n’est pas une mauvaise chose! Étant toutefois néophytes dans ce domaine, je n’aimais pas la barrière à l’entrée. Par ailleurs, certaines des équipes avec qui je travaille ont eu des petits problèmes de performance au niveau de la recherche qui peut être longue à s’initialiser. Le moteur de recherche est Lunr.js.

Site MkDocs


DocFx est la plateforme de documentation as code de Microsoft. Elle sert à plusieurs de leurs sites de documentation ou est en fait un produit Open Source dérivé de leur vraie plateforme. Son gros avantage est qu’il est plutôt en .NET Core, donc plus facile d’approche que le Python dans mon cas. Cependant, il est aussi basé sur Lunr.js. Comme j’avais peur de vivre les mêmes problèmes de performance que mes collègues, je n’aimais pas l’idée. Le support multilingue prévu pour une nouvelle version prochainement était aussi intéressant.

Pour publier le site en HTML, il faut aussi trouver une manière de l’héberger, ce qui n’est pas intéressant dans l’optique d’un Minimal Valuable Product (MVP). Je voulais valider l’approche « As Code » avant de m’embourber dans les problématiques d’hébergement ou autre.

Site DocFx

Azure DevOps Wiki

C’est alors que j’ai découvert Azure DevOps Wiki. Une plateforme de documentation Wiki fournie avec Azure DevOps. En plus d’être hébergée gratuitement à même notre abonnement Azure DevOps, elle permet de publier les fichiers Markdown directement à partir d’un repo Git.


On peut choisir la branche de laquelle on veut publier et aussi un sous-répertoire au besoin. Tout changement qui sera inclus dans un commit sera automatiquement en ligne sur le Wiki.

Ce qui est également important dans un site de publication de documentation est d’avoir une bonne navigation. Azure DevOps Wiki permet de structurer la documentation de manière hiérarchique en créant des répertoires dans le repo. C’est plutôt minimal, mais ça « fait la job ». Pour plus de détails sur les options disponibles, consultez la page suivante.

Révisions et collaboration

L’avantage d’utiliser les repos Git pour la documentation vient avec l’utilisation des Pull Request (PR). Auparavant, le meilleur moyen était de distribuer un document à travers un courriel ou par Teams/Slack et de recueillir les commentaires. Il fallait aussi intégrer les commentaires de chacun dans un même document et plusieurs personnes ne pouvaient pas collaborer à la révision en prenant connaissance des commentaires des autres. On aurait peut-être pu utiliser un document en édition partagée, mais cela comporte un certain nombre de défis également.

Avec les PR, on obtient une gestion unifiée des commentaires, la possibilité de désigner des réviseurs qui seront informés par courriel que leur contribution est requise et la possibilité de discuter très tôt de son contenu avec le mode brouillon.


Bref, un excellent outil de collaboration pour de la documentation.


Comment gérer le multilingue ?

Un autre critère de sélection pour notre plateforme était d’être en mesure de gérer les différentes langues d’une manière correcte. Je voulais que la documentation des deux langues puisse faire partie de la même PR afin de comparer le contenu traduit avec l’original et surtout de pouvoir valider que le contenu était fourni dans les deux langues.

Pour ce faire, j’ai opté pour une solution simple : un répertoire racine pour chaque langue. Évidemment, la responsabilité nous incombe de s’assurer que la structure est équivalente dans les deux hiérarchies, mais c’est un compromis acceptable.

Azure DevOps ne supporte pas la gestion des langues lors de la publication. Il faut donc publier deux Wikis distincts : un pour chaque langue. C’est là que prends de l’importance la possibilité de publier un sous-répertoire.


VS Code + Extensions

Pour la création du contenu Markdown, VS Code est un éditeur pas mal du tout si on installe certaines extensions :

  • Markdown All in One :
    Permet plusieurs raccourcis dans l’édition du Markdown comme les effets gras et soulignés, la création de tables des matières et la possibilité d’avoir un panneau de prévisualisation intégré à VS Code.
  • Azure Repos :
    Extension fournie par Microsoft pour gérer les éléments relatifs à Azure DevOps comme les PR.
  • Paste Image :
    Permet de coller une image provenant du presse-papier directement dans le Markdown. Le raccourcir Ctrl + Alt + V crée un fichier dans le même répertoire que le fichier en édition et ajoute un lien où se trouve le curseur.


What’s next ?

Ces outils permettent une mise en place rapide d’un site de documentation. Lorsque des besoins plus spécifiques apparaîtront, on pourrait imaginer de finalement publier le même Markdown avec une des plateformes mentionnées précédemment et, pourquoi pas, intégrer la recherche Bing Search ou QnA Maker d’Azure 😊. Bonne documentation!

DevOpsDays Montréal 2018 – Jour 2


Dans mon précédent article, je suis revenu sur les faits saillants de la première journée de la nouvelle conférence DevOpsDays Montréal. C’est maintenant le temps de faire le tour de la deuxième journée. Au menu, nous avions Keynotes, API Gateway, changement de culture et sécurité. Let’s go!

Industry 4.0 – Daniel Koffler

Pour faire suite à la conférence d’hier portant sur les changements menant à la discontinuité, Koffler a présenté les changements que subissaient présentement les secteurs manufacturiers et industriels. La quatrième révolution industrielle est en marche et elle se nomme cyber-physique. Après la vapeur, l’électricité et l’électronique, cette révolution est reliée à l’interconnexion des éléments automatisés.


(image :

Pour Koffler, ces secteurs ont besoins des pratiques DevOps et ils auront besoin des habiletés des gens experts dans le DevOps. Rien pour régler le problème de main-d’œuvre…

Voyage en Tanzanie – Adrian Hooper

En relatant son voyage en Tanzanie, Hooper rappelle les fondements du développement agile et DevOps. Livrez fréquemment, mais pour une bonne raison : parler aux utilisateurs. L’intention est de leur parler afin de comprendre leurs besoins et de pouvoir réagir au feedback obtenu rapidement.

Étouffez-vous ? Un cas d’API Gateway – Alex Gervais

Alex Gervais a été le seul à faire sa présentation en français. Ce n’est pas la seule chose qui m’a plus, au contraire. Il a présenté un retour d’expérience sur l’introduction d’un API Gateway dans leur solution kubernetes. Étape par étape, il a expliqué le chemin qu’ils avaient pris chez AppDirect pour en arriver à utiliser ambassador.

Pour cette entreprise, les principes suivants étaient très importants :

  • Pas de dépendances à un fournisseur cloud
  • Pratiques gitops
  • Architecture cloud-native

C’est pourquoi ils ont utilisé Kubernetes pour gérer leur infrastructure. Toutefois, l’exposition de leurs différents services était faite au départ de manière traditionnelle avec un balanceur de charge. Ils géraient leurs entrées DNS et les ports d’accès des nœuds de manière statique, ce qui est vite devenu compliqué. En plus, ils ont voulu simplifier l’API exposé à leurs clients afin d’abstraire différents détails internes. Ils en sont donc venus à opter pour un API Gateway.


Implementing DevOps in an International multi-cultural and multi-geography environment – Jesse Hurkens

Malgré le titre, cette présentation a davantage parlé de l’importance de la culture DevOps au sein d’une entreprise. M. Hurkens a marqué avec énergie qu’il ne suffit pas d’avoir un beau « pipeline » DevOps pour avoir un vrai succès. C’est d’abord une affaire de culture et il faut que cette culture change, au besoin, pour accueillir les échecs et en apprendre. Mais par où commencer?


Il recommande d’initier ce changement par un petit projet qui, lorsqu’il aura eu son succès, pourra rayonner sur les autres. La pollinisation peut se faire de manière organique et elle créera une fondation solide dans l’organisation. Un truc intéressant qu’il mentionne est de donner des objectifs communs à tous les silos de notre organisation afin de faire travailler les gens dans la même direction.

Voici aussi les principaux challenges qu’il note dans les entreprises qui amorcent le voyage DevOps :

Security Considerations for Containers as a Service (CaaS) and Serverless Architectures – Tsvi Korren

Cette présentation a été selon moi une des mieux structurée. Le présentateur a réussi à bien expliquer les enjeux de sécurité autour du serverless et des conteneurs hébergés et gérés. Si j’essais de résumé, l’enjeu est que l’abstraction de l’infrastructure demande aux spécialistes de sécurité de revoir leurs mécanismes de mitigation des risques. Traditionnellement, on avait l’habitude de mettre en place des antivirus et des contrôles d’accès à l’exécution, mais il n’est pas toujours aussi facile de bien contrôler ces éléments dans un monde où on a aucune visibilité sur ce qui héberge notre code. Comme l’OS et le runtime d’exécution est complètement abstrait, on ne peut pas le sécuriser.

Il propose donc quelques mesures qui peuvent aider comme de baser les images docker sur les versions les plus légères des OS et d’intégrer les validations de sécurité dans le pipeline de livraison. (« Shift-left »).


Comme ce n’est pas suffisant, il recommande de faire en sorte que si un conteneur est compromis, qu’il ne donne pas accès à de multiples ressources. On doit donc pratiquer la micro-segmentation et donner les accès qui sont vraiment requis à chaque ressource. (Shift-up).


Pour finir, voici les différents contrôles de sécurité généraux qu’il recommande :

Le DevSecOps a encore de la maturité à prendre, mais certains outils sont déjà utilisables dans nos pipelines de développement pour détecter les vulnérabilités dans les images Docker que l’on construit et que l’on déploie. En voici quelques exemples :

  1. Microscanner
  2. Kube-Hunter
  3. Kube-bench
  4. Arachni


La conférence s’est achevée avec des Open Spaces qui ont été assez diversifiés. Pour moi, cette conférence a été grandement teintée d’infrastructure et de gestion des opérations. J’avais une conception du DevOps un peu plus équilibrée entre le développement et les opérations. Peut-être que c’est seulement parce que les pratiques en émergences sont surtout du côté de l’infrastructure. Je me demande maintenant s’il faut voir le DevOps comme étant plutôt les pratiques de développement adoptées par les gens des opérations… Mon côté développeur s’est senti un peu délaissé durant ces deux jours… Malgré tout, c’est une conférence que je recommande pour ceux qui veulent apprendre des expériences des autres et aussi à ceux qui veulent partager ou faire des rencontres.