شركة كومورا سوفت ذ.م.م.
日本語 English 한국어 繁體中文 العربية
تواصل معنا
القائمة

المزالق الشائعة في تطوير مكوّنات COM و OCX / ActiveX - فخاخ Visual Studio بين 32-bit و 64-bit، والتسجيل، وصلاحيّات المسؤول

· · COM, ActiveX, OCX, تطوير Windows, التقنيّات القديمة

في العمل على مكوّنات COM و OCX / ActiveX، تتعثّر الفِرَق في الغالب لا في الشيفرة نفسها بل في الحدود المحيطة بـ بيئة التشغيل والتسجيل والاستضافة والصلاحيّات.

تبدو الأعراض النموذجيّة هكذا:

  • البناء ينجح، لكنّ التشغيل يفشل بـ 0x80040154
  • يعمل على جهاز المطوّر، لكن لا يعمل على جهاز PC آخر
  • يعمل في وقت التشغيل، لكنّ Visual Studio Designer وحده يموت
  • يعمل عند التشغيل بصلاحيّات المسؤول، لكنّه ينكسر بصلاحيّات عاديّة
  • تواصل تشغيل regsvr32، ومع ذلك لا يُحَلّ شيء

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

إن أردت ترتيب المصطلحات أوّلًا، فمن المفيد البدء بـ ما هو COM / ActiveX / OCX - دليل عمليّ للفروق والعلاقات.
يكمل هذا المقال من تلك النقطة ويركّز على الأماكن التي يتعثّر الناس فيها فعلًا في الممارسة، بما في ذلك مشاكل bitness الخاصّة بـ Visual Studio وصلاحيّات المسؤول.

1. الإجابة الموجزة

إن قُلْنَاها بطريقة مفيدة في العمل الفعليّ، فإنّ النقاط الجوهريّة هي التالية.

  1. معظم إخفاقات COM / OCX / ActiveX سببها أقلّه منطق العمل، وأكثره عدم تطابق في bitness (32-bit / 64-bit) وموقع التسجيل وعمليّة المضيف والصلاحيّات.
  2. Visual Studio 2022 هو عمليّة 64-bit، لذا فإنّ مسارات التكامل في وقت التصميم التي كانت تعمل سابقًا تحت افتراضات 32-bit القديمة قد تفشل الآن كما هي.12
  3. regsvr32 ليس أمرًا سحريًّا يُسجّل كلّ شيء. إنّه لخوادم COM الأصليّة من نوع in-process مثل DLL و OCX. إن كنت تكشف تجميعات .NET Framework لـ COM، فالأداة هي Regasm.exe؛ وفي .NET 5+ / .NET 6+ / .NET 8+، يصبح المسار تسجيل الـ .comhost.dll المُولَّد.3456
  4. “يعمل عند التشغيل كمسؤول، فلا بدّ أنّه على ما يرام” خطير. كثيرًا ما يعني ذلك فقط أنّ المكوّن مرئيّ بالصدفة من خلال تسجيل per-user، أو أنّ شيئًا كان ينبغي تثبيته بشكل صحيح قد سُجِّل يدويًّا فقط على جهاز المطوّر.378

لذا، عند التعامل مع COM / OCX / ActiveX، الأكثر أمانًا أن تبدأ من هذه المحاور الأربعة:

  • أيّ عمليّة تستضيفه
  • هل تلك العمليّة 32-bit أم 64-bit
  • أين سُجِّل (HKCU / HKLM، عرض 32-bit / عرض 64-bit)
  • هل العمليّة أو مسار التنفيذ يتطلّب فعلًا صلاحيّات المسؤول

2. بالعمل عكسيًّا من الأعراض، يبدو الأمر عادةً هكذا

العَرَض أوّل ما يُشتبه به السبب الحقيقيّ في الغالب
0x80040154 Class not registered غير مُسجَّل في الواقع كثيرًا ما يكون “مُسجَّلًا فقط في عرض الـ bitness الآخر” أو “مُسجَّلًا فقط لذلك المستخدم”
DllRegisterServer failed: 0x80070005 صلاحيّات غير كافية محاولة التسجيل كمستخدم قياسيّ، أو تشغيل تسجيل post-build دون رفع
ينكسر VS2022 Designer وحده قيود Designer لا يستطيع Visual Studio 64-bit تحميل COM / ActiveX 32-bit مباشرةً
يعمل فقط عند التشغيل كمسؤول مشكلة صلاحيّات كثيرًا ما تكون المشكلة الحقيقيّة عدم تطابق نطاق التسجيل أو تصميم التثبيت، لا الصلاحيّات بحدّ ذاتها
تطبيق 64-bit لا يستطيع استدعاء OCX 32-bit قيود معماريّة في COM يجب أن تتطابق خوادم in-process مع bitness المضيف
يعمل على خيط الـ UI لكنّه يتجمّد على خيط خلفيّ نموذج خيوط تُنتَهَك افتراضات STA / MTA أو CoInitializeEx أو حلقة الرسائل

رسميًّا، 0x80040154 هو REGDB_E_CLASSNOTREG، أي حرفيًّا Class not registered.9
و 0x80070005 من regsvr32 موثّق أيضًا كحالة تنقص فيها صلاحيّات المسؤول ولا تستطيع العمليّة الكتابة إلى registry أو System32.10

النقطة المهمّة هي عدم الثقة باسم الخطأ حرفيًّا أكثر من اللازم.
على سبيل المثال، Class not registered لا يعني دائمًا “غير مُسجَّل تمامًا”. قد يحدث أيضًا حين يكون الفصل مُسجَّلًا فقط في عرض registry آخر أو فقط في موقع per-user لا تراه العمليّة الحاليّة.117

3. bitness الخاصّ بـ Visual Studio فخّ كبير

3.1. صار Visual Studio 2022 بـ 64-bit

هذا أحد أكبر الفخاخ في تطوير COM / ActiveX الحاليّ.

Visual Studio 2022 هو 64-bit فقط لـ devenv.exe.1
هذا يعني أنّ جانب Visual Studio من تجربة وقت التصميم لـ WinForms لا يستطيع تحميل المكوّنات 32-bit مباشرةً. تذكر Microsoft صراحةً أنّ Visual Studio 2022 هو عمليّة 64-bit ولذلك لا يمكنه تحميل مكوّنات .NET / COM / ActiveX 32-bit مباشرةً.2

بمعنى آخر، الإعداد الذي كان يعمل تحت افتراضات مثل:

  • المشروع x86
  • ضابط ActiveX المرجعيّ أيضًا x86
  • Visual Studio نفسه 32-bit

يتحوّل إلى شيء مختلف في VS2022:

  • لا يزال تطبيق وقت التشغيل يستطيع العمل كـ x86
  • لكنّ Designer يعمل الآن داخل Visual Studio 64-bit

ينشأ عن ذلك عدم تطابق.
والنتيجة هي الحالة المزعجة بشكل خاصّ حيث لا يزال وقت التشغيل يعمل، لكنّ Designer وحده يموت.2

3.2. التحوّل إلى AnyCPU لا يصلح الأمر تلقائيًّا

هذا سوء فهم شائع آخر.

AnyCPU ليس سحرًا يجعل كلّ تبعيّة محايدة أيضًا.
توضّح Microsoft أيضًا أنّه حتى إن بدا المكوّن نفسه AnyCPU، فإنّ وقت التصميم في Visual Studio 2022 لا يزال ينكسر إن كان شيء أسفله يعتمد في النهاية على COM / ActiveX 32-bit.2

لذا، حين لا يجعل التحوّل إلى AnyCPU الخطأ يختفي، يكون من الأسرع غالبًا أن تشتبه بـ:

  • ما إن كانت تلك التجميعة تعتمد على شيفرة أصليّة 32-bit في الأسفل
  • ما إن كان ضابط ActiveX / OCX مثبّتًا على x86
  • ما إن كانت هناك شيفرة تُحمَّل فقط في وقت Designer

3.3. فخّ System32 و SysWOW64

في Windows x64، تتباعد الأسماء عن الواقع بما يكفي لإرباك الناس.

تشرح Microsoft Learn أنّ %windir%\\System32 على Windows x64 مخصّص لـ التطبيقات 64-bit. أمّا الجانب 32-bit فيُعاد توجيهه إلى مكان آخر بواسطة WOW64 file-system redirector.12
يعمل registry بشكل مشابه: WOW64 registry redirector يقدّم عروضًا منطقيّة مختلفة للشيفرة 32-bit و 64-bit.11

لهذا السبب من الأكثر أمانًا، عند تشخيص المشاكل محلّيًّا، أن تجعل أيّ bitness من regsvr32 تستخدم صريحًا تمامًا.

# When you want to register a 64-bit DLL / OCX
C:\Windows\System32\regsvr32.exe vendor.ocx

# When you want to register a 32-bit DLL / OCX on x64 Windows
C:\Windows\SysWOW64\regsvr32.exe vendor.ocx

الجانب المزعج من هذا الفخّ هو أنّك قد تُسجِّل في الجانب الخطأ وتشعر مع ذلك أنّك سجّلته بنجاح.
تصبح النتيجة النهائيّة:

  • نجح regsvr32
  • لكنّ التطبيق لا يزال يحصل على 0x80040154
  • يبدو registry وكأنّ المُدخل موجود
  • لكنّك تنظر إلى العرض الخطأ

هذا النمط شائع للغاية.1113

3.4. لا يستطيع regsvr32 تسجيل كلّ شيء

هذا أيضًا يُساء فهمه على نطاق واسع.

عادةً تُصدِّر خوادم COM الأصليّة من نوع in-process DllRegisterServer / DllUnregisterServer وتدعم التسجيل الذاتيّ.3
regsvr32 هو الأداة لحالات DLL / OCX تلك.4

في المقابل، إن كنت تريد كشف تجميعة .NET Framework لـ COM، فإنّ الأداة العاديّة هي Regasm.exe. توضّح Microsoft Learn صراحةً أنّ Regasm.exe يُستخدم لتسجيل التجميعات لاستخدام COM.514

ثمّ تتغيّر القصّة مرّة أخرى في .NET 5+ / .NET 6+ / .NET 8+: مع <EnableComHosting>true</EnableComHosting>، يُولّد البناء *.comhost.dll، وذلك الـ DLL المُولَّد هو ما تُسجّله بـ regsvr32.6

بشكل تقريبيّ، الانقسام هو:

ما تريد كشفه طريقة التسجيل النموذجيّة
native C++ DLL / OCX regsvr32
تجميعة .NET Framework مكشوفة لـ COM Regasm.exe
كشف COM في .NET 5+ / 6+ / 8+ تسجيل الـ .comhost.dll المُولَّد بـ regsvr32

عندما تختلط هذه، يكون نمط الإخفاق الشائع جدًّا:

  • تشغيل regsvr32 على DLL مُدارة
  • بوضوح، DllRegisterServer مفقود
  • الاستنتاج بأنّ الـ DLL لا بدّ أنّها معطوبة

ذلك الاستنتاج عادةً خاطئ.

في العوالم التي تحتاج type library أيضًا، مثل VBA و VB6 وبعض مستهلكي early-binding، فإنّ توليد TLB وتسجيله هو مسألة منفصلة أخرى. في .NET Framework، يستطيع Regasm.exe /tlb توليد type library وتسجيلها، وتشرح Microsoft أيضًا أنّ “تسجيل النوع” و “تسجيل type library” نشاطان منفصلان.15

4. مشاكل صلاحيّات المسؤول فخّ كبير آخر

4.1. التسجيل موصول بـ post-build وينجح فقط تحت المسؤول

في بناءات C++ مع Visual Studio، من الطبيعيّ تمامًا بمعنى آليّ استدعاء regsvr32.exe من build events أو custom build steps. تُظهر Microsoft Learn حتى أمثلة post-build تستخدم regsvr32.exe.16

لكنّ الممكن و الآمن ليسا الشيء نفسه.

عندما يشغّل مستخدم قياسيّ regsvr32، قد يفشل بـ 0x80070005 لأنّه لا يستطيع الكتابة إلى registry أو System32. تصف KB من Microsoft أيضًا السبب بأنّه نقص في صلاحيّات المسؤول.10

ما يحدث غالبًا في الممارسة:

  • Visual Studio المُشغَّل بشكل عاديّ يبني الثنائيّات بنجاح
  • لكنّ تسجيل post-build وحده يفشل
  • يُغفل الإخفاق
  • لا يزال تسجيل قديم موجودًا من قبل، فيعمل التطبيق مصادفةً محلّيًّا
  • في بيئة نظيفة، يفشل بطبيعة الحال

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

  • يجب أن يُنتِج البناء ثنائيّات فقط
  • يجب أن يكون التسجيل خطوة تثبيت / سكريبتًا / خطوة installer واضحة
  • في CI، ينبغي أن تكون خطوة “تتطلّب التسجيل” مهمّة منفصلة عن البناء

هذا الفصل وحده يزيل عددًا مدهشًا من الحوادث.

4.2. خلط التسجيل per-user و per-machine يُعطّب الأمور

إن كانت ذاكرتك الوحيدة هي “COM ينظر في HKCR”، فقد تتعثّر هنا.

تشرح Microsoft Learn أنّ COM ينظر فعلًا في HKEY_CURRENT_USER\\Software\\Classes أوّلًا، ثمّ يتعامل مع المعلومات الخاصّة بالجهاز كلّه بعد ذلك.3
كما تشرح أنّ HKEY_CLASSES_ROOT هو عرض مدمج لـ HKLM\\Software\\Classes و HKCU\\Software\\Classes.717

هذا يعني أنّ مواقف كهذه طبيعيّة تمامًا:

  • يسجّل المطوّر A يدويًّا تحت مستخدمه
  • يعمل لدى المطوّر A
  • لا يعمل لدى المطوّر B
  • يفشل أيضًا لحساب خدمة
  • يتغيّر السلوك مرّة أخرى عند التشغيل كمسؤول

كما تذكر Microsoft أنّ التطبيقات التي تتطلّب صلاحيّات المسؤول ينبغي أن تسجّل كائنات COM التابعة في مخزن تكوين COM per-machine أثناء التثبيت.87

لذا في فريق تطوير حقيقيّ، يجب أن يكون التمييز التالي صريحًا:

  • هل هذا تسجيل per-user للمطوّر فقط
  • أم تسجيل إنتاجيّ per-machine لكلّ مستخدم على الـ PC
  • أم تسجيل يجب أن يكون مرئيًّا للخدمات أو التطبيقات المرفوعة

إن بقي ذلك ضبابيًّا، فستحصل على ارتباك كلاسيكيّ مثل “يعمل فقط كمسؤول” أو “يعمل من استضافة Explorer extension، لكن ليس من الخدمة”.

4.3. تشغيل Visual Studio دائمًا كمسؤول ليس إصلاحًا حقيقيًّا

ثمّة حالات يكون فيها الرفع ضروريًّا.
لكن إن كان Visual Studio يعمل دائمًا كمسؤول، فقد يخفي مشاكل ينبغي حلّها فعلًا بواسطة installer أو سكريبت تسجيل صريح.

كما يغيّر Visual Studio نفسه سلوكه في الوضع المرفوع. توثّق Microsoft Learn إعدادات حيث تُعطَّل الامتدادات per-user عند تشغيل Visual Studio مرفوعًا.18

لذا، كنموذج تشغيل، هذا عادةً أكثر أمانًا:

  • قُمْ بالتطوير العاديّ تحت صلاحيّات المستخدم العاديّ
  • شغّل فقط الخطوات التي تتطلّب فعلًا تسجيلًا بـ Developer Command Prompt / PowerShell / installer مرفوع صراحةً
  • إن تكرّر شيء كمسؤول فقط، فاعتبر ذلك الافتراض نفسه حقيقة تصميميّة ينبغي توثيقها

هذا يُسبّب عادةً مشاكل أقلّ لاحقًا.

5. لـ ActiveX / OCX فخاخها الإضافيّة الخاصّة

5.1. قد تختلف رخص وقت التصميم عن رخص وقت التشغيل

جزء مزعج بهدوء من العمل على OCX / ActiveX هو الترخيص.

خصوصًا لضوابط ActiveX الأقدم، قد تكون رخصة وقت التصميم و رخصة وقت التشغيل منفصلتين. توثيق MFC ActiveX يشرح أيضًا آليّات حيث تفصل ملفّات الرخصة أو مفاتيح الرخصة استخدام وقت التصميم عن وقت التشغيل.1920

ينشأ عن ذلك مواقف مثل:

  • استخدام وقت التشغيل يعمل
  • لكنّ وضع الضابط على نموذج يقول إنّه لا توجد رخصة
  • جهاز المطوّر A يستطيع وضعه
  • جهاز المطوّر B لا يستطيع

أخطاء مثل “license information for this component not found” أو “you don’t have an appropriate license” ليست غير معتادة في بيئات ActiveX الأقدم.21

5.2. عند وصوله إلى داخل WinForms، يكون هناك بالفعل طبقة مغلِّفة

عندما يستخدم WinForms ActiveX، فإنّ Windows Forms لا يستضيف ضابط ActiveX خامًا تمامًا.
كما تشرح Microsoft Learn في توثيق Aximp.exe، يُولّد ActiveX Control Importer مغلِّفًا لـ WinForms من type library الخاصّة بـ COM، ثمّ يعمل WinForms مع ذلك من خلال ضابط مبنيّ على AxHost.2223

لذا فالمشكلة ليست طبقة واحدة. إنّها على الأقلّ هذه الطبقات:

  1. الـ OCX / ActiveX الأصليّ نفسه
  2. type library
  3. الـ interop / wrapper المُولَّد
  4. WinForms Designer / runtime

لهذا تحدث أمور كهذه:

  • استبدال OCX المورّد يغيّر تواقيع الأحداث
  • إعادة إضافة المرجع يُعيد توليد المغلِّفات ويُنشئ diff كبيرًا
  • تُولّد آلات مختلفة نتائج interop مختلفة قليلًا

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

5.3. إن استهنت بـ STA / MTA وحلقة الرسائل، تتجمّد الأمور

يجب تهيئة COM لكلّ خيط بـ CoInitializeEx. تذكر Microsoft Learn صراحةً أنّ كلّ خيط يستخدم COM يجب أن يستدعي CoInitializeEx لنفسه.24

كما أنّ STA (single-threaded apartment) يتطلّب حلقة رسائل.2425

غالبًا ما تكون مكوّنات OCX / ActiveX الموجّهة للواجهة قائمة على STA، لذا فإنّ هذا النوع من الإخفاق شائع:

  • يعمل على خيط الـ UI
  • يتجمّد عند نقله إلى Task.Run أو إلى تجمّع الخيوط
  • لا تعود الأحداث أبدًا
  • يتكرّر أحيانًا فقط

في STA، ثمّة أيضًا قاعدة بأنّك يجب ألّا تنسخ مؤشّرات الواجهة عبر الخيوط ببساطة؛ إن احتجت إلى استخدام عبر الخيوط، فيجب أن تُجَرَّ بشكل مناسب.2425

تستهلك هذه الأخطاء وقتًا بقدر مشاكل registry لأنّها لا تفشل بوضوح كـ 0x80040154. غالبًا ما تظهر فقط على هيئة تجمّد، أو لا callback، أو أعطال متقطّعة.

6. ترتيب عمليّ لتشخيص المشاكل يعمل في الميدان

في الممارسة، يكون من الأسرع غالبًا عدم الغوص العميق فورًا، بل تقطيع المشكلة بهذا الترتيب.

6.1. أوّلًا، ثبّت أيّ عمليّة بأيّ bitness

هذا أوّل شيء تتحقّق منه.

  • ما هي عمليّة المضيف (Visual Studio Designer / تطبيقك الخاصّ / Office / Access / Explorer / مضيف شبيه بالمتصفّح)
  • هل هذا المضيف 32-bit أم 64-bit
  • هل الـ DLL / OCX المستهدف 32-bit أم 64-bit
  • هل هو in-process أم out-of-process

إن بقي ذلك ضبابيًّا وبدأت من registry، فستضيع عادةً.

6.2. ثمّ تحقّق من نوع التسجيل الصحيح فعلًا

السؤال التالي هو ما الذي يجب تسجيله بأيّ شيء.

  • DLL / OCX أصليّ → regsvr32
  • كشف COM لـ .NET Framework → Regasm.exe
  • كشف COM لـ .NET 5+ / 6+ / 8+ → .comhost.dll
  • DLL بدون دعم تسجيل ذاتيّ → ليس regsvr32

هذا التصنيف وحده يمنع الكثير من الأخطاء غير المضطرّة.

6.3. بعد ذلك، تحقّق من المكان الذي سُجِّل فيه فعلًا

لمحة بسيطة على HKCR لا تكفي.

تحتاج غالبًا إلى النظر إلى:

  • HKCU\\Software\\Classes
  • HKLM\\Software\\Classes
  • عرض registry 32-bit / 64-bit إن كان ذا صلة
  • ProgID / CLSID / TypeLib المستهدف
  • InprocServer32 / LocalServer32
  • ThreadingModel
  • المسار الفعليّ لـ DLL المرجعيّ

“موجود في HKCR” لا يكفي بعد. لا يصبح ذا معنى إلّا حين تصطفّ مَن ينظر، بأيّ bitness، عبر أيّ عرض.711

6.4. أخيرًا، تحقّق ممّا إن كانت الصلاحيّات تخفي الشكل الحقيقيّ فقط

في الخطوة الأخيرة، تحقّق ممّا إن كانت المشكلة فعلًا صلاحيّات، أو ما إن كانت الصلاحيّات تغيّر فقط أيّ تسجيل مرئيّ.

  • هل يتغيّر السلوك بين المستخدم القياسيّ والمسؤول
  • ماذا يتغيّر إن رُفع Visual Studio
  • هل يتكرّر تحت حساب خدمة أو مستخدم آخر
  • هل يعمل أيضًا في بيئة نظيفة مدفوعة بـ installer

إن كنت تنظر دائمًا إلى جهاز مطوّر واحد فقط، فهنا يُسيء الناس قراءة الموقف بسهولة كبيرة.

7. قرارات تشغيليّة تقلّل الحوادث

في تطوير وصيانة COM / ActiveX / OCX، قد تكون طريقة اتّخاذ قرارات نموذج التشغيل أهمّ من حِيَل التنفيذ منخفضة المستوى.

7.1. قرّر سياسة الـ bitness أوّلًا

في البداية، قرّر هذا صراحةً:

  • هل ستذهب x86 فقط
  • هل x64 هو الهدف الرئيسيّ
  • هل تدعم الاثنين
  • هل يجب أن يبقى هذا المكوّن in-process

إن كان OCX المورّد مثبّتًا على x86، فإنّ تجاهل ذلك وجعل التطبيق فقط x64 سيفشل عادةً لاحقًا.
للهيكليّة الأوسع حول هذه المشكلة، فإنّ كيفيّة استدعاء DLL 64-bit من تطبيق 32-bit - دراسة حالة عمليّة لجسر COM وثيقة الصلة.

7.2. قرّر استراتيجيّة التسجيل

من الأفضل أيضًا التعامل مع التسجيل بشكل متعمَّد.

  • يستخدمه الجهاز كلّه → سجّل per-machine عبر installer
  • يستخدمه فقط ذلك المستخدم → استخدم تسجيل per-user عمدًا
  • يبقى داخل تطبيقك بالكامل → فكّر في COM بدون تسجيل
  • مطلوب فقط للتطوير → احصره في سكريبت إعداد تطوير صريح

COM بدون تسجيل مفيد لأنّه يستطيع الاحتفاظ بمعلومات التفعيل في manifest بدلًا من registry، وهذا يساعد على تقليل جحيم التسجيل. كلّ من registration-free COM على جانب Win32 و RegFree COM على جانب .NET موثَّقان رسميًّا.26627

7.3. لا تترك الكثير من الأصول المُولَّدة خارج التحكّم بالمصدر

من أنماط الإخفاق الشائعة في عمل OCX / ActiveX أنّ التبعيّات تتشتّت:

  • الـ OCX نفسه
  • DLLs التابعة
  • الـ TLB
  • الـ .lic
  • DLLs الخاصّة بـ interop
  • مغلِّف AxHost
  • سكريبتات التسجيل
  • المضيف النموذجيّ

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

كحدّ أدنى، ينبغي الاحتفاظ بما يلي بجوار الشيفرة:

  • أيّ إصدار مفترض
  • ما الذي يجب تثبيته، وبأيّ ترتيب
  • أيّ أوامر تُسجّله
  • هل هو لـ x86 أم x64

8. هذا النوع من الاستشارات مناسب جيّدًا

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

على سبيل المثال، هذه أنواع عمل استشاريّ متوافقة جدًّا:

  • فصل أسباب 0x80040154 أو 0x80070005 إلى مشاكل bitness وتسجيل وصلاحيّات
  • التحقّق من مقدار ما يمكن إنقاذه واقعيًّا من إعداد Designer مكسور بعد الانتقال إلى Visual Studio 2022
  • الإبقاء على OCX المورّد في مكانه مع نقل الشيفرة المحيطة نحو .NET أو C#
  • تقرير إلى أيّ مدى نُمدّ عمر الأصول المثبّتة على x86، وأين نَجسر أو نُغلّف أو نستبدل
  • إعادة تصميم التثبيت / النشر بحيث لا يعتمد النظام على regsvr32 يدويّ

قرار keep / wrap / replace الأوسع نفسه أسهل بكثير في تنظيمه أيضًا مع كيف نتعامل مع ActiveX / OCX اليوم - جدول قرار للإبقاء / التغليف / الاستبدال.

9. الخلاصة

عندما يفشل العمل على مكوّنات COM و OCX / ActiveX، تقع الأسباب عادةً في هذه المجموعات الأربع:

  1. الـ bitness لا يصطفّ
  2. طريقة التسجيل خاطئة
  3. نطاق التسجيل غير متطابق (HKCU / HKLM، عرض 32-bit / 64-bit)
  4. النظام يبدو أنّه يعمل فقط لأنّ الصلاحيّات تكشف شيئًا مصادفةً

مع تحوّل Visual Studio 2022 إلى 64-bit، صار الإعداد القديم بأسلوب “كان يعمل بطريقة ما” أسهل بكثير في الانكسار بطرق مرئيّة.12
لهذا بالضبط، عند لمس COM / OCX / ActiveX اليوم، فإنّ المسار الأسرع غالبًا هو محاذاة افتراضات البيئة قبل كتابة المزيد من الشيفرة.

بدلًا من السؤال عن عدد مرّات تشغيل regsvr32، من الأسرع عادةً ترتيب:

  • أيّ عمليّة تستضيفه
  • أيّ bitness لتلك العمليّة
  • أين يجب تسجيله
  • هل ينبغي فعلًا أن يتطلّب ذلك التسجيل صلاحيّات مسؤول
  • هل يُفحَص Designer ووقت التشغيل بشكل منفصل

المراجع

  1. Microsoft Learn, Visual Studio 2022 version 17.0 Release Notes — devenv.exe is now 64-bit only. https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes-v17.0 ↩ ↩2 ↩3

  2. Microsoft Learn, Troubleshoot 32-bit problems - Windows Forms — Visual Studio 2022 is a 64-bit process, cannot directly load 32-bit .NET / COM / ActiveX, and has out-of-process designer constraints. https://learn.microsoft.com/en-us/dotnet/desktop/winforms/visualstudio/troubleshoot-32bit ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, Classes and Servers — COM registration, HKCU / HKCR, self-registration, and DllRegisterServer. https://learn.microsoft.com/en-us/windows/win32/com/classes-and-servers ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, regsvr32 — syntax and role of regsvr32. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/regsvr32 ↩ ↩2

  5. Microsoft Learn, Registering Assemblies with COM — .NET Framework COM registration uses Regasm.exe. https://learn.microsoft.com/en-us/dotnet/framework/interop/registering-assemblies-with-com ↩ ↩2

  6. Microsoft Learn, Expose .NET Core components to COM — EnableComHosting, generated .comhost.dll, regsvr32, and EnableRegFreeCom. https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com ↩ ↩2 ↩3

  7. Microsoft Learn, Merged View of HKEY_CLASSES_ROOT — HKCR is a merged view of HKLM and HKCU. https://learn.microsoft.com/en-us/windows/win32/sysinfo/merged-view-of-hkey-classes-root ↩ ↩2 ↩3 ↩4 ↩5

  8. Microsoft Learn, HKEY_CLASSES_ROOT Key — recommends per-machine COM registration for applications that require administrator rights. https://learn.microsoft.com/en-us/windows/win32/sysinfo/hkey-classes-root-key ↩ ↩2

  9. Microsoft Learn, COM Error Codes (Generic) (Winerror.h) — including REGDB_E_CLASSNOTREG (0x80040154). https://learn.microsoft.com/en-us/windows/win32/com/com-error-codes-1 ↩

  10. Microsoft Learn, You receive 0x80070005 error when you try to register a DLL by using Regsvr32.exe — the typical permissions-related DLL-registration failure. https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/dllregisterserver-error ↩ ↩2

  11. Microsoft Learn, Registry Redirector — 32-bit / 64-bit registry views under WOW64. https://learn.microsoft.com/en-us/windows/win32/winprog64/registry-redirector ↩ ↩2 ↩3 ↩4

  12. Microsoft Learn, File System Redirector — %windir%\\System32 on x64 Windows and WOW64 file-system redirection. https://learn.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector ↩

  13. Microsoft Learn, Overview of compatibility considerations for 32-bit programs on 64-bit versions of Windows — file and registry redirection under WOW64. https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/compatibility-limitations-32-bit-programs-64-bit-system ↩

  14. Microsoft Learn, Regasm.exe (Assembly Registration Tool) — the role of Regasm.exe and options such as /tlb. https://learn.microsoft.com/en-us/dotnet/framework/tools/regasm-exe-assembly-registration-tool ↩

  15. Microsoft Learn, Packaging a .NET Framework Assembly for COM — type libraries and Regasm.exe /tlb. https://learn.microsoft.com/en-us/dotnet/framework/interop/packaging-an-assembly-for-com ↩

  16. Microsoft Learn, Understanding Custom Build Steps and Build Events — includes a post-build example that uses regsvr32.exe. https://learn.microsoft.com/en-us/cpp/build/understanding-custom-build-steps-and-build-events ↩

  17. Microsoft Learn, The Windows registry for advanced users — behavior of HKCU\\Software\\Classes, HKLM\\Software\\Classes, and HKCR. https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/windows-registry-advanced-users ↩

  18. Microsoft Learn, Find, install, and manage extensions for Visual Studio — behavior of per-user extensions under elevated execution. https://learn.microsoft.com/en-us/visualstudio/ide/finding-and-using-visual-studio-extensions ↩

  19. Microsoft Learn, MFC ActiveX Controls: Licensing an ActiveX Control — design-time / run-time licensing and .LIC. https://learn.microsoft.com/en-us/cpp/mfc/mfc-activex-controls-licensing-an-activex-control ↩

  20. Microsoft Learn, Application Settings, MFC ActiveX Control Wizard — runtime-license generation and .lic files. https://learn.microsoft.com/en-us/cpp/mfc/reference/application-settings-mfc-activex-control-wizard ↩

  21. Microsoft Learn, License information for this component not found. You don’t have an appropriate license to use this functionality in the design environment. https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/license-information-for-this-component-not-found-you-don-t-have-an-appropriate-l ↩

  22. Microsoft Learn, Aximp.exe (Windows Forms ActiveX Control Importer) — converts ActiveX to a WinForms wrapper. https://learn.microsoft.com/en-us/dotnet/framework/tools/aximp-exe-windows-forms-activex-control-importer ↩

  23. Microsoft Learn, AxHost Class — the AxHost-based wrapper produced by ActiveX Control Importer. https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.axhost ↩

  24. Microsoft Learn, Initializing the COM Library — CoInitializeEx, per-thread initialization, and the STA message loop. https://learn.microsoft.com/en-us/windows/win32/learnwin32/initializing-the-com-library ↩ ↩2 ↩3

  25. Microsoft Learn, Single-Threaded Apartments — STA message loops, marshaling, and ThreadingModel. https://learn.microsoft.com/en-us/windows/win32/com/single-threaded-apartments ↩ ↩2

  26. Microsoft Learn, Creating Registration-Free COM Objects — registry-free activation through activation context. https://learn.microsoft.com/en-us/windows/win32/sbscs/creating-registration-free-com-objects ↩

  27. Microsoft Learn, Registration-Free COM Interop — .NET Framework registration-free COM interop. https://learn.microsoft.com/en-us/dotnet/framework/interop/registration-free-com-interop ↩

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

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

ما يجب التحقّق منه عندما لا يعمل ActiveX على Office 2024 / Microsoft 365 - الترتيب العمليّ لتغطية التعطيل الافتراضيّ، 32bit / 64bit، تسجيل COM، DLL التابعة، ووصولًا إلى IE mode

دليل عمليّ لتشخيص توقّف ActiveX على Office 2024 و Microsoft 365، يرتّب الفحوص من التعطيل الافتراضيّ إلى تطابق 32bit / 64bit وتسجيل COM وD...

قراءة المقالة

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

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

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

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

غو كومورا

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

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

تواصل معنا

روابط عامة

GitHub LinkedIn X COM_BLAS COM_BigDecimal
العودة إلى المدونة