El registro de un DLL COM NET durante Wix Instalar

Question

Antecedentes:

Nuestra aplicación es un plugin para una aplicación mucho más amplia. Todo lo que creamos son archivos DLL a los que se conecta la aplicación más grande. Debido a esto, nuestros .NET (C#), los archivos DLL deben estar registrados para una interfaz COM.

Tenemos un proyecto en funcionamiento InstallShield, pero por muchas razones que no entraré aquí, deseamos migrarlo al WiX. Lo único que queda por hacer para el instalador es registrar nuestros archivos DLL para COM.

Problemas

Aquí es un componente de la muestra con un solo archivo DLL.

<Component Id="MyComponent" Guid="COMPONENT-GUID" SharedDllRefCount="yes" > 
    <File Id="MyDLL.dll" Name="MyDLL.dll" KeyPath="yes" Assembly=".net" 
      AssemblyManifest="MyDLL.dll" AssemblyApplication="MyDLL.dll" /> 
</Component> 

De acuerdo con la respuesta aceptada de How do you register a Win32 COM DLL file in WiX 3?, se recomienda añadir SelfRegCost=1 a la etiqueta del archivo. Esto produce un error durante la instalación:

Módulo C: \ Archivos de programa \ Producto \ MyDll.dll no se pudo registrar. HRESULT -2147024769. Contacte a su personal de soporte.

La segunda respuesta en la misma pregunta (por Rob Menshing) recomienda en contra de este enfoque, pero a añadir dentro de la etiqueta de archivos siguiente:

<Class Id="PUT-CLSID-HERE" Context="InprocServer32" ThreadingModel="apartment" Description="Your server description"> 
     <ProgId Id="Your.Server.1" Description="Your ProgId description"> 
      <ProgId Id="Your.Server" Description="Your ProgId description" /> 
     </ProgId> 
    </Class> 

    <Class Id="PUT-PROXY-CLSID-HERE" Context="InprocServer32" ThreadingModel="both" Description="Your server Proxies, assuming you have them"> 
     <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface1" /> 
     <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface2" /> 
     <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface3" /> 
     <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface4" /> 
    </Class> 

estoy un poco confundido en cuanto a poner en que la ID de CLSID. Puse un GUID generado y lo instalé. Se instaló bien, pero la aplicación más grande no pudo encontrar los archivos DLL. (Utilicé las etiquetas generadas a partir de la interfaz heat.exe.)

Otro enfoque que se encuentra en la misma pregunta (por Adan tegen) recomienda el uso de archivo heat.exe MYDLL.DLL salida privado my.wxs

Uso de la salida, agrego esto a la etiqueta del archivo:

<TypeLib Id="Another Guid" Language="0" MagorVersion="1"> 
    <!--Interfaces generated from heat.exe--> 
</TypeLib> 

Cada forma que he intentado registrarse .NET para COM ha fallado y después de leer tantas preguntas sobre el tema que hay cerca de conocer la forma correcta de hacerlo yo. ¿Que debería hacer? ¿Por qué es una tarea tan difícil cuando todo lo demás en WiX ha sido bastante simple?

Debo mencionar que el proyecto original InstallShield creó una acción personalizada que llamaría regasm.exe. Si todo lo demás falla, podría ser una posibilidad, pero preferiría hacer las cosas bien.

Acabo de encontrar que heat.exe file myDll.dll -scom -o myDll.wxs genera valores de registro similares a los que necesito. Ahora, ¿cómo hago referencia al componente recién creado dentro del componente DLL?

Answer 1

Acabo de encontrar que heat.exe file myDll.dll -scom -o myDll.wxs genera valores de registro similares a los que necesito.

¿Estás seguro de -scom allí? ¡AFAIK, esa opción en realidad suprime el registro COM!

Ahora, ¿cómo hago referencia al componente recién creado dentro del componente DLL?

El componente generada por heat.exe ya incluye un elemento File para el DLL. Por lo tanto, en realidad contiene todo lo necesario para instalar y registrar el archivo DLL. No necesita el "componente DLL" original.

Si necesita colocar el archivo y su registro COM en componentes separados, entonces tendrá que eliminar el elemento File del componente generado por heat.exe.

Además, los componentes no pueden hacer referencia a otros componentes. Sin embargo, puede tener referencias entre ComponentGroup s, algo que utilizamos mucho en nuestras wixlibs para model dependencies, pero ese es un caso de uso bastante avanzado.