web-dev-qa-db-fra.com

Point d'arrêt non vérifié dans le code Visual Studio

J'essaie de déboguer le projet VS Code lorsque tout à coup (car il fonctionnait parfaitement il y a quelques jours) certains de mes points d'arrêt deviennent inaccessibles:

 enter image description here

Et la liste des points d'arrêt est grisée avec les informations que Breakpoint set but not yet bound.

Mon package.json et .vscode/launch.json sont au même niveau, mes informations de version du code VS:

 enter image description here

Il existe toutefois des anecdotes supplémentaires à ce problème: La définition de points d'arrêt sur certains fichiers fonctionne réellement. et ils sont frappés correctement. Donc, pour moi, il n'y a pas de corrélation entre le type de fichier, son emplacement, sa fonction ou son temps de chargement, certains fichiers ne peuvent pas être gérés pour Chrome Debugger ... 

Mon code VS exécute les configurations ci-dessous:

  "configurations": [

    {
      "name": "Launch Chrome against localhost",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:4210",
      "webRoot": "${workspaceFolder}",
      "sourceMaps": true
    },
    {
      "name": "ng serve",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:4210/#",
      "webRoot": "${workspaceRoot}"
    },
  ]

J'ai aussi essayé de désinstaller/désactiver/activer le débogueur Chrome, de l'exécuter avec tous les autres addons désactivés. La définition des points d'arrêt et la réexécution du débogueur ne prend pas effet, de même que la désactivation/réactivation de tous les points d'arrêt.

visual-studio-codebreakpoints
2
Tomas

Ok, après un certain temps, la résolution vient. Tout cela était dû au mécanisme de routage Angular. Si les composants dont le point d'arrêt est localisé ont été parcourus par component, les points d'arrêt sont définis immédiatement et peuvent être atteints. Pour les composants parcourus par loadChildren, le point d'arrêt n'est pas vérifié jusqu'à ce que la page réelle soit chargée. Ensuite, le point d'arrêt devient "accessible".

MODIFIER

Pour rendre la réponse moins anguleuse, la cause finale était que des points d'arrêt non vérifiés étaient définis sur des parties de code JavaScript qui n'étaient pas encore envoyées au navigateur (c'est-à-dire que la sous-page n'était pas visitée, la partition du script n'était pas oui demandée par AJAX)

0
Tomas