2009-07-23 5 views
5

Je travaille sur un projet multi-développeurs et l'application en cours de développement est lanceur via une application de lancement qui transmet des paramètres tels que l'utilisateur connecté, leur emplacement, etc. l'application que je mis un point d'arrêt sur le code qui analyse les paramètres d'entrée et j'assigner la variable nom d'utilisateur mon nom d'utilisateur, etc.Débogueur Visual Studio - Affectation des variables automatique

je pouvais coder en dur ces valeurs, mais:

  • Je crois que c'est une mauvaise pratique.
  • Je suis inquiet que le fichier soit vérifié dans notre VCS et ait des effets d'entraînement désastreux.
  • Plusieurs développeurs travaillent sur le projet afin de coder en dur mon nom, les affectations de localisation, etc. n'est pas vraiment une option.
  • Je ne peux pas faire le fichier en lecture seule car il est en développement actif et j'ai besoin continuellement d'obtenir la version mise à jour de ce fichier.

Ma question est:

  • est-il un moyen intégré ou une extension pour affecter les variables une valeur AUTOMATIQUEMENT en mode débogage. En ce moment, je souligne la variable et tapez mon texte, cela peut-il être automatisé?

Merci à l'avance

Répondre

1

Quand je frappé des situations comme cela, je généralement une combinaison de compilation conditionnelle et variable d'environnement/clé reg. Vous pouvez utiliser ces mécanismes de stockage pour héberger vos informations sans les coder en dur dans l'application.

#if DEBUG 
if (null != Environment.GetVariable("CUSTOM_INFO")) { 
    userName = Environment.GetVariable("CUSTOM_USERNAME"); 
    ... 
} 
#endif 

De cette façon, cela n'affectera aucun autre développeur. À moins bien sûr, ils veulent accomplir la même chose.

0

Ajout à la réponse de JaredPar, rendre la classe partielle.

Cela vous permettra de garder le fichier principal (celui qui est enregistré) mis à jour. L'autre fichier (celui contenant IF DEBUG) sera local & ne sera pas archivé.

Espérons que ça aide.

0

Question étrange. Il a été publié il ya une vie de chien, mais les concepts de tests unitaires et de développement piloté par les tests étaient déjà bien établis en 2009. Avec un excellent outillage disponible, comme nunit et testdriven.net. Un débogueur n'est pas le bon outil à utiliser, qui produit juste des cheveux gris.

+0

Apparemment, mais pour exécuter le système entier, en insérant des valeurs au fur et à mesure, les frameworks de test ont tendance à ne pas fonctionner aussi bien. Ou du moins j'ai eu l'impression que c'était le cas. Je pense que l'on peut être capable de le faire via des points d'arrêt conditionnels, mais le débogueur de Green Hills a un "point d'arrêt de saut" qui vous permet d'ignorer des parties de code ou de définir des conditions lorsque le point d'arrêt est atteint. –

Questions connexes