Требуются предложения рабочего процесса TeamCity + WiX + MSBuild

Question

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

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

Answer 1

Я вижу некоторую пользу в попытках выполнить задачи сообщества 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 кажется слишком большой работой. Я только что собрал свой установщик, используя AdvancedInstaller , и это заняло всего пару дней, и до сих пор работало хорошо (хотя мы сейчас только на ранних стадиях разработки, но приступаем к непрерывному развертыванию и тестированию). Цены на AI разумны (сейчас мы все еще в пробной версии), но я буду покупать в ближайшие пару дней.

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

Answer 2

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

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

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