Question

Je travaille sur un projet de bibliothèque de classes C # .NET dans VS2010. Dans mes paramètres du projet -> Paramètres de débogage, j'ai l'ensemble du projet pour lancer un programme externe (C: \ Windows \ SysWOW64 \ wscript.exe) qui exécute un fichier JScript très simple (de test.js). Le script crée simplement une instance de la classe et appelle une des méthodes est tout.

Le problème est quand je commence le débogage, VS2010 ne se limite pas à l'un de mes points d'arrêt. Si j'ouvre exactement le même projet en VS2008 il fait escale aux points de rupture. Y at-il un nouveau quelque part de réglage qui empêche les points d'arrêt d'être frappé? Quelqu'un at-il rencontré ce problème?

Était-ce utile?

La solution

Pour résoudre ce problème en créant un fichier de configuration pour l'application qui utilise le composant débogage avec les données suivantes:

<?xml version="1.0"?>
<configuration>
  <startup>
     <supportedRuntime version="v2.0.50727"/>
  </startup>
</configuration>

Avec ce fichier, vous dire le débogueur d'utiliser la version d'exécution droite pour le débogage (il semble que le débogueur utilise la version 4.0 par défaut).

Autres conseils

Mon premier chèque serait de désactiver "Just My Code"

  • Outils -> Options
  • Debugger
  • Décochez la case "Activer juste mon code"

Essayez à nouveau le scénario.

Je l'ai essayé une toute une journée pour savoir pourquoi je ne pouvais pas déboguer mon studio visuel 2012 l'application de la console, et la réponse était embarrassant.

Je courais en mode "RELEASE".

Parfois, l'évidence est le difficile à trouver.

Fermer l'IDE Visual Studio et ouvrez-le. Maintenant, il va fonctionner. Pour moi, ce sont également confrontés à la même question. J'ai utilisé cette façon de surmonter

J'ai eu un « Reconstruit » VS2013 projet que je ne pouvais pas debug (pas de symboles). Enfin, j'ai vu l'optimisation a été vérifiée (Projet-> Propriétés-> Construire). Je décoché et Reconstruit. Symboles chargés finalement. Mes deux cents, utilisez uniquement (compilation) Optimisation lorsqu'il est absolument nécessaire.

Alors que je ne peux pas répondre pourquoi cela arrive, je peux vous fournir solution de contournement.

  1. Inclure

    using System.Diagnostics;
    
  2. Au début de votre code (par exemple constructeur de classe) placer les lignes suivantes:

    #if (DEBUG)
                    while(!Debugger.IsAttached);
                    Debugger.Break();
    #endif
    
  3. Démarrer le débogage.

  4. Menu Outils → Attacher au processus
  5. Joindre à votre processus.

devrait déclencher dans breakpoint votre code. D'autres points d'arrêt devraient déclencher aussi bien.

Peut-être un certain nombre de raisons. Habituellement, c'est parce que vous essayez de débogage contre la mauvaise version.

Ces actions travaillent environ 80% du temps.

  • Obtenez le dernier code
  • Clean
  • Reconstruire
  • Redémarrer les services Internet
  • Réessayez

Si aucun bon, allez à Debug> de Windows> Modules et si le dll concerné est là, faites un clic droit et symboles de charge.

Si ce n'est pas dans la liste, essayez d'exécuter le code de toute façon. Parfois, même si elle dit le point d'arrêt ne sera pas touché, il est seulement parce que le dll n'est pas chargé jusqu'à ce que vous entrez dans un scénario qui en a besoin. Essayez le scénario qui dépend de la dll, et il peut frapper juste le point d'arrêt de toute façon.

Oh une autre idée, redémarrez votre navigateur. Vous pourriez avoir quelque chose en cache d'un dll plus.

Si la raison est incorrecte .NET version d'exécution (ce qui était mon problème), au lieu de créer le fichier de configuration, vous pouvez simplement choisir la bonne version dans le Attacher au processus dialogue.

Dans la boîte de dialogue, à côté de attach à cliquez sur Sélectionnez et passer de automatiquement ... Debug ces types de code où vous devriez vérifier la bonne version.

Si ce problème était-il aussi, alors vous avez probablement eu « Les symboles non chargés » message sur votre points d'arrêt. Immédiatement après avoir sélectionné la bonne version, vous devriez voir que cette erreur ne soit signalée plus.

Pour moi, il a été fixé par:

  1. Ouvrez les propriétés du projet est VS2010

  2. Aller à Compile -> Options avancées de compilation

  3. Modifier 'Générer les informations de débogage' de 'None' à 'Full'

Le problème pourrait être votre navigateur utilise une version en cache de la page, vous travaillez avec. Essayez d'ajouter un non-sens som querystring supplémentaire dans votre ligne de l'adresse du navigateur f.x. ajouter? NONSENSE = 1234 Cela oblige le navigateur à utiliser une nouvelle version de la page Web, car il ne sait pas si la page doit être différente à la fin de cette requête. la prochaine utilisation? Nonsens = 1235.

J'ai eu un problème avec des points d'arrêt égaré dans mon code c ++ natif. La raison était que j'avais modifier le code de sorte que certaines extrémités de ligne dans le code n'a pas été \ r \ n. Il n'a pas été possible de voir dans le code, à moins que vous avez recherché \ r \ n. Après l'insertion des extrémités de la ligne appropriée de r \ n le débogueur travaillé.

Je rencontrais la question similaire, mais son dans un projet CLR. J'ai eu un vieux c ++ syntaxe dans le projet CLR. Pour moi, après avoir activé la fonction "mode de compatibilité géré utilisation dans Outils> Options> Debugging> Général il a commencé à frapper les points de rupture.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top