Необходимы предложения рабочего процесса TeamCity + WiX + MSBuild

Question

Необходимы предложения рабочего процесса TeamCity + WiX + MSBuild

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

Сначала немного истории:

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

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

Я также хотел, чтобы конфигурация сборки TeamCity автоматически обновляла номер версии всех моих сборок. Мне удалось смоделировать эту функциональность, установив Задачи сообщества MSBuild на моем компьютере для разработки и создав конфигурацию развертывания, в которой для изменения номера версии используются цель 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 на сервере сборки, а затем я могу создать системную переменную среды, к которой могут обращаться <WixToolPath>,

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

5

msbuild wix teamcity msbuildcommunitytasks

Источник

user214071 27 окт '10 в 04:06

2 ответа

Решение

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

Интересно, это так?

альтернативный текст

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

0

Источник

user214071 27 окт '10 в 04:11

Другие вопросы по тегам msbuild wix teamcity msbuildcommunitytasks

user7913 27 окт '10 в 04:36 2010-10-27 04:36 · Accepted Answer · 2010-10-27 04:36

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

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

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

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

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

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

При указании путей всегда используйте пути относительно корня вашего решения (checkout dir). Так, например, в этом случае вы просто используете wix30\MSBuildCommunityTasks, TeamCity выполняет msbuild с рабочим каталогом в качестве корня, и, кроме того, не имеет значения, где вы или другие разработчики делают свои проверки - пути все просто относительные.
Вы можете передать параметры в teamcity в msbuild, используя Параметры сборки -> Свойства системы. Так, например, добавить свойство с именем agentHome это имеет значение %system.agent.home.dir% и затем вы можете ссылаться на него в файле msbuild как $(agentHome). Обратите внимание, что если вы также снова вызываете msbuild, как в моем примере выше, вам нужно сделать:
```
  <MSBuild Projects="Project.sln" Properties="agentHome=$(agentHome)" Targets="Build"/>
```
на самом деле передать эту переменную в Project.sln. Я думаю, но я не уверен, что msbuild, работающий с файлом.sln, также передаст все свойства всем отдельным проектам, так что вы можете получить к нему доступ в событии до сборки.

Дополнительное замечание по установщикам (недавно я прошел через то же самое, что и вы): я остановился на WiX 3.0, и, несмотря на то, что у него есть достаточная кривая обучения, он работает хорошо. Мы начали новый поток разработки и начали использовать VS2010 и.NET 4. Что ж, WiX 3.0 не совместим с VS2010, поэтому нам нужен WiX 3.5 (который все еще находится в бета-версии, хотя его состояние сейчас выглядит намного лучше, чем сейчас). было несколько месяцев назад, но они все еще отстают. Такова природа открытого исходного кода, иногда). У меня были некоторые проблемы с установкой WiX 3.0 и 3.5 для совместной установки, но я все-таки понял.

Хотя разочарование по этому поводу (между несовместимостью, нестабильными бета-версиями (из нескольких месяцев назад) и общим медленным прогрессом) действительно отключило меня от WiX (не в обиду парням, работающим над WiX, но я просто хочу установщик и не хочу не хочу вмешиваться. Обратите внимание, они тоже очень расстроены). Добавьте к этому продукт, который мне нужен для следующего, требует гораздо более сложного установщика, и WiX кажется слишком большой работой. Я только что собрал свой установщик, используя http://www.advancedinstaller.com/, и это заняло всего пару дней, и до сих пор работало хорошо (хотя мы сейчас находимся на ранних стадиях разработки, но приступаем к непрерывному развертыванию и тестированию). Цены на AI разумны (мы все еще в пробной версии), но я буду покупать в ближайшие пару дней.

Я уверен, что время, которое я потратил на изучение ИИ, было НАМНОГО меньше, чем я бы потратил на изучение WiX, а затем пытался заставить его делать все, что мне нужно. Немного неизбежно узнать кое-что о том, как работает установщик Windows, но вам не нужно слишком углубляться в это.