Je me demandais s'il y avait un moyen de verrouiller mon code tout en le débogage dans Visual Studio 2008. Les documents de code sont automatiquement verrouillés lors de l'exécution d'applications 64 bits, que je préfère grandement; Cependant, je fais la majeure partie de mon codage en train de faire des compléments pour Excel, qui est 32 bit. Le résultat est que, même si je ciblais "AnyCPU", l'hôte VS sait qu'il fonctionne dans un processus de 32 bits et, par conséquent, le code source est pas verrouillé pendant que le code est hébergé dans Visual Studio.
Je peux éteindre l'édition et continuer en allant à Outils> Options> Débogage> Édition et Continuer, puis décochez la case "Activé Edition et Continuer". Cela ne verrouille pas complètement le code, cependant. Cela empêche toute modification du code d'être exécutée dans l'exécution actuelle , mais elle n'empêche pas les clics de souris ou les touches de la souris de modifier réellement le code.
Encore une fois, lorsque vous travaillez avec des applications 64 bits, cela ne se produit pas - le code est complètement verrouillé. Je préfère grandement que le code soit complètement verrouillé pendant au moins deux raisons:
Je peux frapper accidentellement une clé ou similaire pendant le débogage, que je ne veux certainement pas faire. C'est rare, mais c'est un problème.
Beaucoup de mes tests automatisés conduisent l'interface utilisateur via SendKeys. Cependant, lorsque vous passez un tel test à l'aide du débogueur, je peux parfois oublier que certains des aspects impliquent des envois, ce qui signifie que les frappes de frappe se remettent à l'IDE Visual Studio au lieu d'Excel.
Dans le numéro n ° 2 ci-dessus, le test de l'unité échoue, ce qui convient, c'est bon - mon mauvais - mais avoir toutes les frappes de frappe envoyées au module de code et détruire mon code est totalement inacceptable.
Quelqu'un a-t-il des idées ici? Peut-on verser complètement le code lorsqu'il est hébergé dans Visual Studio tout en étant compilé contre un processeur 32 bits?
Certains postes liés sur cette question, mais dont aucun ne traite directement ceci:
Merci d'avance pour toute aide ou idées ...
Mike
3 Réponses :
Hey là-là - Désolé, je ne peux pas vous aider à verrouiller complètement votre code - j'ai le désir opposé: Pour le déverrouiller complètement pendant le débogage, mais je peux vous aider avec votre deuxième problème.
Je suggère que vous envisagez de vérifier la fenêtre active avant d'envoyer des clés et si la fenêtre active est autre que votre site cible, mettez en pause l'exécution de votre test jusqu'à ce que la fenêtre soit renvoyée sur cette fenêtre.
Je sais que ce n'est pas la solution que vous voulez, mais cela ne ferait probablement pas de mal d'empêcher d'autres problèmes similaires.
Bonne chance!
Adam
+1 très belle idée adam. Je vais certainement utiliser une version de ceci. Je ne peux pas vous donner la coche pour cela - comme vous le savez - mais c'est une bonne aide. Merci! (On dirait que je devrai commencer une prime dans l'espoir d'obtenir les principaux problèmes résolus ... Je commence à penser que cela ne peut pas l'être.)
J'aimerais savoir si vous avez réussi à rendre le code complètement modifiable et comment.
Voici le meilleur que je puisse trouver. Cela fonctionne, mais il y a quelques étapes que vous ne voudrez peut-être pas prendre.
Pour l'essentiel, la technique consiste à définir les fichiers de votre projet en lecture seule lorsque vous exécutez l'application, puis les remises à inscriptible une fois la fin de votre application.
Toutefois, dans VS2K8, par défaut, définissez un fichier à lecture seule vous permet toujours de modifier le fichier. Vous devez d'abord éteindre le réglage "Autoriser l'édition de fichiers en lecture seule ..." Dans Outils> Options> Environnement> Documents.
Deuxièmement, vous devez ajouter la clé suivante au registre sous forme de DWORD et définir sa valeur sur 1: ceci toujours < / em> ne fonctionnera pas complètement. Ce que vous avez ensuite à faire est de définir votre contrôle source pour ce projet à la source visuelle Safe. (<- C'est l'étape que je suppose que vous ne voudrez pas aimer.) puis redémarrez vs2k8. à ce stade si vous définissez un de vos fichiers à lire Seulement, vous verrez que Visual Studio ne vous permettra pas de modifier ce fichier. Lorsque vous essayez, il joue votre musique d'exception de l'ordinateur. Maintenant, pour que vos fichiers en lecture seule lorsque vous exécutez l'application, définir un processus de post-construction pour le faire. C'est facile. plus difficile, c'est de les remettre en écriture une fois que votre application se termine en cours d'exécution. La solution la plus simple est probablement un raccourci de fichier de lots.
+1 wow, très impressionnant. Je cherche quelque chose de nettoyant et plus facile, mais il semble que une sorte de hack ou de macro sera nécessaire. Si personne ne vient de plus en plus facile, je vous donnerai la coche, mais je vais laisser cela continuer pendant quelques jours de plus pour voir si quelqu'un peut faire mieux. (BTW, serait-ce plus propre ou plus facile à faire dans VS 2010? Ne faites pas de travail pour rechercher cela, mais si vous savez au sommet de votre tête.)
Semble comme une mauvaise idée de jouer avec les bits en lecture seule derrière le dos du fournisseur de contrôle source.
"On dirait qu'une mauvaise idée d'aller jouer avec les bits en lecture seule derrière le dos du fournisseur de contrôle source". C'est un bon point josh. Et l'obligation d'utiliser Visual Source Safe est définitivement un problème. Je pense que je vais devoir renaître sur ma promesse à «Humain intelligent» de donner la coche ici ... Je pense que celui-ci reste vraiment non résolu. :-( :-(
Human intelligent: Y a-t-il un moyen facile de désactiver temporairement l'édition de code pour certains documents et / ou tous les documents de VS2005 ou d'autres versions? Parfois, je finis par taper accidentellement des choses dans mon code lorsque je veux avoir une autre fenêtre ouverte. (Penser) mieux encore: il y aurait un moyen de prévenir les documents de recevoir la mise au point "par défaut" ou via un point d'arrêt, par opposition à une action délibérée?
Voici une astuce que j'utilise sous Visual Studio 2005 (n'ont pas la possibilité de tester sous Visual Studio 2008, mais cela devrait fonctionner):
Les documents de code doivent rester verrouillés, même lorsqu'un point d'arrêt est touché et que toute tentative de modification doit déclencher une pop up affiche que les modifications
Laurent, ça sonne très prometteuse ... mais cela ne fonctionne pas pour moi lors de la compilation contre "x86". Le comportement ne change pas du tout, malheureusement. Dois-je ajouter des opérations «dangereuses» quelque part pour forcer cet effet de verrouillage à se produire?
Dans "Outils> Options> Débogage> Général", avez-vous "enfreindre tous les processus lorsqu'un processus se casse." vérifié ? Je vais essayer de faire un test avec Visual Studio 2008 et de vous tenir au courant.
Bonjour Laurent, oui, "briser tous les processus quand un processus se casse" est coché. Merci d'avoir mis l'effort dedans. (En fait, +1 pour les efforts jusqu'à présent, je l'apprécie vraiment.)
Voici un autre avantage: vous pouvez activer / désactiver le comportement "Modifier et continuer" pour un assemblage, en utilisant le debommableauTribute au niveau du module. Ses propriétés de débogageFlags permettent de spécifier si "éditer et continuer" peut être utilisé. Ce drapeau est automatiquement ajouté par le compilateur en mode "Débogage". Je ne sais pas si cela peut fonctionner pour vous ...
Bonjour Laurent, j'apprécie les efforts, mais je peux déjà activer ou désactiver l'édition et continuer sur le plan global, et cela ne verrouille pas le code lorsqu'il est compilé contre une CPU x86, donc je ne vois donc pas comment définir cela pour un assemblage donné personne pourrait aider ... :-(
Notez qu'un test d'unité qui parle au logiciel externe est appelé test d'intégration.
@Lasse: OK, assez juste. Je modifierai ce qui précède pour dire "Tests automatisés", car j'exécute une suite de tests variant des tests d'unité isolés aux tests d'intégration. Merci. Cela ne compte pas beaucoup ici, ce sont des envois qui sont le problème, quel que soit le type de test que vous souhaitez considérer.