Це, мабуть, найболючіша тема при спробах поширити своє дітище на простори інтернету. Існує величезна кількість платних Інсталлер, яких не розглядав взагалі як майбутніх своїх пакетів. Коштують вони багато, а толку як і від безкоштовних. Піратство - погано 🙂.
Є і в wizard стилі - виконуючи послідовно кілька дій, отримуєш готовий установник. Є і скріптованние повністю, весь код треба писати руками: є Inno, є NSIS. Але я пішов іншим шляхом. Поліз в самі нетрі нічого незрозумілого XML і WiX.
У даній статті я опущу багато подробиць по тому що і для чого призначене. Це можна почитати як на офіційній сторінці проекту WiX, так і на форумах. Акцент буде зроблений саме на істотні речі, що вимагають обґрунтування по створенню.
Вид вікна Solidworks з встановленим тестовим аддоном
Передбачається, що WiX встановлений і його шаблон доступний в VS.
Додаємо в рішення майбутній проект инсталлера: Файл-Додати-Створити проект. У менюхе вибираємо Windows Installer XML - Setup Project. Вводимо ім'я майбутнього установника і натискаємо ОК.
Бачимо щось таке: Підходити до Setup будемо за всіма правилами. Та так, щоб потім самому не загубитися у всіх цих рядках. Для початку додамо кілька файлів: ПКМ по проекту Setup - Додати - Створити елемент. Зверніть увагу, що додаємо 2 файли Verifications.wxs і Files.wxs які є «Installer Files» і один файл Variables.wxi який є «Include Files». Розберемося докладніше.Files.wxs - тут буде зберігатися інформація по всіх файлів, які будуть включені в проект установника.
Product.wxs - власне саме опис установника.
Variables.wxi - список змінних проекту. Це знадобиться для того, щоб використовувати одні і ті ж значення (ім'я проекту, версія, шлях до основного файлу) всюди по коду установника.
Verifications.wxs - перевірки, необхідні для установки (версія NET Framework, встановлений Solidworks).
Так само, додамо бібліотеки
Деякі можуть зараз не знадобитися, але просто знайте де вони знаходяться. Наприклад, для створення свого власного діалогового вікна (ну наприклад введення даних про користувача, або будь-які інші реєстраційні дані) необхідна буде бібліотека WixUIExtension.dll Вона йде в стандартній поставці, але по-замовчуванням не додається.
Так як працюємо в одному рішенні, то додамо і вихідний файл з проекту TestInstall. Для цього ПКМ на Referenses, «Додати посилання», вибрати вкладку «Проекти» і там вибрати TestInstall - той самий проект з аддоном до Solidworks.
Приступимо до безпосередньо КОДІНГ.
У файлі Variables видаліть всі рядки і вставте наступні:
У фіналі, зайдемо в властивості проекту та виставимо дефолтний мову:
а так же виключимо показ деяких помилок при компіляції (ICE20; ICE57)
9 thoughts on "Створення інсталятора для аддона за допомогою Visual Studio і WiX. "
Дякуємо. Тестове додаток працює, а ось з робочим поточним не виходить. Що то невірно в head файлі - при установці інсталятора відпрацьовується реєстрація нормально. Всі активні елементи (кнопки) аддона видно, але неактивні. Якщо потім на встановлену бібліотеку нацькувати regasm ручками - то все стає добре ...
Другий день шукаю де собака зарита, поки не знайшов 🙂
heat - НЕ heaD! )))
Це якийсь збирач даних по яких нацькував на нього файлу аддона. Реєстрація аддона - це фактично запис необхідних інтерфейсів до реєстру + додаткова інфа.
Цілком ймовірно, що в робочому проекті щось генерітся по ходу. Тоді установник просто не може заздалегідь знати про це. Це один варіант. Інший - що як то не так згенерувати файл heat. Ну і третій - ви накриваєте збірку якихось протектором. Якщо останній випадок, то спочатку зробіть зі звичайною версією файл heat, ці дані запишіть в установник, а потім вже накривайте.
А хоча стоп «Всі активні елементи (кнопки) аддона видно, але неактивні.» - це типовий випадок, коли код всередині валиться без викиду помилки користувачеві у вигляді MessageBox-а. Порада така, обернути критичні області в try-catch з виловом типу такого:
Не, прибирання не допомагає, струму гірше робить. Можливо потрібно додати ключ -svb6. Після цього з'являється опис цього класу. Однак, до реєстру, в HKEY_LOCAL_MACHINE \ SOFTWARE \ Classes \ CLSID \ додаються шляху до розташування вихідного файлу (в дебаге), а не того, який інсталятор виклав в C: \ Program Files
Ручний виклик регасм робить нові ключі з правильним шляхом файлу.
Але вже все, очі закриваються ... завтра ...
ЗИ.
І до речі, це не абстрактний ActiveX який мені придумалося зробити, а панелька, яка впроваджується в праву палітру панелей соліди (там де текстури, зовнішні види. Тулбокс і т.д.). Панелі інструментів зверху не завжди зручні, а тут купа місця ...
Не, і не в шляхах справу. Не зміг знайти що такого додає regasm, чого heat не робить, навіть розглядаючи рег-файл, який виходить після виклику першого. Упарився і прописав CustomAction на ручний виклик regasm. Так - все оре.