Передовая Практика: Среда Совместной Работы, Каталог Bin, SVN

Все сборки, которые должны быть в GAC, должны оставаться в GAC. Это включает в себя System.web.dll или любую другую стороннюю dll, которую вы развернете на GAC в рабочей среде. Это означает, что новый разработчик должен будет установить эти сборки.

Все остальные сборки сторонних производителей должны быть ссылками через относительный путь. Моя типичная структура-это:

-Project
--Project.sln
--References
---StructureMap.dll
---NUnit.dll
---System.Web.Mvc.dll
--Project.Web
---Project.Web.Proj
---Project.Web.Proj files
--Project
---Project.Proj
---Project.Proj files

Project.Web и Project ссылаются на сборки в корневой папке/References относительно. Эти .dlls проверяются в subversion.

Кроме того, */bin */bin/* obj должен быть в вашем глобальном пути игнорирования.

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

Это конкретный вопрос .Net?

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

Если каталог bin , на который вы ссылаетесь, содержит сторонние двоичные файлы, а не сборку вашего проекта, игнорируйте (downvote?) этот Совет.

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

Maven очень помогает с этой проблемой, когда я кодирую java. Мы фиксируем pom.xml в scs, и репозиторий maven содержит все наши зависимости. Для меня это кажется хорошим способом сделать это.

Мы следуем практике использования каталога поставщиков, который содержит все заголовки и двоичные файлы конкретных поставщиков. Цель состоит в том, чтобы любой человек мог построить продукт, просто проверив его и запустив какой-то сценарий сборки верхнего уровня.