Est-ce que .net appelle COM qui appelle à son tour un autre objet .net COM fonctionne lors de l'utilisation SxS et les fichiers manifestes sont utilisés

Question

J'ai une application .net appelant à un composant COM (C ++) qui appelle à son tour à un autre objet COM implémenté dans .NET.

Cette application utilise les capacités de Windows SxS et n'enregistre aucun de ses composants COM. Pas celui écrit en C ++, et non pas celui écrit en .net.

Ce premier appel à la composante C ++ COM fonctionne très bien. Mais lorsque le composant C ++ COM appelle le .net un, il échoue avec classe non enregistrée.

J'ai essayé de créer une petite application C ++ avec un fichier manifeste qui appelle le composant .net et cela fonctionne. Il semble que lorsque le flux est .net -> COM NATIVE -> .NET COM. Alors casse SxS et ne fonctionne pas.

Lorsque l'on regarde les journaux Fusion (assemblage __gVirt_NP_NNS_NNPS<__ journaux de chargement) Je vois que personne ne même tente de résoudre l'ensemble COM .NET.

Est-ce scénario SxS même censé travailler (je pense qu'il ne censé travailler)? Si oui, que puis-je faire mal?

Ce sont les fichiers manifestes que je utilise.

Le manifeste d'application pour l'application .net (embeded en tant que ressource):

<?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 (fichier régulier):

<?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 manifeste (embeded comme ressource PerformanceMonitor.dll pour travailler autour de .net com bogue dans 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

Il fonctionne, mais il y a des choses qui peuvent le casser (comme je l'ai découvert).

Apparemment, si votre application est une application WinForms, et il utilise cette ) cette commande en elle-même crée un contexte d'activation pour rediriger processus pour utiliser la version Microsoft.Windows.Common-Controls 6.0.0.0. Et pour une raison quelconque cela brise l'utilisation de l'objet com .net que vous définissez dans votre fichier manifeste.

Suppression Application.EnableVisualStyles de l'application, et le remplacer par cette dépendance dans le fichier manifeste semble faire l'affaire:

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