كيف تختار أسلوب توزيع تطبيق Windows - MSI وMSIX وClickOnce وxcopy والتحديث الخاص

نزّل ورقة عمل Excel للقرار، بورقتين يابانية وإنكليزية

عند تقرير أسلوب توزيع تطبيق Windows، يسهل بدء الحديث من «أيّها أحدث» أو «أيّها أبسط». لكن ما يؤثّر فعلاً في التشغيل محور آخر.

• أتريد التثبيت بوحدة المستخدم أم على الجهاز كلّه
• أتريد إيكال التحديث إلى منصّة التوزيع أم حمله بنفسك
• هل يوجد تكامل مع نظام التشغيل مثل خدمة / تعريف / امتداد Shell / تسجيل COM
• هل يلزم الصمود في شبكة مغلقة أو غير متّصلة أو توزيع USB
• هل تحتاج package identity، أم تريد العمل Win32 خام غير مقيَّد

اختيار أسلوب التوزيع ليس تفضيل صيغة المثبِّت، بل اختيار إلى أيّ حدّ تلمس نظام التشغيل ومن يحمل مسؤولية التحديث.

flowchart TB
    accTitle: محوران يقرّران أسلوب التوزيع
    accDescr: مخطّط يبيّن أنّ اختيار أسلوب التوزيع ليس تفضيل صيغة المثبِّت من حيث الأحدث أو الأبسط، بل اختيار محورين: إلى أيّ حدّ تلمس نظام التشغيل، ومن يحمل مسؤولية التحديث.
    a0["«أيّها أحدث · أبسط»"] -.-> a1["لا تقرّر بهذا المحور"]
    a2["إلى أيّ حدّ تلمس نظام التشغيل"] --> a4["يُقرَّر أسلوب التوزيع"]
    a3["من يحمل مسؤولية التحديث"] --> a4

الشكل 1: أسلوب التوزيع لا يُقرَّر بالتفضيل بل بمحورين: كثافة التكامل مع نظام التشغيل ومسؤولية التحديث.

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

1. الخلاصة أوّلاً

بصياغة فضفاضة لكن سهلة الاستخدام عمليّاً، كالتالي.

• إن كان التثبيت على الجهاز كلّه، مع خدمة أو تسجيل COM أو إدخال افتراضات، فكّر أوّلاً من MSI نقطة انطلاق
• إن افترضت Windows 10/11 وأردت clean install / clean uninstall وتحديثاً متكرّراً وpackage identity، فـ MSIX خيار قوي
• إن أردت توزيع تطبيق سطح مكتب .NET داخلي بوحدة المستخدم بسهولة مع تحديث تلقائي، فما زال ClickOnce قويّاً جدّاً
• إن أوليت أداة تعمل بمجرّد الوضع، وشبكة مغلقة، وتوزيع USB، وبلا امتيازات مدير، فـ xcopy الأصدق
• إن أردت الإمساك بتجربة التحديث والقنوات والتوزيع المتدرّج وقياس الاستخدام واستراتيجية الاستعادة بنفسك، فـ updater خاص
• إن لزم تعريف، فأأمن ألّا تفكّر من البداية بمركزية MSIX
• إن لزم امتداد Shell داخل العملية في Explorer، فافحص أوّلاً نطاق ما يدعمه MSIX وشروط إصدار نظام التشغيل

بجمع فضفاض، كالتالي.

1. التسجيل في نظام التشغيل كثيف → أميل إلى MSI
2. تريد package identity وتغليفاً حديثاً → MSIX
3. تريد توزيعاً per-user سهلاً وتحديثاً مضمَّناً → ClickOnce
4. توزيع الوضع فقط أولوية قصوى → xcopy
5. عندك عزم تصميم منصّة التحديث وتشغيلها داخل الشركة → updater خاص

flowchart TB
    accTitle: جمع فضفاض للأساليب الخمسة
    accDescr: مخطّط يبيّن أنّ التسجيل الكثيف في نظام التشغيل يميل إلى MSI، وأنّ طلب package identity والتغليف الحديث يختار MSIX، وأنّ التوزيع per-user السهل مع تحديث مضمَّن يختار ClickOnce، وأنّ توزيع الوضع فقط أولوية قصوى يختار xcopy، وأنّ عزم تصميم منصّة التحديث وتشغيلها داخل الشركة يختار updater خاص.
    b1{"هل التسجيل في نظام التشغيل كثيف؟"} -->|"نعم"| b2["أميل إلى MSI"]
    b1 -->|"لا"| b3{"هل تريد package identity؟"}
    b3 -->|"نعم"| b4["MSIX"]
    b3 -->|"لا"| b5{"توزيع per-user سهل + تحديث تلقائي؟"}
    b5 -->|"نعم"| b6["ClickOnce"]
    b5 -->|"الوضع فقط أولوية قصوى"| b7["xcopy"]
    b7 -.-> b8["إن عزمت الإمساك بمنصّة التحديث فـ updater خاص"]

الشكل 2: إن تحيّرت، افصل بهذا الترتيب: كثافة التسجيل، ثمّ identity، ثمّ سهولة التوزيع.

1.1 مصطلحات تظهر في المتن

حول التوزيع كثير من المصطلحات المتداولة بالإنكليزية كما هي، فنرتّبها أوّلاً.

1.2 ماذا يوجد في ورقة العمل في المقدّمة

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

ورقة Planner تنقسم إلى ثلاث كتل.

1. ورقة الإدخال: ملء البنود السبعة التالية يتيح كتابة المرشّح الأوّل والسبب
   • نطاق التوزيع … per-user / per-machine / كلاهما / غير مقرَّر
   • عناصر التكامل مع نظام التشغيل … لا يوجد / خدمة / تعريف / امتداد Shell / تسجيل COM / عدّة
   • package identity … لازم / غير لازم / لا يمكن الحكم
   • متطلّب التثبيت بمستخدم قياسي … إلزامي / غير لازم / حسب الشرط
   • وتيرة التحديث … يدوي أو نادر / شهري / أسبوعي / أعلى
   • البيئة المستهدفة … مغلقة / غير متّصلة / Windows جديد مُدار / Windows مختلط الأجيال القديمة / USB وميدان
   • مذكّرة نوع التطبيق … سطح مكتب .NET داخلي / منتج تجاري / أداة مساعدة / مختلط
2. تمييز المرشّحين: لكلّ أسلوب من الخمسة «شرط يُنظَر فيه بقوّة أوّلاً» و«شرط يسهل استبعاده أوّلاً»
3. تدفّق الحكم: بأيّ ترتيب ترى البنود أعلاه، وإلى أيّ أسلوب تميل النتيجة

ورقة Reference تحمل جدول حكم الفصل 3 وجدول مقارنة الفصل 4 كما هما.

أي أنّها فصول 3 و4 و7 من المقالة بشكل يمكن ملؤه لكلّ قضية. إن خرجت الخلاصة بالقراءة وحدها فلا حاجة للتنزيل. استخدمها حين تريد مقارنة قضايا عدّة، أو إبقاء حجّة الحكم داخل الشركة.

flowchart TB
    accTitle: كيف تستخدم ورقة العمل
    accDescr: مخطّط يعرض تدفّق ورقة عمل تسجّل الحكم لكلّ قضية: املأ البنود السبعة في ورقة الإدخال، وضيّق بتمييز المرشّحين وتدفّق الحكم، واكتب المرشّح الأوّل والسبب.
    c1["املأ بنود ورقة الإدخال السبعة"] --> c2["ضيّق بتمييز المرشّحين"]
    c2 --> c3["مل إلى أسلوب بتدفّق الحكم"]
    c3 --> c4["اكتب المرشّح الأوّل والسبب"]
    c4 -.-> c5["ورقة Reference جداول الفصلين 3 و4"]

الشكل 3: ورقة العمل لتحويل حكم المقالة إلى سجلّ لكلّ قضية.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 17، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. الخمسة ليست على الملعب نفسه

هذه نقطة مهمّة جدّاً.

MSI / MSIX / ClickOnce / xcopy حديث أساساً عن كيف تُدخل. أما الـ updater الخاص فحديث أساساً عن كيف تحمل مسؤولية التحديث.

أي أنّه عمليّاً أسهل ترتيباً التفكير في طبقتين.

بالرسم كالتالي. الخطّ المتقطّع «وسيلة تحديث تتّصل بسلاسة إن اخترت أسلوب التثبيت ذلك».

flowchart TB
    APP["تطبيق Windows المراد توزيعه"] --> Q1["أوّلاً: كيف تُدخل<br/>طبقة التثبيت الأوّل"]
    APP --> Q2["ثمّ: من يحمل مسؤولية التحديث<br/>طبقة التحديث المستمر"]

    Q1 --> MSI["MSI"]
    Q1 --> MSIX["MSIX"]
    Q1 --> CO["ClickOnce"]
    Q1 --> XC["xcopy"]

    Q2 --> AI["MSIX App Installer"]
    Q2 --> COU["تحديث ClickOnce المضمَّن"]
    Q2 --> MAN["استبدال يدوي"]
    Q2 --> OWN["updater خاص"]

    MSIX -.-> AI
    CO -.-> COU
    MSI -.-> MAN
    XC -.-> MAN
    MSI -.-> OWN
    XC -.-> OWN

الشكل 4: نموذج الطبقتين: التثبيت الأوّل والتحديث المستمر. الخطّ المتقطّع وسيلة تحديث تتّصل بسلاسة.

ClickOnce وMSIX إذا قرّرت الطبقة العليا تقرّر الطبقة السفلى تقريباً. في المقابل MSI وxcopy يحتاجان تقرير الطبقة السفلى على حدة. «كيف تحدّث» يسهل أن يظلّ معلَّقاً حين تختار هذين.

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

flowchart TB
    accTitle: التحديث يظلّ معلَّقاً مع MSI وxcopy
    accDescr: مخطّط يبيّن أنّ اختيار ClickOnce وMSIX يقرّر تقريباً وسيلة التحديث أيضاً، بينما MSI وxcopy يحتاجان تقرير طبقة التحديث المستمر على حدة، وأنّ الـ updater الخاص يُختار إضافة حين لا تكفي متطلّبات التحديث تلك.
    d1["اختيار ClickOnce / MSIX"] --> d2["وسيلة التحديث تُقرَّر تقريباً"]
    d3["اختيار MSI / xcopy"] --> d4["كيف تحدّث يظلّ معلَّقاً"]
    d4 --> d5["قرّر طبقة التحديث المستمر على حدة"]
    d5 -.-> d6["أضِف updater خاص حين لا يكفي"]

الشكل 5: الـ updater الخاص ليس الخيار الأوّل بل إضافة تسدّ ثغرة طبقة التحديث.

3. جدول حكم في صفحة واحدة

أوّلاً أضع أسهل جدول حكم استخداماً.

أهمّ ما في هذا الجدول ألّا تقفز إلى updater خاص لمجرّد وجود تحديث.

4. مقارنة حسب الزاوية

ما يُنظَر إليه في هذا الجدول ليس ما هو الأقوى بل ما فيه أقلّ احتكاك.

5. أيّ القضايا تناسب كلّ أسلوب

5.1 MSI

MSI نقطة مرجعية حين تريد تثبيت / إلغاء / إصلاح تطبيق سطح مكتب Windows تقليدي بشكل سليم.

ما يناسبه خصوصاً قضايا كهذه.

• تطبيق عمل لكلّ المستخدمين
• تطبيق يشمل خدمة Windows
• تطبيق يصحبه تسجيل COM أو ربط ملفّ أو إعداد على مستوى الجهاز
• منتج يوجد له تشغيل مثبِّت قائم

قوّة MSI أنّها تسهّل التعبير بأسلوب Windows عن «كيف أُدخل التطبيق في نظام التشغيل».

في المقابل نقاط الضعف واضحة أيضاً.

• إنشاء المثبِّت (authoring) صعب بشكل هادئ
• تصميم upgrade / patch بلا رويّة يسهّل المعاناة لاحقاً
• كلّما زادت custom action ازداد الكسر
• في منتج عالي وتيرة التحديث تثقل تجربة التحديث بسهولة

flowchart TB
    accTitle: قوّة MSI وثمنها
    accDescr: مخطّط يبيّن أنّ MSI تسهّل التعبير بأسلوب Windows عن كيف أُدخل التطبيق في نظام التشغيل، بينما إنشاء المثبِّت صعب، وكلّما زادت custom action ازداد الكسر، وتثقل تجربة التحديث في التحديث العالي الوتيرة.
    e1["MSI"] --> e2["التعبير بأسلوب Windows عن طريقة الإدخال في نظام التشغيل"]
    e2 --> e3["اكتمال install / uninstall / repair"]
    e1 -.-> e4["إنشاء المثبِّت صعب بشكل هادئ"]
    e4 -.-> e5["كلّما زادت custom action ازداد الكسر"]

الشكل 6: MSI تحمل صعوبة إنشاء المثبِّت مقابل قدرة التعبير عن التكامل مع نظام التشغيل.

5.2 MSIX

MSIX اختيار تريد فيه تغليفاً حديثاً وclean update / uninstall. ومعناه يكبر أيضاً حين تريد وظائف Windows تحتاج package identity.

ما يناسبه تقريباً هذا.

• تطبيق سطح مكتب يمكنه افتراض Windows 10/11
• تطبيق عمل أعلى وتيرة تحديث نسبيّاً
• تطبيق يريد وظائف Windows يؤثّر فيها package identity
• قضية تريد التقريب إلى Intune أو App Installer

قوّة MSIX نظافة التحديث وإلغاء التثبيت.

لكن ليس كلّ شيء يدخل. خصوصاً هذه الأربع أأمن فحصها أوّلاً.

• امتداد Shell داخل العملية (من Windows 11 21H2 يمكن لـ MSIX تسجيل legacy context menu handler وغيره، لكن يلزم إعلان في البيان وفحص نظام التشغيل المستهدف)
• تعريف
• افتراض Win32 قديم غير مقيَّد
• تركيب لا تريد فيه package identity

هذه الأربع تختلف جهة الفحص لكلّ منها. إن لم تتوقّف عند «يبدو أنّ MSIX مستحيل» وقرّرت حتى أيّ مصدر يحسم، كان أسرع.

روابط الكلّ في مراجع الفصل 9. عند الحكم انظر حتى «من أيّ إصدار، وبأيّ إعلان يُدعَم» لا «هل يُدعَم» فقط. إن لم تُمسَك مع شروط إصدار نظام التشغيل، تظهر لاحقاً بشكل «عمل على جهاز التحقّق ولم يدخل على Windows القديم في الميدان».

flowchart TB
    accTitle: قيود MSIX تُحسَم حتى جهة الفحص
    accDescr: مخطّط يبيّن أنّ النقاط الأربع التي تتحيّر فيها مع MSIX مثل امتداد Shell والتعريف تختلف مصادر فحصها، لذا لا تتوقّف عند «يبدو مستحيلاً» وانظر حتى من أيّ إصدار وبأيّ إعلان يُدعَم، فتمنع حادثة العمل على جهاز التحقّق والفشل في الميدان.
    f1["أربع نقاط تتحيّر فيها مع MSIX"] --> f2["لا تتوقّف عند «يبدو مستحيلاً»"]
    f2 --> f3["قرّر أيّ مصدر يحسم"]
    f3 --> f4["انظر حتى من أيّ إصدار وبأيّ إعلان يُدعَم"]
    f4 -.-> f5["امنع تحقّق الجهاز ورفض الميدان"]

الشكل 7: قيود MSIX تُحسَم بفحص شروط إصدار نظام التشغيل وطريقة الإعلان.

5.3 ClickOnce

ClickOnce ما زال قويّاً جدّاً حين تريد إدارة تطبيق سطح مكتب .NET داخلي per-user بسرعة، مع التحديث.

ما يناسبه مشاهد كهذه.

• تطبيق عمل داخلي
• تريد التثبيت بمستخدم قياسي
• التوزيع بوحدة المستخدم يكفي
• لا تريد بناء تجربة تحديث إلى ذلك الحدّ

في المقابل أأمن ألّا تتوقّع منه منتجاً يلمس نظام التشغيل بعمق، ولا دوراً مثبِّتاً يجمع عدّة افتراضات.

5.4 xcopy

xcopy توزيع (deploy) لا تثبيت (install). لا تسجيل في السجلّ، ولا وظيفة إصلاح، ولا package identity. مقابل ذلك، إن كفى الوضع فهو في طبقة الأقوى بساطة.

طبعها يظهر في أدوات كهذه.

• أدوات تشخيص
• أدوات إعداد أجهزة
• أدوات جمع سجلّات
• أدوات مساعدة تُسلَّم USB إلى الميدان
• حالات تريد تعايش عدّة إصدارات side-by-side

قوّة xcopy أنّ شكل الفشل واضح. سهولة التشغيل: استبدل المجلد كلّه، وإن أردت الرجوع فارجع إلى الإصدار السابق.

flowchart TB
    accTitle: xcopy توزيع لا تثبيت
    accDescr: مخطّط يبيّن أنّ xcopy لا يحمل تسجيلاً في السجلّ ولا إصلاحاً ولا package identity، مقابل الاكتفاء بالوضع، واستبدال المجلد كلّه عند التحديث والرجوع إلى الإصدار السابق عند الإعادة، أي تشغيل شكل فشله واضح.
    g1["ضع المجلد كلّه"] --> g2["يعمل كما هو"]
    g2 --> g3["التحديث استبدال المجلد كلّه"]
    g3 --> g4["الرجوع إعادة الإصدار السابق"]
    g1 -.-> g5["لا تسجيل ولا إصلاح ولا identity"]

الشكل 8: قيمة xcopy في بساطة التثبيت والتحديث والإعادة.

لكن بطبيعة الحال توجد أوجه ضعف.

• قائمة ابدأ / ARP / repair
• ربط ملفّ / خدمة / امتداد Shell / تعريف
• تحديث مضمَّن

5.5 updater خاص

الـ updater الخاص اختيار مسؤولية أكثر من اختيار حرّية.

يستحقّ النظر حين توجد متطلّبات كهذه.

• وتيرة التحديث عالية
• تريد قنوات مثل stable / beta / preview
• تريد التحكّم بالتوزيع المتدرّج ونسبة الطرح
• تريد التحكّم الدقيق بتنزيل الخلفية والإشعارات وفترة الصيانة
• تريد رؤية قياس الاستخدام أو استعادة الانهيار بنفسك

القوّة كبيرة، وما تدفعه كبير أيضاً.

• التحقّق من التوقيع
• بيان التوزيع
• إعادة المحاولة / الاستئناف
• الوكيل / الجدار الناري / الشبكة المغلقة
• rollback
• استعادة التحديث التالف
• تحديث الـ updater نفسه

أي أنّ المسؤولية تزيد لا الحرّية.

flowchart TB
    accTitle: الـ updater الخاص اختيار مسؤولية
    accDescr: مخطّط يبيّن أنّ الـ updater الخاص اختيار تحصل فيه على حرّية مثل القنوات والتوزيع المتدرّج وقياس الاستخدام، مقابل تحمّل تصميم وتشغيل التحقّق من التوقيع وبيان التوزيع وrollback واستعادة التحديث التالف وتحديث الـ updater نفسه.
    h1["ما تحصل عليه: قنوات · توزيع متدرّج · قياس استخدام"] --> h3["updater خاص"]
    h2["ما تدفعه: تحقّق توقيع · rollback · استعادة"] --> h3
    h3 --> h4["المسؤولية تزيد لا الحرّية"]
    h2 -.-> h5["تحديث الـ updater نفسه أيضاً عملك"]

الشكل 9: ما يزيده الـ updater الخاص ليس الحرّية بل مسؤولية تشغيل منصّة التحديث.

5.6 بعد تقرير الأسلوب، ماذا تبحث لاحقاً

حتى إن قرّرت «نمضي بـ MSI»، تتوقّف إن لم تعرف ماذا تبحث بعد ذلك. نرتّب مداخل تمثيلية. ليست «استخدم هذا»، بل إن اخترت ذلك الأسلوب، يستحقّ معرفة الاسم أوّلاً.

هنا انتبه إلى أنّ اختيار الأداة واختيار الأسلوب أمران مختلفان. مثلاً Inno Setup سهل التعامل، لكن الناتج ليس MSI، فلا يركب تشغيلاً يفترض Windows Installer مثل توزيع البرمجيات بسياسة المجموعة أو الإصلاح بـ msiexec. إن كان سبب اختيار MSI في 5.1 هناك، يلزم مواءمة الأداة أيضاً.

flowchart TB
    accTitle: اختيار الأداة واختيار الأسلوب أمران مختلفان
    accDescr: مخطّط يبيّن أنّ Inno Setup سهل التعامل لكن الناتج ليس MSI، فلا يركب توزيع البرمجيات بسياسة المجموعة أو الإصلاح بـ msiexec، لذا يلزم اختيار الأداة موافقاً سبب اختيار الأسلوب.
    i1["قرّر الأسلوب"] --> i2["قرّر الأداة"]
    i2 -.-> i3["Inno Setup لا يصنع MSI"]
    i3 -.-> i4["لا يركب توزيع GPO ولا إصلاح msiexec"]
    i4 -.-> i5["وائِم الأداة مع سبب اختيار الأسلوب"]

الشكل 10: الأداة المريحة لا تركب بالضرورة ملعب الأسلوب الذي اخترته.

6. نقاط يسهل التحيّر فيها

6.1 هل تحتاج package identity

إن كان المراد وظائف Windows تفترض package identity، تقفز قيمة MSIX دفعة واحدة.

في المقابل،

• وصول غير مقيَّد إلى نظام الملفّات
• وصول غير مقيَّد إلى السجلّ
• حرّية الترقية / نموذج العملية
• إبقاء افتراض Win32 القديم كما هو

فالأسلوب الأميل إلى unpackaged أطبيعي.

flowchart TB
    accTitle: افصل حسب لزوم package identity
    accDescr: مخطّط يبيّن أنّ طلب وظائف Windows تفترض package identity يقفز قيمة MSIX دفعة واحدة، وأنّ الوصول غير المقيَّد إلى الملفّات والسجلّ وإبقاء افتراض Win32 القديم يجعل الأسلوب الأميل إلى unpackaged أطبيعي.
    j1{"هل تريد وظائف تفترض package identity؟"} -->|"نعم"| j2["تقفز قيمة MSIX دفعة واحدة"]
    j1 -->|"تريد عملاً غير مقيَّد"| j3["الأسلوب الأميل إلى unpackaged أطبيعي"]

الشكل 11: لزوم identity خطّ تقسيم بين packaged وunpackaged.

6.2 هل توجد خدمة / تعريف / امتداد Shell

هذه الثلاثة تثقل أسلوب التوزيع دفعة واحدة.

• تعريف: لا يناسب MSIX
• امتداد Shell داخل العملية: لا يناسب MSIX
• خدمة Windows: MSI طبيعي، وMSIX أيضاً مقارنة مشروطة

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

6.3 per-user أم per-machine

إن مضيت وهذا غامض، تتشاجر حتماً لاحقاً.

• تريد الميل إلى per-user
  • ClickOnce
  • xcopy
  • بعض MSIX
• تريد الميل إلى per-machine
  • MSI
  • MSIX إن وافقت الشروط

«تريد التثبيت بلا امتيازات مدير» و«تريد أن يستخدم كلّ المستخدمين من الموضع نفسه» ليسا الشيء نفسه.

flowchart TB
    accTitle: لا تخلط per-user وper-machine
    accDescr: مخطّط يبيّن أنّ الميل إلى per-user يرشّح ClickOnce أو xcopy أو بعض MSIX، والميل إلى per-machine يرشّح MSI أو MSIX إن وافقت الشروط، وأنّ التثبيت بلا صلاحيات واستخدام كلّ المستخدمين من الموضع نفسه حديثان مختلفان.
    k1["تريد الميل إلى per-user"] --> k2["ClickOnce / xcopy / بعض MSIX"]
    k3["تريد الميل إلى per-machine"] --> k4["MSI / MSIX إن وافقت الشروط"]
    k1 -.-> k5["التثبيت بلا صلاحيات وموضع مشترك للجميع حديثان مختلفان"]

الشكل 12: إن مضيت ونطاق التثبيت غامض، تتشاجر حتماً لاحقاً.

6.4 وتيرة التحديث ومسؤولية التشغيل

بحسّ وتيرة التحديث تقريباً كالتالي.

• تحديث ربعي إلى شهري: MSI يكفي لإدارته
• تحديث شهري إلى أسبوعي: MSIX / ClickOnce أريح بكثير
• تحديث أسبوعي إلى يومي: يظهر سبب النظر في updater خاص
• التحديث يدوي يكفي / جهة الوضع تتحكّم: xcopy يكفي

أسلوب التوزيع اختيار تقنية وفي الوقت نفسه تصميم تشغيل.

flowchart TB
    accTitle: سلّم وتيرة التحديث
    accDescr: مخطّط يعرض مؤشّر وتيرة التحديث: الربعي إلى الشهري يكفي فيه MSI، والشهري إلى الأسبوعي يصير فيه MSIX أو ClickOnce أريح بكثير، والأسبوعي إلى اليومي يظهر فيه سبب النظر في updater خاص، والتحديث اليدوي يكفي فيه xcopy.
    m1["ربعي〜شهري: MSI يكفي"] --> m2["شهري〜أسبوعي: MSIX / ClickOnce أريح"]
    m2 --> m3["أسبوعي〜يومي: يظهر سبب النظر في updater خاص"]
    m1 -.-> m4["إن كفى اليدوي فـ xcopy يكفي"]

الشكل 13: كلّما ارتفعت وتيرة التحديث زادت قيمة التحديث المضمَّن أو المنصّة الخاصّة.

6.5 التوزيع المغلق وغير المتّصل

في الشبكة المغلقة كثيراً ما تفوز البساطة على التحديث التلقائي الأنيق.

• xcopy قوي
• MSI قوي أيضاً
• ClickOnce يعمل أيضاً بمشاركة ملفّ أو وسيط قابل للإزالة
• MSIX يعمل أيضاً حسب استخدام App Installer

لكن إن حدّثت بكثرة في شبكة مغلقة، إن لم تقرّر حتى «من يضع الإصدار الجديد أين، وكيف تُبقى الإصدارات القديمة»، يسهل انهيار التشغيل حتى بعد اختيار الأسلوب وحده.

flowchart TB
    accTitle: في الشبكة المغلقة تفوز البساطة
    accDescr: مخطّط يبيّن أنّ الشبكة المغلقة كثيراً ما تفوز فيها البساطة على التحديث التلقائي الأنيق، وأنّ التحديث المتكرّر إن لم يقرّر حتى من يضع الإصدار الجديد أين وكيف تُبقى الإصدارات القديمة يسهل انهيار التشغيل حتى بعد اختيار الأسلوب وحده.
    n1["بيئة مغلقة / غير متّصلة"] --> n2["البساطة تفوق التحديث التلقائي الأنيق"]
    n2 --> n3["xcopy وMSI قويان"]
    n2 -.-> n4["قرّر حتى من يضع الإصدار الجديد أين"]
    n4 -.-> n5["قرّر أيضاً كيف تُبقى الإصدارات القديمة"]

الشكل 14: في الشبكة المغلقة قرّر تشغيل وضع الإصدار الجديد والقديم قبل اختيار الأسلوب.

7. ستّ أسئلة تُرى أخيراً عند التحيّر

1. هل يكفي التطبيق للمستخدم الحالي فقط، أم يلزم إدخاله على مستوى الجهاز
2. هل توجد خدمة / تعريف / امتداد Shell / تسجيل COM
3. هل تستخدم وظائف Windows تحتاج package identity
4. هل تريد التثبيت بمستخدم قياسي فقط
5. هل وتيرة التحديث شهرية أم أسبوعية أم أعلى
6. هل البيئة المستهدفة مغلقة، وهل إصدارات نظام التشغيل متوائمة

الإجابة عن هذه الستّ وحدها تُظهر موضع الاستقرار تقريباً.

• 2 «نعم» → فكّر أوّلاً من جهة MSI
• 3 «نعم» → انظر في MSIX بأولوية
• 1 المستخدم الحالي، و4 «نعم»، وتطبيق سطح مكتب .NET → ClickOnce خيار قوي
• 4 «نعم»، و2 «لا»، وتشغيل الوضع فقط يكفي → xcopy خيار قوي
• 5 عالية، وتريد الإمساك بتجربة التحديث قيمة منتج → أدخل الـ updater الخاص في المقارنة

flowchart TB
    accTitle: موضع الاستقرار من ستّ أسئلة
    accDescr: مخطّط يبيّن موضع الاستقرار: إن وُجد تكامل مع نظام التشغيل مثل خدمة أو تعريف فكّر أوّلاً من جهة MSI، وإن لزم package identity فانظر في MSIX بأولوية، وإن كان تطبيق سطح مكتب .NET per-user بمستخدم قياسي فـ ClickOnce قوي، وإن كفى تشغيل الوضع فقط فـ xcopy قوي، وإن أردت الإمساك بتجربة التحديث فأدخل الـ updater الخاص في المقارنة.
    p1{"هل يوجد تكامل مع نظام التشغيل (خدمة وغيرها)؟"} -->|"نعم"| p2["فكّر أوّلاً من جهة MSI"]
    p1 -->|"لا"| p3{"هل يلزم package identity؟"}
    p3 -->|"نعم"| p4["انظر في MSIX بأولوية"]
    p3 -->|"لا"| p5{"per-user + تثبيت بمستخدم قياسي؟"}
    p5 -->|"إن كان سطح مكتب .NET"| p6["ClickOnce خيار قوي"]
    p5 -->|"إن كان تشغيل الوضع فقط"| p7["xcopy خيار قوي"]
    p6 -.-> p8["إن أردت الإمساك بتجربة التحديث قارن أيضاً updater خاص"]

الشكل 15: تتبّع إجابات الستّ بهذا الترتيب يُظهر موضع الاستقرار تقريباً.

8. الخلاصة

أسلوب توزيع تطبيق Windows يُختصَر كثيراً في هذه الجملة.

افصل وقرّر كيف يُقام التثبيت الأوّل ومن يحمل مسؤولية إدارة التحديث المستمر.

بعد ذلك، الحكم العملي التقريبي كالتالي.

• MSI: تطبيق سطح مكتب تقليدي يُدخل بعمق في نظام التشغيل
• MSIX: تطبيق يريد package identity وتغليفاً / تحديثاً حديثاً
• ClickOnce: تريد توزيع تطبيق عمل .NET per-user بسهولة مع التحديث
• xcopy: أداة مكتفية ذاتياً يكفي وضعها
• updater خاص: منتج عنده عزم تصميم التحديث نفسه وتشغيله داخل الشركة

ثمّ الأهمّ هذا.

• إن وُجد تعريف / امتداد Shell / خدمة، فأسلوب التوزيع لا يُقرَّر بالمظهر الأخير بل من أسلوب التكامل مع نظام التشغيل
• إن لزم package identity، فمعنى MSIX كبير
• الـ updater الخاص ورقة أخيرة لا الخيار الأوّل
• في الشبكة المغلقة كثيراً ما تفوز البساطة على الذكاء

إن تحيّرت، فتثبيت per-user أم per-machine، وماذا تسجّل في نظام التشغيل، وكم وتيرة التحديث فقط أوّلاً، يمضي الحديث إلى الأمام كثيراً.

flowchart TB
    accTitle: ثلاثة تثبّتها أوّلاً
    accDescr: مخطّط يبيّن أنّك إن تحيّرت فتثبيت per-user أم per-machine، وماذا تسجّل في نظام التشغيل، وكم وتيرة التحديث فقط أوّلاً، يمضي حديث أسلوب التوزيع إلى الأمام كثيراً.
    q1["per-user أم per-machine"] --> q4["ثبّتها أوّلاً"]
    q2["ماذا تسجّل في نظام التشغيل"] --> q4
    q3["كم وتيرة التحديث"] --> q4
    q4 --> q5["يمضي الحديث إلى الأمام كثيراً"]

الشكل 16: إن تحيّرت في الأسلوب، ثبّت هذه الثلاث فقط أوّلاً.

9. روابط مرجعية

• Microsoft Learn, Windows Installer
• Microsoft Learn, What is MSIX?
• Microsoft Learn, Packaging overview for Windows apps
• Microsoft Learn, MSIX features and supported platforms
• Microsoft Learn, Support legacy context menus for packaged apps
• Microsoft Learn, App Installer file overview
• Microsoft Learn, Prepare to package a desktop application
• Microsoft Learn, Know your installer
• Microsoft Learn, Convert an installer that includes services
• Microsoft Learn, ClickOnce deployment and security
• Microsoft Learn, Manage updates for a ClickOnce application
• Microsoft Learn, Choosing a ClickOnce deployment strategy
• Microsoft Learn, ClickOnce cache overview
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما الفرق بين MSI وMSIX؟

MSI صيغة المثبِّت التقليدية في Windows، تتوافق مع التثبيت per-machine، وخدمات Windows، وتسجيل COM، وامتداد Shell الذي يلمس نظام التشغيل بعمق، ويعبّر عن install / uninstall / repair بأسلوب Windows. MSIX تغليف حديث يفترض Windows 10/11، وقوّته clean install / clean uninstall والتحديث المتكرّر وpackage identity. في المقابل MSIX لا يناسب التعريفات، وامتداد Shell داخل العملية مدعوم بشروط من Windows 11 21H2 فصاعداً، ولا يناسب افتراض Win32 القديم غير المقيَّد. إن كان التسجيل في نظام التشغيل كثيفاً فابدأ من MSI؛ وإن أردت package identity ونظافة التحديث فابدأ من MSIX.

أيّهما تختار: MSIX أم ClickOnce؟

إن أردت توزيع تطبيق عمل .NET داخلي per-user بسهولة مع تحديث تلقائي، فما زال ClickOnce خياراً قويّاً جدّاً. نموذج التحديث المضمَّن سهل الاستخدام، ويمكن التثبيت بصلاحيات مستخدم قياسية، ولا تحتاج بناء تجربة تحديث. في المقابل إن أردت وظائف Windows تحتاج package identity، أو أوليت نظافة install / uninstall، أو أردت التقريب إلى Intune أو App Installer، فـ MSIX خيار قوي. كلاهما لا يناسب منتجاً يلمس نظام التشغيل بعمق، فإن وُجدت خدمة أو تعريف فكّر من جهة MSI.

هل ما زال ClickOnce صالحاً؟ أليس تقنية قديمة؟

ما زال صالحاً، وفي المشاهد المناسبة خيار قوي جدّاً. ينفع حين تريد توزيع تطبيق سطح مكتب .NET داخلي بسرعة، بوحدة المستخدم (per-user)، بصلاحيات مستخدم قياسية، وإدارته بنموذج تحديث مضمَّن. في المقابل أأمن ألّا تتوقّع منه منتجاً يلمس نظام التشغيل بعمق مثل خدمة Windows أو تعريف أو امتداد Shell، ولا دوراً مثبِّتاً يجمع عدّة افتراضات. من زاوية وتيرة التحديث، إن كان التحديث شهريّاً إلى أسبوعي تقريباً، يمكن إدارة الأمر براحة كبيرة بـ ClickOnce أو MSIX.

متى تنظر في updater خاص؟

الـ updater الخاص ليس ما تختاره أوّلاً، بل ما تضيفه حين توجد متطلّبات تحديث لا تكفيها أساليب التوزيع القائمة. يستحق النظر حين تكون وتيرة التحديث عالية، أو تريد قنوات مثل stable / beta / preview، أو تريد التحكّم بالتوزيع المتدرّج ونسبة الطرح، أو تريد رؤية قياس الاستخدام أو استعادة الانهيار بنفسك. لكنّك تتحمّل تصميم وتشغيل التحقّق من التوقيع وبيان التوزيع وإعادة المحاولة وrollback واستعادة التحديث التالف وتحديث الـ updater نفسه، لذا يجب اعتباره اختياراً يزيد المسؤولية لا الحرّية.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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