Помогите в один шаг собрать все проекты + установщик (.NET + WiX) - PullRequest
2 голосов
/ 26 января 2009

У меня есть события предварительной сборки в установщике, чтобы перестроить проекты с соответствующей конфигурацией и т. Д.

Если я щелкну правой кнопкой мыши на сборке / перестройке проекта WiX (3.0) в visual studio, все будет нормально, но если я попытаюсь запустить MSBuild для файла wixproj, события предварительной сборки вызовут ошибки.

Вместо этого я могу вызвать Candle and Light на wixproj, но он не будет запускать события перед сборкой.

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

Другая проблема заключается в том, что мне нужно ввести самообновляющийся номер версии в WiX из командной строки.

Я планировал использовать просто csproj для обработки номера версии и его обновления, а также просто оболочку MSBuild и Candle and Light, но проблема в том, что я не знаю, как получить доступ к каталогу решений из кода, отличного от жестко закодировать его в

Ответы [ 2 ]

2 голосов
/ 27 января 2009

Нам было проще всего использовать утилиту для редактирования самого проекта и выгрузки всех событий до и после сборки до того, как мы создадим его с помощью нашего автоматического сборщика (в нашем случае VisualBuild ).

Это оставляет нам приятный и сочный процесс сборки, который не зависит от каких-либо неприятных хаков в IDE и дает нам полный контроль над тем, откуда исходит источник и куда идут встроенные компоненты.

0 голосов
/ 09 мая 2013

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

  • Я сохраняю номер версии в командном файле , который просто записывает его в переменную окружения
  • Я создаю свои релизные сборки, запустив пакетный файл , который сначала вызывает пакетный файл "номер версии" (поэтому у меня есть номер версии в переменной среды с именем %VersionNumber%) и затем выполняет файл проекта MSBuild
  • Файл проекта MSBuild создает решение, и я получаю номер версии .exe в файле .csproj , считывая его из переменной среды, если она существует (и затем я использую Задачи сообщества MSBuild для создания AssemblyInfo файла с номером версии в событии перед сборкой)
    Это означает, что .exe имеет версию 0.0 при сборке из Visual Studio, но я в порядке, потому что я создаю все свои выпуски из командного файла.
  • Чтобы создать релейную сборку с настройкой WiX, я запускаю другой пакетный файл , который просто вызывает упомянутый выше пакетный файл "build", а затем вызывает утилиты WiX candle и light для создания фактической настройки.
  • candle использует этот .wxs файл для создания установки, где я снова получаю номер версии из переменной среды: $(env.VersionNumber)
  • последний .msi файл, созданный light, включает в себя номер версии в своем имени файла, потому что я передаю имя файла (включая переменную среды с номером версии) в качестве аргумента: -out release\msi\bitbucket-backup-%VersionNumber%.msi

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

...