Создание установщиков MSI для служб Windows с настраиваемыми именами служб с помощью MSBuild - PullRequest
Новая
       42

Создание установщиков MSI для служб Windows с настраиваемыми именами служб с помощью MSBuild

1 голос
/ 06 апреля 2011

Привет, Я пытаюсь понять, как реализовать следующий сценарий с MSBuild и Visual Studio 2010.

  1. У меня есть набор из трех служб, которые я хотел бы установить. Каталог установки по умолчанию должен отличаться в зависимости от сборки (qa, uat и production).
  2. Чтобы добавить еще одну забавную мелочь ко всему этому, иногда среда uat может быть запущена в эксплуатацию, когда мы находимся в пиковой нагрузке, поэтому каждая сборка службы должна иметь свое имя. Это случается не часто, но оно есть в списке. Как настроить установщики службы для динамического изменения имени службы?
  3. Я хочу иметь возможность создавать установщики MSI для служб (для любой текущей сборки). У меня есть существующий и обширный скрипт MSBuild для различных веб-сайтов, с которыми я уже работаю, но я немного не уверен, как продолжить работу сервисов.
  4. Очевидно, что файлы конфигурации для каждой сборки службы будут разными.
  5. Я добавил классы установщика для каждой из служб.

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

1 Ответ

3 голосов
/ 19 июля 2011

Может быть проще заархивировать служебные биты во время сборки и развернуть их с помощью MSBuild, используя задачи расширения MSBuild.Вы бы поместили данные конфигурации вашей среды в файл msbuild .properties (mylocal.service.properites, qp.service.properties, uat.service.properties и т. Д.).Это способ развертывания служб.

примечание: файл свойств будет содержать такие вещи, как строка подключения к базе данных, TargetDir, ServiceName и т. Д.

Имена служб указываются во время установки, см. 'Sc',' installutil 'или фрагмент задачи пакета расширений WindowsService ниже.Это означает, что вы можете скопировать одни и те же служебные биты из нескольких каталогов и установить каждый с уникальным именем (например, QAService, UATService, PRODService).

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

<WindowsService TaskAction="Install"
                ServiceName="$(ServiceName)"
                MachineName="$(TargetServer)"
                ServicePath="$(FullServicePath)" 
                User="$(User)" />

Подход аналогичен для установщиков MSI.Я предполагаю, что ваши установщики запрашивают все необходимые данные конфигурации среды ... Все [достойные] установщики имеют способ предоставить ответы из файла, а не использовать установщик в интерактивном режиме.Итак, как и выше, вы создаете один файл ответов для каждой среды и передаете его установщику в командной строке.

Вы не хотите делать это во время сборки ... и, следовательно, имеете отдельный установщик дляПлатформа.Был вынужден сделать это с помощью древней версии установщика wyse.Мне грустно.Требуется один установщик MSI, который можно запустить в любой среде (с учетом файла ответов для конкретной среды).

Подробная информация о командной строке MSI и формате файла ответов зависит от продукта.Какой установочный пакет вы используете?

Cheers, / jhd

...