Использование FxCop для анализа только последних изменений

Question

Я пытаюсь заставить FxCop работать таким образом, чтобы он анализировал только инкрементные изменения в exe / dll, который он анализирует, а не весь объект, который уже охватил эту часть ... любые мысли, как достичь этого ?? ... заранее спасибо ...

С уважением,

ASV ...

Answer 1

Это похоже на этот вопрос.

Diff fxcop results

Возможно, но результаты не будут на 100% точными.Одним словом, вы запускаете анализ своей сборки и создаете отчет.После изменения сборки снова запустите анализ, настройте проект FXCop так, чтобы он сообщал только о новых ошибках, и импортируйте старый отчет в качестве базового показателя.Лучше всего делать это с помощью fxcopcmd.exe, а не пользовательского интерфейса.

Причина, по которой результаты не будут на 100% точными, заключается в том, что сопоставление старого отчета с новым кодом не является простой задачей.Сдвиги строк, код подвергается рефакторингу, исправляются нарушения, вводятся новые нарушения и т. Д. Таким образом, вы можете снова получать сообщения о некоторых нарушениях в измененных сборках, даже если о них сообщалось ранее.Но в целом, fxcop делает довольно приличную работу, создавая отчет о различиях.

Answer 2

Я думаю, было бы слишком много хлопот, чтобы это произошло. Мой совет - выбрать правила fx cop, с которыми вы можете жить, и извлечь все ошибки / предупреждения из вашего кода. Таким образом, если другой член команды что-то изменит, вы заметите это, если они не пишут код, который проходит. в этом случае нет проблем.

Если вы не работаете над каким-то грандиозным проектом, для проверки которого у fxcop требуются годы, я думаю, что все должно быть в порядке, и нет причины проверять только постепенные изменения.

Если вы находитесь в ситуации, когда проект стал настолько большим, что для его анализа требуются годы, подумайте о рефакторинге. В контексте Visual Studio, где бы у вас ни были папки в проекте, рассмотрите возможность превращения их в новые проекты. Это поможет с разделением вашего кода и позволит проанализировать части всего решения, а не всего решения и всех его проектов, большинство из которых не будет иметь изменений.

Рефакторинг часто будет быстрее, с меньшими затратами на обучение, чем создание действительно индивидуальной настройки тестирования, чтобы компенсировать сложный сценарий.