J'essaie de faire fonctionner FxCop de manière à ce qu'il n'analyse que les changements incrémentiels dans l'exe/dll qu'il analyse et non pas le tout car il a déjà analysé cette partie. ... des pensées comment on pourrait y parvenir ?? ... merci d'avance ...Utiliser FxCop pour analyser uniquement les dernières modifications
Cordialement,
... ASV
je pense que ce serait trop compliqué pour que cela se produise. Mon conseil serait de choisir les règles de flx fx avec lesquelles vous pouvez vivre, et d'obtenir toutes les erreurs/avertissements de votre code. De cette façon, si un autre membre de l'équipe change quelque chose, vous le remarquerez, à moins d'écrire du code qui passe. Dans ce cas, il n'y a pas de problème.
À moins que vous ne travailliez sur un projet masif qui prend beaucoup de temps à vérifier avec fxcop, je pense que cela devrait être correct et il n'y a aucune raison de vérifier seulement les changements incrémentiels.
Si vous êtes dans une situation où un projet a pris tellement de temps qu'il faut du temps pour l'analyser, pensez à le refactoriser. Dans un contexte Visual Studio, lorsque vous avez des dossiers dans un projet, envisagez de les créer dans de nouveaux projets. Cela aidera avec la séparation dans votre code, et rendra possible d'analyser des parties de la solution entière, plutôt que la solution entière et tous ses projets, dont la plupart n'auront aucun changement.
Le refactoring sera souvent plus rapide, avec moins de courbe d'apprentissage, que de faire une configuration de test vraiment personnalisée pour compenser un scénario difficile.
Ceci est similaire à cette question.
Il est possible, mais les résultats ne seront pas précis à 100%. En un mot, vous exécutez l'analyse sur votre assemblage et produire un rapport. Une fois l'assemblage modifié, réexécutez l'analyse, définissez le projet FXCop pour signaler uniquement les nouvelles erreurs et importez l'ancien rapport en tant que référence. Il est préférable de le faire avec le fichier fxcopcmd.exe plutôt qu'avec l'interface utilisateur.
La raison pour laquelle les résultats ne seront pas précis à 100% est qu'il n'est pas trivial de faire correspondre l'ancien rapport au nouveau code. Les lignes changent, le code est refait, les violations sont corrigées, de nouvelles violations sont introduites, etc. Ainsi, vous pouvez obtenir des violations signalées à nouveau dans les assemblages modifiés, même si elles ont déjà été signalées. Mais dans l'ensemble, fxcop fait un travail assez décent en créant un rapport de diff.
Ouais ... des projets massifs est quelque chose que je ne peux pas ignorer et nous dans un processus de raffinage des processus ... donc besoin d'être cohérent, solution-sage, pour tous les scénarios ... des pensées ?? ... pouvons-nous utiliser l'extensibilité VS en aucune façon? – ASV
Je pensais à quelque chose comme l'activation des builds incrémentaux sur le projet Visual Studio, puis FxCop en cours d'exécution dans le processus de post-construction prendrait soin du reste .... est-ce juste de le penser ... serait des builds incrémentaux font aussi FxCop Rechercher les changements incrémentiels dans l'exe/dll .. bien que je doute moi-même que cela se produise ainsi ... – ASV
Vous devriez envisager de faire des projets fxcop plus petits qui s'exécutent sur différentes parties de la solution, plutôt qu'une grande analyse. Certains projets feront face à plus de changements que d'autres. Si vous exécutez fx cop dans le cadre d'une intégration continue, envisagez d'avoir des versions différentes avec les projets fxcop plus lourds exécutés moins fréquemment. –