My<cod/>.net
Различные решения / файлы проектов для локальных сред vs Build
В рамках усовершенствования нашего процесса сборки мы в настоящее время обсуждаем, следует ли нам иметь отдельные файлы проекта/решения в нашей производственной среде CI от наших локальных сред разработки.
Причина, по которой это произошло, заключается в том, что в нашем предыдущем проекте мы столкнулись с проблемами ссылок. Часто люди ошибочно добавляют ссылку на assembly в неправильном месте, что означает, что он будет хорошо работать в их локальной среде, но может сломаться на чьей-то другой или на машине сборки.
Кроме того, ссылочные пути находятся в файлах csproj.user, что означает, что они должны быть зафиксированы в системе управления версиями, поэтому все должны совместно использовать эти же параметры.
Поэтому мы думаем о том, чтобы иметь отдельные проекты и решения на нашем сервере CI, чтобы при сборке он использовал эти проекты, а не локальные разработки.
Он имеет очевидные недостатки, такие как накладные расходы на поддержание этих отдельных файлов и связанного с ними процесса, который должен быть определен и соблюден, но он имеет преимущества в том, что мы будем в большей степени контролировать EXACTLY , что происходит в производственной среде.
Но я не смог найти ничего по этому вопросу - не могу поверить, что мы единственные люди, которые думают об этом, - так что все мысли приветствуются.
В нашем крупнейшем проекте (система, состоящая из множества приложений) мы имеем следующую структуру
/3rdPartyAssemblies
/App1
/App2
/App3
/.....
Все внешние сборки добавляются в 3rdPartyAssemblies/Vendor/Version/...
У нас есть файл CoreBuild.sln, который действует как сценарий MSBuild для всех сборок, которые совместно используются для обеспечения построения в порядке зависимости (т. е. убедитесь, что App1.Interfaces построен до App2, поскольку App2 имеет ссылку на App1.Interfaces).
Все ссылки между приложениями нацелены на папку /bin (мы не используем bin / debug и bin/release, просто bin, таким образом, ссылки остаются теми же, и мы просто меняем конфигурацию выпуска в зависимости от цели сборки).
Круиз-контроль создает основное решение для любых зависимостей перед созданием любого другого приложения, и поскольку папка 3rdPartAssemblies присутствует на сервере, мы гарантируем, что машины разработчиков и сервер сборки имеют одинаковый макет разработки.
Я знаю, что это анахронизм. Но единственный лучший способ, который я нашел, чтобы справиться с проблемой ссылок, - это иметь папку, сопоставленную с буквой диска, такой как R: и затем все проекты встраиваются или копируют выходные данные в эту папку. Тогда все ссылки R:\SomeFile.dll и т. д. Это позволяет обойти проблему, что иногда ссылки добавляются по абсолютному пути, а иногда они добавляются относительно. (есть что-то связанное с "HintPath", что я действительно не могу вспомнить)
Тогда хорошо, что вы все еще можете использовать те же файлы решений на вашем сервере сборки. Что, честно говоря, является абсолютной необходимостью, поскольку вы теряете уверенность в том, что то, что строится на машине разработки, является тем же самым, что и на сервере сборки в противном случае.
Мы изменили структуру нашего проекта (используя SVN внешних элементов), где каждый проект теперь полностью самодостаточен. То есть любые ссылки никогда не выходят из каталога проекта (например, если проект A ссылается на ASM X, то ASM X существует в подпапке ProjectA)
Я подозреваю, что это должно каким-то образом помочь решить некоторые наши проблемы, но я все еще вижу некоторые преимущества в том, чтобы иметь больший контроль над проектами сборки.
Я бы настоятельно рекомендовал этого не делать.
Ссылочные пути хранятся не только в файле .user. Путь подсказки хранится в самом файле проекта. Вам никогда не придется проверять файл .user в системе управления версиями.
Пусть существует один набор (хорошо, возможно, версионных) файлов решений/проектов, которые используют все разработчики, и конфигурации выпуска которых являются тем, что вы в конечном итоге создаете в рабочей среде. Наличие отдельных файлов проекта приведет к путанице в будущем, когда некоторые настройки проекта будут подправлены, а не перенесены и запущены в производство.
Вы также можете проверить это:
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx http://bytes.com/forum/thread268546.html
@David-хотите верьте, хотите нет, но это то, что мы имеем сейчас, и все же это по-прежнему вызывает у нас проблемы!
Однако мы вносим некоторые изменения, которые навязываются нам из - за перехода на TeamCity и нескольких агентов сборки, поэтому мы не можем иметь ссылки на каталоги вне текущего проекта, как я уже упоминал в своем предыдущем ответе.
Посмотрите на внешний раздел этой ссылки, чтобы понять, что я имею в виду- http://www.dummzeuch.de/delphi/subversion/english.html
Обычно вы создаете проекты сборки / скрипты в той или иной форме для вашего производства, и поэтому создание другого файла решения не входит в картину.
Было бы проще обучить всех использовать ссылки на проекты и создать каталог в структуре файла проекта для внешних ссылок assembly. Таким образом, все следуют одной и той же среде.