Различные решения / файлы проекта для локальных и сборочных сред - PullRequest
1 голос
/ 18 августа 2008

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

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

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

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

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

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

Ответы [ 6 ]

1 голос
/ 21 августа 2008

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

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

1 голос
/ 21 августа 2008

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

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

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

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

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

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

0 голосов
/ 21 августа 2008

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

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

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

0 голосов
/ 21 августа 2008

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

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

0 голосов
/ 18 августа 2008

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

  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 голосов
/ 18 августа 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...