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