ما هو Reg-Free COM - كيف يعمل Registration-Free COM وأين يلائم وأين لا يلائم

في مشاريع COM / ActiveX / OCX، يميل الطين نفسه في النشر إلى العودة في كلّ مرّة تشحن فيها أو تحدّث.

• يصبح regsvr32 جزءاً من العمليّة
• تميل صلاحيّات المسؤول إلى التسلّل
• يمكن أن تتصادم نسخة مثبّتة من تطبيق آخر مع نسختك
• يمكن أن يُتلف إلغاء التثبيت مكوّنات لا تزال منتجات أخرى بحاجة إليها
• يعمل على جهاز المطوّر، لكنّه يفشل في بيئة نظيفة

يمكن لـ Reg-Free COM أن يزيل جزءاً كبيراً بشكل مفاجئ من تلك الفوضى.

لكنّه على الرغم من اسمه، ليس سحراً يجعل كلّ مشكلات COM تختفي. ما يزيله بشكل رئيسيّ هو الألم الذي يأتي من التسجيل العام كنموذج تنشيط رئيسيّ. لا يجعل مشكلات الـ bitness أو الـ DLLs التابعة أو الـ type libraries أو مخاوف threading model تختفي.

يركّز هذا المقال على Reg-Free COM بشكل رئيسيّ في سياق إبقاء COM DLLs أو OCXs محصورة محليّاً داخل تطبيقات سطح مكتب Windows.

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

إليك النسخة التقريبيّة لكنّ المفيدة أوّلاً.

• يخزّن Reg-Free COM بيانات تنشيط COM الوصفيّة في manifests بدلاً من الاعتماد على الـ registry
• في وقت التشغيل، يمكن حلّ الاستدعاءات مثل CoCreateInstance وCLSIDFromProgID عبر activation context أوّلاً
• هذا يجعل من الممكن إبقاء COM DLLs / OCXs خاصّة بتطبيق واحد
• المزايا الرئيسيّة هي النشر بأسلوب XCOPY بشكل أسهل، وعدد أقلّ من تصادمات النسخ، وسلوك إلغاء تثبيت أقلّ هشاشةً
• لكنّ مشكلات 32-bit / 64-bit لا تختفي
• والـ DLLs التابعة والـ type libraries والمراجع في وقت التصميم وتبعيّات التسجيل غير القياسيّة لا تزال تحتاج إلى اهتمام منفصل
• في الممارسة العمليّة، يكون مفيداً بشكل خاصّ عندما تريد شحن مكوّنات COM التي تنتمي إلى تطبيق واحد فقط

أبسط طريقة لقولها هي هذه:

يسحب Reg-Free COM تنشيط COM نحو حدود التطبيق.

2. ما يقصده هذا المقال بـ Reg-Free COM

Reg-Free COM هو اختصار لـ Registration-Free COM.

كلمة “registration-free” لا تعني أنّ COM نفسه يختفي، ولا تعني أنّ الـ GUIDs تصبح غير ضروريّة.

تعني أنّ استخدام COM لم يعد يعتمد كلّيّاً على بيانات الـ registry العامّة مثل HKCR وCLSID وInprocServer32.

يستهدف هذا المقال بشكل رئيسيّ حالات مثل:

• COM DLLs الأصيلة (native)
• خوادم COM المعتمدة على ATL
• عناصر تحكّم ActiveX / OCX
• COM interop المعتمد على .NET Framework
• كشف COM من .NET 5+ / .NET 8 عبر دعم COM host

هناك تمييزان مهمّان جدّاً هنا:

1. Reg-Free COM يدور بشكل رئيسيّ حول التنشيط (activation)
2. توزيع معلومات النوع وإعداد المراجع في وقت التصميم يمكن أن يبقيا مشكلتين منفصلتين

إن اختلطت هاتان النقطتان، تصبح المحادثة بأكملها موحلة بلا داعٍ.

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

flowchart LR
    APP["MyApp.exe"] --> AM["Application Manifest"]
    AM --> DEP["dependentAssembly"]
    DEP --> CM["Component / Assembly Manifest"]
    CM --> META["file / comClass / typelib"]
    META --> DLL["VendorControl.dll / .ocx"]

    APP --> ACTX["Activation Context"]
    ACTX --> COM["CLSIDFromProgID / CoCreateInstance"]
    COM --> DLL

في تنشيط COM العاديّ، يسير CoCreateInstance عبر معلومات الـ registry ليقرّر أيّ DLL ينبغي تحميله.

مع Reg-Free COM، يمكن لوقت التشغيل أن يستشير أوّلاً activation context النشط حاليّاً، ثمّ يحلّ المكوّن من بيانات الـ manifest بدلاً من الـ registry.

هذا ما يجعل من الأسهل على التطبيق A والتطبيق B على الجهاز نفسه أن يحملا نسخاً مختلفة من مكوّنات COM المماثلة دون أن يدوس أحدهما على الآخر بسهولة.

4. لماذا يصبح نشر COM العاديّ ثقيلاً بسهولة

نشر COM العاديّ مؤلم، ليس لأنّ COM نفسه سيّئ بطبيعته، بل لأنّ التسجيل العام مدمج في نموذج التشغيل.

لتنشيط فئة COM، عادةً ما تحتاج إلى معلومات مثل:

وضع هذا في الـ registry مريح للمشاركة على مستوى الجهاز.

لكن في العمل العمليّ، تلك المشاركة نفسها هي التي تسبّب المشكلات في الغالب.

• يستبدل installer منتجٍ ما تسجيل COM لمنتج آخر
• يزيل uninstaller شيئاً ظنّ أنّه خاصّ، لكنّه كان في الواقع مشتركاً
• جهاز المطوّر يحتوي على تسجيلات لا يحتويها جهاز النشر
• تنحرف تسجيلات 32-bit و64-bit بطرق غريبة

في كثير من الأحيان، يؤذي نموذج التوزيع أكثر من COM نفسه. يوجد Reg-Free COM إلى حدٍّ كبير لتقليل ذلك الألم.

5. كيف يعمل Reg-Free COM

5.1 يعلن application manifest عن التبعيّة

على جانب التطبيق، تصف أيّ side-by-side assembly يعتمد عليه التطبيق في application manifest.

يمكن لذلك الـ manifest أن يكون:

• موضوعاً بجانب الـ EXE، مثل MyApp.exe.manifest
• مضمّناً في الـ EXE كمورد

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

كما أنّه عند وجود نسخة مضمّنة ونسخة في نظام الملفّات معاً، تأخذ الـ manifest الموجودة في نظام الملفّات الأولويّة.

5.2 يحمل component manifest بيانات COM الوصفيّة

على جانب المكوّن، يتمّ التعبير عن البيانات الوصفيّة التي ستعيش عادةً في الـ registry في component manifest بدلاً من ذلك.

يمكن أن يشمل ذلك مدخلات مثل:

• comClass
• clsid
• progid
• threadingModel
• typelib
• وأحياناً تفاصيل proxy / stub أو window classes إن لزم الأمر

لذا فإنّ النموذج الذهنيّ بسيط:

بدلاً من وصف مكوّن COM عبر مفاتيح الـ registry، تصف هويّة COM الخاصّة به في صيغة XML manifest.

يمكن لـ component manifest نفسه أيضاً أن يكون:

• ملفّاً منفصلاً موضوعاً بجانب الـ DLL
• مضمّناً في الـ DLL كمورد

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

5.3 activation context هو مركز الجاذبيّة الفعليّ

هذا هو قلب الآليّة بأكملها.

عندما يستدعي التطبيق CLSIDFromProgID أو CoCreateInstance، يمكن لوقت تشغيل COM أن يستشير activation context النشط.

إن وُجدت معلومات ProgID-إلى-CLSID وCLSID-إلى-DLL اللازمة هناك، يمكن لوقت التشغيل أن يحلّ المكوّن دون استخدام تسجيل الـ registry.

إن كانت المعلومات اللازمة مفقودةً، يمكن أن تعود عمليّة الحلّ إلى المسار العاديّ المعتمد على الـ registry.

سلوك العودة هذا هو بالضبط سبب ظهور أحد أبشع الفخاخ:

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

6. ما هي المزايا العمليّة

في عمل تطبيقات Windows الحقيقيّ، المزايا ملموسة بشكل معقول.

6.1 نشر بأسلوب XCOPY أسهل

يمكنك إبقاء الملفّات اللازمة معاً داخل مجلّد التطبيق، ممّا يجعل الـ installers وخطوات التسجيل أخفّ بكثير في الغالب.

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

6.2 تصادمات نسخ أقلّ

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

هذا يقلّل من الحادث الكلاسيكيّ:

“إعداد منتج آخر غيّر السلوك في تطبيقي.”

6.3 مواقع الاستدعاء الموجودة لا تحتاج في الغالب إلى تغييرات كبيرة

يغيّر Reg-Free COM كيفيّة حلّ المكوّنات، وليس بالضرورة كيفيّة استدعاء الكود الموجود لها.

لذا إن لائم المكوّن النموذج بشكل نظيف، يمكنك أحياناً تقديمه دون لمس جانب CoCreateInstance من كود التطبيق إلّا قليلاً.

6.4 التراجع والحذف يصبحان أنظف

لأنّ المكوّن يبقى قريباً من حدود التطبيق، يمكن للتحديثات والتراجع أن يصبحا أبسط بكثير.

في بعض الحالات، يصبح من الواقعيّ التفكير من حيث:

استبدال المجلّد بأكمله

بدلاً من “تشغيل uninstall وإصلاح التسجيل والأمل ألّا يُكسر شيء مشترك.”

7. أين يلائم وأين لا يلائم

7.1 ملاءمة جيّدة

يكون Reg-Free COM جذّاباً بشكل خاصّ في حالات مثل هذه.

يميل إلى الاقتران بشكل جيّد بشكل خاصّ مع تطبيقات سطح مكتب الأعمال وأدوات تكامل الأجهزة والأصول الموجودة من بيئات مثل VB6 أو MFC أو WinForms.

7.2 ملاءمة ضعيفة أو على الأقلّ شيء يحتاج إلى تقييم بعناية

تحتاج بعض الحالات إلى مزيد من الحذر.

النقطة الأخيرة تلك مهمّة كثيراً.

يساعد Reg-Free COM في التنشيط في وقت التشغيل. لا يعيد تلقائيّاً تصميم ما تفترضه أدوات المراجع في وقت التصميم.

8. مفاهيم خاطئة شائعة

8.1 Reg-Free COM يزيل مشكلات الـ bitness

لا يفعل ذلك.

يمكن لعمليّة 32-bit أن تحمّل فقط COM DLL داخل العمليّة 32-bit، ويمكن لعمليّة 64-bit أن تحمّل فقط DLL 64-bit.

تبقى تلك القاعدة كما هي بالضبط.

8.2 Reg-Free COM يعني أنّه لا يتمّ الرجوع إلى الـ registry أبداً

ليس بالضرورة.

إن كانت بيانات الـ manifest غير مكتملة، يمكن أن يُستخدم الحلّ المعتمد على التسجيل العاديّ.

لهذا السبب:

“لقد عمل على جهاز المطوّر” لا يثبت أنّ إعداد Reg-Free كان صحيحاً فعلاً.

8.3 Reg-Free COM يحلّ تلقائيّاً مشكلة type library أيضاً

جزئيّاً فقط.

يمكن للـ manifest أن يصف معلومات typelib، لكنّ أشياء مثل مراجع VBA أو #import في C++ أو إنشاء interop في وقت التصميم على جانب .NET لا تزال غالباً تحتاج إلى تخطيط صريح.

Reg-Free COM يدور أوّلاً حول:

جعل التنشيط يعمل

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

8.4 يمكن جعل أيّ ActiveX / OCX ببساطة Reg-Free

من الخطر افتراض ذلك.

إن لائم المكوّن أنماط تسجيل COM العاديّة، فلديك فرصة أفضل بكثير.

لكن إن كان يعتمد بشدّة على حالة registry مخصّصة أو منطق ترخيص أو عمل إعداد إضافيّ أو مجموعة أكبر من الوحدات التابعة، يمكن أن يصبح مسار Reg-Free أقلّ مباشرةً بكثير.

8.5 Reg-Free COM يعني تقريباً الشيء نفسه عبر .NET Framework و.NET 8

هناك أوجه تشابه، لكنّ سلاسل الأدوات ليست متماثلة.

عالم .NET Framework + RegAsm وعالم .NET 5+ / .NET 8 + comhost مرتبطان، لكنّهما ليسا قابلين للتبادل لمجرّد أنّ كليهما يقول “COM”.

9. COM الأصيل مقابل .NET Framework مقابل .NET 5+ / .NET 8

هذا أحد أسهل الأماكن التي تُخلط فيها المحادثات معاً، لذا يساعد فصل العائلات بشكل صريح.

9.1 COM المعتمد على .NET Framework

مع COM المعتمد على .NET Framework، يكون الإعداد أكثر تعقيداً قليلاً من COM الأصيل في الغالب لأنّك قد تحتاج إلى كليهما:

• application manifest بأسلوب Win32 على جانب العميل
• component manifest على جانب المكوّن المُدار

تلك هي النقطة التي تصبح فيها كثير من المحادثات موحلةً مرّةً أخرى:

“لقد فهمت Reg-Free COM، لكنّ مسار المكوّن المُدار يضيف الآن manifest آخر.”

9.2 كشف COM لـ .NET 5+ / .NET 8

في .NET 5+ / .NET 8، تصبح نقطة الدخول لكشف COM هي *.comhost.dll.

وإن مكّنت EnableRegFreeCom=true، يمكنك أن تجعل البناء ينتج side-by-side manifest لـ Reg-Free COM.

لكنّ تمييزاً واحداً لا يزال مهمّاً:

استراتيجيّة Reg-Free COM واستراتيجيّة TLB موضوعان منفصلان.

في .NET 5+ وما بعده، لم تعد في عالم .NET Framework الأقدم حيث يبدو أنّ type library يخرج طبيعيّاً من مسار الأداة نفسه.

إن كان الاستهلاك المُتحقَّق منه قويّاً مهمّاً، فمن الأكثر أماناً تخطيط توليد TLB وتضمينه وتوزيعه كاهتمام صريح.

10. نموذج ذهنيّ بحدّ أدنى

افترض أنّ MyApp.exe يستخدم Vendor.CameraControl.dll عبر Reg-Free COM.

10.1 صورة تخطيط الملفّات

MyApp.exe
MyApp.exe.manifest
Vendor.CameraControl.dll
Vendor.Helper.dll

في هذه الصورة، يُفترض أنّ component manifest مضمّن في الـ DLL.

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

10.2 صورة application manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
    type="win32"
    name="KomuraSoft.MyApp"
    version="1.0.0.0"
    processorArchitecture="amd64" />

  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Vendor.CameraControl.Asm"
        version="1.0.0.0"
        processorArchitecture="amd64" />
    </dependentAssembly>
  </dependency>
</assembly>

10.3 صورة component manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
    type="win32"
    name="Vendor.CameraControl.Asm"
    version="1.0.0.0"
    processorArchitecture="amd64" />

  <file name="Vendor.CameraControl.dll">
    <comClass
      clsid="{01234567-89AB-CDEF-0123-456789ABCDEF}"
      progid="Vendor.CameraControl.1"
      threadingModel="Apartment"
      tlbid="{89ABCDEF-0123-4567-89AB-CDEF01234567}" />

    <typelib
      tlbid="{89ABCDEF-0123-4567-89AB-CDEF01234567}"
      version="1.0"
      helpdir="" />
  </file>
</assembly>

أهمّ شيء في هذا المثال ليس صياغة XML بدقّة. بل هو أنّ dependentAssembly للتطبيق وassemblyIdentity للمكوّن يتطابقان فعلاً.

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

11. الفخاخ الشائعة

11.1 يعمل على جهاز المطوّر، لكن ليس على جهاز النشر

أوّل ما ينبغي الاشتباه به هو:

أنّ التطبيق كان لا يزال يُساعَد من قبل تسجيل الـ registry المحلّيّ.

لهذا السبب يكون التحقّق من Reg-Free COM أكثر أماناً بكثير في بيئة نظيفة فعلاً.

11.2 “side-by-side configuration is incorrect”

تشير عائلة الفشل تلك في الغالب إلى عدم تطابق في الـ manifest أو نقص في الـ DLLs التابعة أو نقص في قطع VC++ runtime أو عدم تطابق في البنية المعماريّة.

نصّ خطأ السطح ليس لطيفاً بشكل خاصّ، لذا فإنّ الأدوات التالية المعتادة هي:

• Event Log
• sxstrace

11.3 application manifest وcomponent manifest ينحرفان عن بعضهما

تشمل أوجه عدم التطابق الصغيرة-لكن-القاتلة الشائعة:

• أسماء مختلفة
• نسخ مختلفة
• processorArchitecture مختلف
• نسخ manifest أقدم بالخطأ

11.4 نُسي وضع الـ DLLs التابعة

من السهل النظر فقط إلى Vendor.CameraControl.dll وتفويت ما يحمّله بعد ذلك، مثل:

• Vendor.Helper.dll
• قطع VC++ runtime
• proxy / stub DLLs

يقلّل Reg-Free COM من مشكلات تسجيل COM. لا يزيل مشكلات حلّ التبعيّات الأصيلة العاديّة.

11.5 تأجيل استراتيجيّة type library والمراجع لفترة طويلة جدّاً

يمكنك جعل التنشيط في وقت التشغيل يعمل ولا تزال غير مكتمل إن كنت تحتاج إلى:

• ربط مبكر (early binding) من VBA
• #import من C++
• توليد interop في وقت التصميم على جانب .NET

لهذا السبب يساعد الفصل بوعي بين:

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

12. الخلاصة

في جملة واحدة، Reg-Free COM هو طريقة لنقل بيانات تنشيط COM الوصفيّة من الجهاز بأكمله نحو حدود التطبيق.

هذا يمنحك مزايا عمليّة مثل:

• تعبئة COM DLLs / OCXs محليّاً للتطبيق بشكل أسهل
• تصادمات نسخ أقلّ
• نشر وتراجع أبسط

لكنّ هذه لا تزال مهمّة بالقدر نفسه كما من قبل:

• توافق 32-bit / 64-bit
• الـ DLLs التابعة
• استراتيجيّة TLB / المراجع
• تبعيّات التسجيل غير القياسيّة
• التحقّق على بيئات نظيفة

لذا فإنّ الموقف الأساسيّ لاعتماد Reg-Free COM هو:

1. التعامل معه كموضوع تنشيط أوّلاً
2. فصل اهتمامات وقت التشغيل عن اهتمامات وقت التصميم
3. التحقّق على بيئة نظيفة
4. ترتيب الـ bitness والـ DLLs التابعة مبكّراً

إن أبقيت على هذا الترتيب، يصبح النهج أقلّ هشاشةً بكثير.

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

• ما هو COM / ActiveX / OCX - الفروقات والعلاقات في مكان واحد
• كيف نتعامل مع ActiveX / OCX اليوم - جدول قرار للإبقاء أو التغليف أو الاستبدال
• كيف تستخدم DLL خاصّ بـ .NET 8 من VBA بنوع قويّ - كشف COM وتوليد TLB باستخدام dscom

14. مراجع

• Microsoft Learn: Creating Registration-Free COM Objects
• Microsoft Learn: Application Manifests
• Microsoft Learn: Assembly Manifests
• Microsoft Learn: Manifest File Schema
• Microsoft Learn: Registration-Free COM Interop (.NET Framework)
• Microsoft Learn: Expose .NET components to COM
• Microsoft Learn: sxstrace

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

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

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

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

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

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

غو كومورا

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

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