Когда следует использовать ссылку на проект, а не двоичную ссылку?

Question

В моей компании есть общая библиотека кода, которая состоит из множества проектов библиотек классов, а также вспомогательных тестовых проектов.Каждый проект библиотеки классов выводит один двоичный файл, например.Company.Common.Serialization.dll.Поскольку мы владеем скомпилированными и протестированными двоичными файлами, а также исходным кодом, ведутся споры о том, должны ли наши приложения-потребители использовать двоичные файлы или ссылки на проекты.

Некоторые аргументы в пользу ссылок на проекты:

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

Некоторые аргументы в пользу бинарных ссылок:

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

Какова ваша политика/предпочтения в отношении использования проектных или двоичных ссылок?

Answer 1

Мне кажется, что вы рассмотрели все основные моменты.Недавно у нас на работе было похожее обсуждение, и мы еще не совсем определились.

Однако мы рассмотрели одну вещь: ссылаться на двоичные файлы, чтобы получить все отмеченные вами преимущества, но создавать двоичные файлы с помощью общей системы сборки, где исходный код находится в общем месте, доступном со всех компьютеров разработчиков ( по крайней мере, если они сидят в сети на работе), чтобы при необходимости любая отладка могла фактически углубиться в библиотечный код.

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

По сути, я определенно поддерживаю (в терминах SO) ваши комментарии о сохранении проверенного кода библиотеки вне поля зрения обычного разработчика.

Кроме того, если я загружаю файл глобального решения, который содержит все проекты и, по сути, все, у ReSharper 4 возникает какая-то коронарная проблема, поскольку Visual Studio практически останавливается.

Answer 2

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

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

Answer 3

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

Очень важно создавать файлы символов отладки (pdb) для каждой сборки библиотеки и делать их доступными.Другой вариант — создать локальное хранилище символов в вашей сети и попросить каждого разработчика добавить это хранилище символов в свою конфигурацию VS.Это позволит вам выполнять отладку кода и при этом пользоваться преимуществами использования двоичных ссылок.

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

Answer 4

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

Я сделал это для того, чтобы позволить разработчикам открыть плотное решение, в котором есть только домен, тесты и веб-проекты.Наши сервисы win, Silverlight и библиотеки веб-управления представлены в отдельных решениях, которые включают в себя нужные вам проекты, но nant может построить все это.

Answer 5

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

Я склонен думать, что решения должны содержать проекты, которые разрабатываются в тесном сотрудничестве.Например, ваши сборки API и ваши реализации этих API.

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

Answer 6

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

Короче говоря, я разделяю это по понятиям