كيفية إدارة التحديثات باستخدام MSIX على نظام التشغيل ويندوز

إذا كنت تعمل مع أنظمة تشغيل ويندوز، فستواجه نفس المشكلة عاجلاً أم آجلاً: كيفية تحديث التطبيقات دون إحداث مشاكل للمستخدم أو استهلاك النطاق الترددي بشكل مفرط من الشبكة. مع وصول تنسيق MSIX وبفضل النظام البيئي الكامل الذي بنته مايكروسوفت حوله، لم تعد إدارة التحديثات مجرد "تنزيل برنامج تثبيت جديد وتشغيله"، بل أصبحت تتعلق بتنسيق متى وكيف ومن أين يتم التحديث.

سنتناول في هذه المقالة، بهدوء ولكن بشكل مباشر، كيفية إدارة التحديثات باستخدام MSIX داخل وخارج متجر Microsoftما هو دور ملفات AppInstaller و PowerShell و MDM CSPs ومنصة تنسيق تحديثات Windows الجديدة، ولماذا تستعد MSIX لاستبدال MSI و AppX في العديد من سيناريوهات المؤسسات؟

ما الذي يقدمه نظام MSIX في إدارة التحديثات؟

وُلدت MSIX كـ التطور الحديث لتنسيقات MSI و EXE و AppXيجمع بين أفضل ما في العالمين: سهولة نشر MSI، وتغليف AppX ونظافته، والمرونة التي تتطلبها تطبيقات Win32 الكلاسيكية (Win32، WPF، WinForms، .NET Framework، إلخ).

عندما تقوم بتجميع تطبيقاتك في MSIX، يتم تنفيذ عمليات التركيب والإزالة في غضون حاوية خاضعة للرقابةيضمن هذا أن جميع الملفات ومفاتيح التسجيل تتبع قواعد صارمة ومتوقعة. عند إزالة التطبيق، تتم إزالة كل شيء معه، مما يمنع حدوث ما يُعرف بـ"تلف نظام ويندوز" الناتج عن عقود من تثبيت وإزالة ملفات MSI وEXE.

ومن المزايا الرئيسية الأخرى للتحديثات ما يلي: تم تصميم MSIX من الصفر لدعم ترقيات التروس التفاضليةيتم تنزيل الأجزاء المُعدّلة فقط من الحزمة، وليس الحزمة بأكملها. وهذا يُحدث فرقًا في شبكات الشركات الكبيرة أو الشبكات ذات الروابط المحدودة.

وبالإضافة إلى ذلك، لا يقتصر نظام MSIX على متجر مايكروسوفتيمكنك توزيع الحزم بنفسك، عبر الويب، أو الموارد المشتركة، أو أدوات الإدارة مثل Configuration Manager أو Intune أو Citrix أو VMware، مع الحفاظ على مزايا الحاويات والتحديثات الفعالة.

كيفية عمل ترقية الترس التفاضلي على نظام MSIX

لفهم سبب تحسين MSIX للتحديثات بشكل جيد للغاية، نحتاج إلى النظر في مكون محدد: ملف AppxBlockMap.xml، والذي يعمل كخريطة كتل لجميع الملفات في الحزمة.

أثناء عملية التغليف، يتم إنشاء جزء من البيانات الوصفية وتضمينه في الملف نفسه. .msix أو .msixbundleتسمح هذه الكتلة من البيانات الوصفية لنظام التشغيل Windows بتحديد كل جزء من الحزمة بشكل فريد، بحيث يمكنه مقارنة إصدار قديم وإصدار جديد وتحديد الأجزاء التي يجب تنزيلها بالضبط.

ملف AppxBlockMap.xml هو مستند XML يحتوي على مصفوفة معلومات لكل ملفأولاً، تُعرض المعلومات العامة (الاسم، الحجم، إلخ) بالتفصيل، ثم تُدرج قيم التجزئة SHA2-256 لكل كتلة من كتل الملف بحجم 64 كيلوبايت. تُمثل كل كتلة بتجزئة مستقلة، لذا إذا تغير جزء فقط من الملف، فسيتم تحديث تلك الكتل فقط.

عملياً، عندما تُصدر نسخة جديدة من ملف MSIX الخاص بك، يقوم نظام التشغيل Windows بمقارنة تجزئات الكتل بين الإصدار المثبت والإصدار الجديدإذا طرأ أي تغيير على أي جزء من الملف، يتم تنزيله؛ وإلا، يُعاد استخدام الجزء الموجود مسبقًا على الجهاز. أما إذا كان الملف بأكمله متطابقًا (جميع أجزائه متطابقة)، فيُعاد استخدامه كما هو ولا يُنزّل مرة أخرى.

يُجري هذا النهج تحديثات العمل من أي إصدار إلى أي إصدار آخر (شريطة أن تكون حزمة الوجهة ذات إصدار أحدث أو يتم فرض تغيير الإصدار)، تقليل عرض النطاق الترددي ووقت التثبيت، خاصة عندما تكون الحزم موجودة في موارد مشتركة أو مستودعات خارجية.

قيود هامة عند تحديث حزم MSIX

على الرغم من أن محرك تحديث MSIX مرن للغاية، إلا أن هناك عددًا من القواعد التي يجب أن تكون واضحة قبل إعداد استراتيجية الإصدار والنشر الخاصة بك، خاصة في بيئات المؤسسات حيث لا تريد أن تتعطل أي شيء في بيئة الإنتاج.

أولا، تتم التحديثات دائمًا ضمن نفس مجموعة الحزميجمع اسم عائلة الحزمة بين اسم الحزمة والناشر (على سبيل المثال، Contoso.ContosoApp_8wekyb3d8bbwe). إذا قمت بتغيير هذه المعلومات، فستتعامل مع عائلة مختلفة، ولن يكون الأمر ترقية بل تثبيتًا موازيًا.

إفتراضي، يتطلب التحديث أن يكون للإصدار الجديد رقم أعلى من رقم الإصدار المثبت.تمنع العملية القياسية محاولات الرجوع إلى إصدار أقدم. مع ذلك، منذ إصدار ويندوز 10 رقم 1809، يمكنك استخدام خيارات مثل ForceUpdateFromAnyVersion (في PowerShell، أو CSP، أو واجهة برمجة تطبيقات PackageManager، أو داخل AppInstaller نفسه) للسماح بالترقية والرجوع إلى إصدار أقدم إذا كنت بحاجة إلى العودة إلى إصدار سابق.

هناك تفصيل آخر ذو صلة وهو أن قد تتغير بنية النظام في التحديث.طالما أن البنية الجديدة متوافقة مع النظام. مثال نموذجي: لديك تطبيق MSIX x86 على نظام Windows 10 x64، ثم تقوم لاحقًا بنشر نسخة x64؛ سيتم تحديث النظام من x86 إلى x64 دون أي مشاكل.

وأخيراً، يجب مراعاة نوع الحزمة: يمكنك الترقية من MSIX بسيط إلى حزمة MSIXولكن ليس العكس. إذا كان الجهاز يحتوي على حزمة مثبتة، فيجب أن تكون التحديثات اللاحقة أيضًا حزمًا، للحفاظ على اتساق نموذج الموارد.

تحسين تقنية ترقية التروس التفاضلية

لتحقيق أقصى استفادة من ترقية نظام التروس التفاضلية في MSIX، لا يكفي مجرد تجميعها والاكتفاء بذلك: ينبغي تصميم الهيكل الداخلي للعبوة التفكير في كيفية تعديل الملفات مع مرور الوقت.

التوصية الأولى هي حافظ على حجم الملفات صغيرًا نسبيًاإذا أنشأت ملفًا واحدًا كبيرًا تقوم بتعديله باستمرار، فقد يُجبرك تغيير كبير فيه على تنزيل جزء كبير منه. في المقابل، فإن تقسيمه إلى عدة ملفات أصغر حجمًا وأسهل في التعامل معه عادةً ما يقلل من حجم التنزيل.

كما أن ذلك يساعد أيضاً ينبغي أن تكون التغييرات تراكمية قدر الإمكانإذا ركزت التعديلات على إضافة بيانات أو كتل جديدة، بدلاً من إعادة كتابة الكتل الموجودة بالكامل، فسيتعين على النظام تنزيل تلك الكتل المعدلة فقط، مع الاحتفاظ بالباقي كما هو.

إلى أقصى حد ممكن ، يحاول هذا الأسلوب تركيز التغييرات ضمن كتل بحجم 64 كيلوبايت.إذا كان تطبيقك يعمل مع ملفات كبيرة جدًا وتحتاج إلى تعديل المناطق الداخلية، فمن الأفضل تجميع المنطق بحيث لا تنتشر التعديلات عبر العديد من الكتل المختلفة، وبالتالي يظل التأثير على حجم التحديث تحت السيطرة.

التحديثات والإصلاحات التلقائية باستخدام ملفات AppInstaller

عند توزيع تطبيقات MSIX خارج متجر Microsoft، يدخل عنصر أساسي في العملية: ملف تثبيت التطبيق (.appinstaller)يحدد هذا الملف إعدادات التحديث والإصلاح التلقائي لكل تطبيق، ويسمح لنظام التشغيل Windows بإدارة هذه العمليات دون الحاجة إلى إعادة اختراع العجلة.

عند تثبيت تطبيق باستخدام ملف AppInstaller الخاص به، يقوم نظام التشغيل Windows بإنشاء إدخال في مستودع مثبت التطبيقات. مع الخيارات التي قمت بتكوينها. يمكن تعديل هذا الإدخال لاحقًا من تطبيق إعدادات ويندوز، أو عبر باور شيل، أو من خلال موفر خدمة التشفير (CSP) إذا كنت تدير أجهزة الكمبيوتر باستخدام إدارة الأجهزة المحمولة (MDM)، ولكن أي تغييرات ستطبق على هذا التطبيق المحدد وستحل محل التكوين السابق.

عمليًا، يتيح لك برنامج AppInstaller تحديد ما إذا كان التطبيق تحقق من وجود تحديثات عند بدء التشغيل، سواء تم فحصها في الخلفية، أو تم إخطار المستخدم أو تم كل شيء بصمت، وحتى إذا كان التحديث إلزاميًا قبل فتح التطبيق، مما يمنع التنشيط حتى يتوفر أحدث إصدار.

تستخدم التطبيقات افتراضيًا مسار URI الرئيسي المحدد في AppInstaller للتحقق من وجود تحديثات. إذا كان هذا المصدر غير متاح، فيمكنهم اللجوء إلى واحد أو أكثر من عناوين URI الاحتياطية للتحديث. سيحاول النظام استخدام كل عنوان URI حتى يعثر على مُثبِّت تطبيقات صالح ومتاح، والذي سيحدد بعد ذلك ما إذا كان هناك إصدار جديد متاح.

يدعم قسم التحديث في AppInstaller عناصر مثل الساعات بين عمليات التحقق من التحديث (الحد الأدنى للتكرار بين عمليات الفحص)، إظهار موجه الأوامر (إظهار أو إخفاء واجهة المستخدم عند التحقق من التحديثات أو تثبيتها) و تحديث تفعيل الكتل (حدد ما إذا كان يمكن فتح التطبيق بدون تحديث أو ما إذا كان التحديث إجباريًا قبل البدء).

إعدادات متقدمة باستخدام UpdateSettings في AppInstaller

يتم تحديد السلوك الدقيق للتحديثات باستخدام العنصر تحديث الإعدادات من ملف AppInstaller. هنا يمكنك تحديد ليس فقط وقت التحقق من التحديثات، ولكن أيضًا كيفية تطبيقها وما هي المرونة المتاحة للمستخدم.

من جهة، يمكنك اختيار ما إذا كانت عمليات التحقق ستتم أم لا فقط عند بدء تشغيل التطبيق (عند التشغيل) أو إذا تم أداؤها أيضًا في الخلفية بواسطة مهمة خلفية تلقائية، كل بضع ساعات ودون تدخل مباشر من المستخدم.

عند استخدام OnLaunch، تدخل عدة سمات حيز التنفيذ: الساعات بين عمليات التحقق من التحديث يحدد الحد الأدنى للفاصل الزمني بالساعات بين عمليات الفحص؛ إظهار موجه الأوامر يحدد ما إذا كانت ستظهر نافذة تُعلم بالتحديث؛ و تحديث تفعيل الكتل يحدد ما إذا كان يمكن بدء تشغيل التطبيق دون تحديث أو ما إذا كان المستخدم مجبرًا على تطبيق التصحيح قبل فتحه.

إذا تم ضبط خاصية UpdateBlocksActivation على القيمة true، لا يمكن للمستخدم إلا الاختيار بين تحديث التطبيق أو إغلاقه.في حال ضبط هذا الخيار على "خطأ"، سيُتاح لك خيار التحديث الآن أو المتابعة دون تحديث، مما يسمح للنظام بتطبيق التغيير في الخلفية لاحقًا. تتوفر هذه الخيارات بدءًا من إصدارات معينة من نظام التشغيل Windows 10 (الإصدار 1903 أو أحدث، حسب الخاصية).

أما مهمة الخلفية التلقائية، من جانبها، يقوم بإجراء فحوصات منتظمة كل 8 ساعات تقريباً.بغض النظر عما إذا كان المستخدم يفتح التطبيق أم لا، فإن هذه الآلية لا يمكنها عرض واجهة، مما يجعلها مثالية للحفاظ على كل شيء محدثًا بأقل قدر من الإزعاج للمستخدم.

وأخيرًا، السمة التحديث الإجباري من أي إصدار يسمح لك ذلك بكسر قاعدة "التحديث للأمام فقط" الكلاسيكية والترقية إلى الإصدارات الأعلى والأدنى، وهو أمر مفيد للغاية إذا كنت بحاجة إلى تصحيح تراجع عن طريق الرجوع مؤقتًا إلى إصدار سابق.

التحديث والإصلاح التلقائيان عبر CSP و MDM

في بيئات المؤسسات، تُدار الأجهزة عادةً باستخدام حلول إدارة الأجهزة المحمولة مثل Microsoft Intune أو أدوات إدارة الأجهزة المحمولة التابعة لجهات خارجية. في هذه الحالات، وسّعت Microsoft نطاق إدارة تطبيقات المؤسسات الحديثة CSP، مما يسمح لك بالتحكم في التحديث التلقائي وإصلاح تطبيقات MSIX غير الموجودة في المتجر.

يوجد تكوين التحديث التلقائي في مسار CSP من النوع ./Device/Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/nonStore/ /AppUpdateSettings/AutoUpdateSettings/AutoUpdateSettings/حيث تتولى كل عقدة جوانب محددة من السلوك.

من بين المعايير المتاحة مصدر الحزمة (مصدر ملف .appinstaller الذي سيتم استخدامه للبحث عن التحديثات)، مهمة خلفية تلقائية (إذا تم فحصه وتحديثه في الخلفية)، OnLaunchUpdateCheck (تحقق في البداية)، الساعات بين عمليات التحقق من التحديث, إظهار موجه الأوامر (عرض مربعات حوار التحديث أو الإصلاح) و تحديث تفعيل الكتل (إذا كان من الممكن تشغيل التطبيق عند وجود تحديث معلق).

أماكن أخرى مثيرة للاهتمام هي التحديث الإجباري من أي إصدار، مما يتيح التحديثات التصاعدية أو التنازلية، والقيمة تعطيليشير هذا إلى ما إذا كانت التحديثات التلقائية مُفعّلة أم مُعطّلة لحزمة معينة. وباستخدام هذه المعايير، يستطيع المسؤولون ضبط تجربة التحديث بدقة للأسطول الكبير من الأجهزة.

إلى إصلاح تلقائييستخدم موفر خدمة السحابة مسارًا مكافئًا ينتهي في …/إصلاح السيارات/مع تعديل رئيسي واحد: مصدر الحزمة، مما يشير إلى أصل ملف .appinstaller أو حزمة MSIX نفسها التي سيتم استخدامها لإصلاح التطبيق إذا اكتشفت مشاكل.

في كلتا الحالتين، يسمح الجمع بين CSP وMDM تطبيق سياسات التحديث والإصلاح المركزية دون أن يضطر المستخدم إلى القيام بأي شيء، مما يحافظ على توافق التطبيقات الداخلية وتطبيقات الطرف الثالث مع استراتيجية الأمان والدعم الخاصة بالشركة.

إدارة التحديثات باستخدام PowerShell

للمسؤولين والبرامج النصية الآلية، لا تزال PowerShell أداة أساسية عند تدقيق وتكوين تحديث تطبيقات MSIX المثبتة باستخدام AppInstaller.

على وجه الخصوص، هناك أوامر مثل Get-AppxPackageAutoUpdateSettings، والتي تُرجع تكوين التحديث والإصلاح الحالي لتطبيق معين أو لجميع التطبيقات التي لها إدخال في مستودع مثبت التطبيقات، مما يسمح لك برؤية كيفية تكوين البيئة بسرعة.

من ناحية التكوين، Set-AppxPackageAutoUpdateSettings يتيح لك ذلك ضبط خيارات التحديث والإصلاح التلقائي لحزمة مثبتة من ملف AppInstaller، مع استبدال الإعدادات الحالية عند الضرورة.

علاوة على ذلك، يتم عادةً نشر وتحديث حزم MSIX مباشرةً باستخدام cmdlet إضافة حزمة التطبيق، والذي يتضمن معايير محددة للتحكم في تجربة المستخدم أثناء التحديث.

ومن بين هذه المعايير، تبرز المعايير التالية: -تأجيل التسجيل عند استخدام الحزم (تجنب التحديث أثناء استخدام التطبيق)، -فرض إيقاف تشغيل التطبيق (يغلق العمليات النشطة للحزمة وتوابعها لتطبيق التحديث)، -ForceUpdateFromAnyversion (يسمح بتسجيل إصدار معين بغض النظر عما إذا كان هناك إصدار أعلى مسجل بالفعل) و -تحديث (يشير إلى أن الحزمة عبارة عن تحديث لتبعية موجودة).

هناك أيضًا خيارات مثل -InstallAllResources (يفرض تثبيت جميع حزم الموارد المضمنة في دفعة واحدة) أو -RetainFilesOnFail (يحتفظ بالملفات التي تم إنشاؤها في حالة فشل التنفيذ)، وهو أمر مفيد في سيناريوهات الاختبار والتشخيص لعمليات نشر MSIX المعقدة.

التحديثات التي يتم إجراؤها من خلال الكود الخاص بالتطبيق

إحدى نقاط قوة MSIX هي أنه إذا قمت بتقديم طلبك بهذا الشكل، يمكنك بدء التحديثات برمجياً من داخل التطبيق نفسه.دون الاعتماد بشكل حصري على AppInstaller أو منطق إدارة الأجهزة المحمولة (MDM).

للقيام بذلك، عليك تحديد السعة في البيان. إدارة الحزم ضمن قسم القدرات. تُمكّن هذه القدرة من استخدام واجهات برمجة التطبيقات (APIs). Windows.Management.Deployment.PackageManagerوهي تلك التي تسمح لك بتنزيل وتطبيق حزم جديدة من خلال الكود.

إذا تم توزيع التطبيق باستخدام ملف AppInstaller، ينبغي أن تستمر التحديثات التي يتم بدء تشغيلها بواسطة التعليمات البرمجية في استخدام واجهات برمجة التطبيقات الخاصة بـ AppInstaller، مثل PackageManager.AddPackageByAppInstallerFileAsync أو PackageManager.RequestAddPackageByAppInstallerFileAsync، حتى لا تعطل عملية التحديث المحددة لهذا التطبيق.

للتحقق من توفر إصدار جديد عند استخدام AppInstaller، يمكنك الاتصال بـ Package.CheckUpdateAvailabilityAsyncإذا أشارت النتيجة إلى توفر تحديث (متوفر أو مطلوب)، يمكنك إضافة التثبيت إلى قائمة الانتظار باستخدام AddPackageByAppInstallerFileAsync، وإذا لزم الأمر، تمرير الخيار إيقاف تشغيل التطبيق بالقوة لإغلاق النسخة الحالية وتطبيق التغيير.

في الحالات التي لا تستخدم فيها AppInstaller، يمكن للتطبيق نفسه تحقق من خادمك الخاص لمعرفة ما إذا كان هناك إصدار أحدث. (على سبيل المثال، عن طريق قراءة ملف نصي للإصدار أو خدمة ويب)، قم بالمقارنة مع الإصدار الحالي، وإذا كان الأمر كذلك، اعرض مربع حوار يعرض التحديث أو التأجيل.

بمجرد موافقة المستخدم، يمكن للتطبيق استخدام PackageManager.AddPackageAsync يشير إلى حزمة MSIX أو الحزمة الاختيارية المقابلة، مع تمرير خيارات مثل ForceApplicationShutdown مرة أخرى بحيث يقوم Windows بإغلاق التطبيق وإكمال التثبيت دون مزيد من التدخل.

إعادة تشغيل التطبيق تلقائيًا بعد التحديث

من الأمور التي غالباً ما يتم تجاهلها ما يحدث بعد تثبيت الإصدار الجديد: هل تتم إعادة تشغيل التطبيق تلقائيًا أم يتعين على المستخدم القيام بذلك يدويًا؟ تعتمد الإجابة على نوع التطبيق وكيفية تشغيل التحديث.

في حالة تطبيقات UWP المعبأة بصيغة MSIX، إذا قمت بتمرير خيارات مثل عند تطبيق التحديث AddPackageByAppInstallerOptions.ForceApplicationShutdown o AddPackageOptions.ForceTargetAppShutdownيمكن لنظام التشغيل ويندوز جدولة التطبيق لإعادة التشغيل تلقائيًا بمجرد اكتمال التحديث.

بالنسبة للتطبيقات غير المتوافقة مع منصة UWP (مثل تطبيقات Win32 المعبأة في MSIX)، يُوصى بما يلي: استدعاء واجهة برمجة التطبيقات الأصلية RegisterApplicationRestart قبل بدء عملية إيقاف التشغيل والترقية، يقوم هذا الاستدعاء بتسجيل المثيل الحالي حتى يتمكن نظام التشغيل Windows من إعادة تشغيله بالمعلمات المحددة عند اكتمال العملية.

عادةً ما يتم استخدام فئة مساعدة صغيرة في لغة C# والتي، من خلال قابلية التشغيل البيني، استورد RegisterApplicationRestart من kernel32.dll ويوضح هذا الأسلوب طريقةً ملائمةً لاستخدامها في كود التطبيق. كما يتيح لك التحكم في الشروط التي ترغب في إعادة تشغيل التطبيق في ظلها (على سبيل المثال، منع إعادة التشغيل بعد الأعطال أو أخطاء محددة).

بتطبيق هذا النمط بشكل صحيح، تضمن أن تكون تجربة التحديث أكثر سلاسة للمستخدميتم إغلاق التطبيق، ويتم تثبيت الإصدار الجديد، وبعد بضع ثوانٍ، يعود المستخدم إلى نفس النقطة دون الحاجة إلى القلق بشأن أي شيء.

منصة تنسيق تحديثات ويندوز الجديدة

إلى جانب MSIX، تتخذ مايكروسوفت خطوة أبعد مما تسميه منصة تنسيق تحديثات ويندوز، وهي طبقة تهدف إلى توحيد تجربة التحديث في نظام التشغيل Windows 11 ليس فقط للنظام وبرامج التشغيل، ولكن أيضًا لتطبيقات الطرف الثالث.

حتى الآن، كان كل تطبيق يحتوي على آلية التحديث الخاصة بها (خدمات مقيمة، وفحوصات خلفية، ومحدثات مدمجة، إلخ)، بينما كان نظام التشغيل وبعض برامج التشغيل يعتمد على تحديثات ويندوز. والنتيجة: نظام بيئي مجزأ، يصعب إدارته في الشركات ومربك للمستخدمين.

تتيح مايكروسوفت من خلال المنصة الجديدة ذلك تطبيقات معبأة بصيغ MSIX أو APPX أو حتى بعض تطبيقات Win32 مع مُثبِّت مخصص التكامل مع تحديثات ويندوز وتفويض تخطيط وتنفيذ التحديثات إليها، دون التخلي عن منطقها الداخلي.

يمكن للمطورين تسجيل سياسات التحديث الخاصة بهم باستخدام واجهات برمجة تطبيقات WinRT وأوامر PowerShell، مع تحديد شروط ذكية مثل: نشاط المستخدم، ومستوى البطارية، وحمل النظام، وتوافر الطاقة "النظيفة"، أو فترات انخفاض النشاط لتقليل التأثير على تجربة المستخدم.

علاوة على ذلك، يتم تسجيل جميع الإجراءات في نظام تشخيص موحد ويمكن للتطبيقات عرض إشعارات تحديثات ويندوز الأصلية، بالإضافة إلى ظهورها في سجل تحديثات النظام، مما يسهل تتبع التحديثات ودعمها في المنزل وفي الشركات.

MSI مقابل MSIX: التأثير الحقيقي على النشر والترقيات

لعقود من الزمن، كان هذا الشكل لطالما كانت MSI المعيار الفعلي لتنفيذ البرامج على نظام التشغيل ويندوزيوفر هذا النظام تثبيتًا قياسيًا، وتخصيصًا من خلال التحويلات (.mst)، وإمكانية التراجع، والإصلاح الذاتي، وعمليات التثبيت الإدارية للشبكة، والتكامل مع سياسة المجموعة.

تكمن المشكلة الكبرى لشركة MSI في أنه بمرور الوقت، يميل إلى ترك رواسب في النظامالملفات الموجودة في AppData، وإدخالات التسجيل، والمجلدات اليتيمة... كل هذا يساهم في "تلف نظام التشغيل Windows" وينتهي به الأمر بالتأثير على أداء واستقرار الكمبيوتر.

يأتي نظام MSIX تحديداً لحل هذا السيناريو، الحفاظ على مزايا الإدارة المركزية ولكن إضافة الحاويات، والتنظيف الكامل عند إلغاء التثبيت، والتحديثات التفاضلية، ونموذج أمان أكثر قوة (يجب توقيع جميع الحزم والتحقق من صحتها).

من وجهة نظر التبني، كانت العديد من المنظمات حذرة في البداية لأن كانت الإصدارات الأولى من MSIX تحتوي على أخطاء وقليل من أدوات التحويل المتطورة.ومع ذلك، فإن النظام البيئي يتطور: فقد أطلقت مايكروسوفت أداة MSIX للتغليف وإطار عمل دعم الحزم، كما أن جهات خارجية مثل TMEditX تسهل تحويل الحزم وضبطها بدقة، حتى إلى تنسيقات مثل AppAttach.

اليوم، مع تطبيقات مثل أصبحت حزمة Microsoft Office والإصدار الجديد من Teams الآن مضمنة في MSIX.ومع نهاية عمر تطبيق-V مع استهداف عام 2026، هناك المزيد من الحجج للرهان على MSIX باعتباره تنسيق النشر والتحديث الرئيسي في بيئات ويندوز الحديثة.

مع هذه المجموعة الكاملة من المكونات (MSIX، AppInstaller، CSP، PowerShell ومنصة تنسيق تحديثات ويندوز)، تتيح لك إدارة التحديثات باستخدام MSIX الانتقال من التصحيحات اليدوية والبرامج النصية الهشة إلى نموذج أكثر قابلية للتنبؤ والكفاءة والتحكم.حيث يتم تحديث التطبيقات بشكل تفاضلي، بسياسات واضحة ودون ترك أي بقايا، وحيث يتمتع كل من المستخدمين والمسؤولين بتجربة أنظف وأكثر اتساقًا.