Question

Je me demandais s'il y avait un moyen de verrouiller complètement mon code pendant le débogage il dans Visual Studio 2008. Les documents de code se verrouillent automatiquement lors de l'exécution de 64 applications de bits, que je préfère beaucoup; cependant, je fais la plupart de mon codage faire des compléments pour Excel, ce qui est 32 bits. Le résultat est que même si je cible « AnyCPU », l'hôte VS sait qu'il est en cours d'exécution dans un processus 32 bits et, par conséquent, le code source est pas verrouillé alors que le code est en cours d'exécution hébergé dans Visual studio.

Je peux désactiver Modifier et continuer en allant dans Outils> Options> Debugging> Modifier et continuer, puis en décochant la « Activé Modifier et continuer » case à cocher. Cela ne se verrouille pas complètement le code, cependant. Cela n'empêche toutes les modifications dans le code d'être exécuté dans le courant run, mais il ne l'empêche pas de clics de souris ou des frappes de réellement changer le code.

Encore une fois, lorsque vous travaillez avec les applications 64 bits, cela ne se produit pas - le code est complètement verrouillé. Je préfère grandement le code soit complètement verrouillé pour au moins deux raisons:

  1. Je peux frapper accidentellement une clé ou similaire pendant le débogage, que je ne veux certainement pas faire. Il est rare, mais il est un problème.

  2. Un grand nombre de mes tests automatisés conduisent l'interface utilisateur via SendKeys. Lorsque par un renforcement test en utilisant le débogueur, cependant, je peux parfois oublier que certains aspects impliquent SendKeys, ce qui signifie que les frappes du vent jusqu'à obtenir envoyé à Visual Studio IDE au lieu d'Excel.

Dans le numéro 2, ci-dessus, le test unitaire échoue, ce qui est très bien - mon mauvais -. Mais ayant toutes les séquences de touches envoyées au module de code et de détruire mon code est tout à fait inacceptable

Est-ce que quelqu'un a des idées ici? Peut-on verrouiller complètement le code lors de l'exécution hébergé dans Visual Studio en compilé avec un CPU 32 bits?

Certains postes liés à cette question, mais aucun d'entre eux adresser directement ceci:

Merci d'avance pour toute aide ou idées ...

Mike

Était-ce utile?

La solution

Voici le meilleur que je pouvais trouver. Il fonctionne, mais il y a quelques étapes que vous 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 remettre à inscriptible une fois la fin de votre application.

Cependant, VS2k8, par défaut, la mise en un fichier en lecture seule vous permet encore d'éditer le fichier. Vous devez d'abord désactiver le paramètre « Autoriser la modification de fichiers en lecture seule ... » dans Outils> Options> Environnement> Documents.

En second lieu, vous devez ajouter la clé suivante au Registre comme DWORD et définissez sa valeur à 1:

HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed  

toujours ne fonctionne pas complètement. Qu'est-ce que vous avez alors à faire est de définir votre contrôle de code source pour ce projet à Visual Source Safe. (<-. C'est l'étape Je suppose que vous ne voulez)

Ensuite, redémarrez VS2k8.

À ce stade, si vous définissez un de vos fichiers en lecture seule, vous verrez que Visual Studio ne vous laissera pas modifier ce fichier du tout. Lorsque vous essayez, il joue la musique d'exception de votre 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.

Harder, est de les remettre à inscriptible une fois que votre application termine en cours d'exécution. La solution la plus simple est probablement un raccourci fichier batch.

Autres conseils

Voici une astuce que j'utilise sous Visual Studio 2005 (ne pas la chance de tester sous Visual Studio 2008, mais il devrait fonctionner):

  • Ouvrir les propriétés de l'assemblage exécutable
  • Aller à la Debug
  • Vérifiez la Activer le débogage de code non managé case à cocher

Les documents de code doivent rester bloqué, même si un point d'arrêt est frappé, et toute tentative de changement devrait déclencher une fenêtre contextuelle dire « Les changements ne sont pas autorisés lorsque le débogage non géré est activé » .

Hé - désolé, je ne peux pas vous aider à bloquer complètement votre code - je le désir contraire. À DÉVERROUILLER complètement pendant le débogage, mais je peux vous aider avec votre deuxième question

Je suggère que vous considérez comme la vérification de la fenêtre active avant d'envoyer des clés et si la fenêtre active est autre que votre site cible, mettre en pause l'exécution de votre test jusqu'à ce que l'accent est retourné que cette fenêtre.

Je sais que ce n'est pas la solution que vous voulez, mais il serait sans doute pas de mal à empêcher que d'autres problèmes similaires.

Bonne chance!

Adam

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