Développer sous VS Code / Windows en remote sur un Linux WSL / Github Codespaces en quelques minutes

Grand fan de WSL (sous-système Linux) qui apporte à Windows la touche manquante comparé à un environnement de développement Mac : un véritable Shell Linux/Unix. WSL rend accessible bon nombre d’outils de développement uniquement disponible sous Linux (ou s’exécutant mieux et avec moins de configuration et de dépendances).

A cela s’ajoute le fait que vous pouvez avoir plusieurs sous-systèmes Linux et vous en servir comme environnement de développement dédié, et cela sans avoir besoin de lancer une VM Hyper-V coûteuse en ressources et une intégration avec Windows beaucoup moindre (accès aux fichiers directement, intégration Visual Studio, etc). Pas besoin donc de déployer tous les runtimes et langages (Python, Ruby, Go, NodeJS, etc) sur votre machine de production Windows.

Cet article vous présente le développement avec un environnement distant WSL, mais cela s’applique à bon nombre d’autres scénarios dont le service Github Codespaces.

Prérequis

  • Windows Terminal : la fine fleur du terminal sous Windows (même si Commander a encore un peu d’avance mais Terminal suffit largement dans la majorité des scénario)
  • WSL installé (Windows 10/11) : voir la documentation suivante et avec une distribution déployée
  • Extensions Visual Studio Code :
    • Remote – WSL

Installation de VS Code Server sur vos distro WSL

En une ligne : dans votre shell Terminal connecté à votre système WSL, saisissez :

code

Laissez le système installer le serveur (hôte) tout seul :

Puis laissez VS Code s’ouvrir pour vous tout seul :

En prime vous aurez droit d’avoir un walkthroughs « Get started with Remote -WSl » à vous mettre sous la dent pendant quelques minutes pour vous aider dans vos premiers pas à bien comprendre le développement remote sur votre distro Linux.

Vous pourrez aussi ouvrir directement le répertoire courant dans lequel vous avez lancer code grâce à l’explorateur :

Le terminal VS Code est déjà directement branché sur votre shell WSL :

Vous pouvez maintenant installer tous les langages et les extensions nécessaires pour faire de votre WSL votre environnement de développement.

Extensions

Les extensions de votre VS Code ne seront pas activées dans cette configuration de travail à distance sur votre instance WSL. En réalité, ils n’ont pas les droits pour accéder aux fichiers distants ni d’exécuter des scripts à distance. C’est pour cela qu’il existe des extensions de « lieu de travail » – on utilisera workspace pour la suite 🙄 – qui eux s’exécutent dans l’environnement distant et peuvent donc accéder aux fichiers, permettre de débugger, exécuter des scripts, etc. (voir schéma dans la partie suivante pour mieux comprendre l’architecture).

Il faudra les réinstaller dans l’hôte de travail à distance WSL :

Attention : soyez patient il faudra parfois un peu de temps pour que l’extension s’installe et que l’UI de VS Code réagisse pour vous dire que c’est en cours ou installé.

Optionnel : comment ça marche techniquement ?

Je ne ferais pas mieux que la documentation qui vous présente cela très bien : Supporting Remote Development and GitHub Codespaces | Visual Studio Code Extension API

Bonne lecture pour les plus techniques d’entre vous.

Conclusion

Que dire à part : à vous les joies d’un environnement de développement Linux tout en restant sur votre Windows pour utiliser le meilleur de ces deux mondes !

Vous pourrez trouver quelques informations supplémentaires spécifiques à l’utilisation d’un environnement distant WSL dans la documentation Developing in the Windows Subsystem for Linux with Visual Studio Code.

PnPJS 3.2.0 est sortie et liste des projets PnP recommandés

Ce n’est pas tout frais, mais ça valait le coup de s’arrêter quelques minutes dessus. Comme tout développeur SharePoint, la librairie PnPJS est l’une des pierres angiulaires de nos projets => pnp/pnpjs: Fluent JavaScript API for SharePoint and Microsoft Graph REST APIs (github.com)

C’est avec plaisir que la version 3.2.0 est sortie corrigeant quelques petites coquilles que j’avais pu voir lors de mes derniers projets, et apporte aussi quelques nouveautés qui nous faciliteront la vie pour la suite, je vous laisse consulter le CHANGELOG pour voir de quoi il en retourne spécifiquement.

Je vous partage aussi quelques uns des projets de PnP que je suis activement :

Migrer vos applications vers .NET 5 avec l’assistant de migration (partie 1)

Même si toutes ne savent pas comment, les sociétés qui développent des logiciels souhaitent suivre le rythme effréné des montées de version, que ce soit des OS, des frameworks ou des bibliothèques. L’objectif est de ne pas être larguer, de pouvoir parfois gagner en performances, résoudre quelques problèmes de sécurité du framework ou encore permettre d’utiliser des technologies plus modernes (HTTP 2, etc) lors de ces passages.

Pour que les équipes de développement, l’objectif sera surtout de suivre les évolutions, d’identifier les breaking change, de refactoriser le code et également de garder la motivation de maintenir, ce qui deviendra quoiqu’on en veuille : ‘une vieille application à maintenir’.

Pour la société, l’objectif sera surtout de minimiser le coût de cette montée de version, qui si elle n’apporte pas de valeur ajoutée pour les utilisateurs (hormis de meilleurs performances et une sécurité parfois renforcé, concernant le framework en lui-même aka cela n’améliorera pas votre code dans ce domaine par magie) permet d’avoir sur le marché des ressources plus à même d’intervenir sur des technologies récentes qu’anciennes.

MAIS … la stratégie est souvent de faire un POC de mise à niveau d’un projet ‘pas trop gros’, et de se dire ‘voici une application A’, on essaye, et si ça ne coûte pas trop cher on fera l’application B, C, etc. Le biais dans lequel l’entreprise risque de tomber est qu’elle pensera que calculer le temps d’upgrade d’un premier projet, sur lequel l’équipe essuie tous les plâtres de la migration, pourra servir de référence de charges/coûts pour les suivantes. C’est du bon sens … mais c’est ce qui se passe tous les jours, dans d’autres domaines dans les sociétés …

En résumé, la migration d’un projet vers .NET Core 5 prendra beaucoup du temps et la décision sera de ne pas migrer les projets amenant une montagne de ‘vieilles applications à maintenir’ à être maintenu par des personnes dont la motivations égalera celle d’un paresseux au repos. Mais tada … Microsoft à créer l’upgrade assistant pour vous afin de vous aider au maximum à pouvoir évaluer la migration et vous assister dans cette tâche, surtout sur les parties simples et fastidieuses d’une migration de code. Mais attention, cet outil est votre assistant et le magicien c’est vous, pas lui !

Installation

L’assistant de migration est un outil dotnet (dotnet tool) qu’il suffit d’installer de cette manière :

image

Troubleshooting

Erreur “Impossible de charger l’index de service pour la source “/ “Unable to load the service index for source”

Cette erreur arrive lorsque vous avez déclaré un source Nuget dans votre configuration Nuget dont l’outil n’arrive pas à accéder (mauvaise URL, credentials outdated, etc).

image

Dans ce cas, rien de plus simple vous avez deux options :

1. Utilisez l’argument --ignore-failed-sources dans la ligne de commande

2. Supprimer la source dans votre fichier de configuration Nuget qui se trouve dans :

image

Windows Terminal : modifier le shell par défaut

A chaque fois que j’ouvre Windows Terminal, cela ouvre PowerShell pour Windows, ce qui ne correspond pas à mes habitudes d’utilisation (PowerShell Core ou Bash Linux/WSL Linux).

POur se faire, allez dans Paramètres :

image

Cela ouvre le fichier de configuration de Windows Terminal dans Code (ou Blocnote en fonction de votre configuration d’ouverture par défaut des fichiers) :

image

La ligne importante est le defaultProfile qui détermine le profile par défaut qui s’ouvre lorsque vous lancez Windows Terminal.

Si vous regardez un peu plus bas, vous trouverez la liste des profils dans la sections profiles/list.

image

Copiez le GUID du profile qui vous intéresse par défaut et copier le dans la valeur de defaultProfile.

Et tada, la fois d’après vous ouvrirez votre shell préféré au lancement de Windows Terminal.

image