Ссылки на сборки вне GAC без определения пути - PullRequest
2 голосов
/ 12 февраля 2010

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

Меня тянет к элегантности структуры, изложенной в W Craig Trader's ответ на этот вопрос . Мы используем TFS, а не SVN, но подход также применим. Используя этот подход, у каждого разработчика будет локальное рабочее пространство, содержащее последнюю общую сборку для каждой основной версии. Каждая из этих сборок будет именно той, которая будет развернута в GAC целевого хоста.

Каждый член команды разработчиков может свободно размещать свою машину, так как он чувствует себя наиболее комфортно, поэтому каталог, содержащий сборки, на которые можно ссылаться во время разработки, может легко измениться с dev на dev. Мы не хотим хранить сборки в GAC машин разработчиков. И не хочу, чтобы каждый разработчик обновлял ссылки каждый раз, когда проверял проект или входил в него.

Итак, мой вопрос: есть ли способ настроить папку, чтобы она действовала как общесистемное хранилище сборок а-ля GAC? Или есть способ настроить VS2008 для поиска сборок в определенном месте?

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

Любые мысли или предложения приветствуются.

Спасибо, Dan

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

Альтернатива - написать клиентский прослушиватель событий TFS, который может увеличить файл проекта при извлечении и очистить его при регистрации. Но я не уверен, насколько это безопасно.

Ура, Dan

Ответы [ 2 ]

1 голос
/ 24 февраля 2012

NuGet помогает решить эту проблему. Создайте свой общий код как пакеты nuget, и затем вы можете использовать локальные каналы , хранящиеся на сетевом диске или общем сервере, для размещения ваших пакетов nuget. Я только что увидел, что в Teamcity 7 теперь даже есть встроенная поддержка для размещения каналов nuget.

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

Пакеты Nuget могут не только предоставлять простые ссылки на DLL: например, можно распространять библиотеки JavaScript или изображения, либо любой другой контент. Если вы создаете несколько веб-приложений, которые имеют общие настройки (стили, формы, логины и т. Д.), Вы можете упаковать необходимые файлы / библиотеки / и т. Д. В пакет nuget, а затем просто добавить ссылку на пакет.

1 голос
/ 12 февраля 2010

На моей предыдущей работе все разработчики имели диск R: \, который содержал все общие сборки. С помощью скрипта сборки на диске были обновлены путем копирования их из общего сетевого ресурса.

...