Déboguer le logiciel source indexé avec Visual Studio est une douleur

Question

Je suis responsable de certains outils internes et je veux les déboguer aussi facilement que possible sur les machines clientes. Nous les envoyions avec du code source complet et des informations de débogage et les construisions exactement au même endroit que le chemin d'installation typique du client. Cela a rendu le débogage extrêmement facile.

Nous avons maintenant déplacé à l'aide de Windows Installer pour déployer notre logiciel, et nous symbolisons servir les informations de débogage et l'index source les pdbs. Cela rend maintenant le débogage un vrai problème, car pour chaque client que je veux déboguer, je dois modifier plusieurs options dans Visual Studio pour activer l'indexation source et ajouter un fichier dans un répertoire Visual Studio pour l'empêcher de se plaindre de l'exécution du commandes de contrôle de source. Je ne peux pas non plus chercher le code source facilement car les fichiers ne sont extraits qu'à la demande.

Y a-t-il un meilleur moyen de le faire? J'ai essayé d'héberger des archives du code source sur un partage réseau et d'utiliser des liens symboliques pour alias le partage réseau avec le disque dur local lors de la construction, mais cela nécessite des chemins UNC, que l'outil manifeste VS2008 ne peut pas gérer.

Nous avons également utilisé une option de lieur non documentée (/ sourcemap) qui vous permet de rediriger tous les chemins source vers un emplacement arbitraire, mais cela ne fonctionne pas pour les applications .Net (cette option est disponible pour link.exe)

Même si nous fournissions le code source avec l'installation, les chemins dans la PDB seraient toujours incorrects.

Est-il possible de patcher une PDB (prise en charge ou non par Microsoft) pour rediriger les chemins ailleurs?

Answer 1

Je ne peux pas vous aider avec une réponse directe, mais je peux peut-être vous inspirer avec une méta-réponse.

Le débogage dans un environnement de production est fondamentalement erroné. D'autres l'ont essayé (Netscape me vient à l'esprit) et ont lamentablement échoué. Pour quelque chose comme des outils, il est encore plus pertinent d'assurer le bon fonctionnement grâce à des tests unitaires solides et des tests automatisés pour votre version. Vous pouvez configurer vos tests pour qu'ils fonctionnent avec différentes qualités d'entrée (de parfait-manuel à moyen à médiocre à médiocre) et de quantités (c'est-à-dire de limites de test). Il y a beaucoup de books disponibles sur les tests et en particulier les tests unitaires.

Je comprends qu'il est difficile de sortir du quotidien pour faire quelque chose comme ça (je suis au fond de moi-même), mais c'est l'un des plus sains, sinon le .