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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Я разделяю это понятием вкратце