J'ai écrit une classe de base abstraite pour des tests d'unités qui constituent un environnement suffisant pour que nos tests soient exécutés. La classe expose certains des bits d'environnement d'exécution en tant que propriétés dont les types varient d'essai par test (les types de propriétés sont des arguments de type spécifiés dans la classe d'essais en béton héritante).
C'est tout bien et bien, sauf un collègue de collègue qu'il ne peut voir aucune des propriétés de classe dans le débogueur. Il s'agit de la raison en témoigne qu'il n'avait pas de champs défini dans sa classe héritante et le CLR a optimisé quelque chose ou d'autre part. Le débogueur ne pouvait donc pas afficher les propriétés. Est-il possible d'empêcher cela dans la classe de base en quelque sorte ou dois-je avoir recours à tout le monde dont ils ont besoin pour définir au moins un champ utilisé quelque part pendant les tests? P>
EDIT: P>
sonne comme un coupable probable devrait être les paramètres d'optimisation / de débogage. Cela dit, je construis une application de Visual Studio en mode de débogage, j'ai vérifié que tous les projets sont définis pour une version de débogage et aucun des projets de cette solution n'a l'optimisation de l'indicateur d'optimisation. P>
Peut-être qu'il serait également pertinent de noter que j'utilise Mstest et le coureur de test Visual Studio. P>
EDIT 2: P>
par "Impossible d'afficher les propriétés" I «M faisant référence à l'évaluation de la propriété à Quickwatch et obtenez une marque d'exclamation rouge et un texte" Impossible d'évaluer l'expression "Texte d'erreur. Et de peur que vous ne pensez que je suis entièrement basé avec mes soupçons, l'ajout d'un champ d'instance qui est initialisé dans la méthode d'initialisation des tests rend le problème disparaître ... p>
EDIT 3: P>
Vérifié la sortie de construction. Je remarque que le compilateur est invoqué avec ces options: p>
/debug+ /debug:full /optimize- /define:DEBUG,TRACE
3 Réponses :
J'ai déjà rencontré ce même problème, et cela est invariablement dû au fait que le mode de débogage a été désactivé d'une manière ou d'une autre. Essayez de vérifier chacun des éléments suivants:
Si tout est correct, alors je vous recommande de coller le texte écrit à la fenêtre sortie ici afin que nous puissions poser potentiellement une cause plus inhabituelle du problème.
Cela semble probable, mais la configuration active est déboguée, la configuration dit "DEBUG" pour tous les projets et le drapeau "Optimiser" pour l'assemblage où les classes sont situées n'est pas définie. Je suis physiquement incapable de coller quoi que ce soit ici (machine différente) et non autorisé à le faire, malheureusement. Quelque chose de spécifique que je devrais rechercher?
@RYTMIS: Pourriez-vous s'il vous plaît clarifier ce que vous entendez par «il ne peut afficher aucune des« propriétés »de la classe. Utilisez-vous des montres / survolez simplement les noms de variables avec la souris? N'importe quel message? En ce qui concerne la production de construction, je chercherais simplement des anomolies. Maintenant que vous avez mentionné, c'est Mstest cependant, je commence à penser que le problème est quelque chose de spécifique à cela.
Ajout de clarification au problème Description: Lorsque j'ouvre Quickwatch et tapez le nom de la propriété, je reçois "Impossible d'évaluer l'expression". Au moment où j'ajoute un champ d'instance à la classe héritante (celle en cours de débogage), ce problème disparaît.
@RYTMIS: Pouvez-vous confirmer si vous obtenez le même problème de débogage normalement (par opposition à l'utilisation de MSSTest)?
Je ne suis plus dirigé dans cela, alors je suppose que j'ai bâclé quelque chose dans la reconstruction après avoir changé ces paramètres. :)
J'écroché ce problème aussi, mais tout était prêt à déboguer. Même a fait un nettoyé / reconstruisant en vain. J'ai complètement fermé la solution, rouvert, et tout allait bien.
# 2 était le problème pour moi. Le profil de débogage avait optimisé vérifié pour une raison quelconque.
Assurez-vous que votre ne pas essayer de déboguer votre version de sortie. Tous ces paramètres de compilation définis derrière ces configurations. La version de débogage est une pour débogage; -)
Dans mon cas, la configuration du projet était correcte, mais mon code résultait d'une décompilation d'ILSPY, et il avait des attributs d'assemblage comme suit: supprimer ces attributs corrigé débogueur ...
Que se passe-t-il si vous faites une construction de débogage?
Hmm ... cela semble très étrange. Pourriez-vous fournir un programme de test court mais complet la démontrant?
@John Saunders: exactement ce que j'ai décrit.
@RyTmis: C'est pourquoi je pense que vous envisagez une version de sortie. Ou bien, quelqu'un l'a mis pour optimiser lors d'une construction de débogage. C # ne fait pas beaucoup d'optimisation en aucun cas. Optimiser quelque chose semble très improbable dans une construction de débogage - d'où ma suspicion que vous ne regardez pas une construction de débogage.
Eh bien, je serai damné. Le cas de test le plus simple que je puisse penser ne présente pas ce comportement. :(
@John Saunders: Nope, double-vérifié. Tous les projets définis sur la construction de débogage. : /
@RYTMIS: Build de débogage et quel est le drapeau d'optimisation réglé pour, et faire une reconstruction.
@John Saunders: Mise à jour de la description. Drapeau d'optimisation non défini pour aucun des projets non plus. Reconstruire fait aussi.
HMM, les options du compilateur ont l'air me corrigée.
@RYTMIS: Ma prochaine étape serait de "titrer" entre le test le plus simple que vous avez essayé (qui n'a pas affiché le problème) et le code réel (qui affiche le problème). Je m'interrogerais aussi à propos de Mstest. En particulier, je me demande de la manipulation post-compilée de l'IL. Aussi, utilisez-vous POSTSHARP?
Pas de post-postparp. Mstest fait cependant certaines instrumentation pour la couverture de code. Je vais voir ce que je peux creuser demain ...