VS.NET: ссылки на проекты и сборки

Question

Здесь есть некоторые споры, которые лучше ссылаться на нашу общую базу кода из других проектов: по проекту или по сборке.Я за то, чтобы ссылаться на проект, тем более что у нас есть автоматические модульные тесты, которые доказывают, что общий код делает то, что ему нужно.

Мысль из другого лагеря состоит в том, чтобы блокировать эти проекты и выпускать сборки только один раз в месяц или что-то в этом роде.Затем заставьте все проекты ссылаться на сборки.Они думают, что это защитит их от развертывания непроверенного кода.Они «слишком заняты», чтобы писать автоматические модульные тесты и настраивать свои проекты для непрерывной интеграции, и я не имею на это никакого влияния, поэтому, пожалуйста, не фокусируйтесь на этом аспекте.

Вот причины, по которым я могу подумать, почему проектссылки являются лучшим решением.Я также ищу другие мнения.

PROS:

• Ссылки на проекты гарантируют, что вы работаете с последним кодом.Вам не нужно ничего ждать.
• Сокращение дублирования.Без самого последнего кода есть больше шансов заново изобрести колесо.
• Если разработчику нужно что-то и он не может добавить его в сборку, к которой он принадлежит, он будет создан в любом месте, которое будет работать, создавая много несоответствий и дублирование кода.
• Разработка проще, потому что вы легко можете видеть / отлаживать то, что происходит в ссылочном коде.
• Наши общие вещи меняются не так часто, но когдада, обычно это что-то полезное.Зачем добавлять дополнительное бремя обслуживания и управления выпуском сборки.

CONS:

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

Answer 1

Вот пара плюсов, которые вы пропустили

• Обновление в реальном времени: такие функции, как intellisense, будут автоматически обновляться между проектами и ссылками на проекты при изменении API
• Определение GoTo: если у вас есть ссылка на сборку, определение GoTo перенесет вас к действительному определению кода. Со ссылкой на сборку вы попадете в сгенерированную подпись метаданных.
• Найти все ссылки: будет обрабатывать весь код в ссылках проекта для использования ссылки. Для ссылки на сборку вы увидите только использование в метаданных
• Быстрый поиск (только 2010): аналогично поиску всех ссылок, лучше работает в ссылке P2P

В ответ на ваши минусы

• Да: загрузка проекта обычно выполняется медленнее, чем загрузка ссылки. С разумным количеством проектов, хотя эта разница во времени незначительна и не должна влиять на вашу повседневную рутину разработки
• Да: добавление проекта в решение обычно происходит медленнее, чем добавление ссылки. Разница, однако, в секундах и составляет единовременную стоимость. Я считаю ошибкой считать это частью критериев.

Answer 2

ССЫЛКА НА СТРАТЕГИЮ ВСЕГДА БУДЕТ ОБЩЕЙ ПРОБЛЕМОЙ

Я знаю, что это очень старый вопрос, но это всегда будет актуальный вопрос с относительными ответами, и я помню, что этот же вопросНесколько лет назад влияние этих двух вариантов ( проект по сравнению со сборкой ссылки) стало для меня очевидным только в течение последних двух лет, когда я работал полный рабочий день над сборщиком для системы с 800+ проектами в 300+ решения для одного приложения WPF.

ССЫЛКИ НА ПРОЕКТЫ ИДЕАЛЬНЫ ДЛЯ ВИЗУАЛЬНОЙ СТУДИИ

Ссылки на проекты идеальны, потому что вы предоставляете IDE гораздо больше информации о деталях вашего кода, потому что вы явно говорите Visual Studioгде ссылочный проект и весь его код.Если вы работаете в системе с менее чем 200 проектными модулями и можете позволить себе иметь только несколько решений (группировок проектов), воспользуйтесь ссылками на проекты, потому что Visual Studio может сделать для вас больше с этой дополнительной информацией во время разработки, например, показывать вамкод вместо отражения ссылочных сборок.

СБОРКА ССЫЛКИ МОЖЕТ БЫТЬ МАСШТАБНОЙ ЛУЧШЕ

Если ваша система намного больше чем 200 проектов, ваши сборки могут стать очень медленными.Я видел 20 минут на сборку, и это действительно отстой.Поэтому, если вы можете ссылаться на DLL, которая не изменяется, вы говорите Visual Studio «НЕ» для ее создания, и это, очевидно, оказывает некоторое влияние на время сборки.

СБОРКА ССЫЛКИ СОЗДАТЬ ANИЛЛЮЗИЯ ОТКЛЮЧЕННОЙ СИСТЕМЫ

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

PROS ссылок на сборки:

1. Рассматривая некоторые проекты как внешние зависимости, выможет создавать меньшие решения и меньшие группы связанных проектов, потому что несвязанные проекты обрабатываются как внешние сборки
2. Позволяет Visual Studio достаточно хорошо обрабатывать очень большие модульные системы.
3. Заставляет вас работать с DLL/ стратегия подготовки сборки во время процесса сборки.

НЕДОСТАТКИ ссылок на сборку:

• Возможны циклические ссылки, и ваши менее опытныеРазработчики не будут замечать эти ссылки изначально.

  Вы можете обойти эту проблему циклических ссылок, рассматривая одну из ваших сборок как стороннюю сборку, которую она зарегистрировала, перенося ее на следующую версию.и строить его в прошлом.Когда сборка завершается неудачей в проекте, который использует эту исключенную сборку, вы можете решить перестроить этот назначенный проект и часто размазывать круговую зависимость.(НЕ РЕКОМЕНДУЕТСЯ, но это возможно)

• Также возможны восходящие ссылки на фреймворк, потому что вы добавляете ссылки на dll, скомпилированные с более высокой платформой .net, а Visual Studio не делаеткогда это произойдет, вы получите ясные сообщения о причинах, так что вы попробуете много вещей, чтобы решить проблему, и много раз потерпите неудачу, прежде чем выяснить, как исправить версии платформы.

  В новых проектах по умолчанию используется последняя версия .net Framework, не учитывая тот факт, что все проекты в текущем решении все еще находятся в более ранней версии .net, поэтому при добавлении ссылки на этот проект с использованиемСсылка на сборку, вы часто будете получать странную ошибку, которую не так просто выяснить.

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

  Вы нажимаете «добавить ссылку», переходите на несколько каталогов вверх, переходите на несколько каталогов вниз, выбираете dll и нажимаете «добавить», не осознавая, что dll на самом деле слишком далеко вверх и вниз, в другую ветку, над которой вы также работаете. Эта проблема станет очевидной гораздо позже, когда сервер сборки попытается разрешить эту сборку и завершится неудачно. И ошибка "неизвестное пространство имен, вам не хватает ссылки на сборку?" не поможет вам напрасно тратить время всей вашей команды.

Answer 3

Ну, если вы используете какой-либо источник контроля, вы можете удовлетворить оба лагеря. Использование ветвления или маркировки (в зависимости от вашего источника контроля).

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

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

Другой стороной этого сценария является то, что у вас может быть исправление для общего кода, чтобы не связываться с текущими усилиями по разработке. Конечно, это добавляет дополнительную нагрузку на управление обновлением общего кода в нескольких местах, где это необходимо.