Каковы риски создания моего собственного кроссплатформенного установщика (Win + OSX)?

У меня довольно сложный процесс сборки с участием разных каталогов (для плагинов); в настоящее время я использую NSIS в Windows и PackageMaker в OS X, но у меня есть проблемы с их улучшением, так как мой процесс установки / удаления со временем усложняется.

Чем больше я изучаю это, тем больше я чувствую, что должен написать свой собственный кроссплатформенный установщик с кроссплатформенным графическим интерфейсом, например wxWidgets (я использовал его раньше), и скопировать себе нужные файлы в нужные каталоги, потому что я не могу их найти. хороший межплатформенный установщик программного обеспечения ИЛИ даже программно настраиваемые установщики программного обеспечения для обеих платформ.

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

Заранее спасибо!


macos windows installation nsis packagemaker
person ttoinou    schedule 16.04.2019    source источник
comment
Может быть, быстро прочтите.   -  person Stein Åsmul    schedule 16.04.2019
comment
Спасибо! Мне не нужен громоздкий установщик на основе Java, а также автоматическое развертывание (я хочу, чтобы пользовательский интерфейс позволял включать / отключать некоторые компоненты, обнаруживать старые версии, отображать журнал изменений и т. Д.). Другое программное обеспечение не кажется программно настраиваемым или очень дорогим.   -  person ttoinou    schedule 16.04.2019

Ответы (1)


arrow_upward
0
arrow_downward

Кто-нибудь знает, чего добиться труднее всего?

Самое сложное в установщиках - это не графический интерфейс мастера, а интеграция с ОС. Эта интеграция кардинально отличается в зависимости от ОС.

В Windows вам нужно использовать MSI. NSIS не очень хорошо справляется, MSI позволяет исправлять / изменять функции, по умолчанию MSI может обновлять данные, даже если старая версия все еще работает (и она продолжает работать при замене), некоторые библиотеки MS поставляются как модули слияния * .MSM ... Кстати, я обычно использую для этого WIX.

Точно так же в Debian и Ubuntu Linux вам нужно создавать пакеты .deb. Даже если вы делаете установщик с графическим интерфейсом. Они также поддерживают восстановление и обновления, управление версиями и зависимости, но делают это совершенно иначе, чем MSI.

У меня нет большого опыта работы с OSX, но я думаю, что у нее есть другая инфраструктура установщика, реализованная в ОС.

person Soonts    schedule 16.04.2019
comment
Спасибо за ответ, но какой риск, если я не буду выполнять интеграцию с ОС (кроме регистрации деинсталлятора в списке установленных приложений Windows)? Копирую только нужные мне файлы - person ttoinou; 16.04.2019
comment
Если ваше приложение не использует какие-либо внешние компоненты, такие как .NET framework или библиотеки времени выполнения VC ++, NSIS, вероятно, в порядке. Я тоже его использовал. С MSI легче управлять этими зависимостями, проще выполнять автоматическую установку, а также лучше работает обновление. - person Soonts; 16.04.2019
comment
Да, я бы хотел упаковать VC ++ 2017Redist, но если это отдельный .exe, я прошу пользователей запустить, тогда это еще не конец света - person ttoinou; 17.04.2019
comment
Это не так, но с модулем слияния MSM для VCRedist пользовательский интерфейс лучше. Устанавливается автоматически основным установщиком, единым индикатором выполнения, откатом при ошибках. Также установлена ​​зависимость, пользователи получат предупреждение при попытке удалить VCRedist о том, что он используется вашим приложением. - person Soonts; 17.04.2019
comment
Спасибо за информацию! - person ttoinou; 17.04.2019
comment
Вероятно, я мог бы сделать это самостоятельно: blogs.msdn.microsoft.com/astebner/2010/10/20/ - person ttoinou; 18.04.2019