Перенос пользовательских правил анализа кода в VS2012

Question

Я написал десятки пользовательских правил анализа кода. Правила были разработаны для Visual Studio 2010. При необходимости сборка содержит ссылку на версии 10.0 FxCopSdk, Microsoft.Cci и Microsoft.VisualStudio.CodeAnalysis. Они корректно работают в Visual Studio 2010 и правильно собираются в TFS 2010.

Я хотел бы перейти на Visual Studio 2012. Однако, когда я запускаю пользовательские правила в существующем решении с использованием VS 2012, я получаю ошибки CA0062. Основной причиной является ошибка CA0053 при загрузке сборки пользовательских правил. Я понимаю, что эти ссылки на эти три сборки необходимо обновить до версии 11 для Visual Studio 2012. Это можно сделать с помощью перенаправления версий в файлах конфигурации. Я могу заставить его работать локально, перенаправив двоичные файлы Visual Studio 2012 IDE и FxCopCmd, но у меня возникают проблемы при проверке кода в TFS 2010.

Мы рассмотрели два очевидных решения, но ни одно из них не очень приемлемо. Во-первых, требуется, чтобы каждый разработчик перенаправлял локально, а затем модифицировал агенты сборки TFS, чтобы перенаправлять также. Во-вторых, необходимо поддерживать две ветви правил анализа пользовательского кода: одну для версии 10 (VS2010), а другую для версии 11 (VS2012).

Есть ли лучший способ сделать это, или нам нужно все обновить до TFS 2012 и Visual Studio 2012 одновременно?

Answer 1

Вы можете попытаться вручную отредактировать файл проекта и написать два включаемых блока (один для VS2010 и один для VS2012), а затем определить условия для использования правильного. Вам нужно только как-то определить, хотите ли вы собрать для VS2010 или VS2012 в msbuild.

Answer 2

Между вашими подходами и предложением, предложенным ZFE, у вас есть все потенциальные кандидаты. Учитывая выбор, я настоятельно рекомендую переходить, так как для FxCop нет официального SDK с гарантиями обратной совместимости.

Если вам повезет, вы не столкнетесь ни с какими поведенческими изменениями или изменениями поверхности API, которые влияют на ваши правила, и единственное различие между вашими двумя ветвями будет ссылками, поэтому любые объединения будут тривиальными. Однако любые временные вложения, которые вы вкладываете в альтернативный подход сейчас, будут потеряны, если вам потребуется перейти позже, и вероятность того, что в конечном итоге потребуется переход, не является ничтожной.