Fa .net COM, che a sua volta chiama altre opere oggetto .NET COM quando si utilizza SxS e sono utilizzati file manifesto chiamando

Question

Ho un'applicazione .NET chiama a un componente COM (C ++), che a sua volta le chiamate verso un altro oggetto COM implementata in .NET.

Questa applicazione utilizza le funzionalità di Windows SxS e non registra da suoi componenti COM. Non quello scritto in C ++, e non quello scritto in .NET.

Questa prima chiamata al C ++ COM componente funziona bene. Ma quando le chiamate C ++ COM componente a .NET uno, non riesce con classe non registrata.

Ho provato a generare un'applicazione piccola C ++ con un file manifesto che chiama la componente .NET e funziona. Sembra che quando il flusso è .net -> COM NATIVE -> NET COM. Poi pause e SxS non funziona.

Se si guarda alla Fusion Logs (Registri di carico di montaggio) Vedo che nessuno è ancora cercando di risolvere il NET COM assemblaggio.

E 'questo scenario SxS anche supposto per il lavoro (penso che non dovrebbe lavoro)? Se sì, allora cosa posso fare male?

Questi sono i file manifesto che sto usando.

Il manifesto app per l'applicazione .NET (embeded come risorsa):

<?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 (file normale):

<?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 manifesta (embeded come risorsa nel PerformanceMonitor.dll Per ovviare a .net com bug in 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

Si fa il lavoro, ma ci sono cose che si possono rompere (come ho scoperto).

A quanto pare, se l'applicazione è un'applicazione WinForms, e utilizza comando Application.EnableVisualStyles di utilizzare gli stili di visualizzazione fornite dal sistema operativo, e allo stesso tempo utilizza i file manifesto per creare un contesto di attivazione, allora siete in una salamoia .

Sembra (in base al questo ) questo comando in sé crea un contesto di attivazione al processo di reindirizzamento di utilizzare Microsoft.Windows.Common-Controls versione 6.0.0.0. E per qualche ragione questo utilizzo pause di .NET com oggetto si definisce in voi file manifesto.

La rimozione Application.EnableVisualStyles dall'applicazione, e la sua sostituzione con questa dipendenza nel file manifesto sembra fare il trucco:

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