ما هو ClickOnce: الآليّة والتحديث ومتى يلائم العمل ومتى لا يلائمه

عندما يدور الحديث عن توزيع تطبيقات سطح مكتب Windows على .NET، يخرج اسم ClickOnce بهدوء مرّة بعد مرّة من خلف MSI وMSIX.

والخطأ الشائع هو الانحراف بشدّة نحو أحد هذين الاتّجاهين:

• إنّها تقنيّة قديمة، فلا ينبغي استعمالها بعد الآن
• تبدو بسيطة، فبوسعنا غالباً استعمال ClickOnce لكلّ شيء

كلاهما عادةً خاطئ.

ClickOnce ليس installer شاملاً يستطيع فعل كلّ شيء. وفي الوقت نفسه، لتطبيقات .NET الداخليّة للأعمال حيث تريد التوزيع لمستخدمين قياسيّين وإبقاء التحديثات تعمل بتكلفة تشغيل منخفضة، فهو لا يزال خياراً قويّاً جدّاً.

تشرح هذه المقالة ما هو ClickOnce، وكيف يعمل، وما الذي يبرع فيه، وأين يصبح الأداة الخاطئة، مع عدد كبير نسبيّاً من رسوم Mermaid لتيسير متابعة البنية. يفترض النقاش بشكل أساسيّ معلومات Microsoft Learn التي أمكن التأكّد منها حتّى أبريل 2026.

هذه الرسوم رسوم مفاهيميّة. في بيئة Markdown تدعم Mermaid، تُعرض كرسوم.

القرّاء المستهدفون

كُتبت لـ مطوّرين ينظرون في كيفيّة توزيع تطبيق سطح مكتب Windows على .NET (WinForms / WPF) ولمسؤولي أنظمة معلومات يشغّلون ذلك التوزيع والتحديث. نفترض أنّ قرار استعمال ClickOnce لم يُحسَم بعد، لذلك نرتّب مواد الحكم أوّلاً، ونضع عمليّات النشر الفعليّة في 6.4.

مصطلحات يجدر ضبطها مسبقاً

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

جدول المحتويات

1. الخلاصة أوّلاً
2. ما هو ClickOnce
3. ممّ يتكوّن ClickOnce
4. من التثبيت إلى التشغيل
5. كيف يعمل التحديث
6. ما الذي يبرع فيه ClickOnce
7. أين يلائم
8. أين لا يلائم
9. مواضع يتعثّر فيها العمل الفعليّ
10. الخلاصة
11. مقالات ذات صلة
12. المراجع

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

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

إن لخّصنا ClickOnce في جملة، فهو تقنيّة توزيع لتطبيقات سطح مكتب Windows على .NET تسهّل التوزيع لكلّ مستخدم وتشمل التحديث التلقائيّ.

يميل إلى الملاءمة في حالات كهذه:

• تطبيقات WinForms / WPF داخليّة للأعمال
• تريد الإدخال لمستخدمين قياسيّين
• التوزيع per-user كافٍ
• تريد تحديثاً مضمَّناً built-in
• مسار التوزيع عبر موقع ويب أو مشاركة ملفّات يكفي

وعادةً ما يكون أكثر أماناً البدء بنموذج آخر إذا كنت تحتاج إلى:

• تثبيت machine-wide لكلّ المستخدمين
• Windows service، أو driver، أو in-process shell extension، أو تسجيل COM ثقيل
• package identity
• قنوات إصدار، أو إصدار تدريجيّ، أو UX مخصَّص للـ rollback
• installer بمسؤوليّات أكبر للاندماج العميق مع نظام التشغيل

فالخلاصة العمليّة بسيطة: ClickOnce قويّ في التوزيع السهل والتحديث السهل، لكنّه ليس ملاءمة جيّدة للتطبيقات ذات متطلّبات اندماج OS الثقيلة.

اطّلع على الموقع في صفحة واحدة أوّلاً

flowchart TD
    A["نريد توزيع تطبيق Windows"]
    B{"هل توجد متطلّبات لاندماج عميق مع OS؟"}
    C["ابدأ من جهة MSI / MSIX"]
    D{"هل هو تطبيق سطح مكتب Windows على .NET<br/>ويكفي التوزيع per-user؟"}
    E{"هل تريد التوزيع لمستخدمين قياسيّين؟"}
    F{"هل يكفي التحديث المضمَّن؟"}
    G["ClickOnce مرشّح قويّ"]
    H["قارن أيضاً xcopy / updater خاصّاً"]

    A --> B
    B -- نعم --> C
    B -- لا --> D
    D -- لا --> H
    D -- نعم --> E
    E -- لا --> H
    E -- نعم --> F
    F -- نعم --> G
    F -- لا --> H

2. ما هو ClickOnce

ClickOnce تقنيّة من Microsoft لتوزيع تطبيقات Windows. رسميّاً، يوصَف بأنّه تقنيّة توزيع لتطبيقات قائمة على Windows يمكن تثبيتها وتشغيلها بأقلّ قدر من تفاعل المستخدم وقادرة على تحديث نفسها.

الجزء المهمّ هو ألاّ تفكّر في ClickOnce بوصفه مجرّد «نوع من أنواع الـ installer».

في الواقع، ClickOnce هو نموذج توزيع يعتني بكلّ هذه الأمور معاً:

• أيّ إصدار يجب توزيعه
• أيّ ملفّات تنتمي إلى ذلك الإصدار
• كيف تُكتشَف التحديثات
• من أين تُحمَّل التحديثات
• كيف يُحفَظ التطبيق في موقع آمن لكلّ مستخدم
• كيف تُتحقَّق سلامته عند الإطلاق

فالمركز الحقيقيّ لـ ClickOnce ليس setup.exe نفسه. بل أقرب إلى منظومة محورها الـ manifest تتعامل مع التوزيع والتحديث وإدارة الـ cache معاً.

ولا يزال ClickOnce خياراً عاديّاً في .NET الحاليّ. في Visual Studio، تُستعمل Publish tool لـ .NET Core 3.1 و.NET 5 فما بعد، وإذا احتجت إلى التعامل مع manifests يدوياً، فالأداة هي dotnet-mage.exe.

المسؤوليّات التي يعتني بها ClickOnce

flowchart LR
    CO["ClickOnce"]
    V["أيّ إصدار يُوزَّع"]
    U["من أين تُجلَب التحديثات"]
    S["الحفظ في موقع آمن لكلّ مستخدم"]
    I["التحقّق من السلامة ثمّ التشغيل"]

    CO --> V
    CO --> U
    CO --> S
    CO --> I

3. ممّ يتكوّن ClickOnce

عندما تريد فهم آليّة عمل ClickOnce، يساعد كثيراً النظر إلى هذه القطع الأربع:

النواة هنا هي النوعان من الـ manifest.

• يقول الـ deployment manifest أيّ إصدار هو الصحيح حاليّاً
• يقول الـ application manifest ما الذي يقع داخل ذلك الإصدار

فاكتشاف التحديث يبدأ من الـ deployment manifest، بينما يحدّد الـ application manifest ما يحتاج فعليّاً إلى التحميل.

كيف ترتبط العناصر الأربعة

flowchart LR
    Setup["setup.exe<br/>اختياريّ<br/>فحص / إدخال المتطلّبات المسبقة"]
    Deploy["deployment manifest (.application)<br/>أيّ إصدار يُوزَّع<br/>مصدر التحديث / شروطه"]
    App["application manifest (*.exe.manifest)<br/>محتوى ذلك الإصدار<br/>قائمة الملفّات / hashes / نقطة الدخول"]
    Files["ملفّات التطبيق<br/>exe / dll / config / data"]
    Cache["ClickOnce cache<br/>per-user / per-application"]

    Setup --> Deploy
    Deploy --> App
    App --> Files
    Files --> Cache

setup.exe مساعد، لا الفاعل الرئيس

كثيراً ما يكون setup.exe هو الجزء المرئيّ، لكنّه ليس النقطة الرئيسة في ClickOnce. دوره فحص المتطلّبات المسبقة وإدخالها.

مثلاً، إذا احتاج التطبيق إلى .NET runtime الصحيح أو إلى مكوّنات قابلة لإعادة التوزيع إضافيّة، فبإمكان setup.exe تجهيز ذلك أوّلاً ثمّ تسليم التشغيل إلى توزيع ClickOnce نفسه.

4. من التثبيت إلى التشغيل

إذا بسّطنا تدفّق ClickOnce للعمل العمليّ، يبدو كما يلي:

1. يفتح المستخدم setup.exe أو .application من صفحة ويب أو من مشاركة ملفّات
2. إذا كان التوزيع يستعمل setup.exe، تُفحَص المتطلّبات المسبقة وتُثبَّت الناقصة
3. يقرأ ClickOnce الـ deployment manifest
4. يقرأ الـ application manifest الذي يشير إليه الـ deployment manifest
5. تُجلَب الملفّات المطلوبة وتُوضَع في ClickOnce cache الخاصّ بكلّ مستخدم
6. إذا سمح الإعداد بالاستعمال دون اتّصال، يُسجَّل التطبيق في قائمة Start أو في قائمة التطبيقات
7. بعد ذلك، يُطلَق التطبيق تحت إدارة ClickOnce

النقطة الأساسيّة هي أنّ هذا ليس الفكرة نفسها التي يضع بها installer تقليديّ ملفّاتٍ تحت Program Files.

تذهب تطبيقات ClickOnce إلى موقع cache آمن لكلّ مستخدم، وتكون مفصولة لكلّ تطبيق ولكلّ مستخدم. هذا الفصل واحد من أهمّ خصائص ClickOnce.

من التثبيت إلى الإطلاق الأوّل

sequenceDiagram
    participant U as المستخدم
    participant P as setup.exe / .application
    participant D as deployment manifest
    participant A as application manifest
    participant C as ClickOnce cache
    participant X as التطبيق

    U->>P: فتح
    Note over U,P: في إعداد يستعمل setup.exe<br/>يأتي فحص المتطلّبات المسبقة أوّلاً
    P->>D: جلب وقراءة
    D->>A: الإشارة إلى الإصدار المستهدف
    A->>C: جلب الملفّات اللازمة والتحقّق من السلامة
    C->>X: وضع وتشغيل

المتاح عبر الشبكة فقط مقابل المتاح دون اتّصال

يقدّم ClickOnce التطبيق على نحو واسع بطريقتين:

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

لتطبيقات الأعمال الداخليّة، يكون الخيار العمليّ في الغالب متاح دون اتّصال.

flowchart LR
    subgraph Online[عبر الشبكة فقط]
        O1["التشغيل انطلاقاً من موقع النشر"]
        O2["شعور أضعف بالتثبيت الدائم"]
        O3["يميل إلى افتراض توفّر الشبكة"]
        O1 --> O2 --> O3
    end

    subgraph Offline[متاح دون اتّصال]
        F1["الإدخال في منطقة المستخدم"]
        F2["التسجيل في قائمة Start"]
        F3["التشغيل محلّيّاً"]
        F4["فحص التحديث في التوقيت المحدَّد"]
        F1 --> F2 --> F3 --> F4
    end

5. كيف يعمل التحديث

أوضح نقاط قوّة ClickOnce هي على الأرجح أنّ نموذج التحديث فيه مضمَّن.

اكتشاف التحديث يبدأ من الـ deployment manifest

تقرأ تطبيقات ClickOnce الـ deployment manifest لتفحص:

• ما إذا كان يوجد إصدار أحدث
• ما إذا كان التحديث إلزاميّاً
• من أين ينبغي تحميل التحديث

بمجرّد بدء التحديث، يستعمل ClickOnce file patching لتجنّب إعادات تحميل كاملة غير ضروريّة. عمليّاً، لا بأس بالتفكير فيه على أنّه مقارنة الـ application manifest الجديد بالحاليّ ثمّ تحميل الملفّات التي تغيّرت فقط.

الأنماط الشائعة لتوقيت التحديث هي هذه:

• الفحص قبل بدء التشغيل
• الفحص بعد بدء التشغيل
• توفير واجهة «التحقّق من التحديثات» داخل التطبيق

ومع ذلك، يختلف .NET Framework عن .NET 5+ في الـ APIs المتاحة وفي أسطح الإعداد. النقطة المهمّة ألاّ تبدأ التنفيذ من الذاكرة القديمة لـ ClickOnce وحدها.

تدفّق التحديث

flowchart TD
    Start["بدء التطبيق"]
    Check["فحص deployment manifest"]
    New{"هل يوجد إصدار أحدث؟"}
    Run["التشغيل كما هو"]
    Get["جلب application manifest الجديد"]
    Compare["مقارنة التوقيعات / hashes"]
    Download["جلب الأجزاء المتغيّرة فقط"]
    Switch["إقامة الإصدار الجديد والتبديل إليه"]
    Restart["إن لزم، تشغيل الإصدار الجديد بعد إعادة التشغيل"]

    Start --> Check --> New
    New -- لا --> Run
    New -- نعم --> Get --> Compare --> Download --> Switch --> Restart

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

الإصدارات تُحفَظ بشكل منفصل

ClickOnce أقرب إلى «إنشاء الإصدار الجديد بشكل صحيح ثمّ التبديل إليه» منه إلى «الكتابة فوق الملفّات الحاليّة في مكانها».

كذلك، يحتفظ ClickOnce cache بالـ إصدار الحاليّ والإصدار السابق بشكل منفصل. وذلك من الأسباب التي تجعل تجنّب تلويث البيئة أو تصادم الإصدارات أيسر.

flowchart TB
    subgraph UA[ClickOnce cache للمستخدم أ]
        APrev["الإصدار السابق"]
        ACur["الإصدار الحاليّ"]
        AData["إعدادات / بيانات"]
    end

    subgraph UB[ClickOnce cache للمستخدم ب]
        BPrev["الإصدار السابق"]
        BCur["الإصدار الحاليّ"]
        BData["إعدادات / بيانات"]
    end

    APrev --> ACur
    AData --> ACur
    BPrev --> BCur
    BData --> BCur

النقطتان العمليّتان هنا هما:

• يقلّ احتمال الخلط بين مستخدمين مختلفين
• يقلّ احتمال التصادم بين إصدارات مختلفة

هذا الانخفاض في خطر DLL Hell يأتي من هذه البنية أكثر ممّا يدركه الناس عادةً.

6. ما الذي يبرع فيه ClickOnce

قيمة ClickOnce ليست فقط أنّه سهل التوزيع. في العمل الفعليّ، هذه هي النقاط التي تهمّ أكثر.

6.1 من السهل التوزيع لمستخدمين قياسيّين

يلائم ClickOnce بطبيعته التوزيع per-user، وواحدة من أكبر نقاط قوّته أنّ التثبيت بدون صلاحيات المسؤول سهل نسبيّاً.

هذا موقف عمليّ شائع جدّاً في تطبيقات الأعمال الداخليّة:

• المستخدمون مستخدمون قياسيّون
• لا تريد فتح طلب تثبيت مع IT في كلّ مرّة
• لكن لا تريد أيضاً أن تتعطّل التحديثات

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

6.2 لست مضطرّاً إلى بناء updater خاصّ بك

إن بنيت التحديثات التلقائيّة من الصفر، يكبر حجم العمل أسرع ممّا يبدو في البداية:

• التحقّق من إصدار جديد
• تحميله
• التحقّق من السلامة
• التبديل من الإصدار القديم
• التعافي من الإخفاقات
• بناء واجهة التحديث
• التعامل مع الـ updater نفسه

يغطّي ClickOnce جزءاً كبيراً من ذلك بنموذج موجود مسبقاً.

flowchart LR
    subgraph Custom[مسؤوليّات يملكها updater خاصّ]
        C1["اكتشاف إصدار جديد"]
        C2["التحميل"]
        C3["التحقّق من السلامة"]
        C4["التبديل"]
        C5["التعافي من الإخفاق"]
        C1 --> C2 --> C3 --> C4 --> C5
    end

    subgraph Click[مسؤوليّات يمكن إسنادها إلى ClickOnce]
        K1["اكتشاف إصدار جديد"]
        K2["الجلب والتحقّق"]
        K3["التبديل"]
        K1 --> K2 --> K3
    end

ذلك لا يعني أنّه يتيح لك فعل كلّ شيء بحرّيّة. لكنّه يغطّي كثيراً من «سلوك التحديث الكافي» الذي تحتاجه تطبيقات الأعمال الداخليّة.

6.3 يقلّ احتمال تصادم التطبيقات بعضها مع بعض

تطبيقات ClickOnce مفصولة بحسب التطبيق وبحسب المستخدم وبحسب الإصدار.

يجعل ذلك من غير المحتمل الوقوع في مشكلات الطراز القديم مثل:

• تعارض إصدارات في مكوّنات مشتركة
• الكتابة فوق DLL وكسر تطبيق آخر
• تلويث البيئة عبر استبدال يدويّ

6.4 من السهل النشر من Visual Studio

يعمل ClickOnce جيّداً مع نشر Visual Studio، وهو ما يعني أيضاً أنّ المسافة من البناء إلى التسليم قصيرة.

قبل الدخول في نوع آخر من التعقيد مثل تأليف MSI، يكون من الأسهل:

• النشر أوّلاً
• التوزيع أوّلاً
• تشغيل التحديثات أوّلاً
• الحصول على الملاحظات من الميدان أوّلاً

الحدّ الأدنى لخطوات النشر

المفهوم وحده يُبقي المسافة بعيدة، لذلك نضع العمليّات الفعليّة أيضاً. لتطبيقات سطح مكتب Windows على .NET Core 3.1 / .NET 5 فما بعد تُستعمل Publish tool لا Publish Wizard القديمة. المستهدف Visual Studio 2019 الإصدار 16.8 فما بعد وVisual Studio 2022. تطبيقات .NET Framework لها معالج مختلف، فالخطوات تختلف.

1. في مستكشف الحلول انقر بزرّ الفأرة الأيمن على المشروع واختر «نشر». من القائمة يمكن ذلك عبر «بناء» ثمّ «نشر».
2. إن وُجد ملفّ نشر مسبقاً تُفتح صفحة «نشر»، فاختر «جديد».
3. في صفحة نوع وجهة النشر اختر «مجلّد».
4. في الصفحة التالية «هدف محدَّد» اختر «ClickOnce».
5. أدخل مسار وجهة النشر أو اختره عبر «استعراض». هنا مكان كتابة مخرجات البناء.
6. في صفحة «موقع التثبيت» حدّد من أين يُدخل المستخدم التطبيق. قد يختلف عن مكان الكتابة في الخطوة 5، وهذا أوّل موضع يتعثّر فيه الناس. اختر موقعاً على الويب، أو مشاركة UNC، أو CD / DVD / USB.
7. في صفحة «الإعدادات» قرّر إمكان الاستعمال دون اتّصال. إن فعّلته، يظهر التطبيق في قائمة Start ويُحدَّث تلقائيّاً عند نشر إصدار جديد. افتراضيّاً يكون مصدر التحديث هو موقع التثبيت نفسه. إن أردت مصدراً آخر، حدّده من إعدادات التحديث في هذه الصفحة. الموضع المحدَّد هنا يصبح deploymentProvider في 9.6.
8. من الرابط أعلى الصفحة نفسها «الإعدادات» تستطيع تحديد الملفّات المضمَّنة في التوزيع (Application Files)، وحزم المتطلّبات المسبقة (Prerequisites)، وخيارات أخرى. إصدار النشر، وما إذا كان يُرفَع تلقائيّاً في كلّ نشر، هنا أيضاً.
9. في صفحة «توقيع الـ manifest» تحدّد هل توقّع الـ manifests وبأيّ شهادة. هذا يتّصل بحديث 9.5.
10. في صفحة «التكوين» تختار تكوين البناء، وهل التطبيق يعتمد على الإطار أم مكتفٍ ذاتيّاً، ومعرّف وقت التشغيل المستهدف.
11. «إنهاء» يحفظ الملفّ، ثمّ في صفحة «الملخّص» تضغط «نشر» فيُنفَّذ البناء والنشر. من المرّة الثانية يكفي ضغط «نشر» في هذه الصفحة.

عمليّاً يجدر معرفة نقطتين مسبقاً:

• إصدار النشر مستقلّ لكلّ ملفّ ClickOnce. إن فصلت ملفّاً للتحقّق وآخر للإنتاج، تحتاج إلى إدارة رقم الإصدار لكلّ منهما بوعي.
• تنشئ Publish tool ملفّ نشر .pubxml. عند البناء من سطر أوامر MSBuild تحدّد هذا .pubxml. هذا مدخل وضعه على CI.

6.5 ترحيل الإعدادات سلس نسبيّاً

عندما تستعمل مزوّد إعدادات التطبيق الافتراضيّ، يمتلك ClickOnce آليّة لـ دمج إعدادات الإصدار السابق في الإصدار الجديد أثناء التحديثات.

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

7. أين يلائم

يلائم ClickOnce بشكل خاصّ حالات كهذه:

أمثلة محدَّدة كثيراً ما تلائم جيّداً:

• تطبيقات إدخال بيانات داخليّة
• أدوات أعمال لسطح المكتب لعروض الأسعار والطلبات والاستلام والمخزون
• تطبيقات مساعدة لتهيئة المعدّات
• عملاء داخليّون موزَّعون على فروع أو مصانع أو موظّفي مكاتب خلفيّة
• تطبيقات ينبغي أن تتحدّث، لكنّها لا تبرّر بناء updater مخصَّص

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

شجرة قرار لمعرفة الملاءمة

flowchart TD
    S["ترتيب المتطلّبات"]
    Q1{"هل هو تطبيق سطح مكتب .NET<br/>مثل WinForms أو WPF؟"}
    Q2{"هل يكفي التوزيع per-user؟"}
    Q3{"هل تريد الإدخال لمستخدم قياسيّ؟"}
    Q4{"هل يمكن التوزيع عبر الويب أو مشاركة ملفّات؟"}
    Q5{"هل يُقبل ألّا تُبنى واجهة التحديث بإفراط؟"}
    G["ClickOnce مرشّح قويّ جدّاً"]
    O["قارن مقاربات أخرى"]

    S --> Q1
    Q1 -- لا --> O
    Q1 -- نعم --> Q2
    Q2 -- لا --> O
    Q2 -- نعم --> Q3
    Q3 -- لا --> O
    Q3 -- نعم --> Q4
    Q4 -- لا --> O
    Q4 -- نعم --> Q5
    Q5 -- نعم --> G
    Q5 -- لا --> O

8. أين لا يلائم

ثمّة كذلك مواقف واضحة يكون فيها فرض ClickOnce عادةً قراراً خاطئاً.

8.1 تحتاج إلى تثبيت machine-wide

ClickOnce في جوهره نموذج per-user.

• تريد تثبيتاً واحداً يتشاركه كلّ المستخدمين
• تريد تثبيتاً تحت Program Files
• تريد توزيعه وإدارته على مستوى الجهاز كاملاً

إن كان ذلك هو المتطلّب، فإنّ MSI أو نموذج installer آخر عادةً أكثر طبيعيّة من ClickOnce.

8.2 Windows service، أو driver، أو shell extension، أو تسجيل COM ثقيل

هذه الفئة هي التي يلامس فيها التطبيق نظام التشغيل بعمق.

• Windows service
• driver
• in-process shell extension
• تصاميم تعتمد على تسجيل COM ميكانيكيّ

بمجرّد دخول هذه إلى الصورة، تصبح خارج رؤية «التوزيع الخفيف» الخاصّة بـ ClickOnce.

8.3 تحتاج إلى package identity

أحد أسباب اختيار MSIX هو حين يكون package identity نفسه جزءاً من المتطلّب.

ClickOnce ليس موجَّهاً في هذا الاتّجاه. إن كان ما تريده هو التعبئة الحديثة أو ميزات تعتمد على Windows package identity، فإنّ MSIX نقطة بداية أكثر طبيعيّة.

8.4 تريد امتلاك UX التحديث وقنوات التوزيع كجزء من المنتج

مثلاً، إذا أردت أموراً مثل:

• قنوات stable وbeta وpreview
• إصدار تدريجيّ
• التحكّم في الـ rollout بناءً على القياس عن بُعد
• تحكّم دقيق في التحميل في الخلفيّة
• استراتيجيّات rollback مخصَّصة
• دورة حياة أكثر تعقيداً للـ updater نفسه

فحينها يبدأ نموذج التحديث المضمَّن في ClickOnce في القصور.

8.5 أداة بسيطة تنسخ وتعمل تكفي

هناك أيضاً حالات يكون فيها الخيار الأبسط أفضل:

• يعمل التطبيق إذا وضعت المجلّد فقط
• الاستبدال اليدويّ يكفي للتحديثات
• يحدث التوزيع عبر USB
• البساطة تهمّ أكثر من أيّ شيء آخر في بيئة مغلقة

في حالات كهذه، يمكن أن يخلق توزيع xcopy احتكاكاً أقلّ.

أيّ متطلّبات تدفعك نحو نموذج آخر

flowchart LR
    A1["إدخال لكلّ المستخدمين"] --> B1["MSI / وفي بعض الحالات MSIX"]
    A2["service / driver / shell extension / COM ثقيل"] --> B2["MSI / installer مخصَّص"]
    A3["الحاجة إلى package identity"] --> B3["MSIX"]
    A4["إصدار تدريجيّ / قنوات / UX مخصَّص"] --> B4["updater خاصّ"]
    A5["النسخ يكفي"] --> B5["xcopy"]

فإذن ClickOnce ليس شاملاً في أيّ من الاتّجاهين. هو الأقوى في المشاريع ذات القدر الصحيح من التعقيد.

9. مواضع يتعثّر فيها العمل الفعليّ

ClickOnce مريح، لكن من السهل التعثّر إن دخلت إليه باستخفاف. هذه نقاط جديرة بالفهم مسبقاً بشكل خاصّ.

9.1 لا تنظر إليه بنفس النموذج الذهنيّ لـ installer تقليديّ

ClickOnce ليس نموذجاً يدير الناس فيه مباشرةً موقع تثبيت ثابت بطريقة سهلة التصفّح.

تعيش الملفّات الفعليّة في الـ cache الذي يديره ClickOnce، وهي مفصولة بحسب الإصدار. بسبب ذلك، لا يلائم جيّداً ممارسات مثل:

• عمليّات تفترض مساراً ثابتاً للـ EXE
• الكتابة اليدويّة فوق الملفّات في مكانها
• عمليّات يُتوقَّع فيها من البشر التحكّم المباشر في الموقع الفيزيائيّ للملفّ

ClickOnce ليس نموذج وضع ملفّات يديره الناس؛ هو نموذج لحالة التوزيع تديره الـ manifests.

9.2 كثير من مقالات ClickOnce القديمة تفترض .NET Framework

هذا يهمّ كثيراً.

حتّى الآن، كثير من النتائج العالية ترتيباً لـ ClickOnce في البحث مبنيّة على عصر .NET Framework. .NET الحديث مختلف قليلاً.

• على .NET Core 3.1 و.NET 5 و.NET 6، لا يمكن استعمال ApplicationDeployment API بالطريقة القديمة
• اعتباراً من .NET 7 وما بعده، يمكن قراءة بعض خصائص النشر عبر متغيّرات البيئة
• إن تعاملت مع manifests يدوياً، يصبح dotnet-mage.exe الأداة المعنيّة
• نشر Visual Studio أيضاً لم يعد يتطابق واحداً لواحد مع افتراضات Publish Wizard القديمة

فحتّى لو كنت تظنّ «أعرف ClickOnce بالفعل»، فمن الأكثر أماناً عدم تنفيذه من الذاكرة القديمة وحدها.

9.3 عامل المتطلّبات المسبقة بشكل منفصل

ClickOnce نموذج توزيع، لكنّ التطبيق قد لا يزال يعتمد على متطلّبات مسبقة:

• الـ runtime المطلوب
• مكوّنات قابلة لإعادة التوزيع إضافيّة
• تبعيّات أخرى

هنا يساعد إعداد bootstrapper باستعمال setup.exe. إذا بقي هذا الجزء غامضاً، تنتهي إلى «تمّ توزيعه بـ ClickOnce، لكنّه لا يعمل».

9.4 ترحيل الإعدادات يعتمد على ما تحفظه وكيف تحفظه

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

• مزوّد إعدادات مخصَّص
• سلوك موجَّه نحو الـ roaming
• موقع حفظ مخصَّص خاصّ بك
• تغييرات هيكليّة كبيرة في الإعدادات بين الإصدارات

9.5 لا تستهن بالتوقيع وبمسارات التحديث

يعطيك ClickOnce آليّة توزيع وتحديث، لكنّ ذلك لا يجعل المسؤوليّة الأمنيّة تختفي.

خاصّةً في الإنتاج، يستحقّ ترتيب الأمور التالية مبكّراً:

• كيف تُدار شهادات التوقيع
• كيف يُعرض اسم الناشر
• كيف يُتحكَّم في مصدر التحديث
• كيف تُفصَل الشهادات الموقَّعة ذاتيّاً وقت الاختبار عن توقيع الإنتاج

flowchart TD
    Cert["شهادة code signing"]
    AppMan["application manifest"]
    DepMan["deployment manifest"]
    Verify["التحقّق على العميل"]
    Run["تحديث / تشغيل"]
    Tamper["التلاعب بالـ manifest"]
    Stop["التوقّف عند فشل التحقّق"]

    Cert --> AppMan
    Cert --> DepMan
    AppMan --> Verify
    DepMan --> Verify
    Verify --> Run
    Tamper -. فشل التحقّق .-> Stop

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

9.6 راجع deploymentProvider إذا حرّكت موقع النشر

هذه نقطة دقيقة، لكنّها تسبّب كثيراً من المتاعب في العمل الفعليّ.

ينظر تطبيق ClickOnce المثبَّت إلى الموقع المُشار إليه بـ deploymentProvider في الـ deployment manifest باعتباره مصدر التحديث. يعني ذلك أنّك حتّى لو نسخت كامل المجلّد المنشور إلى URL آخر أو مشاركة أخرى، قد يستمرّ العملاء في النظر إلى الموقع القديم ما لم يُحدَّث deploymentProvider.

وبمجرّد أن تعدّل الـ manifest يدوياً، تحتاج إلى توقيعه مرّة أخرى.

تدفّق التشغيل من النشر إلى التقاط التحديث

flowchart TD
    Build["البناء"]
    AppManifest["توليد application manifest الجديد"]
    SignApp["توقيع application manifest"]
    UpdateDep["تحديث deployment manifest إلى الإصدار الجديد"]
    SignDep["توقيع deployment manifest"]
    Publish["وضعه في موقع النشر"]
    Client["اكتشاف العميل للتحديث"]

    Build --> AppManifest --> SignApp --> UpdateDep --> SignDep --> Publish --> Client

فالنقطة العمليّة هي أنّ ما يهمّ في تشغيل ClickOnce ليس فقط ما إذا كانت الملفّات قد وُضعت في مكان ما، بل ما إذا كانت الـ manifests والتوقيعات تبقى متّسقة بعضها مع بعض.

10. الخلاصة

في جملة واحدة، ClickOnce هو:

طريقة لتوزيع تطبيقات سطح مكتب Windows على .NET per-user، ببساطة، ومع تحديثات بتكلفة تشغيل منخفضة نسبيّاً

نقاط قوّته الرئيسة:

• من السهل التوزيع لمستخدمين قياسيّين
• يمتلك نموذج تحديث مضمَّناً
• يستطيع تحديث الأجزاء التي تغيّرت فقط بكفاءة
• يفصل التطبيقات والإصدارات بنظافة
• من السهل النشر من Visual Studio
• يلائم تطبيقات الأعمال الداخليّة جيّداً

لكنّه ليس شاملاً.

• التثبيت machine-wide
• services وdrivers وshell extensions
• تسجيل COM ثقيل
• package identity
• قنوات مخصَّصة أو إصدار تدريجيّ
• UX التحديث المعالَج كجزء من قيمة المنتج

إن كانت هذه متطلّبات حقيقيّة، فعليك البدء من MSI أو MSIX أو updater مخصَّص بدلاً من فرض ClickOnce.

فإذن ClickOnce ليس installer بسيطاً يتقبّل أيّ شيء. ما هو عليه، بدلاً من ذلك، أنّه لا يزال خياراً قويّاً جدّاً حيث يلائم المشروع جيّداً.

إن كان ما تريد توزيعه:

• تطبيق .NET للأعمال على Windows
• حيث التثبيت per-user كافٍ
• حيث تريد التوزيع لمستخدمين قياسيّين
• وحيث لا تريد امتلاك تنفيذ التحديث بنفسك

فحينها ينتمي ClickOnce إلى القائمة المختصرة.

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

• كيف تختار نموذج توزيع تطبيق Windows - MSI و MSIX و ClickOnce و xcopy والـ custom updaters
• أساسيّات أمان ميزة التحديث التلقائيّ - الأنماط السيّئة وأفضل الممارسات
• متى يصبح Windows admin privilege ضرورياً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم

مواضيع ذات صلة

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

مواضيع Windows التقنيّة

هذه صفحة المدخل التي تنظّم المواضيع التقنيّة حول تطوير Windows والتحقيق في الأخطاء والتعامل مع الأصول الموجودة.

الخدمات المتّصلة بهذا الموضوع

تتّصل هذه المقالة طبيعيّاً بصفحات الخدمات التالية. ابدأ من أيّها أقرب إلى وضعك.

تطوير تطبيقات Windows

لتطبيقات الأعمال الداخليّة، وأدوات تهيئة الأجهزة، وتحسينات البرامج الموجودة، الخيار الأقلّ احتكاكاً بين ClickOnce وMSI وMSIX وxcopy يتوقّف غالباً وبشدّة على مراجعة المتطلّبات قبل بدء التنفيذ.

عرض الخدمة للتواصل

الاستشارة التقنيّة ومراجعة التصميم

أسئلة مثل ما إذا كان ClickOnce كافياً، وما إذا كان ينبغي للتصميم التحرّك نحو MSIX أو MSI، وما إذا كان التحديث التلقائيّ يبقى مضمَّناً أم يملكه الفريق، تصبح الإجابة عنها أسهل بكثير حين تُنظَّم قبل بدء التنفيذ.

عرض الخدمة للتواصل

نبذة عن المؤلِّف

غو كومورا

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

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

عرض الملف الشخصيّ للتواصل

12. المراجع

• Microsoft Learn - ClickOnce deployment and security
• Microsoft Learn - ClickOnce for .NET on Windows
• Microsoft Learn - Deploy a .NET Windows Desktop app with ClickOnce
• Microsoft Learn - An overview of Package Identity in Windows apps
• Microsoft Learn - How ClickOnce performs application updates
• Microsoft Learn - Choosing a ClickOnce update strategy
• Microsoft Learn - ClickOnce deployment manifest
• Microsoft Learn - ClickOnce application manifest
• Microsoft Learn - ClickOnce cache overview
• Microsoft Learn - ClickOnce and application settings
• Microsoft Learn - Install prerequisites with a ClickOnce application
• Microsoft Learn - ClickOnce and Authenticode
• Microsoft Learn - Security, versioning, and manifest issues in ClickOnce deployments

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

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

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

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

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

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

ما هو ClickOnce؟

تقنيّة توزيع لتطبيقات سطح مكتب Windows على .NET تسهّل التوزيع لكلّ مستخدم وتشمل التحديث التلقائيّ. رسميّاً توصف بأنّها تقنيّة توزيع لتطبيقات قائمة على Windows يمكن تثبيتها وتشغيلها بأقلّ قدر من تفاعل المستخدم وقادرة على تحديث نفسها. في الواقع هي نموذج توزيع يجمع التوزيع والتحديث وإدارة الـ cache حول الـ manifests، ويُحفَظ التطبيق في منطقة cache آمنة لكلّ مستخدم، مفصولة لكلّ تطبيق ولكلّ مستخدم ولكلّ إصدار.

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

في .NET الحاليّ يبقى ClickOnce مرشّحاً عاديّاً. في Visual Studio تُستعمل Publish tool لـ .NET Core 3.1 و.NET 5 فما بعد، وعند التعامل مع الـ manifests يدوياً تكون الأداة dotnet-mage.exe. غير أنّ الأمر يختلف عن عصر .NET Framework: على .NET Core 3.1 / .NET 5 / .NET 6 لا تُستعمل ApplicationDeployment API كما كانت، ومن .NET 7 فما بعد تُقرأ بعض خصائص النشر عبر متغيّرات البيئة. من غير الآمن الدخول في التنفيذ من ذاكرة مقالات قديمة وحدها.

لأيّ تطبيقات يلائم ClickOnce؟

يلائم خصوصاً تطبيقات WinForms / WPF الداخليّة للأعمال، حين تريد التوزيع لمستخدمين قياسيّين دون صلاحيات مسؤول، ويكفي التوزيع per-user، وتريد تحديثاً مضمَّناً. مسار التوزيع عبر موقع ويب أو مشاركة ملفّات يكفي. في المقابل لا يلائم التثبيت machine-wide لكلّ المستخدمين، ولا Windows service أو driver أو shell extension أو تسجيل COM ثقيل، ولا المتطلّبات التي تحتاج package identity، ولا حين تريد امتلاك قنوات التحديث والإصدار التدريجيّ؛ عندئذٍ ابدأ من MSI / MSIX / updater خاصّ.

كيف يعمل التحديث التلقائيّ في ClickOnce؟

يبدأ الحكم على التحديث من deployment manifest (.application). يقرأ التطبيق ذلك الـ manifest ليرى هل يوجد إصدار أحدث، وهل التحديث إلزاميّ، ومن أين يُجلَب. عند التحديث يستعمل file patching: يقارن application manifest للإصدار الجديد بالحاليّ ويجلب الملفّات المتغيّرة فقط، فيتجنّب إعادة التحميل الزائدة. يحتفظ ClickOnce cache بالإصدار الحاليّ والسابق مفصولين، والفكرة إقامة الإصدار الجديد بشكل صحيح ثمّ التبديل إليه. إن لم تكن الشبكة متاحة، يُشغَّل التطبيق كما هو دون فحص تحديث.

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

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

غو كومورا

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

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