J'essaie de déboguer à distance une application hébergée sur Linux
"Debian GNU/Linux 8 (jessie)"
avec
Outils de ligne de commande .NET (2.1.500)
Je me connecte via Visual Studio via SSH
et j'ai essayé les deux modes:
Géré .NET Core pour Unix
Native (GDB)
Le projet a été compilé sous Windows
dotnet publish --configuration Release -r linux-x64
et aussi
dotnet publish --configuration Debug -r linux-x64
et fonctionne parfaitement bien, mais pour une raison quelconque, je reçois:
Managed .NET Core pour Unix:
Echec de l'attachement au processus: impossible d'énumérer les instances en cours d'exécution du CoreCLR dans le processus spécifique
Et si cela est pertinent (probablement pas, car d'autres personnes utilisent Managed .NET Core for Unix pour cela)
Native (GDB): Impossible de démarrer le débogage. Impossible d'établir une connexion à GDB. La sortie de débogage peut contenir plus d'informations
informations de débogage:
Starting unix command: 'gdb --interpreter=mi'
bash: gdb: command not found
gdb --interpreter=mi exited with code 127.
Dans Visual Studio, le processus est répertorié comme suit:
Process: MyProjectName
Title: /home/deploy/app/MyProjectName StartUpArgument
Quelqu'un a une idée de ce qui peut causer ça?
Vous pouvez voir comment les gens font cela avec Raspberry Pi ici:
Apparemment notre stupidité est sans limite
Nous avons exécuté notre application en tant que service, mais FROM OTHER USER ACCOUNT THAN WAS USED IN SSH
La connexion au processus fonctionne correctement, mais pour une raison quelconque
Breakpoint will not currently be hit. No symbols have been loaded for this document
modifier:
Solution:
J'ai aussi vérifié:
Activer le support du lien source
Revenez à l’autorisation du gestionnaire des identifiants git. pour toutes les demandes de lien source
Activer la prise en charge du serveur source Activer uniquement mon code [OFF]