Які переваги використання .msi-файлів над звичайними файлами setup.exe?
У мене складається враження, що розгортання простіше на машинах, де користувачі мають мало дозволів, але не впевнені в деталях.
Які функції має msiexec.exe, що робить розгортання простішим, ніж використання сценаріїв setup.exe?
Якісь поради чи підказки при розгортанні .msi-додатків?
Відповіді:
Лише кілька переваг:
Думаю, коли я розгортаю програмне забезпечення в умовах підприємства: розгортання програмного забезпечення через MSI майже приємно. На відміну від цього, я майже завжди відчуваю страх розгортання програмного забезпечення, коли воно знаходиться в іншому контейнері.
Для отримання додаткової інформації про маніпуляції з установками MSI введіть msiexecдіалогове вікно Запуск.
ОНОВЛЕННЯ, липень 2018 року . На стаціонарному потоці доступний надзвичайно стислий підсумок наведеної нижче інформації: Основні переваги MSI ( "executive summary"- різновиди).
Я працював у розробці як менеджер випусків , інженер збірки , розробник налаштувань, а також інженер , що пакує прикладні програми та розгортання у великих корпораціях.
Це огляд найкращих (і найгірших) концептуальних та реальних особливостей MSI. Найбільш поширені проблеми проектування , знайдені в MSI файли представлені як окремий відповідь нижче . Не претендуючи на повноту - насправді просто безладний «мозковий смітник» - призначений як «той матеріал, який не можна знайти в книгах» (можливо, з поважних причин).
Я також хочу запропонувати цю статтю MSDN як добре прочитану: Установник Windows: Переваги та реалізація для системних адміністраторів .
Одним словом, MSI - це і про стандартизацію, і про боротьбу з " запахами розгортання " застарілих технологій інсталятора. Ціла колекція поганих конструкцій архітектури установки, що викликала неодноразові проблеми розгортання.
Загалом MSI забезпечує комплексний, стандартизований фреймворк для інсталятора, який вирішально також включає в себе видалення та вбудовані функції та варіанти безшумного запуску із стандартизованим графічним інтерфейсом, який можна запустити віддалено .
Ці функції лише в значній мірі покращують попередні технології встановлення, які видаляли випадково та безшумно працювали - можливо, найважливіші функції корпоративного розгортання разом із надійним віддаленим управлінням пакетами через Active Directory або спеціальні засоби віддаленого адміністрування, такі як Microsoft SCCM (раніше SMS), IBM Tivoli , CA Unicenter та подібні.
Хтось дублював попередню версію цієї відповіді . Може, швидше прочитати?
MSI активно відлякує застарілі запахи розгортання дизайном. Ці теми обговорюються в наступних розділах нижче, але як короткий перелік, найбільш впізнавані проблеми зі застарілими установниками та старішими технологіями розгортання були:
Список продовжується з великою кількістю інших важливих та визнаних вад розгортання . Очевидно, що у світі корпоративного розгортання ці проблеми виникали найчастіше, і це призвело до " перепакування додатків ", коли застарілий інсталятор захоплений за допомогою технологій сканування дисків та реєстрів , щоб створити MSI-файл, сумісний із стандартами. для надійного розгортання.
Перепакування додатків - це робота спеціаліста і, як правило, призводить до відмінної якості MSI-файлів, якщо це зроблено правильно кваліфікованими людьми, але неможливо перепакувати всі додатки через складну логіку реєстрації, яку необхідно запускати інтерактивно для роботи певних додатків.
У простій мові дійсно важливі переваги MSI є (в довільному порядку):
У реальному світі я знайшов менш вдалі аспекти, включаючи виправлення (дуже складний), MSI-GUI (звичайні функції, досить складні, не вистачає гнучкості), стійкість (може призвести до важкої налагодження повторюваних проблем із самостійним ремонтом ) та загальної складності роботи з технологією для початківців (висока складність основних операцій часом - наприклад, оновлення, графічний інтерфейс та безліч взаємодіючих деталей спричиняють несподівані результати тощо). Швидкість процесу встановлення також значно сповільнилася через збільшення накладних витрат MSI. Див. Кілька порад щодо підвищення швидкості встановлення MSI .
У решті тексту детальніше розглядається деякі з цих аспектів MSI.
Файл MSI - це, по суті, позбавлений бази даних SQL-сервера, що зберігається як COM-структурований файл зберігання - по суті це файлова система у файлі або набір потоків даних. Це тип файлу, який використовується в документах Microsoft Office , і він дає стандартний формат, який можна переглянути і перевірити - величезна проблема для великих корпорацій.
За винятком складених спеціальних дій, файл MSI - це біле поле . Якщо налаштування змінить щось божевільне, наприклад, загальносистемні налаштування мережі, ви можете побачити це за допомогою відповідних інструментів . Помітним винятком є складені спеціальні дії - це чорний ящик . Вимоги логотипу Windows вимагають анотації користувальницьких дій, щоб пояснити, що вони роблять, але це розробники налаштувань часто ігнорують. Сподіваємось, поява Wix покращить це.
Щоб визначити, що такі компільовані спеціальні дії насправді роблять у технічному розумінні, необхідно встановити налаштування . Це навряд чи робилося в моєму досвіді. Частіше звертатися до продавця за інформацією, якщо програмному забезпеченню потрібно затвердження для корпоративного розгортання, і тоді це може бути саме додаток, яке перешкоджає його використанню, а не лише налаштування.
MSI можна налаштувати за допомогою перетворень, щоб відповідати потребам та стандартам організації, в той же час дозволяючи взаємодію з оновленнями встановника постачальника. Ви не змінюєте сам інсталятор, ви створюєте налаштування в окремому файлі, визначеному для організації, який називається перетворення (.mst файл) (фрагмент бази даних або транзакція зміни, якщо вам це потрібно). Ви можете відключити власні дії та взагалі змінити, змінити або відключити що-небудь у програмі встановлення, і ви навіть можете додавати нові речі, включаючи файли. Файли перетворення також іноді використовуються для локалізації файлу MSI на різних мовах. До однієї MSI можна застосувати кілька перетворень, ось зразок із усіченими контурами :
msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Швидке пояснення параметра:
/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.
Windows Installer підтримує вичерпну базу даних усіх елементів, які продукт встановив у реєстрі ( HKEY_CLASSES_ROOT \ Installer - ніколи тут нічого не змінюйте безпосередньо! Це стосується і експертів).
Ви можете достовірно визначити, чи встановлено продукт, які функції були встановлені та які версії файлів були встановлені. Крім того, ви можете отримати список будь-яких патчів, застосованих до базового продукту, якщо такі є. Ви можете отримати доступ до цієї бази даних за допомогою API, що підтримує Win32, COM або .NET, використовуючи різні інструменти сценаріїв, конфігурації та адміністрування, такі як Microsoft SCCM , IBM Tivoli , CA Unicenter тощо ...
MSI також включає принципи "підвищених прав", що дозволяє обмеженому користувачеві запускати інсталяцію продукту, для якого потрібні права адміністратора. Це частина " функції реклами ", яка дозволяє адміністратору робити доступними інсталятори для користувачів, фактично не встановлюючи їх на всіх робочих станціях. Сам інсталятор повинен бути належним чином зареєстрований на декількох основних облікових записах, щоб ця концепція підвищених прав працювала правильно. Користувачі можуть самі запускати інсталяцію продукту, або інсталяція може контролюватися спеціальною системою розгортання, такою як SCCM, Tivoli, Unicenter (зазвичай більші компанії). Не потрібно возитися з тимчасовими правами адміністратора, щоб налагодити роботу що часто трапляється із застарілими інсталяторами.
Комплексна база даних також забезпечує повний огляд встановлених патчів і, отже, можливість виявити вразливості безпеки за допомогою засобів автоматизації та адміністратора.
Файли MSI можна перевірити за допомогою правил перевірки, щоб переконатися, що вони відповідають ряду правил внутрішньої узгодженості (згаданих як ICE). Корпорації можуть створювати власні чеки ДВС для виконання спеціальних корпоративних правил та вимог. Це дуже допомагає із забезпеченням якості. Причина валідації можлива, обумовлена самореференційним характером реляційних баз даних та відповідною схемою бази даних. База даних повинна бути внутрішньо узгодженою та сумісною зі своєю власною схемою щодо зовнішніх ключів, типів даних, ширини поля, версії схеми тощо ... Перевірка також виходить за рамки цього і здатна виявляти справжні логічні недоліки та помилки в пакеті , а не лише вади форматування та типу. Наприклад, він може виявити файли або типи файлів, які розгортаються до помилкових цільових пунктів призначення.
Функція встановлення адміністратора інсталятора Windows забезпечує стандартний спосіб витягнути вихідні файли з MSI ( ось деяка додаткова інформація на цю тему ). Ці вихідні файли можуть бути передані на загальний доступ і бути доступними для всіх робочих станцій для встановлення. Це забезпечує завершення ремонту, видалення та модифікації, не вимагаючи інсталяційного носія на компакт-диску чи подібних. Це особливо важливо для операцій з виправленням та оновленням, які можуть вимагати доступу до вихідних файлів старих версій за особливих обставин.
Існують також загальні проблеми з цією стійкістю. Більшість адміністраторів мають досвід машин із циклічними циклами самостійного ремонту, які, здається, ніколи не зупиняються. Перейдіть за посиланням, щоб отримати довгий список причин цієї проблеми. І знову: ось коротша версія, яку може бути легше читати.
Встановлення файлу MSI, як правило, спричинить створення точки відновлення . Крім того, всі файли та елементи реєстру, замінені або перезаписані під час встановлення, будуть збережені та відновлені, якщо установка не вдасться завершити, що забороняє будь-які зміни, зроблені в користувацьких діях.
Спеціальні дії повинні реалізувати власну підтримку відкату для відповідності логотипу Windows. Це часто ігнорується, але передбачає створення другої спеціальної дії для скасування змін, внесених основною спеціальною дією.
Відкат забезпечує те, що робоча станція залишиться в стабільному стані, навіть якщо встановлення не вдалося. Фактичний сценарій відкоту зберігається в прихованій папці безпосередньо на системному диску - взагалі C: \ Config.Msi , і він містить файли з розширеннями .RBS і .RBF - Відкат файлів сценаріїв . Оскільки ви можете очікувати, що погано розроблені файли MSI можуть порушити вбудовані функції Windows тут, докладнішу інформацію див. У моїй іншій публікації в цій темі.
Є способи відключити відкат і пришвидшити встановлення. Загалом не рекомендується, але ось деталі щодо властивості MSIFASTINSTALL та DISABLEROLLBACK . Це складна функція, але ось короткий огляд відката .
Незважаючи на те, що це дуже складно, виправлення в інсталяторі Windows повністю управляється та реєструється в системі, щоб стан безпеки системи можна було визначити, перевіривши, що було встановлено. Оновлення стандартизовано до кількох основних варіантів, і це дозволяє оновленню проводитись з більш високим ступенем достовірності, за умови, що ви зможете впоратися зі складною складністю. Системи розгортання зможуть повідомити про те, які оновлення не відбулися та чому.
У суб'єктивному перегляді виправлення добре працює для 2 основних застосувань : 1 ) невеликих виправлень для поставлених продуктів та 2 ) виправлення встановленого продукту для виправлення його несправної послідовності видалення, яка не дозволяє видалити продукти при видаленні.
Патч просто механізм доставки для поновлення, вже працює . Як такий, це просто контейнер, який складніший і схильний до помилок, ніж сам оригінал налаштування. Правило номер один для патча полягає в тому, що він повинен бути меншим, ніж початковий MSI, або немає явної причини для доставки патча взагалі. Патч може отримати величезний швидко, якщо він націлений на кілька версій продукту.
Windows Installer пропонує стандартизовану функцію ведення журналу, яка значно перевершує попередні втілення, хоча майже надмірно багатослівна. Файли журналів можна розшифрувати за допомогою аналізаторів журналів , а користувацькі рівні журналів можна використовувати для усунення генерування занадто великих файлів журналів із непотрібною інформацією. Для налагодження вкрай корисний багатослівний журнал. Дивіться у блозі Rob Mensching про гарний ручний спосіб прочитати файл журналу MSI (по суті ви шукаєте " значення 3 " у файлі журналу). Ось зразок командного рядка, який виконує багатослівний журнал:
msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"
Ця стаття Роберта Макдональда з команди інсталятора Windows дуже рекомендується як практичний погляд на журнал MSI: Як інтерпретувати журнали інсталятора Windows .
Не все добре про інсталятор Windows . Його складність часом може бути збитковою , але для великих корпорацій файли MSI значно перевершують будь-яку іншу форму розгортання, якщо враховувати перелік переваг вище.
Для розуміння нової " парадигми " важливо розуміти, що MSI призначений як декларативний опис того, що буде відбуватися в цільовій системі, а не фіксований послідовність подій. Я думаю, ви можете вважати це величезним SQL-висловлюванням . Наприклад, ви оголошуєте елементи, які потрібно додати або змінити у файл INI. По мірі запуску установки відстежуються зміни, і відкат доступний, щоб зміни можна було повернути, якщо установка не вдалася. Це дійсно працює як " автоматичне " і є надійним при правильному виконанні.
Для досвідчених розробників MSI це великий головний біль, коли люди бачать, що люди покладаються на складні, ненадійні спеціальні дії для функціональності, які краще реалізуються за допомогою вбудованих функцій MSI. Значна частка всіх помилок MSI та проблем з відкатом викликається помилковими спеціальними діями, а більшість інших помилок викликані помилковим використанням дизайну MSI (див. Окрему відповідь для переліку поширених помилок MSI).
Окрім вбудованих функцій MSI, тепер все нові та інші користувацькі функціональні можливості доступні через нові рамки, такі як Wix - спосіб XML для компіляції файлів MSI, тому для більшості операцій все менше потребує складної власної логіки дій.
MSI має повну підтримку для злиття налаштувань файлів ini, шрифтів, змінних середовища, ключів реєстру, інформації про COM, ярлики, розширення файлів, умови запуску, встановлення GAC, ODBC тощо ...
WIX йде далі з підтримкою дуже розширених функцій, таких як розширення SQL-сервера, встановлення та конфігурація IIS, лічильники продуктивності, перевірка DirectX та інші завдання, пов’язані з іграми, генерація нативного зображення .NET, COM +, драйвери, правила брандмауера, розширення PowerShell, закриття додатків, управління користувачами, групами, акціями та багато іншого. Дещо залучено до вирішення, але набагато надійніше, ніж ваші власні власні дії.
Для того, щоб спробувати поставити його в перспективі: ці вбудовані і готові рішення будуть зроблені кращими розгортанням наявних експертами , і вони проходять тисячі, десятки тисяч або , можливо , навіть мільйони користувачів (для вбудованого матеріалу в MSI себе). Ви справді думаєте, що можете краще зробити власні власні дії? Використання спеціальної дії має бути рідкісною подією, і вона повинна бути абсолютно необхідною для досягнення чогось унікального для встановленого продукту . І ви також маєте написати належну підтримку відкату, що дуже пов'язано.
Написання власної дії майже завжди є помилкою , але є справжні випадки, коли вам також потрібна гнучкість. Як завжди, важливо добре підібрати свої битви. Спочатку це може бути цікавим завданням, але ви, швидше за все, зіткнетеся з багатьма несподіваними проблемами і витратите багато дорогого часу. Я маю на увазі це дуже серйозно. Я сам написав набір спеціальних дій C ++ для корпоративного використання (щоб усунути схильні до помилок VBScript користувальницькі дії) - це не прогулянка по парку, і хоча кодування може бути не найскладнішим у світі, налагодження та тестування та підключення до фактичного файлу MSI не відрізняється від надзвичайної участі. Деякий час досліджуючи, які готові варіанти доступні, швидше за все, ви заощадите тижні роботи з розробки та отримаєте набагато більшу надійність розгортання.
Дуже важливий моментом є те, що багато конфігураціями додатки повинні відбуватися під час запуску програми , коли у вас є передбачуваний контекст виконання і хороша обробка помилок доступні, а не в установці , яка виконується тільки один раз і показує дуже складне уособлення , секвенування , кондиціювання та виконання складність .
Ваша установка не повинна конфігурувати додаток, вона повинна підготувати програму до конфігурації при першому запуску . Зокрема, ваша установка повинна записувати всі налаштування, які вимагають підвищених прав - запис у HKLM, реєстрація служб, установка на окремі шляхи та всі такі речі, які програма не може самостійно писати з правами користувача.
Якщо ви розробник налаштувань, вам слід запропонувати задіяти кодування послідовності запуску програми замість написання налаштованих дій налаштування . Якщо нічого іншого, щоб не виглядати так, як ви намагаєтесь "передати долар" комусь іншому. У цій послідовності запуску ви можете написати набагато надійніший і перевіряється код, який легше отримати допомогу від персоналу QA для тестування (вони часто не розуміють тестування розгортання, а також тестування додатків).
Основа складності налаштування полягає в тому, що помилки накопичуються (ви керуєте процесом доставки, а не просто швидкою перекомпіляцією), помилки дуже важко налагодити (немає доступу до систем, де трапляються помилки), а також цільової системи держави різняться практично у кожному способі, який можна уявити . Будь ласка, дивіться цю відповідь, щоб більш детально обговорити цю складність та те, як цільові системи можуть насторожувати в шокуючій кількості способів: інсталятор Windows і створення WiX, і складність розгортання (див. Внизу).
Прочитайте це швидке введення WiX для опису нового способу компіляції файлів MSI на основі XML. Текстові вихідні файли забезпечують набагато кращий контроль над джерелами, ніж раніше. Це безкоштовний інструментарій з відкритим кодом, який дуже рекомендується .
NB : Побачте інше місце в потоці для швидкого усунення розповсюджених проблем із дизайном файлів MSI - це дуже неповно, але його варто прочитати. Я не хотів додати це до цієї відповіді, оскільки це не пов'язане на 100%, але для використання в реальному світі це важлива тема.
(вибачте за безсоромне "просування" - це для легкого доступу та пошуку)
Ось лише декілька посилань на теми, які можуть бути корисними системним адміністраторам у їх спробах контролювати розгортання у своїх мережах:
Спеціальні теми щодо:
Концептуальні теми / найкраща практика:
Ця відповідь - це вже незавершене виробництво та приблизний контур. Доповнення, запитання та оновлення вітаються. Цей список аж ніяк не вичерпний. Додайте коментар з інформацією про проблемні пакети.
Я також повинен попередити, що багато файлів MSI містять помилки, іноді серйозні, але навчені пакети програм зможуть виявити це і в більшості випадків усунути проблему. Я додаю це як окрему відповідь, оскільки він по суті відповідає на інше запитання, але я вважаю, що це доречно в одній темі.
Технічні деталі MSI дуже складні . На базовому рівні мова йде про декомпозицію ваших файлів та налаштувань реєстру на компоненти (атомна установка) та функції (вибрані користувачем частини програми для встановлення, наприклад функцію словника). Існує ряд правил найкращої практики для розбиття компонентів, і помилок у файлах MSI тут багато. Ці помилки, як правило, обробляються шляхом стандартизації використання "великих оновлень".
Фактична установка виконується в ряді інсталяційних послідовностей, у деяких з підвищеними правами . Усі ці речі визначені в таблицях баз даних, і саме тут MSI страшенно складно зрозуміти і мати справу з ними. Поширення по послідовності встановлення - це стандартні та власні дії. Стандартні дії розроблені корпорацією Майкрософт та повинні відбуватися (послідовність може іноді змінюватись). Спеціальні дії доступні постачальникам для виконання власної логіки, не охопленої самою MSI. Вони можуть бути у сценарії або у складеному вигляді. Спеціальні дії можуть бути негайними (виконуватись одразу, не слід змінювати систему, але часто це робити) або відкладатись (записується у сценарій виконання, який потім виконується як транзакція і, отже, підтримує відкат).
Типові помилки в MSI є (не в певному порядку - і справді подаються як справжній безлад):
Є низка більш тонких помилок та кілька великих, типових проблем, про які я забуду.
Перегляньте статтю найкращих практик Windows Installer від MSDN .
Використання MSI також полегшує виправлення (файли MSP) та оновлення. MSI використовує концепцію унікальних кодів продуктів та оновлень, що полегшує весь процес.
Деякі системи розгортання (CA Unicenter Software Delivery є одним із прикладів) також можуть зрозуміти особливості MSI особливим чином, що дозволяє їм набагато краще інтегруватися в систему розгортання. Наприклад, ви можете подати MSI в бібліотеку програм системи розгортання, і він автоматично виявить різні функції в продукті і автоматично дозволить набагато більш детальні спеціальні дії (локальна установка, перевірка, ремонт тощо) та ведення журналу.
Самолікування / ремонт також є головним плюсом для MSI.
Крім того, ознайомтеся з відкритим кодом Windows Installer XML , "набір інструментів, який будує інсталяційні пакети Windows з вихідного коду XML. Набір інструментів підтримує середовище командного рядка, яке розробники можуть інтегрувати в свої процеси збирання для створення пакетів налаштувань MSI та MSM". Це використовується в MS для підготовки декількох його основних програмних пакетів.
Ви можете робити перетворення - теоретично ви можете багато чого налаштувати, якщо програма була упакована належним чином постачальником, ви можете зробити повністю автоматизоване розгортання без будь-якої взаємодії з кінцевим користувачем - що дуже корисно, коли ви хочете стандартизувати своє середовище Windows і мати більше, ніж кілька комп'ютерів.
щоб побачити, що люди роблять з msis [або без нагляду розгортанням], відвідайте, наприклад, цей сайт та його форуми.