48
Наши проекты в TFS организованы следующим образом:NuGet и TFS лучшие практики
$\DefaultCollection\ProjectName\Source <-- source code goes here
$\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here
Теперь, когда NuGet находится на сцене, есть ли причина изменить наш подход и использовать папку пакеты NuGet для библиотек DLL, которые приходят из Проекты, поддерживающие NuGet? Я склоняюсь против этого, потому что
1) он создает два места нужно искать зависимости 2) он оставляет нас открытые для одного разработчика обновления пакета и разбивая некоторую зависимость
, что сказал, если кто-нибудь могут сообщить хорошая причина для начала использования NuGet в среде TFS, я с радостью представляю свои идеи своей команде, как если бы они были моими (шутка).
Вам не нужно хранить пакеты из NuGet в системе управления версиями, используя вместо 'NuGet.exe' заполнить локальную копию из' packages.config' файлов проектов: HTTP: // blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html – Richard
Как это работает для решений, имеющих несколько проектов? Наше главное - два веб-приложения, два консольных приложения и служба. Преимущество подхода dll store заключается в том, что все они либо работают, либо не работают вместе. –
Перейдите по ссылке: запустите 'nuget-exe' для каждого' package.config' с той же папкой репозитория, будут загружены только отсутствующие пакеты (это также может быть шаг предварительной сборки для каждого проекта). – Richard