ما هو ClickOnce - كيف يعمل، وكيف تعمل التحديثات، ومتى يلائم العمل الفعليّ ومتى لا يلائمه

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

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

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

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

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

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

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

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

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

1. الإجابة المختصرة

في جملة واحدة، ClickOnce هو تقنيّة توزيع لتطبيقات .NET لسطح مكتب Windows تجعل التوزيع per-user سهلاً وتُبقي التحديثات تعمل تلقائيّاً.

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

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

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

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

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

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

flowchart TD
    A["Need to distribute a Windows app"]
    B{"Are there requirements for deep OS integration?"}
    C["Start by comparing MSI / MSIX"]
    D{"Is it a .NET Windows desktop app<br/>and is per-user deployment enough?"}
    E{"Do you want to distribute to standard users?"}
    F{"Is built-in updating enough?"}
    G["ClickOnce is a strong candidate"]
    H["Also compare xcopy / a custom updater"]

    A --> B
    B -- Yes --> C
    B -- No --> D
    D -- No --> H
    D -- Yes --> E
    E -- No --> H
    E -- Yes --> F
    F -- Yes --> G
    F -- No --> H

2. ما هو ClickOnce

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

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

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

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

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

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

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

flowchart LR
    CO["ClickOnce"]
    V["Which version should be delivered"]
    U["Where updates are downloaded from"]
    S["Store safely in a per-user location"]
    I["Verify integrity and launch"]

    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/>optional<br/>checks / installs prerequisites"]
    Deploy["Deployment manifest (.application)<br/>which version should be delivered<br/>update source / update conditions"]
    App["Application manifest (*.exe.manifest)<br/>what is inside that version<br/>file list / hashes / entry point"]
    Files["Application 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 الصحيح أو إلى redistributable components إضافيّة، فبإمكان setup.exe تجهيز ذلك أوّلاً ثمّ تسليم التشغيل إلى ClickOnce deployment نفسه.

4. كيف يعمل التثبيت والإطلاق

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

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

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

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

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

sequenceDiagram
    participant U as User
    participant P as setup.exe / .application
    participant D as Deployment manifest
    participant A as Application manifest
    participant C as ClickOnce cache
    participant X as Application

    U->>P: Open
    Note over U,P: In a setup.exe-based configuration,<br/>prerequisite checks happen first
    P->>D: Retrieve and read
    D->>A: Refer to the target version
    A->>C: Obtain required files and verify integrity
    C->>X: Place and launch

online-only مقابل المتاح offline

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

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

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

flowchart LR
    subgraph Online[Online-only]
        O1["Start from the published location"]
        O2["Less of a permanently installed feel"]
        O3["More likely to assume network availability"]
        O1 --> O2 --> O3
    end

    subgraph Offline[Available offline]
        F1["Install into the user's area"]
        F2["Register in the Start menu"]
        F3["Launch locally"]
        F4["Check for updates at defined timing"]
        F1 --> F2 --> F3 --> F4
    end

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

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

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

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

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

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

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

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

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

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

flowchart TD
    Start["Application starts"]
    Check["Check the deployment manifest"]
    New{"Is there a newer version?"}
    Run["Launch as-is"]
    Get["Get the new application manifest"]
    Compare["Compare signatures / hashes"]
    Download["Download only the changed parts"]
    Switch["Establish the new version and switch over"]
    Restart["If needed, run the new version after restart"]

    Start --> Check --> New
    New -- No --> Run
    New -- Yes --> Get --> Compare --> Download --> Switch --> Restart

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

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

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

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

flowchart TB
    subgraph UA[ClickOnce cache for User A]
        APrev["Previous version"]
        ACur["Current version"]
        AData["Settings / data"]
    end

    subgraph UB[ClickOnce cache for User B]
        BPrev["Previous version"]
        BCur["Current version"]
        BData["Settings / data"]
    end

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

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

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

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

6. ما الذي يبرع فيه ClickOnce بشكل خاصّ

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

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

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

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

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

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

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

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

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

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

flowchart LR
    subgraph Custom[Responsibilities owned by a custom updater]
        C1["Detect a new version"]
        C2["Download"]
        C3["Verify integrity"]
        C4["Switch over"]
        C5["Recover from failures"]
        C1 --> C2 --> C3 --> C4 --> C5
    end

    subgraph Click[Responsibilities that can be pushed to ClickOnce]
        K1["Detect a new version"]
        K2["Obtain and verify"]
        K3["Switch over"]
        K1 --> K2 --> K3
    end

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

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

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

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

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

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

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

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

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

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

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

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

7. أين يلائم ClickOnce جيّداً

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

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

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

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

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

flowchart TD
    S["Organize the requirements"]
    Q1{"Is it a .NET desktop app<br/>such as WinForms or WPF?"}
    Q2{"Is per-user deployment enough?"}
    Q3{"Do you want standard-user installation?"}
    Q4{"Can it be distributed through the web or a file share?"}
    Q5{"Is it acceptable not to overbuild update UX?"}
    G["ClickOnce is a very strong candidate"]
    O["Compare other approaches"]

    S --> Q1
    Q1 -- No --> O
    Q1 -- Yes --> Q2
    Q2 -- No --> O
    Q2 -- Yes --> Q3
    Q3 -- No --> O
    Q3 -- Yes --> Q4
    Q4 -- No --> O
    Q4 -- Yes --> Q5
    Q5 -- Yes --> G
    Q5 -- No --> O

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

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

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

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

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

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

8.2 Windows services، أو drivers، أو shell extensions، أو تسجيل COM ثقيل

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

• Windows services
• drivers
• in-process shell extensions
• تصاميم تعتمد على تسجيل COM ميكانيكيّ

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

8.3 تحتاج إلى package identity

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

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

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

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

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

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

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

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

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

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

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

flowchart LR
    A1["Install for all users"] --> B1["MSI / in some cases MSIX"]
    A2["Service / driver / shell extension / heavy COM"] --> B2["MSI / dedicated installer"]
    A3["Need package identity"] --> B3["MSIX"]
    A4["Staged rollout / channels / custom UX"] --> B4["Custom updater"]
    A5["Simple copy is enough"] --> 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 وما بعده، يمكن قراءة بعض خصائص deployment عبر متغيّرات البيئة
• إن تعاملت مع manifests يدويّاً، يصبح dotnet-mage.exe الأداة المعنيّة
• نشر Visual Studio أيضاً لم يعد يتطابق واحداً لواحد مع افتراضات Publish Wizard القديمة

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

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

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

• runtime المطلوب
• redistributable components إضافيّة
• تبعيّات أخرى

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

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

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

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

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

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

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

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

flowchart TD
    Cert["Code-signing certificate"]
    AppMan["Application manifest"]
    DepMan["Deployment manifest"]
    Verify["Client-side verification"]
    Run["Update / run"]
    Tamper["Manifest tampering"]
    Stop["Stop on verification failure"]

    Cert --> AppMan
    Cert --> DepMan
    AppMan --> Verify
    DepMan --> Verify
    Verify --> Run
    Tamper -. Verification failure .-> Stop

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

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

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

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

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

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

flowchart TD
    Build["Build"]
    AppManifest["Generate the new application manifest"]
    SignApp["Sign the application manifest"]
    UpdateDep["Update the deployment manifest to the new version"]
    SignDep["Sign the deployment manifest"]
    Publish["Place it in the publish location"]
    Client["Client detects the update"]

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

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

10. الخلاصة

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

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

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

• من السهل التوزيع لمستخدمين قياسيّين
• يمتلك نموذج تحديث built-in
• يستطيع تحديث الأجزاء التي تغيّرت فقط بكفاءة
• يفصل التطبيقات والإصدارات بنظافة
• من السهل النشر من 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 وupdaters خاصّة
• متى يحتاج تطبيق Windows فعلاً صلاحيّات المسؤول؟

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

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

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

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

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

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

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

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

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

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

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

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

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

小村 豪

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

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

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

12. المراجع

• Microsoft Learn - ClickOnce deployment and security
• Microsoft Learn - ClickOnce for .NET on Windows
• 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

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

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

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

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

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

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

غو كومورا

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

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