VS.NET: Проекты Refs vs. Assembly Refs

Question

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

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

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

ПРОФИ:

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

МИНУСЫ:

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

Answer 1

Вот несколько плюсов вы пропустили

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

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

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

Answer 2

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

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

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

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

Answer 3

REFERENCING СТРАТЕГИЯ ВСЕГДА БУДЕТ ОБЩАЯ ПРОБЛЕМА

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

ЛИТЕРАТУРЫ PROJECT идеально подходят для VISUAL STUDIO

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

ЛИТЕРАТУРА СБОРКИ масштабируется ЛУЧШЕ

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

ЛИТЕРАТУРА СБОРКИ СОЗДАТЬ иллюзию развязана СИСТЕМАМИ

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

ПРОФИ ссылок сборки:

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

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

• Циклические ссылки становятся возможными, и ваши менее опытные разработчики не заметят эти ссылки изначально.

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

• Ссылки на обратные рамки становятся возможными, потому что вы добавляете ссылки на библиотеки DLL, которые скомпилированы с более высоким .NET-инфраструктурой, а Visual Studio не дает вам сообщений о явной причине когда это произойдет, вы попробуете много вещей, чтобы устранить проблему и не работать много раз, прежде чем приступать к исправлению версий фреймворка.

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

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

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