Ссылки на сборки проекта между членами команды
Мне было любопытно узнать, какие типы структур вы используете для ссылок на проекты?
Там, где я работаю, у разработчиков есть общая папка AssemblyCache (\\ MACHINENAME \ AssemblyCache), которая сопоставлена с R: \ через GPO в Windows 2008 AD (привязана к группе разработчиков AD).
Наши общие компоненты имеют события после сборки, которые копируют их примерно так:
R: \. Net% VERSION% \ Project \% SOMETHING%
Иногда за ним следует «Обычный», если он общий для проекта, или что-то конкретное. Также есть общий каталог для общих материалов в папке .Net версии.
Это настолько большие проекты с несколькими решениями, которые могут ссылаться на сборки из общего места.
Машина сборки также имеет общий диск с тем же именем, которое разработчики сопоставили с S :. Это позволяет им получить последнюю рабочую сборку, если она им понадобится.
Все это для того, чтобы кто-то мог сесть на новый ПК и открыть проект без необходимости копировать ссылки в разные места и гарантировать, что dev a ссылается на сборку из того же места, что и dev b и т. д.
Это решение хорошо работает для нас, поэтому мне было интересно, какие решения, если таковые имеются, у вас есть для обеспечения того, чтобы все разработчики ссылались на сборки с одного и того же пути?
Ответы 3
- Сохраните все эталонные сборки в системе управления версиями.
- Всегда выбирайте так, чтобы код имел тот же путь родственник к сборкам (например, ../../CommonLibraries)
- Все едут на локальный диск
Необходимость обращения к сетевому диску вызывает различные проблемы:
- Невозможно перейти к более поздней версии, ссылаясь на более ранние версии для существующих веток
- Трудности при работе в офлайн-режиме
- Машина сборки и т. д. Зависит от другой машины - это не автономная сборка
- Производительность невелика
При использовании сетевой папки эту папку также необходимо добавить в надежные расположения с помощью caspol afaik, поэтому настройка новой рабочей среды немного сложнее, чем просто открытие и компиляция решения.
@divo Нельзя ли выполнить эту задачу на этапе предварительной сборки?
Да, это должно быть возможно, но это добавляет дополнительную сложность, и у вас не будет такой же конфигурации безопасности в вашей системе разработки, как в целевой системе. Конечно, это не обязательно, но и не так уж и привлекательно ...
Проблема 1 касается управления версиями сборок. Предположим, я хочу использовать новую версию NUnit (или что-то еще). Это нужно просто обновить в системе управления версиями. Проекты, которые полагаются на определенные версии, должны разветвлять / маркировать соответствующие версии и извлекать их. Каталоги с номерами версий не масштабируются
Хорошо понял. И я согласен, что такие сборки должны поддерживаться системой контроля версий. Но можно ли задать относительные пути к сборкам в Visual Studio?
IIRC, если вы перейдете к сборке, она автоматически станет относительной ссылкой.
Ага, ты прав! Я это проверил. Спасибо за информацию, я этого не знал, так как путь, показанный в окне свойств, всегда является абсолютным.
В одном проекте мы добавили сборки в репозиторий исходного кода. Это тоже не идеально, но предотвращает случайное получение новой версии ссылки, что может легко произойти при использовании общего файлового ресурса.
Вам не нужно создавать общий сетевой ресурс. Я думаю, вы можете обойтись созданием буквы виртуального диска для локальной папки, например, с помощью команды windows subst ...
subst R: "C:\.Net %VERSION%\Project\%SOMETHING%"
Преимущество здесь состоит в том, что произвольный путь может быть направлен к стандартному четко определенному пути для сборок, поэтому, например, различные версии сборок могут быть переназначены на фиксированный ссылочный путь, используемый Visual Studio.
Я думаю, что некоторых из этих проблем можно избежать, если создать букву виртуального диска из локальной папки с помощью команды subst. Не могли бы вы подробнее рассказать о проблеме №1