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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

Я отделяю его по понятию коротким