Проверка двоичных ссылок в решении

Я ищу способ обнаружения проблем со ссылками на сборки в большом решении Visual Studio:

  • Двоичные ссылки на неверные местоположения, например, путь не в системе управления версиями или в выходных данных другого проекта.
  • Двоичные ссылки на несколько версий одной и той же сборки в проектах решения.
  • Двоичные ссылки без пути, которые могут быть перенаправлены в GAC
  • Двоичные ссылки, которые должны были быть ссылками на проект

Вся история

Я работаю над большим проектом C#, в котором почти 200 проектов. Одна из проблем, которая возникает со временем, заключается в том, что ссылки на сборки добавляются, но не всегда на одну и ту же версию или в правильное место.

Например, проект может получить ссылку на System.Web.Mvc без пути подсказки, что заставит его ссылаться на любую версию, которая есть в GAC. Visual Studio (и Resharper) также предложит добавить отсутствующую ссылку, но может сделать это, добавив ссылку на выходную папку другого проекта.

Теперь недавняя катастрофа Центра обновления Windows оставила некоторых членов команды мертвыми в воде, неспособными создать решение. Как вы понимаете, это повысило для нас приоритет управления ссылками на сборки.

Чтобы обнаружить некоторые из наиболее очевидных проблем, я уже настроил файл msbuild, который можно включить в каждый файл csproj и который будет обнаруживать плохие ссылки.

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

Что бы я действительно хотел, так это проверить все файлы проекта в решении на наличие «плохих» ссылок во время непрерывной сборки, чтобы все проекты всегда проверялись.

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

Итак, прежде чем я уйду и разверну свое собственное решение, есть ли уже способ сделать это?

Обновить

Чтобы очистить кодовую базу, я создал немного кода ScriptCS, который будет сканировать все файлы csproj на наличие ссылок на сборки в пакетах Nuget и исправлять их. Это на GitHub.


static-analysis c# msbuild code-analysis
person Marnix van Valen    schedule 16.10.2014    source источник
comment
Вопросы, в которых нас просят порекомендовать или найти книгу, инструмент, программную библиотеку, учебное пособие или другой ресурс за пределами сайта, не относятся к теме Stack Overflow, поскольку они, как правило, привлекают самоуверенные ответы и спам. Вместо этого опишите проблему и то, что уже было сделано для ее решения.   -  person EZI    schedule 17.10.2014
comment
@EZI Я прошу конкретное решение конкретной проблемы разработки программного обеспечения, я бы сказал, что это квалифицируется как тема StackOverflow.   -  person Marnix van Valen    schedule 17.10.2014
comment
У нас была родственная проблема. Со временем в нашем решении будет две или три версии одного и того же пакета NuGet, потому что люди будут просто устанавливать самый последний пакет, а не использовать существующую версию. В любом случае... В итоге я написал свой собственный инструмент для анализа пакетов и выявления любых дубликатов. Я подозреваю, что вам придется сделать то же самое.   -  person Craig W.    schedule 17.10.2014

Ответы (2)


arrow_upward
3
arrow_downward

Вы можете создать пакет NuGet, единственной целью которого является включение в проект пользовательского файла .targets. Недавно я использовал эту стратегию для решения другой проблемы (сообщения об ошибках для отсутствующих файлов .snk).

Если вы создаете аналогичный пакет, легко щелкнуть правой кнопкой мыши узел решения и убедиться, что он установлен во всех ваших проектах C#.

Если ваш анализ более сложен и требует использования сборки (пользовательские задачи сборки) в дополнение к файлу .targets, вы можете использовать подход, который я использую для Antlr4 Пакет NuGet, который содержит задачи сборки, ресурсы и настраиваемые .props и .targets , но не фактические сборки, на которые ссылается проект, в котором они устанавливаются.

person Sam Harwell    schedule 17.10.2014

arrow_upward
2
arrow_downward

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

Даже если вы будете использовать пакет nuget, как было предложено ранее, вам все равно придется вручную проверять, все ли ваши проекты (200 проектов? Правда?) ссылаются на пакет.

person brijber    schedule 17.10.2014