Различные решения / файлы проекта для локальных и сборочных сред

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

Это произошло из-за проблем со ссылками, с которыми мы столкнулись в нашем предыдущем проекте. Часто люди ошибочно добавляли ссылку на сборку в неправильном месте, что означало бы, что она будет работать нормально в их локальной среде, но может сломаться на чужой или на сборочной машине.

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

Поэтому мы думаем о том, чтобы иметь отдельные проекты и решения на нашем CI-сервере, чтобы при создании сборки они использовали эти проекты, а не проекты локальной разработки.

У него есть очевидные недостатки, такие как накладные расходы на обслуживание этих отдельных файлов, и связанный процесс, который необходимо будет определить и выполнить, но у него есть преимущества в том, что мы будем в большей степени контролировать ТОЧНО, что происходит в производственной среде.

Что я не смог найти, так это что-то на эту тему - не могу поверить, что мы единственные люди, которые думают об этом - поэтому все мысли приветствуются.

18.08.2008 14:20:09
6 ОТВЕТОВ

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

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

0
18.08.2008 14:24:48

Я настоятельно рекомендую против этого.

  1. Ссылочные пути хранятся не только в файле .user. Путь подсказки хранится в самом файле проекта. Вы никогда не должны проверять файл .user в системе контроля версий.

  2. Пусть будет один набор (хорошо, возможно, версионных) файлов решений / проектов, которые используют все разработчики, и конфигурации Release, которые вы в конечном итоге создаете в производстве. Наличие отдельных файлов проекта может привести к путанице в будущем, когда некоторые настройки проекта будут изменены, не перенесены и запущены в производство.

Вы также можете проверить это:

http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx http://bytes.com/forum/thread268546.html

0
11.08.2012 16:10:15

Мы изменили структуру нашего проекта (используя SVN Externals), где каждый проект теперь полностью автономен. То есть любые ссылки никогда не выходят за пределы каталога проекта (например, если проект A ссылается на ASM X, то ASM X существует в подпапке ProjectA)

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

0
21.08.2008 08:40:06

В нашем крупнейшем проекте (система, состоящая из множества приложений) мы имеем следующую структуру

/ 3rdPartyAssemblies
/ App1
/ App2
/ App3
/ .....

Все внешние сборки добавляются в 3rdPartyAssemblies / Vendor / Version / ...

У нас есть файл CoreBuild.sln, который действует как скрипт MSBuild для всех общих сборок, чтобы обеспечить сборку в порядке зависимости (т. Е. Убедиться, что App1.Interfaces собран перед App2, поскольку App2 имеет ссылку на App1.Interfaces).

Все ссылки между приложениями предназначены для папки / bin (мы не используем bin / debug и bin / release, просто bin, поэтому ссылки остаются прежними, и мы просто меняем конфигурацию выпуска в зависимости от цели сборки).

Круиз-контроль создает основное решение для любых зависимостей перед созданием любого другого приложения, и поскольку папка 3rdPartAssemblies присутствует на сервере, мы гарантируем, что машины разработчика и сервер сборки имеют одинаковую схему разработки.

1
11.08.2012 16:10:24

@ Дэвид - верьте или нет, но это то, что у нас есть сейчас, и все же это вызывает у нас проблемы!

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

Посмотрите на раздел Externals этой ссылки, чтобы понять, что я имею в виду - http://www.dummzeuch.de/delphi/subversion/english.html

0
21.08.2008 12:04:16

Я знаю, что это анахронизм. Но единственный лучший способ справиться с проблемой ссылок - найти папку, сопоставленную с буквой диска, такой как R: а затем все проекты будут встроены или скопированы в эту папку. Тогда все ссылки - это R: \ SomeFile.dll и т. Д. Это поможет вам решить проблему: иногда ссылки добавляются по абсолютному пути, а иногда - относительно. (есть что-то связанное с «HintPath», которое я не могу вспомнить)

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

1
21.08.2008 12:10:00