Лучшая практика: совместная среда, каталог Bin, SVN

Question

Каковы наилучшие методы проверки в каталогах BIN в совместной среде разработки с использованием SVN? Следует ли исключать ссылки на уровне проекта из проверки? Легче ли просто добавить все каталоги bin?

Я разрабатываю много сайтов DotNetNuke, и кажется, что в среде с несколькими разработчиками всегда очень важно правильно настроить среду.

Конечная цель (конечно), чтобы иметь новый разработчик Checkout ствол из SVN, восстановить базу данных DNN и есть все это просто «работа» ...

Answer 1

Любые сборки, которые, как ожидается, будет в ПКК должен оставаться в ПКК. Это включает в себя файл 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 ссылаются на сборки в папке root/References относительно. Эти .dll проверяются на подрывную деятельность.

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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