Каковы наилучшие методы проверки каталогов BIN в совместной среде разработки с использованием SVN? Следует ли исключать ссылки на уровне проекта из проверки? Легче просто добавить все каталоги bin?
Я разрабатываю много сайтов DotNetNuke, и кажется, что в среде с несколькими разработчиками всегда очень важно правильно настроить среду.
Конечная цель (конечно) состоит в том, чтобы иметь новую проверку разработчика trunk из SVN, восстановить базу данных DNN и все это просто "работать"...
Любые сборки, которые, как ожидается, будут в 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 ссылаются на сборки в папке root/References относительно. Эти .dll проверяются на подрывную деятельность.
Кроме того, */bin */bin/* obj должен находиться в вашем глобальном пути игнорирования.
С помощью этой установки все ссылки на сборки либо через GAC (поэтому должны работать на всех компьютерах), либо относительно каждого проекта в вашем решении.
Это конкретный вопрос .Net?
Как правило, наилучшей практикой является не проверять все, что создано автоматически из файлов, которые уже находятся в SCM. Все это идеально создано как часть процесса автоматической сборки.
Если каталог bin, на который вы ссылаетесь, содержит сторонние двоичные файлы, а не сборку вашего проекта, игнорируйте (downvote?) этот совет.
Tree Surgeon - отличный инструмент, который создает пустое дерево разработки .NET. Он был изменен в течение многих лет использования и реализует множество лучших практик.
Maven помогает довольно много с этой проблемой, когда я кодирую java. Мы передаем pom.xml в scs, а репозиторий maven содержит все наши зависимости. Для меня это кажется хорошим способом сделать это.
Мы следим за практикой использования каталога поставщика, который содержит все заголовки и двоичные файлы конкретного производителя. Цель состоит в том, что любой человек должен иметь возможность создавать продукт, просто проверив его и запустив верхний уровень сборки script.