ClickOnce, WPF, MSBuild и несколько окружений — II

Подготовка к трансформации проекта

Чтобы у нас все получилось, потребуется скачать и установить на машине билд-сервера MSBuild Community Tasks Project, так же советую его поставить и на своей машине, для экспериментов и быстрого доступа к файлу справки. Данный пакет позволяет обращаться к реализации массы наиболее часто востребованных функций во время преобразований в процессе построения приложения с помощью MSBuild. Пакет устанавливается по адресу C:\Program Files (x86)\MSBuild\MSBuildCommunityTasks, это чтобы вы быстро нашли справку по новым доступным задачам.

Канон

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

MSBuild при сборке проекта руководствуется сложным набором правил и указаний, которые мы можем модифицировать или дополнять. Основные указания о сборке проекта содержаться в файле Common.CSharp.targets – который менять каким-либо образом крайне не рекомендуется. По принятому соглашению, все дополнения и расширения, касающиеся построения приложений должны иметь расширение .targets, по сути это XML файл.

Подробнее

ClickOnce, WPF, MSBuild и несколько окружений — I

Или сказ о том, как сделать публикацию приложений в один клик на разные окружения для тестирования разных версий приложений на WPF с помощью ClickOnce и TFS 2010.

На днях мне нужно было решить следующую, на мой взгляд, достаточно распространенную задачу, по размещению двух версий приложения. Одна версия QA – для тестирования текущих наработок, то, что реализуется каждый день: UI, логика, исправление мелких ошибок. Другая версия – Prod – для тестирования общих алгоритмов на реальных данных. В целом стандартная практика в мире разработки.

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

Диспозиция

В качестве исходных данных мы примем то, что у вас есть работоспособное приложение на WPF (для WinForm будет то же самое, но WPF более сложный случай), которое можно локально собрать в нескольких конфигурациях: Dev, QA(Cons), Prod.  Не важно, что именно у вас зависит от конфигурации, в общем случае, скорее всего это строки соединения с базой данных, оптимизация и логирование ошибок/действий пользователя.

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

И еще у вас успешно настроена на публикацию из VisualStudio с помощью ClickOnce хотя бы одна конфигурация приложения.

Еще раз, у нас есть:

  • WPF приложение
  • У приложения несколько рабочих конфигураций
  • Все конфигурации компилируются на билд-сервере (TFS)
  • Хотя бы одна конфигурация публикуется с помощью ClickOnce из VisualStudio

Проблема

В описанной системе все хорошо, все собирается на TFS, в разных конфигурациях. Т.е. я могу в любой момент получить рабочее приложение с любой конфигурацией. Однако распространение для пользователей идет только по линии QA. До определенного этапа разработки этого хватало. Теперь же надо опубликовать Prod, при этом на одном компьютере должны одновременно стоять как QA версия, так и Prod.
Проблем с физической публикацией не возникло. Т.е. на сервер складываются разные версии приложения, но при установке пользователю, одна версия затирает другую.

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

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

Подробнее