автоматизация сборки и развертывания для проектов msbuild EXE

Question

Я работаю над некоторыми автоматизированными изменениями сборки и у меня есть несколько вопросов относительно лучшего подхода для сборки / упаковки EXE-приложений.

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

Первый сценарий, который собирает все решение, копирует результат сборки в известное место захвата, переопределяя выходной путь msbuild. Это приводит к тому, что двоичные файлы для всех удаляются в одну и ту же папку (кроме веб-приложений, где каждый проект находится на своем собственном веб-сайте в разделе _PublishedWebsites). Это проблематично, поскольку, когда я создаю установщик для одного проекта EXE, я хочу включить только EXE и зависимости этого EXE-файла. Однако, поскольку все выходные данные проекта находятся в одной папке, неясно, какие нужны отдельному приложению.

Учитывая, что сборка поместила двоичные файлы для всех исполняемых файлов в одну папку, как я могу создать MSI, который включает только двоичные файлы, необходимые для конкретного EXE-файла?

Я использую psake / powershell для скриптов сборки, использую msbuild для компиляции файлов решения. Я использую WixSharp для сборки установщика из приложения командной строки (не CSC).

Answer 1

РЕЗЮМЕ

Поскольку Wix # фактически создает MSI, когда вы «запускаете» .exe-файл, который он создает, и использует инструментарий WiX, вам потребуется вывести исполняемый файл Wix # +, созданный инструментарием WiX, в вашу папку для перетаскивания. Затем убедитесь, что исполняемые файлы инструментария WiX находятся в вашей переменной PATH или в выходной папке, и создайте сценарии (сценарии) Powershell, которые вызывают ваши исполняемые файлы Wix # в папке удаления. Одним простым подходом было бы иметь один проект Wix # для каждого отдельного «установщика продукта» и каждый из этих исполняемых файлов Wix # выводить в вашу папку для дальнейшей обработки / генерации MSI-файлов нижестоящим Powershell (или другим). скрипты.

Я использую Wix #, интегрированный в IDE VS2013, поэтому мой ответ следует интерпретировать в этом контексте. Мой установщик Wix # - это просто один проект из нескольких в моем общем решении.

ПРИМЕР ДЛЯ ОДНОГО ПРОЕКТА WIX # В ВИЗУАЛЬНОМ СТУДИЯХ РЕШЕНИЯ

Так, например, если ваш файл кода проекта Wix # настроен в VS как проект с именем MyWebsiteSetup, а файл кода Wix # - MyWebsiteSetup.cs, ваш исполняемый файл Wix # будет расположен в \ MyWebsiteSetup \ bin \ Debug \ MyWebsiteSetup.exe.

Пусть сборка поместит этот файл MyWebSiteSetup.exe в папку для размещения, наряду с другими файлами, которые Wix # помещает в папку bin \ debug. Затем попросите второй набор сценариев запустить программу MyWebsiteSetup.exe, которая сгенерирует MSI. Я полагаю, что вам может потребоваться, чтобы файлы установочных компонентов, которые требуется для кода Wix, были развернуты и в папке drop, и в ожидаемой структуре папок. Wix #, похоже, помещает все остальные необходимые файлы поддержки в папку bin \ debug, поэтому просто скопировав все файлы из bin \ debug проекта Wix # в папку drop, вы получите то, что вам нужно.

АДАПТАЦИЯ ПРИМЕРА К НЕСКОЛЬКИМ ПРОДУКТАМ (MULTIPLE Wix # PROJECTS)

Теперь ваш вопрос заключался в том, как сделать это для нескольких веб-сайтов, где все файлы размещены в одной папке. Есть несколько способов решения этой проблемы, но я предлагаю создать отдельный проект Wix # в Visual Studio для каждого отдельного продукта и иметь выходные файлы Wix # для каждого из этих проектов, развернутые в папке для размещения вместе с продуктом. файлы. Если ваши отдельные продукты были названы MyWebSiteSetupA, MyWebSiteSetupB и MyWebSiteSetupC, они будут создавать исполняемые файлы MyWebSiteSetupA.exe, MyWebSiteSetupB.exe и MyWebSiteSetupC.exe. Вам просто нужно, чтобы ваш второй набор скриптов вызывал каждый из них по очереди. Каждый из файлов кода Wix # (файлы .cs) для этих проектов, конечно, будет закодирован, чтобы знать, какие файлы ему нужно выбрать при запуске, и когда будет запущен полученный exe-файл, он получит нужные ему файлы, при условии, что вы сделали их доступными там, где ожидаете, и создадите индивидуальные MSI для каждого установщика продукта.

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