توزيع تطبيق Windows في ملفّ واحد - حدود الملفّ التنفيذي الواحد واعتماد نظام التشغيل

بدأت هذه المقالة من حديث عابر: «إلى أيّ حدّ يجوز في Windows أن نسمّي الأمر ملفاً تنفيذيّاً واحداً (single binary)». المنشور الذي أشعل الحديث هو التالي. يمكن تخطّي هذا الجزء؛ ما بعده مكتوب ليُقرأ وحده.

«إن أمكن، نريد توزيعه في ملفّ واحد» طلب شائع جدّاً في Windows. أدوات داخلية، وأدوات ربط أجهزة، وأجهزة مراقبة، وبيئات غير متّصلة، ومواقع تريد تجنّب المثبِّت قدر الإمكان: جعل الملفّ التنفيذي واحداً جذاب جدّاً هناك.

لكن إن لم تُفصَل هذه القصّة أوّلاً، ينفرط التفاهم في المنتصف عادة. لأنّ «نريد ملفاً تنفيذيّاً واحداً» في Windows يختلط فيه غالباً أربعة أحاديث منفصلة.

• تريد المُنتَج المسلَّم ملفّاً واحداً
• تريد إلغاء التثبيت المسبق لوقت تشغيل .NET أو Visual C++
• تريد أن يعمل بمجرّد الوضع، بلا مثبِّت وبلا امتيازات مدير
• لا تريد الاعتماد على اختلاف Windows المستهدف

هذه الأربعة ليست الشيء نفسه. عمليّاً، التفكير كالتالي هو الأقلّ انحرافاً.

تقريب المُنتَج المسلَّم إلى EXE واحد ممكن إلى حدّ بعيد. لكن تصفير الاعتماد على Windows المستهدف غير ممكن.

تنظّم هذه المقالة ذلك الخطّ الفاصل لصعيد عملي لتطبيقات Windows.

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

الشكل 1: «نريد توزيعه في ملفّ واحد» يختلط فيه الممكن والمستحيل.

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

أوّلاً الخلاصة فقط، كالتالي.

• إن كان EXE سطح مكتب عادياً، يمكن جعله ملفاً تنفيذيّاً واحداً إلى حدّ بعيد
• لكن إمكان EXE واحد وعدم الاعتماد على Windows المستهدف أمران مختلفان
• امتدادات Shell، وخدمات Windows، والتعريفات، وWebView2، وجزء من WinUI 3، غالباً ما يكون موضوعها ماذا تسجّل في نظام التشغيل وماذا تفترض أكثر من عدد الملفّات
• الأهمّ عمليّاً فصل القرار: أتريد ملفاً تنفيذيّاً واحداً، أم إلغاء المثبِّت، أم تقليل الاعتماد على نظام التشغيل

بعبارة أخرى، الخطّ الفاصل في Windows كالتالي.

• تقريب المُنتَج المسلَّم إلى ملفّ واحد: ممكن إلى حدّ بعيد
• حمل وقت تشغيل إضافي: ممكن إلى حدّ بعيد
• التقريب إلى توزيع xcopy: حسب نوع التطبيق
• محو الاعتماد من جهة Windows المستهدف: مستحيل

flowchart TB
    accTitle: الخطّ الفاصل في Windows
    accDescr: مخطّط يبيّن أنّ تقريب المُنتَج المسلَّم إلى ملفّ واحد وحمل وقت تشغيل إضافي ممكنان إلى حدّ بعيد، وأنّ التقريب إلى توزيع xcopy حسب نوع التطبيق، وأنّ محو الاعتماد من جهة Windows المستهدف مستحيل.
    b1["تقريب المُنتَج المسلَّم إلى ملفّ واحد"] --> b2["ممكن إلى حدّ بعيد"]
    b3["تضمين وقت تشغيل إضافي"] --> b2
    b4["التقريب إلى توزيع xcopy"] --> b5["حسب نوع التطبيق"]
    b6["محو اعتماد جهة نظام التشغيل"] --> b7["مستحيل"]

الشكل 2: خطّ فاصل بين ما يمكن، وما يعتمد على النوع، وما لا يمكن.

1.1 مصطلحات تستخدمها المقالة

أوّلاً نرتّب كلمات تتكرّر لاحقاً.

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

2. «الملفّ التنفيذي الواحد» يُفكَّر فيه على أربع درجات

إن رُسمت الدرجات أوّلاً، تكون كالتالي. تصعب من الأسفل إلى الأعلى، والأعلى لا يُبلَغ في Windows.

flowchart BT
    A["المستوى A: المُنتَج المسلَّم ملفّ واحد<br/>ممكن إلى حدّ بعيد"]
    B["المستوى B: بلا تثبيت مسبق لوقت تشغيل اللغة<br/>ممكن إلى حدّ بعيد"]
    C["المستوى C: بلا تثبيت ولا تسجيل<br/>حسب نوع التطبيق"]
    D["المستوى D: بلا اعتماد على Windows المستهدف<br/>لا يُبلَغ في Windows"]

    A --> B
    B --> C
    C --> D

الشكل 3: أربع درجات للملفّ التنفيذي الواحد. تصعب من الأسفل، والمستوى D لا يُبلَغ.

حديث «نريد ملفاً تنفيذيّاً واحداً» يتغيّر العمل اللازم فيه تماماً حسب أيّ درجة من هذه الأربع يُقصَد.

2.1 المستوى A: المُنتَج المسلَّم ملفّ واحد

الأكثر سطحية هذا.

• يُرسَل واحداً بالبريد
• يكفي وضع واحد على USB
• يُوضَع app.exe فقط في وجهة النشر

هذا حديث وحدة التسليم الظاهرة. حتى إن وُسِّع مؤقّتاً عند الإقلاع، أو اعتمد على DLL من جهة نظام التشغيل، يكفي هذا الشرط وحده.

2.2 المستوى B: بلا تثبيت مسبق لوقت تشغيل اللغة

التالي حالة تعمل دون تثبيت وقت تشغيل .NET أو حزمة VC++ القابلة لإعادة التوزيع مسبقاً على الجهاز المستهدف.

• الربط الساكن في C/C++
• self-contained في .NET
• single-file في .NET
• Native AOT في .NET

عند هذا المستوى يقوى إحساس «يُحمَل وحده» كثيراً.

2.3 المستوى C: بلا تثبيت ولا تسجيل

من هنا يصعب فجأة.

EXE العادي قد يعمل بمجرّد الوضع. لكن هذه ليست كذلك.

• امتداد Shell
• خدمة Windows
• مخطّط URL مخصَّص أو ربط نوع ملفّ
• تعريف (driver)
• مكوّن يُحمَّل في عملية أخرى مثل Explorer أو Office

هذا المجال لا يكفي وضع الملفّات. يلزم تسجيل في جهة نظام التشغيل، أو ربط مع جهة المضيف.

flowchart TB
    accTitle: مجال لا يكفي فيه الوضع فقط
    accDescr: مخطّط يبيّن أنّ امتدادات Shell وخدمات Windows وربط الملفّات والتعريفات والمكوّنات المحمَّلة في عملية أخرى لا تكفي بوضع الملفّ، بل تحتاج تسجيلاً في جهة نظام التشغيل أو ربطاً مع جهة المضيف.
    c1["امتداد Shell · خدمة"] --> c4["الوضع وحده لا يكفي"]
    c2["ربط · تعريف"] --> c4
    c3["ما يُحمَّل في عملية أخرى"] --> c4
    c4 --> c5["يلزم تسجيل جهة نظام التشغيل وربط المضيف"]

الشكل 4: المستوى C يصعب فجأة لأنّه مجال يحتاج تسجيلاً في نظام التشغيل.

2.4 المستوى D: بلا اعتماد على Windows المستهدف

هذا مستحيل في Windows.

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

3. مجال يسهل فيه التقريب إلى EXE واحد إلى حدّ بعيد

حتى في Windows توجد تطبيقات يسهل نسبيّاً تقريبها إلى EXE واحد.

• أدوات سطح مكتب تُشغَّل وحدها
• تطبيقات عمل يحمل فيها EXE نفسه الواجهة والمعالجة
• أدوات مثل الاتصال ومعالجة الملفّات وجمع السجلّات والمراقبة والتحكّم بالأجهزة
• ما لا يحتاج تكامل مضيف مع Explorer أو Office
• واجهة لا تفترض وقت تشغيل ويب

لهذا النوع كثير ممّا يسهل تضمينه في جسم التطبيق.

• شيفرتك
• الموارد
• البيان (manifest)
• الإعدادات الافتراضية
• بيانات القوالب
• بعض مكتبات الطرف الثالث
• جسم وقت تشغيل اللغة

وإضافة، حتى دون دفن DLL بالكامل داخل EXE، توزيع app-local بوضع DLL بجانب EXE خيار قوي شائع في Windows. عمليّاً،

• app.exe واحد
• أو app.exe + بضعة DLL مجاورة
• لكن بلا مثبِّت، بلا امتيازات مدير، يُوزَّع بـ xcopy

هذا الشكل ليس نادراً أن تكون صيانته أسهل من الضغط قسراً إلى EXE واحد.

flowchart TB
    accTitle: app-local بوصفه موضع استقرار
    accDescr: مخطّط يبيّن أنّ وضع DLL بجانب EXE دون دفنها بالكامل في EXE، إن أمكن توزيع xcopy بلا مثبِّت وبلا امتيازات مدير، ليس نادراً أن تكون صيانته أسهل من الضغط قسراً إلى EXE واحد.
    d1["app.exe+بضعة DLL مجاورة"] --> d2["بلا مثبِّت · بلا امتيازات مدير"]
    d2 --> d3["يُوزَّع بـ xcopy"]
    d3 -.-> d4["قد تكون الصيانة أسهل من ضغط EXE واحد قسري"]

الشكل 5: حتى دون الإصرار على EXE واحد، كثيراً ما يفي التوزيع app-local بالغرض.

4. اعتماد Windows الذي لا يزول حتى مع EXE واحد

إن ظننت «EXE واحد يعني عدم الاعتماد على Windows المستهدف»، تقع الحادثة هنا. في الواقع يبقى اعتماد حتى مع EXE واحد.

4.1 الاعتماد على إصدار نظام التشغيل

لكلّ واجهة Windows حدّ أدنى من نظام التشغيل المدعوم. ويوجد أيضاً فرق x64 / Arm64. أي حتى مع EXE واحد،

• هل يعمل حتى Windows 10
• أم يفترض Windows 11
• أم يُشغَّل أيضاً على Windows Server
• أيّ من x86 / x64 / Arm64 مستهدف

يلزم تثبيتها أوّلاً.

4.2 الاعتماد على مكتبات DLL للنظام

حتى إن نويت EXE واحداً، تستخدم عند التشغيل بطبيعة الحال مكوّنات يوفّرها نظام التشغيل.

• kernel32.dll
• user32.dll
• advapi32.dll
• أساس COM
• أساس التحكّم بالخدمات

هذا نطاق مسؤولية جهة Windows.

4.3 الاعتماد على نموذج الأمن

• UAC
• ACL للملفّات
• مدير التحكّم بالخدمات
• السجلّ
• سياسة توقيع التعريفات

هذه لا يستطيع التطبيق حملها وحده.

flowchart TB
    accTitle: اعتماد يبقى حتى مع EXE واحد
    accDescr: مخطّط يبيّن أنّه حتى مع EXE واحد يبقى الاعتماد على أدنى نظام تشغيل مدعوم لواجهات Windows والمعمارية، ومكتبات DLL للنظام مثل kernel32.dll وأساس COM، ونموذج الأمن مثل UAC وACL وسياسة توقيع التعريفات.
    e0["تطبيق EXE واحد"] --> e1["إصدار نظام التشغيل وarch"]
    e0 --> e2["مكتبات DLL للنظام · أساس COM"]
    e0 --> e3["نموذج الأمن"]
    e1 --> e4["لا يستطيع التطبيق حمل أيّ منها"]
    e2 --> e4
    e3 --> e4

الشكل 6: حتى مع مُنتَج مسلَّم واحد يبقى الاعتماد على نطاق مسؤولية جهة Windows.

4.4 الاعتماد على المضيف أو وقت التشغيل

إن لم يكن EXE يُشغَّل وحده بل تصميماً يركب على مضيف ما، يزيد الاعتماد دفعة واحدة.

• استخدام WebView2: يلزم WebView2 Runtime
• استخدام WinUI 3 / Windows App SDK: يلزم ترتيب وضع التوزيع
• صنع امتداد Shell: يلزم تسجيل في جهة Explorer

أي أنّ اختيار الواجهة أو التكامل كثيراً ما يصير صعوبة التوزيع كما هو.

flowchart TB
    accTitle: اختيار الواجهة والتكامل يصير صعوبة التوزيع
    accDescr: مخطّط يبيّن أنّ استخدام WebView2 يلزم Runtime، واستخدام WinUI 3 يلزم ترتيب وضع التوزيع، وصنع امتداد Shell يلزم تسجيلاً في جهة Explorer، فاختيار المضيف أو وقت التشغيل يصير صعوبة التوزيع كما هو.
    f1["استخدام WebView2"] --> f2["يلزم Runtime"]
    f3["استخدام WinUI 3"] --> f4["يلزم ترتيب وضع التوزيع"]
    f5["صنع امتداد Shell"] --> f6["يلزم تسجيل في Explorer"]

الشكل 7: كلّما ابتعدت عن EXE يُشغَّل وحده، زاد الاعتماد دفعة واحدة.

5. مواضع استقرار واقعيّة حسب التقنية

5.1 C/C++ الأصلي

C/C++ الأصلي في الجهة ذات حرّية أعلى لجعل الملفّ التنفيذي واحداً. يوجد مجال لاختيار الربط الساكن، وEXE الذي يُشغَّل وحده يسهل تقريبه كثيراً.

لكن أهمّ عمليّاً من دفن الكلّ في ملفّ واحد:

• كيف تعامل UCRT ووقت تشغيل VC++
• هل تضع مكتبات DLL للطرف الثالث app-local
• إلى أيّ حدّ تضيّق المعالج / نظام التشغيل المستهدف

المدخل: الفرق بين /MT و/MD

ما يقرّر عمليّاً في MSVC «هل تحمل وقت التشغيل» هو خيار المترجم هذا.

أصغر تجربة، في Developer Command Prompt، هذا فقط.

cl /std:c++17 /EHsc /O2 /MT app.cpp /Fe:app.exe

هنا ثلاث نقاط تستحقّ الانتباه.

• صار UCRT مكوّناً من Windows عند تقسيم وقت تشغيل C في Visual Studio 2015، وهو مضمَّن جزءاً من نظام التشغيل من Windows 10 فصاعداً. إن استهدفت Windows أقدم، يلزم إعادة التوزيع بـ vcredist.
• صنع جهة DLL بـ /MT غير مستحسَن. CRT المربوط ساكناً تنغلق حالته داخل ذلك DLL، فيختلف سلوك حجز الذاكرة والإعدادات المحلّية و_set_se_translator بين EXE وDLL. مواءمة «EXE بـ /MT وDLL المضمَّن أيضاً /MT» بلا رويّة تقع حادثتها عند الحجز والتحرير عبر الحدود.
• /clr و/MT لا يُجمَعان. إن اختلط C++/CLI فجهة /MD.

flowchart TB
    accTitle: ثلاث تنبيهات للربط الساكن
    accDescr: مخطّط يبيّن أنّ UCRT مضمَّن في نظام التشغيل من Windows 10 فصاعداً بينما الأقدم يحتاج إعادة توزيع بـ vcredist، وأنّ صنع جهة DLL بـ /MT يغلق حالة CRT داخل DLL فتقع حادثة عند الحجز والتحرير عبر الحدود، وأنّ /clr و/MT لا يُجمَعان.
    g0["ربط ساكن بـ /MT"] --> g1["Windows الأقدم يحتاج vcredist"]
    g0 --> g2["/MT لجهة DLL غير مستحسَن"]
    g0 --> g3["لا يُجمَع مع /clr"]
    g2 -.-> g4["حادثة عند الحجز والتحرير عبر الحدود"]

الشكل 8: /MT قوي، لكن انتبه إلى افتراض UCRT وحدود DLL وC++/CLI.

5.2 .NET

لدى .NET single-file وself-contained وNative AOT، لذا يمكن تصغير وحدة التسليم الظاهرة كثيراً.

لكن التمييز لازم.

• framework-dependent: يعتمد على .NET في البيئة المستهدفة
• self-contained: يحمل وقت تشغيل .NET
• single-file: يقرّب المُنتَج المسلَّم إلى واحد
• Native AOT: يقلّل اعتماد الإقلاع أكثر، مع قيود وظيفية

ليس أنّ «single-file يقلّل الاعتماد على نظام التشغيل». ما يقلّ أساساً هو تماسك مُنتَج التطبيق المسلَّم.

flowchart TB
    accTitle: ما يقلّله single-file تماسك المُنتَج المسلَّم
    accDescr: مخطّط يبيّن أنّ framework-dependent يعتمد على .NET في البيئة المستهدفة، وself-contained يحمل وقت التشغيل، وsingle-file يقرّب المُنتَج المسلَّم إلى واحد فقط، وأنّ single-file لا يقلّل الاعتماد على نظام التشغيل.
    h1["framework-dependent"] --> h2["يعتمد على .NET في البيئة المستهدفة"]
    h3["self-contained"] --> h4["يحمل وقت تشغيل .NET"]
    h5["single-file"] --> h6["يقرّب المُنتَج المسلَّم إلى واحد"]
    h6 -.-> h7["لا يعني تقليل اعتماد نظام التشغيل"]

الشكل 9: لكلّ شكل إصدار في .NET ما يقلّ وما يبقى مختلفان.

المدخل: ثلاثة أنماط لـ dotnet publish

لرؤية الفرق بالتشغيل أوّلاً، هذه الثلاثة تكفي.

rem 1. framework-dependent + single-file: 対象機に .NET ランタイムが要る
dotnet publish -c Release -r win-x64 --self-contained false -p:PublishSingleFile=true

rem 2. self-contained + single-file: .NET ランタイムを抱える
dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true

rem 3. Native AOT: csproj に PublishAot を書いたうえで発行する
dotnet publish -c Release -r win-x64

PublishSingleFile وPublishAot التوصية الرسمية كتابتهما في csproj لا سطر الأوامر. لأنّ تحليل التوافق أثناء البناء يُفعَّل، فتقلّ حوادث تُكتشَف بعد الإصدار.

<PropertyGroup>
  <PublishSingleFile>true</PublishSingleFile>
  <PublishAot>true</PublishAot>
</PropertyGroup>

لاحظ أنّ تحديد RuntimeIdentifier يجعل SelfContained افتراضيّاً true. إن أردت framework-dependent فصرّح بـ --self-contained false. لإصدار Native AOT على Windows يلزم حمل عمل تطوير سطح المكتب بـ C++ في Visual Studio.

المقايضة: «جعله واحداً» ليس مجّاناً

هنا الكتابة عن «الممكن» وحدها تُوقِع حادثة، لذا نرتّب الثمن أيضاً.

التوسيع عند إقلاع single-file

• الافتراضي أنّ ما يُضمَّن هو مكتبات DLL المُدارة فقط. تُحمَّل في الذاكرة عند الإقلاع ولا تُوسَّع إلى مجلد. الثنائيات الأصلية لجسم وقت التشغيل تبقى ملفّات منفصلة.
• لتضمين الثنائيات الأصلية أيضاً في واحد استخدم IncludeNativeLibrariesForSelfExtract، ولتوسيع الكلّ قبل التشغيل استخدم IncludeAllContentForSelfExtract. كلاهما سلوك «وسّع ثمّ أقلع»، وعلى Windows يُوسَّع تحت %TEMP%\.net. يمكن تغيير الموضع بـ DOTNET_BUNDLE_EXTRACT_BASE_DIR، لكن لا تجعله موضعاً يكتب فيه مستخدمون أو خدمات بصلاحيات مختلفة.
• تفعيل EnableCompressionInSingleFile يصغّر EXE كثيراً، لكن الإقلاع يبطؤ بقدر التمديد في الذاكرة عند الإقلاع. الوثائق الرسمية أيضاً بصيغة «قِس الحجم وتكلفة الإقلاع كليهما قبل الاستخدام». الأثر يتغيّر كثيراً حسب التطبيق.

عدم توافق واجهات single-file

جعل المُنتَج المسلَّم واحداً يكسر بهدوء شيفرة تفترض مسار ملفّ.

لمس ملفّ بجانب EXE انحز إلى AppContext.BaseDirectory، وإن لزم مسار الملفّ التنفيذي فانحز إلى Environment.ProcessPath. مكتبات الطرف الثالث قد تستخدم هذه داخليّاً أيضاً، لذا بعد جعله single-file يلزم تأكيد الإقلاع مرّة على جهاز حقيقي.

flowchart TB
    accTitle: شيفرة تفترض المسار تنكسر بهدوء
    accDescr: مخطّط يبيّن أنّ جعل المُنتَج المسلَّم واحداً يغيّر سلوك الواجهات التي تفترض مسار ملفّ مثل إعادة Assembly.Location سلسلة فارغة، لذا انحز لملفّ مجاور إلى AppContext.BaseDirectory ولمسار الملفّ التنفيذي إلى Environment.ProcessPath، وأكّد الإقلاع مرّة على جهاز حقيقي.
    i1["جعله single-file"] --> i2["يتغيّر سلوك الواجهات التي تفترض المسار"]
    i2 --> i3["الملفّ المجاور: AppContext.BaseDirectory"]
    i2 --> i4["الملفّ التنفيذي: Environment.ProcessPath"]
    i3 --> i5["أكّد الإقلاع مرّة على جهاز حقيقي"]
    i4 --> i5

الشكل 10: بعد جعله single-file، استبدل أخذ المسار وتحقّق على جهاز حقيقي.

القيود الوظيفية لـ Native AOT

مقابل «إقلاع أسرع وبلا وقت تشغيل»، يتعذّر التالي.

• التحميل الديناميكي مثل Assembly.LoadFile
• توليد الشيفرة في وقت التشغيل مثل System.Reflection.Emit
• C++/CLI
• على Windows COM المضمَّن
• التقليم إلزامي، فقيود التقليم تركب كما هي
• عمليّاً single-file، فعدم توافق الواجهات أعلاه يركب كما هو
• System.Linq.Expressions يعمل دائماً مفسِّراً، فيبطؤ عن الشيفرة المولَّدة في وقت التشغيل

المنصّة المستهدفة أيضاً مثبتة سلفاً. في .NET 8 Windows هو x64 وArm64، ومن .NET 9 فصاعداً أُضيف x86. تصوّر «واحد بـ AnyCPU» لا يقوم من البداية.

flowchart TB
    accTitle: ثمن Native AOT
    accDescr: مخطّط يبيّن أنّ Native AOT يقلّل اعتماد الإقلاع مقابل تعطّل التحميل الديناميكي وتوليد الشيفرة في وقت التشغيل وC++/CLI وCOM المضمَّن على Windows، وتركب أيضاً قيود التقليم وsingle-file، والمنصّة المستهدفة مثبتة سلفاً.
    j0["Native AOT"] --> j1["يقلّل اعتماد الإقلاع"]
    j0 --> j2["التحميل الديناميكي والتوليد في وقت التشغيل متعذّران"]
    j0 --> j3["C++/CLI وCOM المضمَّن متعذّران"]
    j2 -.-> j4["تركب أيضاً قيود التقليم وsingle-file"]
    j3 -.-> j5["نظام التشغيل وarch المستهدفان مثبتان سلفاً"]

الشكل 11: مزيّة Native AOT تُرى مجموعة مع الوظائف التي تتعطّل.

5.3 WebView2

اعتماد WebView2 يغيّر صعوبة الملفّ التنفيذي الواحد جذريّاً. الموضوع هنا ليس عدد EXE، بل كيف تعامل WebView2 Runtime.

قبل «هل يمكن EXE واحد»، أسئلة يجب التفكير فيها.

• هل تفترض Runtime في البيئة القائمة
• هل تستخدم Evergreen
• هل تضمّن Fixed Version
• إلى أيّ حدّ تتحمّل المسؤولية في التوزيع غير المتّصل

فرق Evergreen وFixed Version تقريباً كالتالي.

Evergreen Runtime مثبَّت مسبقاً جزءاً من نظام التشغيل على Windows 11. لكن تبقى أجهزة Windows 10 بلاه، لذا تكتب Microsoft نفسها «حتى إن اخترت Evergreen فالأفضل توزيع Runtime». أي أنّ إجراء التحقّق من الوجود في جهة التطبيق وإدخاله إن نقص يلزم في الحالين. Fixed Version مقابل «تمسك توقيت التحديث بنفسك» يزيد المُنتَج المسلَّم مئات MB. يلزم تقرير هذا أوّلاً، منفصلاً عن حديث EXE واحد.

flowchart TB
    accTitle: WebView2 قرّر أسلوب التوزيع أوّلاً
    accDescr: مخطّط يبيّن أنّ Evergreen نسخة مشتركة واحدة يحدّثها Microsoft تلقائيّاً لكن قد لا تكون على الجهاز، وFixed Version يمسك التحديث بنفسك مقابل زيادة المُنتَج المسلَّم مئات MB، وفي الحالين يلزم إجراء التحقّق من الوجود في جهة التطبيق وإدخاله إن نقص.
    k0["اعتماد WebView2"] --> k1["Evergreen: نسخة مشتركة تُحدَّث تلقائيّاً"]
    k0 --> k2["Fixed Version: تضمين وتحديث بنفسك"]
    k1 --> k3["تحقّق من الوجود وأدخل إن نقص"]
    k2 -.-> k4["يزيد المُنتَج المسلَّم مئات MB"]

الشكل 12: موضوع WebView2 ليس عدد EXE بل معاملة Runtime.

5.4 WinUI 3 / Windows App SDK

WinUI 3 أيضاً تتغيّر متطلّبات التوزيع لحظة اعتماده. اختيار تقنية الواجهة يصير اختيار أسلوب التوزيع كما هو.

تحديداً، ما تقرّره محوران.

• packaging: packaged (MSIX)، أو packaged يشير إلى موضع خارجي، أو unpackaged
• runtime: framework-dependent أو self-contained

وما يؤثّر من زاوية الملفّ التنفيذي الواحد قيد هذا التركيب.

• PublishSingleFile يعمل فقط لتطبيق WinUI 3 unpackaged وself-contained، ويلزم Windows App SDK 1.5 فصاعداً.
• التطبيقات packaged، والتطبيقات packaged التي تشير إلى موضع خارجي، لا يعمل فيها PublishSingleFile.
• جعلها unpackaged يفقد package identity، فتتعدّر وظائف Windows التي تفترض package identity مثل الإشعارات ومهام الخلفية وربط الملفّات وامتداد قائمة السياق.

أي أنّ في WinUI 3 «جعله EXE واحداً» و«استخدام امتدادات Windows» يصطدمان وجهاً لوجه. إن جعلت الملفّ التنفيذي الواحد أولوية قصوى، كثيراً ما يكون مراجعة افتراض تقنية الواجهة أوّلاً أسرع.

flowchart TB
    accTitle: اصطدام EXE واحد وpackage identity
    accDescr: مخطّط يبيّن أنّ PublishSingleFile في WinUI 3 يعمل فقط في تركيب unpackaged وself-contained، وأنّ unpackaged يفقد package identity فتتعدّر وظائف مثل الإشعارات وربط الملفّات، لذا يصطدم EXE واحد وامتدادات Windows وجهاً لوجه.
    m1["تريد استخدام PublishSingleFile"] --> m2["unpackaged+self-contained فقط"]
    m2 --> m3["تفقد package identity"]
    m3 --> m4["الإشعارات والربط وغيرها تتعدّر"]
    m4 -.-> m5["EXE واحد وامتدادات يصطدمان وجهاً لوجه"]

الشكل 13: في WinUI 3 اختيار EXE واحد يعني التخلّي عن package identity.

6. مجال يحتاج جوهريّاً «تسجيلاً واعتماداً»

6.1 امتداد Shell

امتداد Shell الذي يُحمَّل في Explorer شيء آخر غير «EXE يُوضَع فقط». هنا الموضوع ليس عدد الملفّات بل كيف تسجّل في Explorer.

6.2 خدمة Windows

حتى إن صار exe الخدمة نفسه ملفّاً واحداً، التوزيع مسألة أخرى.

• التسجيل في SCM
• الصلاحيات
• حساب التشغيل
• إعدادات الاستعادة

يلزم التفكير فيها. أي أنّ الخدمة مجال تُحكَم فيه «كيف تثبّت» أكثر من «جعله EXE واحداً».

6.3 التعريفات

التعريفات أوضح. لا تقوم إلّا مع INF والتوقيع وإجراء التثبيت، فتصعب ركوب ملعب الملفّ التنفيذي الواحد من البداية.

flowchart TB
    accTitle: مجال موضوعه التسجيل والتوقيع
    accDescr: مخطّط يبيّن أنّ امتداد Shell تسجيل في Explorer، وخدمة Windows تسجيل في SCM وصلاحيات وحساب تشغيل، والتعريف لا يقوم إلّا مع INF والتوقيع، لذا الموضوع تصميم التسجيل والاعتماد أكثر من عدد الملفّات.
    n1["امتداد Shell"] --> n2["تسجيل في Explorer"]
    n3["خدمة"] --> n4["تسجيل SCM · صلاحيات · حساب"]
    n5["تعريف"] --> n6["INF والتوقيع"]
    n4 -.-> n7["الموضوع تصميم التسجيل أكثر من عدد الملفّات"]

الشكل 14: في هذه المجالات الثلاثة أحكم «كيف تسجّل» أكثر من «جعله EXE واحداً».

7. جدول قرار للتشغيل

للحكم التقريبي هذا الجدول سهل الاستخدام.

أهمّ ما في هذا الجدول إدراك أنّ «عدد الثنائيات» و«نطاق مسؤولية التوزيع» أمران مختلفان.

8. ما يجب تقريره أوّلاً في تصميم التوزيع

إن أردت نجاح جعله ملفاً تنفيذيّاً واحداً، أمور يستحقّ تقريرها قبل التنفيذ.

8.1 قرّر ماذا تريد واحداً

• أتريد المُنتَج المسلَّم ملفّاً واحداً
• أم إلغاء التثبيت المسبق لوقت التشغيل
• أم إلغاء المثبِّت
• أم تبسيط التحديث غير المتّصل

بهذا الجواب تتغيّر التقنية المختارة.

8.2 ثبّت أدنى Windows مدعوم وarch أوّلاً

single-file وNative AOT في الأساس خاصّان بنظام التشغيل / المعمارية. إن مضيت بـ «ملفّ واحد كيفما اتّفق» وهذا غامض، تنسدّ أخيراً بنقص واجهة أو عدم تطابق وقت التشغيل.

8.3 صرّح بما تضمّنه وما توكله إلى Windows

عمليّاً، كتابة هذا الجدول وحدها تقلّل الحوادث كثيراً.

• ما تضمّنه في التطبيق
  • exe الجسم
  • DLL الخاصة بك
  • قالب الإعداد
  • وقت تشغيل self-contained
• ما توكله إلى Windows
  • مكتبات DLL للنظام
  • واجهات نظام التشغيل
  • SCM / السجلّ / Explorer
  • أساس التعريفات
• ما تفترضه على حدة
  • WebView2 Runtime
  • VC++ Redistributable
  • Office / Excel
  • تعريف مخصَّص

flowchart TB
    accTitle: صرّح بثلاثة تصنيفات لنطاق المسؤولية
    accDescr: مخطّط يبيّن أنّ كتابة ثلاثة تصنيفات: ما تضمّنه في التطبيق، وما توكله إلى Windows، وما تفترضه على حدة، وحدها تقلّل حوادث التوزيع كثيراً.
    p0["نطاق مسؤولية المُنتَج المسلَّم"] --> p1["ما تضمّنه في التطبيق"]
    p0 --> p2["ما توكله إلى Windows"]
    p0 --> p3["ما تفترضه على حدة"]
    p3 -.-> p4["كتابته وحدها تقلّل الحوادث"]

الشكل 15: صرّح أوّلاً بثلاثة تصنيفات: التضمين، والتوكيل إلى نظام التشغيل، والافتراض على حدة.

8.4 إن أوليت الملفّ التنفيذي الواحد أولوية، قلّل تكامل المضيف

هذا ذو أثر كبير.

• اترك امتداد Shell واجعله EXE عادياً
• لا تجعله خدمة، واكتفِ بمجدول المهام أو تشغيل صريح
• استخدم واجهة أصلية لا WebView2
• أغلق COM داخل عمليتك

باختصار، كلّما قلّلت تصميماً «يحمّله نظام التشغيل» أو «يسجّله»، اقتربت من الملفّ التنفيذي الواحد.

flowchart TB
    accTitle: كلّما قلّل تكامل المضيف اقتربت
    accDescr: مخطّط يبيّن أنّ ترك امتداد Shell وجعله EXE عادياً، وعدم جعله خدمة والاكتفاء بمجدول المهام أو تشغيل صريح، واستخدام واجهة أصلية لا WebView2، أي تقليل تصميم التحميل والتسجيل في نظام التشغيل، يقرّبك من الملفّ التنفيذي الواحد.
    q1["اترك امتداد Shell واجعله EXE عادياً"] --> q4["قلّل تصميم التسجيل في نظام التشغيل"]
    q2["لا تجعله خدمة واستخدم تشغيلاً صريحاً"] --> q4
    q3["واجهة أصلية لا WebView2"] --> q4
    q4 --> q5["تقترب من الملفّ التنفيذي الواحد"]

الشكل 16: إن أوليت الملفّ التنفيذي الواحد أولوية، قلّل تكامل المضيف نفسه.

9. الخلاصة

جعل الملفّ التنفيذي واحداً في Windows ممكن إلى حدّ بعيد. لكن المحطّة هذه الجملة.

يمكنك جعل التطبيق EXE واحداً. لكن لا يمكنك جعل Windows الذي يعتمد عليه التطبيق EXE واحداً أيضاً.

خمس نقاط تستحقّ التذكّر خصوصاً.

• EXE العادي الذي يُشغَّل وحده يمكن تقريبه إلى توزيع ملفّ واحد إلى حدّ بعيد
• الربط الساكن في C/C++ وsingle-file في .NET وNative AOT خيارات قويّة
• لكن الاعتماد على إصدار نظام التشغيل وarch ومكتبات DLL للنظام ونموذج الأمن لا يزول
• امتدادات Shell والخدمات والتعريفات وWebView2 وجزء من WinUI 3 يصير حديث التسجيل في نظام التشغيل ووقت التشغيل الإضافي هو الأصل
• نجاح الملفّ التنفيذي الواحد يُحسَم بفصل «ماذا تريد واحداً» أوّلاً

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

flowchart TB
    accTitle: مفتاح النجاح درجة الارتباط بنظام التشغيل
    accDescr: مخطّط يبيّن أنّ جعل التطبيق EXE واحداً ممكن بينما جعل Windows الذي يعتمد عليه EXE واحداً غير ممكن، لذا إن أوليت الملفّ التنفيذي الواحد أولوية شديدة فالتصميم عند اختيار التقنية باتجاه خفض درجة الارتباط بنظام التشغيل أنجح.
    r1["جعل التطبيق EXE واحداً"] --> r2["ممكن"]
    r3["جعل Windows المعتمد عليه EXE واحداً"] --> r4["غير ممكن"]
    r4 -.-> r5["لذلك اخفض درجة الارتباط بنظام التشغيل عند اختيار التقنية"]

الشكل 17: نجاح جعله EXE واحداً يُحسَم بتصميم درجة الارتباط بنظام التشغيل أوّلاً.

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

• Microsoft Learn, Create a single file for application deployment
• Microsoft Learn, Native AOT deployment overview
• Microsoft Learn, C runtime (CRT) and C++ standard library (STL) lib files
• Microsoft Learn, Dynamic-link library search order
• Microsoft Learn, Targeting your application for Windows
• Microsoft Learn, Creating Registration-Free COM Objects
• Microsoft Learn, Registering Shell Extension Handlers
• Microsoft Learn, CreateServiceW function
• Microsoft Learn, Overview of INF Files
• Microsoft Learn, Windows driver signing tutorial
• Microsoft Learn, Distribute your app and the WebView2 Runtime
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps
• Microsoft Learn, Package and deploy Windows apps overview
• Microsoft Learn, Packaging overview - Windows apps

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

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

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

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

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

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

هل يمكن توزيع تطبيق Windows في ملفّ EXE واحد فقط؟

إن كان أداة سطح مكتب تُشغَّل وحدها، فإلى حدّ بعيد نعم. الربط الساكن في C/C++، وself-contained وsingle-file وNative AOT في .NET، تقرّب المُنتَج المسلَّم إلى EXE واحد. لكن إمكان EXE واحد وعدم الاعتماد على Windows المستهدف أمران مختلفان؛ الاعتماد على إصدار نظام التشغيل والمعمارية ومكتبات DLL للنظام ونموذج الأمن لا يزول.

هل يزيل single-file في .NET الاعتماد على نظام التشغيل؟

لا. ما يقلّله single-file أساساً تماسك مُنتَج التطبيق المسلَّم، لا الاعتماد على نظام التشغيل. framework-dependent يعتمد على .NET في البيئة المستهدفة، وself-contained يحمل وقت تشغيل .NET، وNative AOT يقلّل اعتماد الإقلاع أكثر مع قيود وظيفية. single-file وNative AOT في الأساس خاصّان بنظام التشغيل والمعمارية، لذا يلزم تثبيت أدنى Windows مدعوم والمعمارية أوّلاً.

أيّ التطبيقات يصعب جعلها EXE واحداً؟

امتدادات Shell، وخدمات Windows، والتعريفات، وواجهة مبنية على WebView2، وجزء من WinUI 3. هنا الموضوع ليس عدد الملفّات بقدر ما يُسجَّل في نظام التشغيل وكيف يُعامَل وقت تشغيل إضافي. مثلاً امتداد Shell يحتاج تسجيلاً في Explorer، والخدمة تحتاج تسجيلاً في SCM وتصميم صلاحيات وحساب تشغيل، والتعريف لا يقوم إلّا مع INF والتوقيع، فلا يقوم توزيع بالوضع فقط. WebView2 يتطلّب تقرير أسلوب توزيع WebView2 Runtime أوّلاً.

هل يوجد أسلوب توزيع أفضل من الدفن قسراً في EXE واحد؟

التوزيع app-local بوضع DLL بجانب EXE خيار قوي. حتى شكل app.exe مع بضعة DLL مجاورة، إن أمكن توزيع xcopy بلا مثبِّت وبلا امتيازات مدير، فليس نادراً أن تكون الصيانة أسهل من الضغط قسراً إلى EXE واحد. المهمّ فصل المراد أوّلاً: أتريد مُنتَجاً مسلَّماً واحداً، أم إلغاء التثبيت المسبق لوقت التشغيل، أم إلغاء المثبِّت.

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

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

غو كومورا

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

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