2009-10-02 11 views
1

Un membre de mon équipe de projet doit ajouter des commentaires de code source à plusieurs de ses projets ASP.NET pour fournir une meilleure documentation. Certains membres de l'équipe de projet recommandent que nous effectuions des tests de régression complets si nous ajoutons des commentaires de code source, car il est fort probable qu'une partie du code source puisse être mise en commentaire par inadvertance et provoquer un changement de comportement du programme. Nous serions également obligés de passer l'application via une procédure de gestion des modifications et de la redéployer sur notre serveur de production. Il me semble que nous devrions pouvoir ajouter les commentaires de code source, recompiler le code source, et utiliser quelque chose comme un hachage md5 (ou sha1) (en utilisant quelque chose comme fciv) pour comparer les DLLs avant et après pour confirmer que les commentaires du code source n'ont pas d'impact sur la version compilée. En testant ce concept avec une simple application console, je vois que le problème est que le hachage des binaires va changer si la version de la DLL s'incrémente. Si je pouvais supprimer le manifeste des binaires, peut-être que je pourrais alors effectuer une comparaison pommes-pommes des binaires. Comme un défi supplémentaire, ces applications ASP.NET utilisent le modèle de compilation de site Web ASP.NET où le code est compilé dynamiquement (vraisemblablement dans le dossier% SystemRoot% \ Microsoft.NET \ Framework \ version \ Temporary ASP.NET Files). la première fois que le site est visité plutôt que le modèle d'application Web où tout le code du projet est compilé en un seul assembly dans un dossier bin.Confirmer que les fichiers binaires du site ASP.NET ne sont pas modifiés après l'ajout de commentaires dans la source

Des idées?

+1

Ne pouvez-vous pas simplement le tester? – recursive

+2

Est-il vraiment nécessaire de faire la comparaison sur les binaires, plutôt que de se fier à un diff du code source avant de le placer dans le dépôt? Mon expérience passée me dit que les membres de l'équipe qui insistent sur des choses comme les comparaisons binaires sont motivés par FUD, et croient toujours qu'il existe un «vaudou» inconnaissable/ingérable impliqué dans le développement de logiciels. – JMD

Répondre

1

réponse de Rohan Ouest (merci Rohan!) M'a conduit aux bitdiffer commentaires qui ont fourni la solution suivante:

  • Avant d'ajouter des commentaires de code, recréer les fichiers de code de IL en utilisant Reflector et la Reflector.FileDisassembler add- dans. Cela va générer un répertoire de fichiers de code source qui contient le code source de base uniquement sans commentaires.
  • Ajouter des commentaires de code.
  • Créez un deuxième répertoire de fichiers de code source générés à l'aide de Reflector et du complément Reflector.FileDisassembler.
  • Utilisez un outil de différenciation tel que WinMerge pour comparer les répertoires de code source générés avant et après et vérifiez que les modifications apportées au commentaire de code source n'ont pas modifié le code principal.
3

Le hachage d'assemblages ne fonctionne pas même si la version est rendue constante, après chaque compilation un guid unique incorporé à l'intérieur de l'assemblage change, cela crée un hachage différent à chaque fois. Est-il possible de changer l'application pour qu'elle soit pré-compilée?

Il existe un outil appelé bitdiffer qui compare les assemblages et signale toute différence. Dans le cadre de vos tests d'intégration, vous pouvez exécuter l'outil sur votre nouvelle version et le comparer à la version de production. cela garantirait que seuls les assemblys avec des modifications de code soient libérés.

Il existe également un outil appelé ndepends qui possède une API pour comparer les assemblages. C'est vraiment cool!