O .Net Calling Com o que, por sua vez

Question

Eu tenho um aplicativo .NET chamando para um componente COM (C ++) que, por sua vez, chama para outro objeto COM implementado no .NET.

Este aplicativo está usando recursos do Windows SXS e não registra nenhum dos seus componentes com. Não é o escrito em C ++, e não o escrito no .NET.

Esta primeira chamada para o componente C ++ com funciona bem. Mas quando o componente C ++ com o .NET ONE, ele falha com a classe não registrada.

Tentei criar um pequeno aplicativo C ++ com um arquivo de manifesto que chama o componente .NET e funciona. Parece que quando o fluxo é .NET -> com nativo -> .Net com. Então o SXS quebra e não funciona.

Ao olhar para os logs de fusão (logs de carregamento de montagem), vejo que ninguém está tentando resolver o conjunto .NET COM.

Esse cenário do SXS deve funcionar (acho que deveria funcionar)? Se sim, então o que posso estar fazendo de errado?

Estes são os arquivos de manifesto que estou usando.

O aplicativo se manifesta para o aplicativo .NET (incorporado como recurso):

<?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 (arquivo regular):

<?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>

Manifesto de Performancemonitor (incorporado como recurso em performancemonitor.dll para contornar o .net com bug no 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

Funciona, mas há coisas que podem quebrá -lo (como descobri).

Aparentemente, se o seu aplicativo é um aplicativo Winforms, e ele usa Application.enableVisualStyles O comando para usar estilos visuais fornecido pelo sistema operacional e, ao mesmo tempo, usa arquivos de manifesto para criar um contexto de ativação, você está em um picles.

Parece (de acordo com isto) Esse comando, por si só, cria um contexto de ativação para redirecionar o processo para usar o Microsoft.Windows.Common-Controls versão 6.0.0.0. E por algum motivo, isso quebra o uso do objeto .NET COM que você define em seu arquivo manifesto.

Remover o aplicativo.enableVisualStyles do aplicativo e substituí -lo por essa dependência no arquivo de manifesto parece fazer o truque:

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