MSIX: Пълно ръководство за пакетиране и внедряване на Windows приложения

Ако работите с приложения за Windows и се занимавате с инсталации, актуализации и деинсталации, в крайна сметка ще се сблъскате с MSIX. Този формат на пакетиране е опитът на Microsoft да унифицира и модернизира начина, по който приложенията се инсталират, актуализират и управляват в Windows, както в домашна, така и в бизнес среда.

Въпреки че на пръв поглед може да звучи като просто още един обрат на класическите EXE и MSI формати, MSIX всъщност е пълен с дълбоки промени: леки контейнери, диференциални актуализации, надеждна инсталация, подобрена интеграция с платформата Windows, корпоративна поддръжка с Intune и Configuration Manager и дори разширени сценарии като прикачване на MSIX приложения за виртуални десктопи . Ще разгледаме стъпка по стъпка как да пакетирате и внедрявате с MSIX, какви видове пакети съществуват, как да ги конфигурирате във Visual Studio и какви капани да избягвате, преди да направите прехода.

Какво е MSIX и защо Microsoft инвестира толкова много в него?

MSIX е съвременният формат за пакетиране на приложения за Windows , който Microsoft е проектирал като еволюция (и в средносрочен план заместител) на класическите формати EXE, MSI и AppX. Той съчетава най-доброто от MSI (предсказуема имплементация) и AppX (модел за идентичност на контейнер, почистване и пакет), елиминирайки много от недостатъците на всеки предишен модел.

За разлика от „традиционния“ EXE инсталатор, който може да записва в почти всяка част на системата и да оставя остатъци след деинсталиране, MSIX пакетът функционира като контролиран контейнер с виртуализирана файлова система и регистър . Това позволява на Windows да знае точно кои файлове и ключове принадлежат на приложението, така че да може да го инсталира, актуализира и премахва, без да оставя никакви ненужни файлове.

В допълнение, идентичността на пакета (издател + име + версия) предоставя на приложението достъп до съвременни системни функционалности, които изискват този идентификатор: push известия, фонови задачи, Live Tiles, AI API на устройството, канал за актуализиране чрез Store или частен канал , както и управление от MDM решения като Intune.

MSIX е проектиран и за междуплатформена работа чрез своя SDK: MSIX може да бъде валидиран и разархивиран на други операционни системи (iOS, Android, macOS, Linux или по-стари версии на Windows) благодарение на MSIX SDK с отворен код , което улеснява хибридните сценарии и инструментите за управление.

Видове MSIX пакети и кога да използвате всеки един от тях

Когато говорим за MSIX, не говорим само за един файл. Има няколко вида пакети и свързани формати , които покриват различни нужди от дистрибуция и архитектура.

Пакет с приложения (.msix или .appx)

Пакетът на приложението е най-основният формат: един .msix файл (или .appx в по-стари сценарии), който съдържа приложението и неговите ресурси за специфична архитектура на процесора ( x86 и x64 в Windows 11 ARM , ARM64 и др.).

Ако приложението ви трябва да достигне до множество архитектури, ще трябва да генерирате пакет за всяка от тях: например x64 пакет и x86 пакет. Всеки пакет включва полезния товар на приложението, манифеста, картата на блоковете и сигнатурата , така че Windows да може да го инсталира и да провери неговата цялост.

Пакет или пакет с приложения (.msixbundle / .appxbundle)

Пакетът с приложения, наричан още пакет (bundle), е просто групиране от няколко отделни MSIX пакета , обикновено по един за всяка архитектура. Например, може да имате пакет с три вътрешни пакета: x86, x64 и ARM.

Този подход има няколко ясни предимства: потребителят или администраторът разпространява само един файл, а Windows избира правилната архитектура за целевото устройство по време на инсталацията . Освен това, диференциалните актуализации се използват по-ефективно, тъй като се изтеглят само модифицираните блокове за текущата архитектура.

Качете файл за магазина (.msixupload / .appxupload)

Ако ще публикувате приложението си в Microsoft Store (чрез Центъра за партньори), най-добре е да генерирате специален файл за качване с разширение .msixupload или .appxupload. Този файл може да съдържа един или повече MSIX пакети или пакет, както и допълнителна информация, като например публични символи за отстраняване на неизправности.

Тези символи (.appxsym, по същество компресиран .pdb файл) се използват, така че Центърът за партньори да може да анализира сривовете на приложенията и производителността им в производствена среда . Файловете за качване се генерират автоматично от Visual Studio, когато изберете потока на опаковане, ориентиран към Microsoft Store.

Вътрешна архитектура на MSIX пакет

В рамките на .msix файл откриваме серия от добре дефинирани компоненти, които са от основно значение за Windows, за да може да обработва жизнения цикъл на приложението с гаранции.

От една страна, има кодът на приложението и файловете с ресурси (двоични файлове, DLL файлове, графични ресурси и др.), които съставляват функционалното натоварване. Наред с тях са включени и няколко ключови файла:

• AppxManifest.xml: манифестът на пакета, където се декларират идентичността на приложението, издателят, версията, необходимите възможности, входните точки, файловите асоциации, персонализираните протоколи, визуалните ресурси и др.
• AppxBlockMap.xmlXML карта, която разделя всички файлове в пакета на блокове от 64 KB и изчислява криптографски хеш за всеки един. Това е основата на диференциални актуализации и целостност на данните.
• AppxSignature p7xЦифровият подпис на пакета. Всеки MSIX пакет трябва да бъде подписан; Windows използва този подпис заедно с блоковата карта, за да провери дали съдържанието не е било подправено.

Благодарение на тази структура, MSIX постига много висок процент на успех при инсталиране (около 99,96% в милиони инсталации ) и осигурява чисто деинсталиране, без да оставя следи във файловата система или системния регистър извън контролираните области.

Ключови предимства на MSIX пред EXE, MSI и AppX

Екосистемата на Windows използва множество инсталационни формати от години: EXE, MSI, AppX и сега MSIX . Всеки от тях има своя собствена история, предимства и недостатъци.

MSI-ите се отличават с прости, ненаблюдавани инсталации, но техният инсталационен модел може да остави следи и те не използват съвременните концепции за контейнери. EXE файловете са много гъвкави, с персонализирани помощници, откриване на предишни инсталации и разширени опции, но са по-сложни за управление и автоматизиране на корпоративно ниво . AppX, от друга страна, е проектиран за UWP приложения, разпространявани чрез App Store, предлагайки добра изолация, но много ограничена до този модел.

MSIX взима най-добрите характеристики от всички тях и добавя нови възможности. Сред най-забележителните предимства:

• Надеждна инсталация и деинсталацияТъй като всичко е в добре дефиниран контейнер, Windows знае точно какво да почисти.
• Диференциални актуализацииИзтеглят се само променените блокове от 64 KB, което намалява използването на мрежата и времето за актуализиране, идеално за бизнеси или ограничени връзки.
• Ефективност на дисковото пространствоФайловете, споделени между приложенията, се управляват интелигентно, като се избягват ненужни дубликати, без да се нарушава независимостта на всяко приложение.
• Лека контейнеризацияВиртуализация на файловата система и системния регистър за намаляване на въздействието върху системата и подобряване на сигурността, без тежестта на пълна виртуална машина.
• Готови за бизнесинтеграция с Intune, Configuration Manager и модерния доставчик на услуги за управление на приложения (CSP).

Освен това, за разлика от AppX, MSIX позволява разпространение извън Microsoft Store : можете да качвате пакетите си на уебсайта си, да ги интегрирате в CI/CD канали, да използвате Intune, GPO, PowerShell скриптове или инструменти на трети страни за контролирано внедряване.

Подгответе приложение за опаковане в MSIX

Преди да се втурнете в пакетирането „хаотично“, струва си да прегледате някои критични точки, за да сте сигурни, че приложението ви ще се представя добре в рамките на MSIX модела , особено в корпоративни сценарии или на системи като Windows 10/11 S.

Изисквания и съвместимост на .NET

Ако приложението ви е разработено в .NET, Microsoft препоръчва да се насочите към .NET Framework 4.6.2 или по-нова версия . Тази версия е включена по подразбиране от Windows 10 1607 (Anniversary Update), а по-късните версии на Windows включват по-нови framework-и.

Приложенията, насочени към .NET 4.0-4.6.1, обикновено работят правилно на 4.6.2+, но е необходимо щателно тестване. Ако вашата цел е 2.0 или 3.5, целевата машина ще трябва да има активирана функцията .NET Framework 3.5 . В тези случаи може да срещнете и фини проблеми с производителността или съвместимостта с 32-битови приложения , така че е необходимо интензивно тестване.

Повишени привилегии, услуги и шофьори

Приложение, което функционира правилно само когато се изпълнява с администраторски права, е много вероятно да причини проблеми, след като бъде пакетирано в MSIX. Не забравяйте, че много потребители в реални среди не са системни администратори и че Microsoft Store отхвърля приложения, които изискват повишени права за критична функционалност.

MSIX също не поддържа драйвери за Windows или услуги за всеки потребител . Разрешени са само услуги за сесия 0 на машина (LocalSystem, LocalService, NetworkService) и в много случаи е за предпочитане да се заменят с фонови задачи или спомагателни процеси, които са по-добре интегрирани в съвременния модел.

Използване на системния регистър, AppData и инсталационните директории

Друг критичен проблем е как приложението използва системния регистър и файловата система. Всеки опит за запис в HKEY_LOCAL_MACHINE от MSIX приложение ще доведе до грешка „достъп отказан“ . Приложението има виртуализиран изглед на системния регистър, така че много класически HKLM стратегии за глобална конфигурация стават неефективни.

Записите в HKEY_CURRENT_USER се пренасочват към изолирано хранилище за потребители и приложения, а нещо подобно се случва и с AppData , което се пренасочва към локалната папка с данни на пакета. Ако вашето приложение е използвало AppData или системния регистър за споделяне на данни с други програми, ще трябва да преразгледате тази стратегия и да обмислите механизми като UWP договори, услуги за приложения или оторизирано споделено хранилище.

И накрая, много често срещана, но проблемна практика е записването в самата инсталационна директория на приложението (например, лог файлове заедно с EXE файла). С MSIX инсталационната директория е само за четене за приложението, така че ще трябва да преместите тези данни в подходящо място за данни на приложението.

Разширения, COM, GAC и нативни зависимости

Ако вашето приложение предоставя COM обекти, разширения на обвивката или разчита на GAC асембли, видими за други приложения, трябва да бъдете особено внимателни. Моделът Packaged COM ви позволява да регистрирате COM и OLE сървъри, видими извън пакета, но не обхваща всички разширения, които зависят от директна проверка на системния регистър.

За C++ приложения, които използват средата за изпълнение на Visual C++, ще трябва да решите дали да се свържете динамично или статично към CRT. Visual Studio 2015/2017/2019 поддържа и двата подхода, но ако разчитате на CRT DLL файлове, инсталирани в паралелни папки на Windows (System32/SysWOW64), ще трябва да включите зависимостите правилно във VFS на пакета и/или да се обърнете към съответните VCLibs framework пакети чрез зависимости в манифеста.

Конфигуриране на MSIX пакета във Visual Studio

В съвременните приложения, особено с Windows App SDK и WinUI 3, Visual Studio предлага сравнително удобно изживяване за конфигуриране и генериране на MSIX пакети, без да е необходимо ръчно редактиране на XML през цялото време.

Манифестът Package.appxmanifest

Ядрото на конфигурацията на пакета е файлът Package.appxmanifest , XML документ, където дефинираме идентичност, възможности, входни точки, визуални ресурси и разширения. Visual Studio включва дизайнер на манифести, който елиминира необходимостта от директно редактиране на XML, въпреки че винаги е препоръчително да го прегледате в режим на код, когато нещата се усложнят.

От Solution Explorer просто отворете Package.appxmanifest (щракнете двукратно). Ако вече сте в XML режим, Visual Studio ще ви подкани да затворите този изглед, за да се покаже дизайнерът. В различните раздели можете да конфигурирате елементи като:

• Визуални ресурсиИкони, лога, размери за различни мащаби и устройства.
• опаковки: данни за издателя, версия, сертификати за подписване.
• възможности: достъп до мрежа, местоположение, камера, микрофон, ограничена файлова система и др.
• Декларации: файлови асоциации, персонализирани протоколи, фонови задачи, псевдоними за изпълнение и др.

От съществено значение е всички MSIX приложения да бъдат подписани със сертификат, на който устройството има доверие . Можете да използвате сертификат, издаден от вашата вътрешна PKI, публичен сертификат или дори самоподписан сертификат за разработка. Ако потребителят ще инсталира пакета директно, сертификатът трябва да бъде инсталиран в неговото хранилище за сертификати като доверен орган.

Свържете приложението с Microsoft Store

Ако основният ви канал за дистрибуция ще бъде Microsoft Store, Visual Studio ви позволява да свържете проекта си с приложение от Store, което вече е регистрирано в Partner Center. От контекстното меню на проекта можете да отидете на Publish (Публикуване) → Associate app with the Store (Свързване на приложение с магазина) и да следвате инструкциите на съветника.

Тази асоциация автоматично актуализира полетата на манифеста, като например идентификатора на пакета, издателя и други метаданни, като ги подравнява с данните в Центъра за партньори. Впоследствие, когато генерира пакети за магазина, Visual Studio може автоматично да създаде файла .msixupload или .appxupload, готов за подаване.

Генериране на MSIX пакети от Visual Studio

След като приложението е готово и манифестът е конфигуриран, следващата стъпка е генерирането на пакетите. Visual Studio предоставя съветник за създаване на пакети , който обхваща както сценарии за Microsoft Store, така и за странично зареждане.

Създаване на пакет за странично зареждане

За да инсталирате приложението на машини, без да преминавате през магазина (например тестови среди, лаборатории или вътрешно внедряване), можете да използвате процеса на странично зареждане:

1. Отворете решението и намерете проекта на приложението.
2. Щракнете с десния бутон върху проекта → Публикуване → Създаване на пакети с приложения.
3. На първия екран изберете опцията, насочена към Странично зареждане.
4. Изберете метода на подписване: пропуснете го (само за силно контролирани сценарии) или изберете/създайте подходящ сертификат.
5. На страницата за избор на пакет, дефинирайте архитектурите (x86, x64, ARM, ARM64) и дали искате да генерирате пакет.

Съветникът ще генерира един или повече .msix файлове (и по избор .msixbundle). Простото щракване двукратно върху пакета на целевия компютър ще позволи на App Installer да покаже подробностите за приложението и да активира инсталирането, при условие че сертификатът е надежден за системата.

Създайте файла за качване за Microsoft Store

Ако подавате заявлението до Партньорския център, процесът е много подобен, с няколко допълнителни стъпки:

1. От менюто „Публикуване“ на проекта, стартирайте отново Създаване на пакети с приложения.
2. Изберете опцията, която съответства на Microsoft Store.
3. Влезте с вашия акаунт за разработчици в Партньорския център и изберете вече регистрирано приложение или резервирайте ново име.
4. Изберете всички целеви архитектури (обикновено x86, x64 и ARM) и конфигурирайте съветника да винаги генерирайте пакет.
5. Поставете отметка в квадратчето, за да включите публични символи за отстраняване на грешки в качения файл.
6. Изберете номер на версията, изходен път и щракнете върху Създаване.

Когато процесът е успешен, ще получите .msixupload или .appxupload файл, който можете да качите директно в Партньорски център . Това се използва за управление на сертифицирането, поетапното внедряване и анализ на грешки в производствения процес.

Ръчно създаване на .msixupload файл

В по-„ръчно изработени“ сценарии или специфични интеграции е възможно да създадете файл за зареждане ръчно. За да направите това:

• Групирайте един или повече пакета с приложения (.msix / .appx) или пакет (.msixbundle / .appxbundle) в папка.
• Добавете файла .appxsym с публичните символи, ако искате да активирате анализ на грешки (силно препоръчително).
• Компресирайте тази папка в ZIP файл.
• Променете разширението от .zip на .msixupload или .appxupload.

Тозият получен файл ще бъде приет от Центъра за партньори като файл за качване в магазина.

Тестване за валидиране и сертифициране на MSIX пакети

Не е достатъчно приложението да работи на вашата машина: преди внедряването му в производствена среда, особено ако ще го използвате през Microsoft Store, е изключително важно да валидирате пакета с комплекта за сертифициране на приложения за Windows (WACK).

Локална валидация

На последния екран на съветника за създаване на пакети на Visual Studio можете да оставите избрана опцията „Локална машина“ и директно да стартирате комплекта за сертифициране на приложения за Windows . Този инструмент изпълнява набор от автоматизирани тестове на пакета: инсталация, поведение на приложението, използване на разрешени API, производителност и други.

Само компилациите за издание могат да бъдат валидирани с този инструмент, а не компилациите за отстраняване на грешки. Ако вашият пакет премине всички тестове, вие сте много по-близо до избягване на изненади по време на сертифицирането на Microsoft Store и намаляване на проблемите при корпоративни внедрявания.

Валидиране на отдалечено устройство с Windows 10/11

Ако трябва да тествате на отдалечена машина (различна среда, различна архитектура, специфично устройство), можете:

1. Активирайте устройството за разработка.
2. Инсталирайте инструментите за отдалечено достъп на Visual Studio и самия комплект за сертифициране на приложения на Windows на отдалечения компютър.
3. В съветника за създаване на пакети изберете опцията за отдалечена машина и конфигурирайте DNS или IP адреса.
4. Изберете подходящия режим на удостоверяване и стартирайте WACK от Visual Studio.

Visual Studio ще се свърже с отдалеченото устройство, ще инсталира пакета и ще изпълни тестовете. Резултатът ще бъде подобен на локална валидация, но отразяващ условията на отдалечената среда.

Автоматизирайте компилирането, пакетирането и изпращането в Microsoft Store

В сериозни проекти, ръчното повтаряне на процеса на пакетиране и публикуване е рецепта за провал. Добрата новина е, че MSIX се интегрира добре с msbuild и CI/CD pipelines.

Компилиране и пакетиране с msbuild

За решения с един проект, базирани на MSIX, с WinUI 3, ключът е използването на правилния параметър msbuild. Основната опция е:

/p:Генериране на AppxPackageOnBuild=true

Без този параметър проектът ще се компилира, но няма да се генерира MSIX пакет. Активирането му ще накара всяка компилация да генерира конфигурирания(ите) пакет(и), което ще улесни интеграцията с действия на GitHub, Azure DevOps или всяка друга система за непрекъсната интеграция.

Автоматично подаване към Microsoft Store от Visual Studio

Започвайки с Visual Studio 2019, след стартиране на WACK, IDE може автоматично да изпрати файла .appxupload в Microsoft Store . За да използвате тази функция, ви е необходимо:

• Свържете акаунта в Центъра за партньори с екземпляр на Microsoft Entra ID (Azure AD).
• Регистрирайте приложение в Azure AD, което да представлява вашия инструмент за публикуване.
• Получете идентификатора на клиента, идентификатора на клиента и клиентската тайна от Центъра за партньори.

С тези идентификационни данни можете да конфигурирате опцията „Автоматично изпращане до Microsoft Store след валидиране“ в съветника и да въведете съответните идентификатори. Оттам, след успешно компилиране и WACK валидиране, Visual Studio ще започне процеса на изпращане и можете да наблюдавате напредъка в прозореца „Проверка и публикуване“.

MSIX в съвременни среди: прикачване на приложения и VHD/CIM контейнери

В контекста на виртуалния работен плот на Windows (сега Azure Virtual Desktop) и други VDI среди, технологията за прикачване на приложения MSIX набра значителна популярност . Идеята е да се отдели образът на базовата система от приложенията, като последните се зареждат от динамично монтирани MSIX контейнери.

За прикачване на приложения можете да използвате VHD, VHDX или CIM (Composite Image File System) контейнери . CIM контейнерите имат предимството, че се монтират и демонтират много бързо и консумират по-малко ресурси, въпреки че VHD/VHDX все още са много често срещани.

Създаването на тези контейнери може да се извърши ръчно с инструменти като MSIX Manager Tool (msixmgr) или чрез помощни програми на трети страни като AppVentiX или MSIX Hero, които значително опростяват процеса и избягват необходимостта от използване на Hyper-V модули в PowerShell.

След като контейнерът с MSIX пакета вътре бъде генериран и скриптовете или правилата за прикачване на приложения бъдат конфигурирани, приложението ще изглежда на потребителя сякаш е инсталирано локално, но в действителност е монтирано от виртуален диск , което значително улеснява управлението на образи и актуализациите на софтуера в многопотребителски среди.

Инструмент за пакетиране MSIX и рамка за поддръжка на пакети: опитомяване на сложни инсталатори

Не всички стари приложения са лесни за употреба: много от тях нямат опции за командния ред, записват на неподходящи места или изискват повишени привилегии. В тези ситуации MSIX Packaging Tool и Package Support Framework (PSF) са незаменими съюзници.

Инструментът за пакетиране на MSIX ви позволява да конвертирате съществуващи инсталатори (EXE, MSI, App-V 5.x, ClickOnce и др.) в MSIX пакети, или чрез графичен интерфейс, или от командния ред. Изисква Windows 10 версия 1809 или по-нова и администраторски права, като се препоръчва да деактивирате услуги като Windows Update, Windows Search или SMS Host, за да избегнете претрупване на пакета.

По време на процеса на заснемане, инструментът инсталира драйвер за пакетиране, изпълнява оригиналния инсталатор и следи кои файлове, ключове в системния регистър и достъп извършва . След завършване, той генерира MSIX пакета и лог на процеса.

Когато оригиналното приложение показва проблемни модели на поведение (например записване в неоторизирани пътища или използване на системния регистър по неподдържан начин), Package Support Framework (PSF ) влиза в действие , позволявайки корекции по време на изпълнение, без да се променя изходният код. Освен всичко друго, PSF може да пренасочва операции с файлове и системния регистър към разрешени местоположения или да прихваща определени извиквания, за да ги адаптира към MSIX контейнера.

За още по-сложни сценарии има помощни програми като PSFTooling (налични в Microsoft Store), които помагат за генерирането и прилагането на тези корекции, въпреки че практическата документация може да е донякъде оскъдна в наши дни и трябва да експериментирате и да преглеждате примери от общността, за да постигнете перфектния пакет.

MSIX се утвърждава като централен компонент на съвременното внедряване на Windows: от прости инсталации на настолни компютри до сложни корпоративни среди и виртуални настолни компютри, той предлага по-чист, по-сигурен и по-автоматизиран модел на пакетиране от EXE или MSI, като същевременно позволява разширени възможности на платформата Windows и улеснява работата на разработчиците, администраторите и екипите за поддръжка, когато целият цикъл на пакетиране и внедряване е правилно проектиран и валидиран.