هل .NET Calling COM والذي بدوره يعمل كائن .NET COM يعمل عند استخدام SXS وملفات البيان المستخدمة

Question

لديّ تطبيق .NET يدعو إلى مكون COM (C ++) والذي بدوره يستدعي كائن COM آخر تم تنفيذه في .NET.

يستخدم هذا التطبيق إمكانيات Windows SXS ولا يسجل أي من مكونات COM. ليس الشخص المكتوب في C ++ ، وليس الشخص المكتوب في .NET.

هذه المكالمة الأولى إلى مكون C ++ COM يعمل بشكل جيد. ولكن عندما يستدعي مكون C ++ COM إلى .NET One ، فإنه يفشل مع فئة غير مسجلة.

لقد حاولت إنشاء تطبيق C ++ صغير مع ملف واضح يستدعي مكون .NET ويعمل. يبدو أنه عندما يكون التدفق .NET -> com native -> .net com. ثم يكسر SXS ولا يعمل.

عند النظر إلى سجلات الاندماج (سجلات تحميل التجميع) ، أرى أنه لا أحد يحاول حتى حل مجموعة .NET COM.

هل من المفترض أن يعمل سيناريو SXS هذا (أعتقد أنه من المفترض أن يعمل)؟ إذا كانت الإجابة بنعم ، فماذا يمكنني أن أفعل خطأ؟

هذه هي الملفات الواضحة التي أستخدمها.

بيان التطبيق لتطبيق .NET (مدمج كمورد):

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
<file name="DotNetComConsumer.dll" hashalg="SHA1">
  <comClass clsid="{44E69FC9-5EAF-4D57-8C09-430F703AD82F}" tlbid="{4F81C9C3-FDDF-48F6-BC25-6F8CD458EBE6}"/>
  <typelib tlbid="{4F81C9C3-FDDF-48F6-BC25-6F8CD458EBE6}" resourceid="1" version="2.0" helpdir="" flags="HASDISKIMAGE"/>
</file>
<comInterfaceExternalProxyStub name="_Class1" iid="{5D41351A-440B-4175-9296-72D5EED83AA7}" tlbid="{4F81C9C3-FDDF-48F6-BC25-6F8CD458EBE6}"   proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"/>
<dependency>
  <dependentAssembly>
    <assemblyIdentity type="win32" name="application.sxs" version="1.0.0.0" />
  </dependentAssembly>
</dependency>
</asmv1:assembly>

application.sxs.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="application.sxs" version="1.0.0.0"/>   
<dependency>
<dependentAssembly>
  <assemblyIdentity name="PerformanceMonitor" version="10.0.0.9999" publicKeyToken="792843134cf0407a" processorArchitecture="msil"/>
</dependentAssembly>
</dependency>
</assembly>

Performancemonitor بيان (تم تضمينه كمورد في performancemonitor.dll للعمل حول .NET COM BUG في XP):

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity name="PerformanceMonitor" version="10.0.0.9999" publicKeyToken="792843134cf0407a" processorArchitecture="msil"></assemblyIdentity>

<clrClass clsid="{AA614438-BC7D-400c-8837-525BFBB7253A}" progid="PerformanceMonitorFactory" threadingModel="Both" name="PerformanceMonitorFactory" runtimeVersion="v2.0.50727"></clrClass>
<file name="PerformanceMonitor.dll" hashalg="SHA1"/>
</assembly>

Answer 1

إنه يعمل ، ولكن هناك أشياء يمكن أن تكسرها (كما اكتشفت).

على ما يبدو ، إذا كان التطبيق الخاص بك هو تطبيق WinForms ، ويستخدم application.enablevisualstyles أمر لاستخدام الأنماط المرئية التي يوفرها نظام التشغيل ، وفي الوقت نفسه يستخدم الملفات البيضاء لإنشاء سياق تنشيط ، ثم تكون في مخلل.

يبدو (حسب هذه) ينشئ هذا الأمر في حد ذاته سياق تنشيط لإعادة توجيه العملية لاستخدام microsoft.windows.common-controls الإصدار 6.0.0.0. ولسبب ما ، يكسر هذا استخدام كائن .NET COM الذي تحدده في الملف الواضح.

إزالة application.

<dependency>
   <dependentAssembly>
     <assemblyIdentity
       type="win32"
       name="Microsoft.Windows.Common-Controls"
       version="6.0.0.0"
       processorArchitecture="X86"
       publicKeyToken="6595b64144ccf1df"
       language="*"
     />
   </dependentAssembly>
</dependency>