Comments 12
Отмечу, что существует проект Wix#, который позволяет описывать инсталлятор на C# и генерировать XML для Wix
var project = new Project("MyProduct",
new Dir(@"%ProgramFiles%\My Company\My Product",
new File(@"Files\Docs\Manual.txt"),
new File(@"Files\Bin\MyApp.exe")));
project.GUID = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
Compiler.BuildMsi(project);На мой неискушенный разметкой взгляд, это читается и пишется гораздо приятнее, плюс можно втыкать любые костыли расширения в виде произвольного кода на шарпе.
Не могу не согласиться - код с использованием Wix# действительно выглядит гораздо более удобочитаемым, да и описывать инсталляционные пакеты с его использованием гораздо проще. Однако, главная проблема Wix# его недостаточно широкая распространенность, что создает риски при разработке крупных проектов, требующих длительной поддержки и глубокой кастомизации процесса установки. К тому же, зачастую, заказчик имеет собственные наработки и решения, которые должны быть интегрированы в конечный продукт, что вынуждает ориентироваться на существующий стек.
Разработчики инсталляторов - это такая закрытая ложа вроде масонов, только в масоны хотят все, а сюда никто не хочет. Однако хоть ниша и узкая, но дело нужное. Во времена оные, помню, все еще осложнялось тем, что в документации на сам Window Installer была невнятица на тему взаимосвязей таблиц, действий, правильного порядка этих действий, переменных и уже не вспомню чего. Тогдашний InstallShield местами помогал, а местами, наоборот, мешал.
Вооот! Про масонов прямо в точку!
Да и сейчас, на самом деле, ситуация с документацией к Windows Installer и инструментами, которые должны упростить жизнь, не сильно поменялась. Очень доставляют ситуации, когда нужно добавить кастомный скрипт, который должен быть запущен на определенном этапе работы инсталлятора с возможностью откатить внесённые изменения. А попытки завязать логику на результате выполнения какого-нибудь CustomAction могут отправить разработчика с низким содержанием стали в нервных клетках на Канатчикову дачу.
А нет ли у вас, случайно, опыта в переводе wix инсталлера с старого .net framework, на новый .net 6?
Интересует аспект с "фрейморк-зависимой" инсталяцией, вроде бы wix еще не умеет проверять наличие новых .net на машине
Добрый день!
По большому счету, для проверки установленных пакетов .net Wix и не нужен какой-то специализированный функционал. Проверку можно осуществить путем поиска по реестру соответствующего ключа (используйте RegistrySearch - https://wixtoolset.org/documentation/manual/v3/xsd/wix/registrysearch.html). Далее, в зависимости от результата поиска можете или выкинуть пользователю предупреждение о необходимости установки соотвествующего пакета, или отменить установку.
Если же стоит задача минимизации участия пользователя в процессе установки, то наилучшим вариантом будет использование проекта типа Wix Bootstrapper, который позволяет произвести установку нескольких пакетов: основной .msi с вашим продуктом + сопутствующее окружение, которое также может быть установлено по условию.
В целом, Wix в комплекте поставки имеет инструменты для проверки и установки .net framework (NetFx), но в 3-й версии они не работают с .net core, а в 4-й только до .net core 3.1 (но я бы не рекомендовал вести разработку с использованием Wix v4 ввиду слабой документации и отсутствия широкого пользовательского опыта), поэтому наиболее оптимальный вариант - это работа с Bootstrapper.
Inno Setup из списка уберите. Он бесплатный, Open source и не создает msi.
wixproj - это обычный сценарий MSBuild со всеми вытекающими.
Когда лет 10 назад начинал делать msi-установщик никакой куцести документации не замечал. Документация как документация.
DiskPrompt для Media необязательный атрибут.
Добрый день!
Спасибо за ваш комментарий и внимательное прочтение статьи.
На счет Inno Setup я не писал, что он позволяет создавать msi файлы, но, пожалуй, об этом следовало указать более явно.
На счет, wixproj - да, это обычный сценарий MSBuild со всеми вытекающими.
По поводу документации к Wix. Вопрос, конечно, дискуссионный, но официальная документация не описывает best practices, не содержит примеры готовых инсталляторов, а читая описание к тегу не всегда очевидно куда его необходимо вставить. Ну и, на мой взгляд, документация написана для людей, которые знакомы с подсистемой Windows Installer - не думаю, что среди людей, впервые столкнуышихся с технологией Wix, таких большинство.
На счет DiskPromt - еще раз отдельное спасибо за ваш комментарий! Когда работал над созданием своего инсталлятора столкнулся с проблемой, что проект wix не собирался, когда я не указывал этот атрибут. И с тех пор был уверен, что DiskPromt является обязательным (тем более, что практически во всех примерах, которые мне попадались в сети у Media был описан DiskPromt). Но, после вашего комментария специально во всех проектах проверил, что будет, если его удалить - о чудо, все они собрались корректно и произвели установку/удаление продуктов корректно!
Чтобы не вводить читателей в заблуждение, внес коррективы в статью.
Спасибо!
Wix toolset: не так страшен черт, как Windows installer