Les points d'arrêt VS2012 ne sont pas touchés
J'ai une classe qui ressemble à ceci:
public class MyService
{
private MyService(){}
public static string GetStuff()
{
var stuffDid = new MyService();
return stuffDid.DoStuff();
}
private string DoStuff()
{
//do stuff
}
//other private helpers
}
Évidemment, j'ai oublié beaucoup de choses, mais c'est le général Shell.
Maintenant, j'ai un test unitaire:
[Test]
public void MyTest()
{
var results = MyService.GetStuff();
}
Je définis des points d'arrêt sur mon test unitaire, et je peux voir que results a des données. Cependant, je mets littéralement des points d'arrêt sur MyService et rien ne se fait toucher à moins que je ne les mette sur une accolade. Ce que je ne peux pas comprendre puisque results a des données, mes déclarations return dans MyService devraient être touchées, n'est-ce pas?
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 ne soit touché? Et si j'interviens manuellement avec F11, il sautille simplement et ne passe même pas par toutes les lignes comme je le pensais. De plus, lorsque je passe manuellement, j'ai tendance à frapper certains codes après que j'aurais dû les frapper à l'origine. Et toutes les instructions switch semblent prendre la valeur par défaut quelle que soit la première option, même si la valeur commutée doit CLAIREMENT entrer une case différente.
J'ai même essayé de créer MyService constructeur public et de supprimer toutes les méthodes static, et cela ne fonctionne toujours pas.
Edit: Mes tests et le code 'Core' sont dans la même solution, mais dans des projets différents (Test et Core, respectivement). Les autres tests n’ont pas de problème pour frapper des points de rupture dans Core, seulement ceci sur un test particulier (le seul test qui teste MyService.
Edit 2:
J'ai supprimé mes fichiers PDB et ma solution nettoyée. Toujours rien.
Il s’avère que cela est lié à la couverture de code.
Le désactiver a corrigé le problème.
Vous pouvez découvrir comment désactiver la couverture de code en suivant le lien ci-dessous
Quelques idées.
- Assurez-vous qu'il s'agit d'une version de débogage et non d'une version
- Désactiver les optimisations dans les propriétés de votre projet si elles sont activées
- Essayez d'insérer
Debugger.Break()dans votre code à la place d'un point d'arrêtin VS - Assurez-vous que les points d'arrêt sont activés (barre d'outils Debug-> Windows-> Points d'arrêt) et que le symbole du point d'arrêt doit être solide.
- Exécutez votre application. Charger la fenêtre Debug-> Window-> Modules. Vérifiez votre Assemblée pour voir si des symboles sont chargés. Sinon, il peut donner un message d'état pertinent.
Avez-vous ajusté la date sur votre ordinateur? Cela peut vraiment bousiller un processus de construction. Si tel est le cas, supprimez tous vos dossiers obj/bin manuellement et recompilez.
Il se peut que vous ne soyez en train de déboguer qu'un seul projet, pas tous les deux Test et Core
Vous pouvez configurer VS pour déboguer plusieurs projets à la fois, vous pouvez le faire par right-click your solution > Properties > Common Properties > StartUp Project
Ici, vous pouvez définir "Plusieurs projets de démarrage" 
Il suffit de définir Core et Test pour commencer. Cela peut résoudre votre problème.
J'ai un scénario très spécifique qui a abouti à la question apparente de "Point d'arrêt non touché".
Puisqu'aucune autre réponse ici ne l'a mentionné, j'ajouterai la mienne au risque d'aider quelqu'un qui a le même problème.
La solution, dans mon cas, était idiote, 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 retourne un IEnumerable, où les instructions de retour contenues sont en réalité des instructions 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 objet IEnumerable, telle que ToList() ou Count(). Seulement puis la méthode sera exécutée et le point d'arrêt atteint.
Assurez-vous simplement que vous avez construit votre assembly avec les symboles du débogueur.
Cette option doit être remplie avec "complet":
Cliquez avec le bouton droit sur votre projet contenant votre fichier de code avec les points d'arrêt non 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 bouton "Avancé ..." situé au bas de la page à onglet. (Au sein du "groupe" de sortie ")
Cliquez sur ce bouton et choisissez "complet" pour la propriété "Informations de débogage". 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 point de 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 nettoyer la structure de votre projet. C’était une situation dans laquelle j’ai reconnu que j’avais besoin de ces fichiers.
J'ai récemment eu le même problème et me fracassais la tête contre le mur.
La réponse s’est avérée assez idiote: mon projet d’essai n’a pas été synchronisé avec le projet de bibliothèque principal. Je construisais les versions de débogage du test et de la bibliothèque, mais le projet de test a copié la bibliothèque à partir du dossier bin/Release. Je viens de recréer la référence du projet et tout a été corrigé.
P.S. C'était même criazier: le débogueur est entré dans une fonction de bibliothèque, mais a en quelque sorte sauté une ligne au milieu.
Cela semble que les 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 point de débogage dans votre projet de test.
- Une fois que vous avez atteint le point de débogage dans votre projet test, vérifiez que les fichiers pdb avec le dernier horodatage sont présents dans le dossier Out de votre sandbox.
3) Si 1 et 2 échouent, j'ai constaté que parfois Visual Studio nécessite un redémarrage :)
Vous devez rendre DoStuff statique.
private static string DoStuff()
{
//do stuff
}
J'ai eu cela dans un projet sur 25 qui étaient tous dans la même solution. Les autres projets respectaient les points d’arrêt mais ce n’était pas le cas. J'ai supprimé le projet de la solution (supprimer, ne pas décharger), ce qui a cassé toutes les références à celui-ci, puis l'a rajouté à la solution et cela a fonctionné!
Si cela ne fonctionne pas, vous voudrez peut-être recréer le projet problématique à partir de zéro et ajouter ce nouveau projet à la solution.
La meilleure explication que j’ai pour expliquer pourquoi cela a fonctionné bien que par pure chance est que nous avons migré des projets d’une version de VS à une autre de nombreuses fois au fil des ans et qu’une de ces migrations a peut-être causé ce problème.
Nettoyez la solution, reconstruisez-la et effectuez également le projet de démarrage.
Pouvez-vous s'il vous plaît jeter un coup d'œil rapide sur BUILD> Configuration Manager, juste pour savoir quelles sont les propriétés de configuration configurées. S'il s'agit d'un développement, vous devrez peut-être ajuster les propriétés du projet -> cliquez sur paramètre avancé -> modifier les informations de débogage sur "complet" dans [onglet de sortie].
vous pouvez également suivre la deuxième étape même si ce n'est pas le mode de développement
Votre code indique un "service", qui pourrait être exécuté en tant que processus séparé. Si c'est le cas, vous pouvez charger votre assembly. Ainsi, les points d'arrêt formeraient des cercles rouges, mais une autre copie de Assembly, exécutée dans un processus distinct, traiterait les demandes.
- vérifiez le Gestionnaire des tâches pour identifier les éventuels contrevenants (processus pouvant héberger votre service). Tuez-les pendant le débogage pour confirmer l'échec des appels.
- Essayez d’utiliser Debugger.Break ();
- Créez un fichier journal de débogage, lors du chargement de la sortie dans le journal, le processus de saisie et les noms d'assembly. Assurez-vous que votre journal est un fichier différent à chaque fois pour éviter les problèmes d'accès async.
Je sais par expérience que Visual Studio ne dispose pas d'une méthode claire pour déboguer des services, en particulier des services Windows. Essayez d’ajouter du code à GetStuff pour l’imprimer dans un fichier texte, pour que vous sachiez au moins que le code est touché. Lors de la création de services, je recourt souvent à cette méthode pour les tests.
Celui-ci est assez obscur:
Assurez-vous de ne pas disposer de deux répertoires virtuels avec des pools d'applications différents pointant vers le même emplacement physique sur votre disque dur. Pendant le développement, c'est quelque chose qui peut parfois arriver pour des tests ou par erreur.
Je ne suis pas parfaitement au point sur les détails 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 a été mappé dans IIS/Visual Studio vers l’autre apppool et non celui qui était réellement. l'exécution.
VS se comporte exactement comme vous l'avez décrit (ne pas toucher les points d'arrêt, mais le code que vous ne vous attendez pas à toucher lors du passage) lorsque vous utilisez un fichier .pdb généré à l'aide du code source, quelque peu différent du code utilisé lors du débogage . Je ne peux pas garantir que ce soit votre cas, mais j'ai souvent observé un tel comportement lorsque je devais entrer dans le code fourni avec une bibliothèque prédéfinie qui avait été générée avec un code plus ancien/différent portant le même nom de fichier/symboles.
Vous pouvez essayer d’ajouter une méthode Thread.Sleep(5000) dans GetStuff et utiliser Attacher au processus.
Visual Studio> Outils> Attacher au processus et voyez si les points d'arrêt sous cette ligne sont atteints.
Peut-être que votre projet Test fait référence à un binaire Core plus ancien, plutôt qu'au projet Core (code source)?
Essayez de ré-ajouter la référence dans votre projet de test:
Accédez à votre projet Test et supprimez la référence au projet Core.
Sélectionnez maintenant le dossier Références, cliquez dessus avec le bouton droit de la souris et sélectionnez l'option de menu pour ajouter une nouvelle référence. Dans la boîte de dialogue Gestionnaire de référence, assurez-vous de sélectionner Solution puis Projects à gauche. Ensuite, au milieu de la boîte de dialogue Gestionnaire de références, sélectionnez (cochez) le projet Core.
Essayez à nouveau de déboguer et voyez si cela vous aide.
J'ai rencontré un problème similaire. Il s'est avéré que la migration de VS2010 vers VS2012 avec le fichier *.testrunconfig était incorrecte. J'ai supprimé l'ancien et mis en place un nouveau pour résoudre le problème.
Commencez par essayer de reconstruire votre projet en faisant un clic droit 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 cela fonctionne pour vous! (l'étape 6 génère les fichiers .pdb, ce sont les symboles de débogage)
Pour déboguer pas à pas, vous devez faire deux choses. Vous devez d'abord définir le point d'arrêt, puis vous devez associer le débogueur au processus exécutant votre code. Si vous exécutez IIS Express et que vous avez une machine 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 d’attachement au processus. Après l'attachement, le point de rupture doit être atteint si le code correspond.
Quelques trucs à essayer:
Vérifiez si les symboles chargés correspondent à l'exécutable débogué:
Ouvrez une invite de commande VS et accédez au répertoire dans lequel se trouve l’exécutable que vous déboguez . Créez ensuite undumpbin /PDBPATH:VERBOSE MyServiceExecutable.exeet analysez le résultat pour rechercher "incompatibilité avec l’âge du PDB" (réf: http://msdn.Microsoft. com/fr-us/library/44wx0fef.aspx )Pas sûr de VS 2012, mais les anciennes versions de VS contenaient un bogue indiquant que le fichier source incorrect serait affiché, à condition que le projet contienne deux fichiers source qui ont le même nomname, même s'ils se trouvent dans des dossiers différents. . Ainsi, si votre projet contient un autre fichier source portant le même nom, vérifiez si le fait de renommer l'un d'entre eux vous aide. (Update: Semble VS 2012 est également affecté .)
Dans les tests unitaires, je n'atteignais pas les points d'arrêt et me suis rendu compte que j'étais en train d'exécuter le test et non de déboguer le test. En haut de l'Explorateur de tests, vous trouverez les options "Tout exécuter", "Exécuter en échec", "Exécuter réussi", etc. Lorsque vous exécutez un test, les points d'arrêt ne sont pas atteints. Pour déboguer un test, dans l'Explorateur de tests, cliquez avec le bouton droit sur le test ou sur le groupe de tests et sélectionnez Déboguer les tests sélectionnés.
S'il est en mode release, passez en mode débogage.
Silly moi, le projet de test n'était pas prévu pour être construit:
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 "Attacher à", sélectionnez la valeur "Avtomatic: Code natif". Meilleures salutations.
