Conjuntos de registro WiX para COM Interop

installer wix3.5

Question

Realmente estoy luchando con WiX. Tengo ensamblados de .NET para instalar que requieren registro para COM Interop, Y deben estar registrados con otro marco que requiera llamar a un método Register () en un ensamblado .NET que esté en el GAC. Este método de registro es una "caja negra" con un mecanismo de almacenamiento oculto, por lo que no puedo realizar esta operación de manera declarativa.

Entiendo que el enfoque declaritivo es mejor para el registro COM, pero tengo dos problemas con el uso de heat.exe:

1. RegAsm funciona, pero Heat.exe se ahoga en mi ensamblaje con el mensaje:

   heat.exe: advertencia HEAT5151: no se pudieron recopilar datos de un archivo que se esperaba fuera un ensamblado: C: [...]. dll. Si este archivo no es un ensamblaje, puede ignorar esta advertencia. De lo contrario, este detalle de error puede ser útil para diagnosticar el error: Excepción ha sido lanzada por el tget de una invocación.

2. El registro secundario que necesito hacer depende del atributo [ComRegisterFunction], que normalmente desencadena acciones adicionales en el momento en que el ensamblado se registra para COM Interop. Esto normalmente ocurre cuando el ensamblado está registrado por RegAsm.exe o llamando a System.Runtime.InteropServices.RegistrationServices. Por lo tanto, necesito que ComRegisterFunction en mi ensamblaje se ejecute durante la instalación.

No me importa tomar el enfoque declarativo para el registro COM (o no me importaría si el calor funcionó en mi ensamblaje) pero necesito llamar a esa función ComRegister como parte de la instalación. Idealmente, me gustaría ver todos los ejecutables que estoy instalando, reflexionar sobre ellos para cualquier método con el atributo [ComRegisterFunction] y llamar a esos métodos, esto se haría después de que se hayan instalado todos los archivos.

¿Cómo puedo lograr esto en WiX? O, ¿hay otro enfoque? Si hace alguna diferencia, estoy usando la integración ''Votive'' de Visual Studio con las referencias del proyecto.

Answer 1

Estos son objetivos opuestos. El punto de usar el enfoque declarativo es no usar Regasm.exe o Regsvr32.exe para llamar a la función de registro. En otras palabras, no se llamará a su método atribuido [ComRegisterFunction]. No puedes tener ambos.

La excepción de que heat.exe muere no es saludable, indica que hay algo mal con su función de registro o contructor de clase. Depure esto haciendo que su DLL sea el proyecto de inicio. Proyecto + Propiedades, pestaña Depurar y hacer que heat.exe sea el programa de inicio. Establezca la línea de comando en su DLL. Depurar + Excepciones y marcar el cuadro Lanzado para excepciones CLR, el depurador se detendrá cuando se lanza la excepción.

Ah, y no te olvides de llamar a RegistrationServices.RegisterAssembly en tu función de registro. Regasm.exe ya no lo hará automáticamente desde que usaste el atributo.

Answer 2

Expondré mi respuesta diciendo que la forma correcta de hacerlo es como dice Hans, a través del calor.

Sin embargo, una alternativa es usar el atributo SelfRegCost del elemento File debajo de un elemento Component.

A continuación se muestra un ejemplo de uno de nuestros kits de instalación anteriores que hasta ahora ha estado funcionando sin problemas.

<File Source="../../External References/MSCAL.OCX" SelfRegCost="1"/>

Al igual que con cualquier respuesta SO, es mejor verificar que esto funcione en su situación y realizar una prueba exhaustiva.