Большинство инсталляторов создаётся при помощи разных утилит (WiX, Inno Setup, Install Shield и т.д.). Меня интересует вопрос создания инсталлятора с собственным UI, как это сделано, например, у Kaspersky Anti-Virus и у Visual Studio. Возможно ли использование .NET Framework в таких делах или потребуется чистый C++? Не будет ли ни у кого ссылок на пояснения того, что конкретно должен делать инсталлятор?
Отслеживать
28.4k 19 19 золотых знаков 54 54 серебряных знака 130 130 бронзовых знаков
задан 28 янв 2018 в 10:17
1,157 1 1 золотой знак 14 14 серебряных знаков 38 38 бронзовых знаков
Если инсталятор предназначен для ОС на которых есть дотНет — то можно и писать на шарпе. Другое дело, версии дотнета из коробки везде разные, на вин7 к примеру по моему 3.5 по умолчанию. А делать инсталятор должен ровно то, что нужно разработчику. Копировать файлы, создавать ярлыки, писать в реестр.
28 янв 2018 в 10:31
Я так не пробовал, но возможно, вам нужно скомпилировать инсталлятор как msi-файл. В вашей программе запускать его в тихом режиме и перехватывать его вывод.
Создания установщика для своей разработки в Visual Studio #6
28 янв 2018 в 11:42
Посмотрите stackoverflow.com/a/2335950/1988244 — там в ответе и комментах есть ссылки на примеры embedded ui. И еще где-то в стандартных примерах WIX есть пример с ui на WPF.
– user177221
28 янв 2018 в 13:29
– user177221
28 янв 2018 в 13:50
Умоляю, пожалуйста, не надо ещё одного велосипеда. Я весь этот долбанный зоопарк поддерживаю и я уже затрахался. Хочешь инсталлер — раскури тот, который на выходе отдаст валидный msi .
28 янв 2018 в 21:18
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
Для создания кастомного UI через WIX можно использовать Burn / BootstrapperApplication — стандартный способ для создания оберток поверх MSI.
Пример для WPF есть в src-пакете WiX, в папке srcSetupWixBA . Прикручивается (судя по документации) примерно так:
- Собирается DLL с UI (WixBA из примеров)
- В bundle.wxs (есть в стандартном шаблоне WiX для VS) добавляется
Сам по себе кастомный UI — это просто класс-наследник BootstrapperApplication в сборке, отмеченной атрибутом BootstrapperApplicationAttribute .
Более подробные примеры:
- Custom WiX Burn bootstrapper user interface?
- Creating a custom UI installer with WIX Burn Bootstrapper
- Author Bootstrapper Application for a Bundle
Альтернативный вариант без burn / .NET, который (в теории) можно прикрутить к любому msi-инсталлятору — прописывание EmbeddedUI DLL в таблице MsiEmbeddedUI. Базовый пример и требования к dll расписаны в MSDN, Using an Embedded UI.
Отслеживать
ответ дан 28 янв 2018 в 15:40
user177221 user177221
Комментарии не предназначены для расширенной дискуссии; разговор перемещён в чат.
30 янв 2018 в 15:45
Создавать инсталлятор полностью с нуля (без использования модели Windows Installer), только ради красивого интерфейса, наверное не стоит. Установить приложение легко, сложнее корректно его удалить во всех ситуациях, не оставив мусора и не запоров настройки системы — особенно если программа меняет ассоциации файлов, устанавливает свои расширения проводника, регистрирует COM-объекты и т.п.
Как создать свой установщик?
Инсталлятор в Windows Installer состоит из двух частей:
- Файл *.MSI — это база данных, которая содержит информацию о структуре приложения, его файлы (либо информацию, где они лежат, если они не встроенные), перечень изменений в реестре и др. Его можно создавать с помощью стандартной утилиты Orca.exe из Windows SDK или с помощью какой-либо сторонней утилиты.
- Приложение-обертка (setup.exe), которое проверяет наличие необходимой версии Windows Installer, при необходимости предлагает пользователю ее установить, а затем запускает установку самой программы с помощью функции MsiInstallProduct.
Они могут по разному между собой соотноситься (MSI внутри EXE, MSI в папке рядом с EXE, EXE скачивает MSI с интернета), но суть одинакова.
Приложение-обертка может использовать либо стандартный интерфейс Windows Installer, либо отключить его и зарегистрировать свой (вызовами MsiSetInternalUI / MsiSetExternalUI перед MsiInstallProduct ). Можно использовать любую GUI-технологию для создания своего интерфейса, а затем передать параметры в MSI с помощью строки свойств типа TARGETDIR=»C:Program FilesMyApp» ADDLOCAL=»Feature1, Feature2″ .
См. данные разделы документации:
Источник: ru.stackoverflow.com
Создание файла Установщика приложений вручную
В этой статье показано, как вручную создать файл установщика приложений, который определяет связанный набор с возможностью автоматического обновления и восстановления. Связанный набор — это не один объект, а сочетание основного и дополнительных пакетов.
Чтобы получить возможность установить связанный набор как один объект, необходимо указать основной и дополнительные пакеты как один объект. Для этого необходимо создать XML-файл с расширением APPINSTALLER для определения связанного набора. Установщик приложений использует файл *.appinstaller и позволяет пользователю устанавливать все определенные пакеты одним щелчком мыши.
Во время развертывания файл установщика приложений будет следующим:
- Пакет приложения Windows, на который ссылается URI атрибут элемента MainPackage>, Publisher проверяет Name и Version атрибуты целевого < пакета приложения Windows. Если элемент Package/Identity в манифесте пакета приложения Windows не совпадает, установка завершится ошибкой.
- Создайте ссылку на URI обновления и восстановления для семейства пакетов.
Инструкции по созданию файла Установщика приложений.
Чтобы распространить связанный набор в виде одной сущности, необходимо создать файл установщика приложений, содержащий элементы, необходимые для этой схемы установщика приложений.
- Создайте *. Файл AppInstaller.
- Укажите атрибуты файла установщика приложений.
- Укажите основной пакет приложения для Windows.
- Укажите связанный набор необязательных пакетов.
- Укажите пакет платформы приложений Windows для зависимостей.
- Укажите пути URI обновления.
- Укажите пути URI восстановления.
- Укажите параметры обновления.
Пример файла установщика приложений
Выполнив описанные выше действия, вы успешно создали файл установщика приложений, который выглядит следующим образом:
http://mywebservice.azurewebsites.net/appset.appinstaller http://mywebservice2.azurewebsites.net/appset.appinstaller http://mywebservice.azurewebsites.net/appset.appinstaller http://mywebservice2.azurewebsites.net/appset.appinstaller
Шаг 1. Создание файла *.appinstaller
С помощью текстового редактора (Notepad.exe) создайте файл с расширением *. AppInstaller
Руководство.
- Откройте меню «Пуск».
- Введите следующее: notepad.exe .
- Откройте меню «Файл «.
- Выберите «Сохранить как » в раскрывающемся меню.
Шаг 2. Добавление базового шаблона
AppInstaller Добавьте элемент в файл установщика приложений, указав версию, путь и сетевое расположение файла установщика приложений. Сведения в элементе AppInstaller будут использоваться при установке связанных приложений Для Windows.
xmlns | Пространство имен XML |
Версия | Версия файла установщика приложений в нотации с четырехточием (1.0.0.0). |
URI | Путь URI к текущему файлу установщика приложений, доступный устройством. |
Руководство.
- Откройте файл, созданный на шаге 1.
- Скопируйте следующее XML-содержимое в *. Файл AppInstaller .
Шаг 3. Добавление сведений об основном пакете
Он используется для идентификации основного приложения Для Windows, которое будет установлено с помощью файла установщика приложений. Он используется, если установщик приложений Для Windows является *.msix или *.appx. Используйте, когда установщик приложений Для Windows является пакетным установщиком приложений Для Windows с расширением *.msixbundle или *.appxbundle.
Имя | Имя основного приложения, которое распространяется через файл установщика приложений. Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Name . |
Publisher | Каноническое имя сертификата издателя, используемого для подписи основного установщика приложений Для Windows. Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Publisher . |
Версия | Версия основного установщика приложений Для Windows в нотации с четырехточием (1.0.0.0). Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Version . |
ProcessorArchitecture | Архитектура, в которую устанавливается основной установщик приложений Для Windows. |
URI | Путь URI к основному установочному носителю приложения Для Windows. |
Сведения в атрибуте или должны совпадать с элементом Package/Identity в манифесте пакета приложений или пакета приложения соответственно.
Установщик приложений Для Windows
Если основной пакет приложения является MSIX-файлом или APPX-файлом, используйте его, как показано ниже. Не забудьте включить ProcessorArchitecture, так как он является обязательным для пакетов, не относящихся к пакету.
Установщик пакета приложений Для Windows
Если основной пакет приложения является MSIXBUNDLE или APPXBUNDLE или файл, используйте вместо этого файл, как показано ниже. Для пакетов не требуется ProcessorArchitecture.
Шаг 4. Добавление дополнительных пакетов
Как и атрибут основного пакета приложений, если дополнительный пакет может являться пакетом приложения или пакетом приложений, дочерний элемент с атрибутом должен являться или . Сведения о пакете в дочерних элементах должны соответствовать элементу идентификатора в манифеста пакета приложений или пакета приложения.
Имя | Имя необязательного приложения, которое распространяется через файл установщика приложений. Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Name . |
Publisher | Каноническое имя сертификата издателя, используемого для подписи необязательного установщика приложений Для Windows. Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Publisher . |
Версия | Версия необязательного установщика приложений Для Windows в нотации с четырехточием (1.0.0.0). Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Version . |
ProcessorArchitecture | Архитектура, в которую устанавливается дополнительный установщик приложений Для Windows. |
URI | Путь URI к основному установочному носителю приложения Для Windows. |
Шаг 5. Добавление зависимостей
В элементе зависимостей можно указать требуемые пакеты платформы для основного пакета или дополнительных пакетов.
Имя | Имя приложения зависимостей, которое распространяется через файл установщика приложений. Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Name . |
Publisher | Каноническое имя сертификата издателя, используемого для подписи установщика приложения для Windows зависимостей. Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Publisher |
Версия | Версия установщика приложения для Windows зависимостей в четырехточии (1.0.0.0). Это можно найти, выполнив следующий командлет PowerShell: $(Get-AppxPackage [AppName]).Version |
ProcessorArchitecture | Архитектура, на которую устанавливается установщик приложений для Windows зависимостей. |
URI | Путь URI к установочному носителю приложения для Windows зависимостей. |
Шаг 6. Добавление параметра обновления
В файле Установщика приложений можно также указать параметр обновления, чтобы связанные наборы автоматически обновлялись при публикации нового файла Установщика приложений. — это необязательный элемент. В параметр OnLaunch указывает, что проверки обновлений должны выполняться при запуске приложения, а HoursBetweenUpdateChecks=»12″ указывает, что проверка обновления должна выполняться каждые 12 часов. Если параметр HoursBetweenUpdateChecks не задан, интервал проверки обновлений по умолчанию — 24 часа. Дополнительные типы обновлений, например фоновые обновления, можно найти в схеме параметров обновления; Дополнительные типы обновлений при запуске, такие как обновления с запросом, можно найти в схеме OnLaunch.
HoursBetweenUpdateChecks | Определяет минимальный пробел в проверках обновления приложений Windows. |
UpdateBlocksActivation | Определяет интерфейс при проверке обновления приложения. |
ShowPrompt | Определяет, отображается ли окно при установке обновлений и проверка обновлений. |
ForceUpdateFromAnyVersion | Указывает, что следующая версия приложения может быть более новой или более старой. Если значение равно True, будет установлено только для обоих версий, если значение false (по умолчанию), будут установлены только новые версии. |
true
Шаг 7. Добавление параметров автоматического обновления
Следующие параметры доступны только при использовании схемы 2021 в сборке программы предварительной оценки Windows Windows 10.
Приложения Windows, установленные с файлом установщика приложений, по умолчанию обновляют свое приложение Для Windows из URI установщика приложений, придерживаясь конфигураций, заданных на предыдущем шаге. URI обновления, настроенные на этом шаге, будут использоваться в качестве резервных URI, которые можно использовать, если исходный URI установщика приложений больше недоступен. Для любого приложения Для Windows можно настроить не более 10 URI обновления.
Универсальный код ресурса (URI) обновления должен быть предназначен для файлов установщика приложений.
Эти параметры работают только в том случае, если схема настроена как 2021 или более позднюю.
https://www.contoso.com/Installers/MainApp.AppInstaller \ServerNameShareInstallersMainApp.AppInstaller
Шаг 8. Добавление параметров автоматического восстановления
Следующие параметры доступны только при использовании схемы 2021 в сборке программы предварительной оценки Windows Windows 10.
Приложения Windows, установленные на устройстве, могут поддерживать автоматическое восстановление приложения Windows, когда оно было изменено. Исходный установщик, который будет использоваться для восстановления приложения Для Windows, можно настроить с помощью свойства. Приложение Windows попытается восстановить себя на основе URI установщика приложений, если он недоступен, то приложение Windows будет использовать URI восстановления для идентификации источника восстановления. Для любого приложения Для Windows можно настроить не более 10 URI восстановления.
URI восстановления может быть предназначен для файлов приложения Windows или установщика приложений. Этот параметр не требует установки приложения Windows с помощью файла установщика приложений.
Полные сведения о схеме XML см. в разделе Справочник по файлу Установщика приложений.
Тип файла установщика приложений является новым в Windows 10 версии 1709 (Windows 10 Fall Creators Update). Развертывание приложений Windows 10 с помощью файла установщика приложений в предыдущих версиях Windows 10 отсутствует. Элемент HoursBetweenUpdateChecks доступен начиная с Windows 10 версии 1803.
Источник: learn.microsoft.com
Сборка и распространение Python проекта
В данной статье мы рассмотрим, как упаковать свое приложение в exe файл и создать установщик программы для windows.
Python применяется для решения множества задач в различных областях деятельности. Разработав программу на Python встает вопрос ее дальнейшего распространения до конечного пользователя. Чтобы вашим приложением было удобно пользоваться, необходимо осуществить сборку кода в exe файл. Для сборки кода в exe файл необходимо воспользоваться библиотекой PyInstaller, и программой Inno Setup.
Для примера осуществим сборку проекта калькулятор. Интерфейс написан на библиотеке PySide2.
Сборка проекта в exe файл
1) Устанавливаем необходимые библиотеки через командную строку:
pip install pyinstaller
2) Далее необходимо запустить командную строку в папке с проектом. Для этого запускаем командную строку и выполняем команду:
cd «Полный путь к папке с проектом»
3) В командной строке выполняем следующую команду:
pyinstaller calculator.py
Результат выполнения команды: В папке с проектом появятся папка build со служебной информацией в которой записаны логи вместе с рабочими файлами. В дальнейшем папка build нам не пригодится. Папка dist с нашим проектом.
Открыв папку dist мы увидим файл calculator.exe, а также все связанные с проектом библиотеки и модули необходимые для работы. Теперь наш проект можно запускать на любом компьютере. Однако, есть несколько нюансов:
- при запуске проекта будет запускаться и консоль;
- в папке с проектом, находятся множество модулей, которые можно случайно удалить и тем самым повредить программу;
- у программы нет иконки.
3) Создадим исполняемый файл, который будет запускаться без консоли, будет упакован в один исполняемый файл. PyInstaller может создать однофайловую сборку, то есть один EXE-файл, который содержит весь код, библиотеки и файлы данных в одном. Также добавим иконку к нашему приложению.
Для этого запускаем командную строку в нашей папке и выполняем команду:
pyinstaller —onefile —icon=calc.ico —noconsole calculator.py
Флаг —onefile — показывает, что проект надо собрать в один файл exe, —icon принимает абсолютный или относительный путь к иконке приложения, —noconsole — сообщает, что программу необходимо запускать без консоли.
Результат выполнения команды в папке с проектом мы найдем файл calculator.exe:
Стоит заметить, что, хотя сборку из одного файла легче распространять, она выполняется медленнее, чем обычное приложение.