Необходимые предложения для TeamCity + WiX + MSBuild

Question

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

Сначала немного:

Я был запущен TeamCity успешно в течение последних нескольких месяцев, и она строит свои конфигурации и запускает свой NUnit и NCover тесты просто отлично.

Я потратил немного времени на изучение инсталляторов - я всегда ненавидел InstallShield и никогда не рассматривал его для моего текущего приложения. Мне нравится NSIS, но потом случилось встретить WiX. У меня нет интимного знания архитектуры MS Installer, которая, как я понимаю, опасна для сложных проектов, поэтому в какой-то момент мне нужно будет узнать больше об этом. Тем не менее, через несколько дней после прохождения вопросов SO, поиска в Интернете и чтения блогов, у меня есть проект WiX, который успешно создает, устанавливает, запускает приложение и все удаляет чисто. Большой!

Я также хотел, чтобы конфигурация сборки TeamCity автоматически обновляла номер версии всех моих сборок. Я смог объединить эту функциональность, установив MSBuild Community Tasks на мою машину разработки и создав конфигурацию развертывания, которая использует цель BeforeBuild и задачу FileUpdate, чтобы изменить номер версии. Это работает правильно, за исключением того, что на моей машине разработки у меня нет переменной окружения build_vcs_number_1 для замены.

Так вот, где я сейчас - мне нужно, чтобы TeamCity выполнял обновление, и хотя у него есть переменная окружения build_vcs_number_1, я не могу понять, как добраться до задач сообщества WiX MSBuild.

Одно сообщение, которое я прочитал, рекомендуется проверить в целевых MSBuild в папку SVN. У меня есть папка/extlib для вещей, как это, так что мои правила Кассовые TeamCity VCS выглядеть примерно так:

+:tags/2010-10-15=>src 
+:extlib=>extlib 

Как добраться до extlib из переменной окружения? Когда я запускаю сборку, TeamCity жалуется (и правильно), что не может найти c:\wix30\MSBuildCommunityTasks. Фактическая папка C:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasks. Папка автоматически генерируется, так как я выполняю проверку на стороне сервера, поэтому должна быть какая-то переменная среды, которую TeamCity устанавливает, чтобы я мог использовать правильный путь.

Одна вещь, которую я должен отметить, это то, что я перешел в конфигурацию сборки -> Свойства и переменные среды и нашел неинтуитивный дропсет со всеми существующими переменными и не видел ничего, что звучало как переменная, указывающая на рабочий путь.

Один из возможных способов решения проблемы - просто установить MSBuild Community Tasks на сервере сборки, а затем я могу создать переменную системной среды, к которой можно получить доступ: <WixToolPath>.

Есть ли у кого-нибудь другие предложения?

Answer 1

Я вижу некоторые достоинства в попытке установить задачи сообщества msbuild в SVN (чтобы уменьшить требования к машине сборки), но лично я просто установил их на сервер. Важная часть: обновите свою документацию для своего сервера сборки, чтобы указать, как это необходимо сделать. Для меня я использую задачи сообщества, в основном, каждый файл msbuild для нескольких проектов и сценарии развертывания, поэтому сохранение их в SVN немного избыточно. У меня также установлен WiX на сервере сборки.

я что-то подобное, но, а не перед компоновкой цели, у меня есть файл MSBuild проекта примерно так:

<Target Name="Build"> 
    <CallTarget Targets="UpdateVersionNumbers"/> 
    <MSBuild Projects="Project.sln" Targets="Build"/> 
</Target> 

Моя UpdateVersionNumbers цель захватывает пересмотр SVN, а затем использует регулярное выражение и задачи FileUpdate изменить 4-ю часть номера версии на версию SVN.

Затем я запускаю обычную сборку файла решения и включаю в него, что он создает .wixproj. Довольно просто, правда.

---

Чтобы ответить на некоторые из ваших вопросов, хотя:

• При указании пути, всегда использовать пути относительно корня вашего решения (выписка дир). Так, например, в этом случае вы просто используете wix30\MSBuildCommunityTasks. TeamCity запускает msbuild с рабочим каталогом в качестве корня, и, кроме того, неважно, где вы или другие разработчики выполняете свою проверку - все пути являются относительными.

• Вы можете передавать параметры в teamcity в msbuild с помощью свойств Build Parameters -> System. Например, добавьте свойство с именем agentHome, которое имеет значение %system.agent.home.dir%, а затем вы можете ссылаться на него в файле msbuild в виде $ (agentHome). Обратите внимание, если вы также применение MSBuild снова, как в моем примере выше, вы должны были бы сделать:

  <MSBuild Projects="Project.sln" Properties="agentHome=$(agentHome)" Targets="Build"/> 
  

  фактически передать эту переменную в Project.sln. I думаю, но я не уверен, что msbuild, запущенный на .sln-файле, также передаст все свойства всем отдельным проектам, так что вы сможете получить к нему доступ в своем событии перед сборкой.

---

Примечание стороны на монтажников (я недавно прошел через то же самое, что вы сделали): Я остановился на WiX 3.0, и хотя есть довольно кривая обучения к ней, она хорошо работает. Мы начали новый поток разработки и начали использовать VS2010 и .NET 4. Ну, WiX 3.0 несовместим с VS2010, поэтому нам нужен WiX 3.5 (который все еще находится в бета-версии, хотя state of it seems much better now than it was a few months ago, но они все еще отстают. это природа открытого источника, иногда). У меня было pain getting WiX 3.0 and 3.5 to install together, но, наконец, выяснилось.

Недостаток этого (между несовместимостью, flaky betas (с нескольких месяцев назад) и полным медленным прогрессом) действительно отключил WiX (не обижайтесь на ребята, работающие на WiX, но я просто хочу установщика и я не хочу участвовать в этом.Заметьте, они очень frustrated тоже). Добавьте к этому продукт, который мне нужен для следующего, требует гораздо более сложного инсталлятора, и WiX просто кажется слишком много работы. Я только что создал свой установщик, используя AdvancedInstaller, и это заняло всего пару дней, и до сих пор работало хорошо (хотя мы сейчас находимся на ранних этапах разработки, но начинаем непрерывное развертывание и тестирование). Цена AI разумна (мы все еще в пробной версии сейчас), но я буду покупать в ближайшие пару дней.

Я уверен, что время, проведенное мной, было намного меньше, чем я потратил на изучение WiX, а затем попытался сделать все, что мне нужно. Немного неизбежно узнать о том, как работает Windows Installer, но вам не нужно слишком углубленно изучать.

Answer 2

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

Интересно, если это он:

Я думаю, мой вопрос сейчас - я могу на самом деле использовать% system.agent.work.dir% в моем .wixproj? Я попробую сейчас.