Les points d’arrêt VS2012 ne sont pas touchés

J’ai un cours qui ressemble à ceci:

public class MyService { private MyService(){} public static ssortingng GetStuff() { var stuffDid = new MyService(); return stuffDid.DoStuff(); } private ssortingng DoStuff() { //do stuff } //other private helpers } 

De toute évidence, j’ai laissé beaucoup de place, mais c’est la coquille générale.

Maintenant, j’ai un test unitaire:

 [Test] public void MyTest() { var results = MyService.GetStuff(); } 

Je fixe des points d’arrêt sur mon test unitaire et je peux voir que les results contiennent des données. Cependant, je place littéralement des points d’arrêt sur tout MyService et rien n’est touché à moins que je ne les mette sur une accolade. Ce que je ne comprends pas puisque les results ont des données, mes déclarations de return dans MyService devraient être touchées, non?

Est-ce que je manque quelque chose? Ai-je complètement oublié les règles les plus élémentaires de quelque chose? Comment se fait-il que rien dans MyService soit touché? Et si j’interviens manuellement avec F11 , ça saute aux yeux et ne traverse même pas chaque ligne comme je le pensais. Aussi, quand je passe à travers manuellement, j’ai tendance à bash un certain code après que j’aurais dû le bash à l’origine. Et toutes les instructions de switch semblent être utilisées par défaut quelle que soit la première option, même si la valeur en cours de commutation devrait entrer CLAIREMENT dans un case différent.

J’ai même essayé de rendre MyService constructeur de MyService et de supprimer toutes static méthodes static , et cela ne fonctionne toujours pas.

Edit: Mes tests et le code ‘Core’ se trouvent dans la même solution, mais avec des projets différents ( Test et Core , respectivement). Les autres tests ne rencontrent pas de problème lorsqu’il s’agit de points de rupture dans Core , mais uniquement sur un test particulier (le seul test qui teste MyService .

Edit 2:

J’ai supprimé mes fichiers PDB et nettoyé la solution. Toujours rien.

Quelques idées.

  1. Assurez-vous qu’il s’agit d’une version de débogage et non pas de la version
  2. Désactivez les optimisations dans les propriétés de votre projet si elles sont activées
  3. Essayez d’insérer Debugger.Break() dans votre code au lieu d’un point d’arrêt dans VS
  4. Assurez-vous que les points d’arrêt sont activés (Debug-> Windows-> Breakpoints toolbar) et que le symbole du point d’arrêt doit être plein
  5. Exécutez votre application. Charger la fenêtre Debug-> Window-> Modules. Vérifiez votre assemblage pour voir si les symboles sont chargés. Il peut donner un message d’état pertinent si ce n’est pas le cas.

Avez-vous ajusté la date sur votre ordinateur du tout? Cela peut vraiment gâcher un processus de construction. Si c’est le cas, supprimez tous vos dossiers obj / bin manuellement et recomstackz.

Cela peut être dû au fait que vous ne faites que déboguer 1 projet, pas à la fois Test et Core

Vous pouvez définir VS pour déboguer plusieurs projets à la fois, vous pouvez le faire en right-click your solution > Properties > Common Properties > StartUp Project

Ici vous pouvez définir “Plusieurs projets de démarrage” entrer la description de l'image ici

Il suffit de définir à la fois Core et Test pour démarrer. Cela peut résoudre votre problème.

Il s’avère que cela était lié à la couverture du code.

La désactivation a résolu le problème.

Vous pouvez découvrir comment désactiver la couverture de code en suivant le lien ci-dessous

Désactiver la couverture de code

J’ai un scénario très spécifique qui a entraîné le problème apparent de “le point d’arrêt n’est pas atteint”.

Étant donné qu’aucune autre réponse ne l’a mentionnée ici, j’appendai la mienne dans la possibilité que cela aide quelqu’un qui a le même problème.

La solution, dans mon cas, était stupide, et avec autant de LINQ que j’utilise, j’aurais dû le comprendre plus tôt. Lors de l’exécution d’une méthode qui renvoie un IEnumerable, où les instructions de retour contenues dans sont en réalité yield return instructions de yield return , cette méthode ne sera pas exécutée lorsque vous l’appelez.

Il sera effectivement exécuté lorsque vous appelez une autre méthode à partir de cet object IEnumerable, tel que ToList() ou Count() . Alors seulement la méthode sera exécutée et le point d’arrêt atteint.

Assurez-vous que vous avez construit votre assembly avec les symboles du débogueur.

Cette option doit être remplie avec “full”:

Cliquez avec le bouton droit de la souris sur votre projet contenant votre fichier de code sans que les points d’arrêt ne soient touchés. Choisissez “Propriétés”.

Une fois les propriétés du projet ouvertes, choisissez l’onglet “Générer”. Méfiez-vous du “Avancé …” – Buttom en bas de la page à onglet. (Dans le “résultat” -Group “)

Cliquez sur ce bouton et choisissez “full” pour la propriété “Debug info”. Cela devrait être une raison pour que les points d’arrêt ne soient pas touchés. Visual Studio utilise les symboles enregistrés dans les fichiers pdb pour trouver la position exacte du sharepoint rupture. Si ces fichiers ne sont pas créés, aucun point d’arrêt n’est atteint. Peut-être avez-vous désactivé la création de ces fichiers afin de mettre de l’ordre dans votre structure de fichiers de projet. C’était une situation que j’ai reconnue que j’ai besoin de ces fichiers.

J’ai récemment eu le même problème et j’ai fracassé la tête contre le mur.

La réponse s’est avérée assez stupide: mon projet de test s’est en quelque sorte désynchronisé du projet de bibliothèque principal. Je construisais les versions de débogage du test et de la bibliothèque, mais le projet de test copiait la bibliothèque à partir du dossier bin/Release . Je viens de recréer la référence du projet et tout a été corrigé.

PS: C’est même plus criant: le débogueur est entré dans une fonction de bibliothèque, mais a sauté d’une ligne à l’autre.

Vous devez rendre DoStuff statique.

 private static ssortingng DoStuff() { //do stuff } 

Votre code indique un “service”, qui peut être exécuté séparément. Si tel est le cas, vous pouvez charger votre assembly, les points d’arrêt étant des cercles rouges pleins, mais une autre copie de l’assembly, exécutée dans un processus distinct, gère en réalité les demandes.

  • vérifiez le Gestionnaire des tâches pour les éventuels délinquants (processus pouvant héberger votre service). Tuez-les lors du débogage pour confirmer que les appels échouent.
  • Essayez d’utiliser Debugger.Break ();
  • Créez un fichier journal de débogage lors du chargement de la sortie dans le journal du processus d’entrée et des noms d’assemblage. Assurez-vous que votre journal est un fichier différent à chaque fois pour éviter les problèmes d’access asynchrone.

Cela ressemble aux fichiers pdb ne sont pas mis à jour dans votre sandbox de test.

1) Assurez-vous que vous êtes en mode débogage.

2) Pouvez-vous essayer d’inclure explicitement un élément de déploiement pour les fichiers pdb?

  • Vous avez dit que vous pouvez attacher un sharepoint débogage dans votre projet de test.
  • Une fois que vous avez atteint le sharepoint débogage dans votre projet de test, vérifiez que les fichiers pdb contenant le dernier horodatage sont présents dans le dossier Out de votre sandbox.

3) Si 1 et 2 échouent, j’ai trouvé que parfois Visual Studio nécessite un redémarrage 🙂

  1. Nettoyez la solution et reconstruisez et faites également le projet de démarrage.

  2. Pouvez-vous s’il vous plaît jeter un coup d’oeil à la BUILD> Configuration Manager, juste pour vous assurer que les propriétés de configuration sont configurées. S’il s’agit d’un développement, vous devrez peut-être ajuster les propriétés du projet -> cliquer sur le paramètre d’avance -> modifier les informations de débogage sur «plein» dans [onglet de sortie].

  3. vous pouvez également suivre l’étape deux même si ce n’est pas le mode de développement

J’ai eu cela dans un projet sur 25 qui étaient tous dans la même solution. Les autres projets ont honoré les points d’arrêt mais ce n’est pas le cas. J’ai retiré le projet de la solution (supprimer, ne pas décharger), ce qui a brisé toutes les références, puis l’a ajouté à la solution et cela a fonctionné!

Si cela ne fonctionne pas, vous souhaiterez peut-être recréer le projet à partir de zéro et append ce nouveau projet à la solution.

La meilleure explication que j’ai de la raison pour laquelle cela a fonctionné indépendamment de la pure chance est que nous avons migré des projets d’une version de VS à une autre, plusieurs fois au cours des années et peut-être une de ces migrations a causé ce problème.

Vous pouvez essayer d’append un Thread.Sleep(5000) dans la méthode GetStuff et utiliser Attach to Process

Visual Studio> Outils> Joindre au processus et voir si les points d’arrêt situés en dessous de cette ligne sont touchés.

S’il est en mode de libération, basculez-le en mode débogage.

Je sais d’expérience que Visual Studio ne dispose pas d’une méthode claire de débogage des services, en particulier des services Windows. Essayez d’append du code à GetStuff pour imprimer dans un fichier texte, de cette façon vous saurez au moins que le code est touché. Lors de la création de services, j’ai souvent recours à cette méthode pour les tests.

J’ai rencontré un problème similaire. Il s’est avéré que pour moi, c’était une mauvaise migration de VS2010 vers VS2012 avec le fichier *.testrunconfig . J’ai supprimé l’ancien et mis en place un nouveau pour résoudre le problème.

VS se comporte exactement comme vous l’avez décrit (ne pas toucher les points d’arrêt, bash le code que vous ne vous attendez pas à atteindre) lorsqu’il utilise le fichier .pdb généré à l’aide du code source différent du code utilisé lors du débogage . Je ne peux pas vous garantir que c’est votre cas, mais j’ai observé de tels comportements plusieurs fois lorsque je devais entrer dans le code fourni en tant que bibliothèque pré-générée et généré avec un code plus ancien / différent avec les mêmes noms de fichiers / symboles.

Peut-être que votre projet de Test fait référence à un ancien binary Core , plutôt qu’au projet Core (code source)?

Essayez de rappend la référence dans votre projet Test:

Accédez à votre projet de Test et supprimez la référence au projet Core .

Maintenant, sélectionnez le dossier Références et faites un clic droit dessus et sélectionnez l’option de menu pour append une nouvelle référence. Lorsque vous êtes dans la boîte de dialog Gestionnaire de références, assurez-vous de sélectionner Solution , puis Projects sur la gauche. Puis, au milieu de la boîte de dialog Gestionnaire de références, sélectionnez (cochez) le projet Core .

Essayez à nouveau de déboguer et voyez si cela vous aide.

Quelques autres choses à essayer:

  • Vérifiez si les symboles chargés correspondent à l’exécutable mis au point:
    Ouvrez une invite de commande VS et accédez au répertoire où réside l’exécutable que vous déboguez. Ensuite, effectuez un dumpbin /PDBPATH:VERBOSE MyServiceExecutable.exe et dumpbin /PDBPATH:VERBOSE MyServiceExecutable.exe la sortie pour rechercher «incompatibilité d’âge PDB» (Réf: http://msdn.microsoft.com/en-us/library/44wx0fef.aspx )

  • Je ne suis pas sûr de VS 2012, mais les anciennes versions de VS avaient un bogue où le mauvais fichier source serait affiché, à condition que votre projet contienne deux fichiers sources portant le même nom, même s’ils se trouvent dans des dossiers différents. Donc, si votre projet contient un autre fichier source portant le même nom, voyez si renommer l’un d’eux vous aide. ( Mise à jour: Semble VS 2012 est également affecté .)

Silly moi, le projet de test ne devait pas être construit:

entrer la description de l'image ici

Celui-ci est assez obscur:

Assurez-vous de ne pas avoir deux répertoires virtuels avec différents pools d’applications pointant vers le même emplacement physique sur votre disque dur. Pendant le développement, cela peut parfois arriver pour des tests ou par erreur.

Je ne suis pas à 100% clair sur les aspects techniques, mais j’avais deux AppPools et deux répertoires virtuels et aucun point d’arrêt n’a été touché car je suppose que le chemin physique était en quelque sorte mappé dans IIS / Visual Studio. en cours d’exécution.

J’ai le même problème. Peut-être que ma solution vous aidera à résoudre votre problème. Juste dans “Attacher au processus” pour l’option “Joindre à” sélectionnez la valeur “Avtomatic: code natif”. Meilleures salutations.

Image

Essayez d’abord de reconstruire votre projet en cliquant avec le bouton droit de la souris sur le projet> Reconstruire. Si cela ne fonctionne pas, essayez de nettoyer le projet (clic droit sur le projet> nettoyer)

Si cela n’a pas fonctionné, vérifiez ceci:

 Right mouse click your project select [Properties] select the [Build] tab make sure [Define DEBUG constant] and [Define TRACE constant] are checked Click the [Advanced] button at the bottom of the Build tabpage Make sure that [Debug Info:] is set to [full] Click [OK] and rebuild the project ;-) 

J’espère que ça marche pour vous! (l’étape 6 génère les fichiers .pdb, ce sont les symboles de débogage)

Pour déboguer étape par étape, vous devez faire deux choses. Vous devez d’abord définir le point d’arrêt, puis vous devez attacher le débogueur au processus exécutant votre code. Si vous exécutez IIS Express et que vous avez un ordinateur 64 bits, vous devez joindre iisexpress.exe qui exécute votre code. Si vous appuyez sur CTRL + ALT + P, vous accédez à la fenêtre Attach to process. Après l’attachement, le point d’arrêt doit être atteint si le code correspond.

Dans les tests unitaires, je n’atteignais pas les points d’arrêt et je réalisais que j’exécutais le test et non le débogage du test. En haut de l’Explorateur de tests, les options “Exécuter tout”, “Exécuter en échec”, “Exécuter en cours”, etc. Pour déboguer un test, dans l’Explorateur de tests, cliquez avec le bouton droit sur le test ou le groupe de tests et sélectionnez Déboguer les tests sélectionnés.