Когда следует использовать ссылку на проект, а не двоичную ссылку?
-
09-06-2019 - |
Вопрос
В моей компании есть общая библиотека кода, которая состоит из множества проектов библиотек классов, а также вспомогательных тестовых проектов.Каждый проект библиотеки классов выводит один двоичный файл, например.Company.Common.Serialization.dll.Поскольку мы владеем скомпилированными и протестированными двоичными файлами, а также исходным кодом, ведутся споры о том, должны ли наши приложения-потребители использовать двоичные файлы или ссылки на проекты.
Некоторые аргументы в пользу ссылок на проекты:
- Ссылки на проекты позволят пользователям отлаживать и просматривать весь код решения без необходимости загрузки дополнительных проектов/решений.
- Ссылки на проекты помогут не отставать от изменений общих компонентов, внесенных в систему контроля версий, поскольку изменения можно будет легко идентифицировать без активного решения.
Некоторые аргументы в пользу бинарных ссылок:
- Двоичные ссылки упростят решения и ускорят загрузку решений.
- Двоичные ссылки позволят разработчикам сосредоточиться на новом коде, а не отвлекаться на уже готовый и проверенный стабильный код.
- Двоичные ссылки заставят нас соответствующим образом тестировать наши материалы, поскольку мы будем использовать общую библиотеку так же, как это должны делать те, кто находится за пределами нашей организации.
- Поскольку двоичную ссылку нельзя отладить (вступить в нее), придется копировать и исправлять проблемы, расширяя существующие тестовые проекты, а не тестируя и исправляя только в контексте приложения-потребителя.
- Двоичные ссылки гарантируют, что параллельная разработка проекта библиотеки классов не окажет влияния на приложение-потребитель, поскольку будет ссылаться на стабильную версию двоичного файла, а не на входную версию.Решение о включении новой версии компонента в случае необходимости будет принимать руководитель проекта.
Какова ваша политика/предпочтения в отношении использования проектных или двоичных ссылок?
Решение
Мне кажется, что вы рассмотрели все основные моменты.Недавно у нас на работе было похожее обсуждение, и мы еще не совсем определились.
Однако мы рассмотрели одну вещь: ссылаться на двоичные файлы, чтобы получить все отмеченные вами преимущества, но создавать двоичные файлы с помощью общей системы сборки, где исходный код находится в общем месте, доступном со всех компьютеров разработчиков ( по крайней мере, если они сидят в сети на работе), чтобы при необходимости любая отладка могла фактически углубиться в библиотечный код.
Однако в то же время мы также пометили множество базовых классов соответствующими атрибутами, чтобы отладчик полностью пропускал их, поскольку любая отладка, которую вы выполняете в своих собственных классах (на уровне, который вы разрабатываете), будет быть значительно увеличены только из-за кода из базовых библиотек.Таким образом, когда вы нажмете Шаг в при отладке сочетания клавиш для класса библиотеки вы снова переходите к следующему фрагменту кода на текущем уровне вместо того, чтобы пробираться через тонны библиотечного кода.
По сути, я определенно поддерживаю (в терминах SO) ваши комментарии о сохранении проверенного кода библиотеки вне поля зрения обычного разработчика.
Кроме того, если я загружаю файл глобального решения, который содержит все проекты и, по сути, все, у ReSharper 4 возникает какая-то коронарная проблема, поскольку Visual Studio практически останавливается.
Другие советы
По моему мнению, самая большая проблема с использованием ссылок на проекты заключается в том, что они не дают потребителям общей основы для их разработки.Я предполагаю, что библиотеки меняются.В этом случае их создание и обеспечение версионности даст вам легко воспроизводимую среду.
Если этого не сделать, ваш код загадочным образом сломается при изменении проекта, на который указывает ссылка.Но только на некоторых машинах.
Я склонен относиться к таким общим библиотекам как к сторонним ресурсам.Это позволяет библиотеке иметь собственные процессы сборки, тестирования качества и т. д.Когда отдел контроля качества (или кто-то еще) «благословляет» выпуск библиотеки, она копируется в центральное место, доступное всем разработчикам.Затем каждый проект должен решить, какую версию библиотеки использовать, копируя двоичные файлы в папку проекта и используя двоичные ссылки в проектах.
Очень важно создавать файлы символов отладки (pdb) для каждой сборки библиотеки и делать их доступными.Другой вариант — создать локальное хранилище символов в вашей сети и попросить каждого разработчика добавить это хранилище символов в свою конфигурацию VS.Это позволит вам выполнять отладку кода и при этом пользоваться преимуществами использования двоичных ссылок.
Что касается преимуществ, которые вы упоминаете в отношении ссылок на проекты, я не согласен с вашим вторым пунктом.На мой взгляд, важно, чтобы проекты-потребители четко знали, какую версию общей библиотеки они используют, и чтобы они предприняли осознанный шаг по обновлению этой версии.Это лучший способ гарантировать, что вы случайно не получите изменения в библиотеке, которые не были завершены или протестированы.
если вы не хотите, чтобы это было в вашем решении или у вас есть возможность разделить ваше решение, отправьте весь вывод библиотеки в общий каталог bin и укажите там ссылку.
Я сделал это для того, чтобы позволить разработчикам открыть плотное решение, в котором есть только домен, тесты и веб-проекты.Наши сервисы win, Silverlight и библиотеки веб-управления представлены в отдельных решениях, которые включают в себя нужные вам проекты, но nant может построить все это.
Я считаю, что ваш вопрос на самом деле о том, когда проекты объединяются в одном решении;причина в том, что проекты в одном решении должны иметь ссылки друг на друга, а проекты в разных решениях должны иметь двоичные ссылки друг на друга.
Я склонен думать, что решения должны содержать проекты, которые разрабатываются в тесном сотрудничестве.Например, ваши сборки API и ваши реализации этих API.
Однако близость относительна.Дизайнер приложения по определению тесно связан с приложением, однако вам не хотелось бы, чтобы дизайнер и приложение находились в одном решении (если они вообще сложны).Вероятно, вы захотите разработать конструктор для ветки программы, которая объединяется через промежутки времени, расположенные дальше друг от друга, чем обычная ежедневная интеграция.
Я думаю, что если проект не является частью решения, не стоит его туда включать...Но это только мое мнение
Короче говоря, я разделяю это по понятиям