Dans un environnement WSL2, le débogage d'une application .NET publiée au format ELF natif nécessite quelques ajustements. Voici une synthèse pratique, assortie d'une mise en garde importante concernant les projets embarquant CEF.

Limites liées à CEF

Lorsqu'une application .NET référence CEF, elle déclenche plusieurs processus fils : le processus navigateur, les processus de rendu, les processus GPU, etc. Sous Windows, Visual Studio 2022 est capable d'attacher automatiquement son débogueur à ces processsus fils grâce à l'API de débogage Windows et aux options DEBUG_PROCESS. Cette capacité n'existe pas dans la chaîne d'outils Linux. Par conséquent, lancer une commande telle que ./MonApp --type=renderer sous WSL2 provoque un échec, même avec l'option --single-process.

Pour ces projets CEF, il est préférable de rester sous Windows pour le débogage. Sous Linux ou WSL2, le débogage attaché provoque généralement une erreur Trace/breakpoint trap au moment où le débogueur intervient.

Configuration de VS Code sous WSL2

Pour les applications .NET natives qui ne dépendent pas de CEF, VS Code dans WSL2 offre une solution confortable.

Depuis le répertoire de la solution ou du projet, ouvrir VS Code :

code .

Lors du premier lancement, le serveur VS Code s'installe automatiquement. Les extensions C# Dev Kit et Solution Explorer sont recommandées. Le SDK .NET doit bien entendu être installé dans la distribution WSL2.

Fichier launch.json

Créer ou modifier le fichier .vscode/launch.json à la racine de l'espace de travail. L'exemple ci-dessous utilise un exécutable natif ELF généré par le build, plutôt que le lancement classique dotnet MonApp.dll.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Débogage ELF natif",
      "type": "coreclr",
      "request": "launch",
      "program": "${workspaceFolder}/${input:nomProjet}/bin/Debug/net8.0/${input:nomProjet}",
      "cwd": "${workspaceFolder}/${input:nomProjet}",
      "console": "integratedTerminal"
    }
  ],
  "inputs": [
    {
      "id": "nomProjet",
      "type": "pickString",
      "description": "Sélectionner le projet à déboguer en mode natif",
      "options": ["MonApp"],
      "default": "MonApp"
    }
  ]
}

Si le fichier launch.json est placé directement dans le répertoire du projet, simplifier le chemin program en supprimant les segmnets /${input:nomProjet}.

Compilation ciblant Linux

Pour que le build produise directement un exécutable ELF sous WSL2 sans passer par une publication explicite, ajouter dans le fichier .csproj :

<PropertyGroup>
  <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
  <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
</PropertyGroup>

Ainsi, dotnet build génère à la fois l'assembly MonApp.dll et l'exécutable MonApp, directement exploitable dans un terminal WSL2.

Lancement du débogage

Après sauvegarde du fichier de configuration, appuyer sur F5 ou utiliser le menu Run > Start Debugging. Le point d'arrêt défini dans le code source est alors atteint.

Cette approche reste efficace pour les applications .NET autonomes ou associées à des bibliothèques natives simples. Dès que CEF ou une architecture multi-processus complexe entre en jeu, la solution la plus fiable reste de déboguer directement sous Windows.