Registrar un CPL dll en COM después de la instalación usando el instalador Wix Msi

Estoy tratando de registrar una biblioteca de CPP en COM durante la instalación de Msi.

He buscado mucho y he encontrado muchas soluciones aquí, pero nada está funcionando en mi código. No sé si hay algún método directo para esto. Intenté usar Custom Action con ExeCommand directo y con un script por lotes.

Aquí está el código con script por lotes.

    

Al usar este código, la instalación no muestra ningún error, pero la DLL no se está registrando. Después de la instalación, si ejecuté el script por lotes por separado, se registra.

Register.bat

cd “C: \ Windows \ System32”

regsvr32 “C: \ Archivos de progtwig (x86) \ ABC \ Abc.dll

ping -n 15 127.0.0.1> nul:

Unregister.bat

cd “C: \ Windows \ System32”

regsvr32 / u “C: \ Archivos de progtwig (x86) \ ABC \ Abc.dll”

ping -n 15 127.0.0.1> nul:

Con Custom Action con ExeCommand, muestra un error como la falta de alguna dependencia de DLL. El código ExeCommand se proporciona a continuación.

   

Y InstallSequence para ambos casos se detalla a continuación.

   NOT Installed Installed AND NOT UPGRADINGPRODUCTCODE  

En ambos casos, creo que se está ejecutando con privilegios elevados.

Este es el error que obtengo la mayor parte del tiempo. enter image description here

Editar

La vista del caminador de dependencias del dll se muestra a continuación.

enter image description here

También estoy agregando el comando de calor que utilicé. He agregado esto para preconstruir el evento para generar el componente. Después de eso, se agregó este componente en el archivo del producto.

llame al archivo “$ (WIX) bin \ heat.exe” “dllPath \ Abc.dll” -dr “INSTALLDIR” -srd -gg -sfrag -suid -out “$ (SolutionDir) Installer \ ComRegisterComponent.wxs”

Y el archivo generado se ve así.

         

Aquí esta ruta de SourceDir me confunde. He añadido la ruta exacta en el comando de calentamiento incluso cuando genera este SourceDir.

Breve, respuesta resumida

Debe dejar de usar archivos por lotes y acciones personalizadas para el registro COM (no confiable) y extraer la información de registro COM utilizando la herramienta heat.exe del kit de herramientas WiX para agregar el registro COM a su base de datos MSI en tiempo de comstackción.

Hay algunas complicaciones para los binarios de 64 bits, ver detalles a continuación. Afortunadamente, parece que se trata de un componente de 32 bits basado en el directorio de instalación que se muestra arriba.

En este caso particular, ayudó a ejecutar heat.exe en el archivo COM después de la implementación cuando todas las dependencias estaban “en su lugar” para que el archivo COM se cargara correctamente. Hay una gran cantidad de “comunicación de depuración” en estas respuestas. Dejaré todo listo para el futuro, pero primero pruebe esta sencilla solución. Y quizás pruebe la nueva herramienta de dependencia “Dependencies.exe” que se describe a continuación.


Respuesta larga y detallada

Antes de intentar responder a la pregunta (que parece girar en torno a dependencias faltantes o algo raro que se hace en el archivo por lotes ), quiero aclarar algunas cosas para usted en cuanto a las mejores prácticas para el registro COM.

Nota : la captura de pantalla parece indicar que ocurre algo extraño en el archivo por lotes, pero las dependencias faltantes aún podrían ser un problema.

Autoregistro considerado dañino

El autoregistro no debe usarse para registrar archivos COM . Aquí hay una descripción de por qué este es el caso: MSI register dll – Autoregistro considerado nocivo . Hay buenas noticias, sin embargo, hacer las cosas como se pretende a través de los mecanismos incorporados de MSI será más fácil y más confiable una vez que lo configure correctamente.

Existe una forma de autoarchivar los archivos durante la instalación sin utilizar acciones personalizadas como lo que intenta hacer ( la tabla de SelfReg ). Es muy difícil que las acciones personalizadas funcionen correctamente, pero tampoco debe usar el mecanismo integrado para ejecutar el autoregistro (como se explica en detalle en la respuesta vinculada más arriba)

En lugar de utilizar acciones personalizadas o la tabla SelfReg, la información de registro COM debe extraerse de sus archivos COM en el tiempo de comstackción , en otras palabras, cuando comstack su archivo MSI desde sus archivos fuente de WiX. Los datos de registro extraídos se deben usar para rellenar la familia de tablas de datos MSI diseñadas para registrar y eliminar el registro del archivo COM de manera confiable durante la instalación y la desinstalación, respectivamente.

WiX: la herramienta de línea de comandos “heat.exe”

Comprender los detalles intrincados de este proceso no es necesario; todo lo que necesita saber es qué herramientas usar. WiX proporciona la herramienta ” heat.exe ” para este propósito. Es esencialmente una herramienta de ” cosechadora ” capaz de generar archivos fuente XML de WiX válidos para varios propósitos, uno de los cuales es la extracción de COM. También admite directorios de desplazamiento en general, generando archivos fuente de WiX que pueden instalar los archivos encontrados durante el recorrido. Esencialmente, es una manera muy rápida de crear un paquete MSI una vez que sepa cómo usarlo.

Dependency Walker

Por lo tanto, hemos establecido que debe tomarse el tiempo para aprender a usar heat.exe para generar la fuente de WiX necesaria para registrar el archivo COM correctamente. sin embargo, hay un problema más : las dependencias faltantes .

Para que un archivo COM se autoregistre, o para que pueda extraer correctamente los datos del registro COM utilizando heat.exe, el archivo COM debe poder cargarse correctamente. Para que esto sea posible, todas las dependencias dll deben estar disponibles en el sistema en cuestión en una ubicación accesible.

Obtenga una copia de Dependency Walker y úselo para escanear su archivo COM para los archivos de los que depende. Aquí hay un ejemplo de un archivo COM que no se carga porque no puede encontrar MMUtilities.dll :

enter image description here

Lo más probable es que encuentre algo similar incorrecto con su dll (o el tipo de archivo que sea, por ejemplo, OCX) cuando se ejecuta desde la ubicación de instalación de la instalación. Los archivos de dependencia requeridos no pueden ser encontrados por regsvr32.exe y el proceso de registro falla.

Hay algunas dependencias informadas que faltan y que no son importantes , supongo que esto tiene que ver con la antigüedad de la herramienta Dependency Walker; hasta ahora no se ha actualizado. Busque un archivo que reconozca como su propio archivo de dependencia o un archivo del sistema central en lugar de nombres muy largos de archivos de los que nunca haya oído hablar. Tenga en cuenta que algunos dlls tienen DLL de idioma de dependencia que son necesarios para la carga. Por ejemplo, MMUtilities.dll necesita MmUtilitiesEnglish.dll u otro dll de idioma presente en la misma carpeta para poder cargar correctamente.

Algunas muestras de dependencias falsas positivas para el archivo anterior: API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL , API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL , API-MS-WIN-CORE-REGISTRY-L1-1-0.DLL , etc. … Había muchos. Creo, pero no estoy seguro, que la causa raíz de estos falsos positivos se centra en los problemas de los componentes uno al lado del otro instalados en la carpeta WinSxS, pero eso es un debate completamente diferente, simplemente mencionarlo.


ACTUALIZACIÓN : Acabo de comprobar esto de nuevo y la mayoría de las dependencias positivas falsas que se muestran arriba son aparentemente conjuntos de API : una característica de Windows introducida mucho después de que se creó Dependency Walker, y por lo tanto no manejada correctamente por la herramienta.

Como indica la respuesta enlazada (léelo, enlace arriba), ahora también hay una reescritura de Dependency Walker en C # llamada ” Dependencias “, disponible aquí: https://github.com/lucasg/Dependencies (no probado por mí en el momento de la escritura, pondrá a prueba en breve).


También menciones rápidas: si tiene un ejecutable para verificar (a diferencia de un dll, ocx, etc.), puede iniciarlo a través de la entrada de menú Profile => Start Profiling... y luego también verá ” oculto “. dependencias de tiempo de ejecución “no especificadas en la tabla de importación binaria (donde se especifican dependencias / importaciones). Necesitas ejercitar realmente la aplicación usando todas las características en todos los diálogos para asegurarte de obtener todas esas dependencias.

La página web de walker de dependencias llama a estas dependencias ocultas dependencias explícitas (una dependencia dinámica o de tiempo de ejecución) y dependencias de enlace de sistema (dependencias inyectadas). Vea el enlace justo arriba para más detalles.

Extracción de Heat.exe

Una vez que haya determinado qué archivos faltan para hacer funcionar su extracción de WiX heat.exe, puede poner los archivos en cuestión “al lado” de su dll COM para que se encuentren durante su carga. Puede probar ejecutar usando regsvr32.exe para ver si el registro se completa correctamente. No debe haber mensajes de error cuando ejecuta el registro manualmente así. Recuerde ejecutar el registro desde un símbolo del sistema elevado .

Varias otras respuestas stackoverflow explican cómo usar heat.exe – No lo he usado en mucho tiempo: cómo ejecutar heat.exe y registrar un dll en wix . Aquí está la documentación oficial de heat.exe de los chicos de WiX. Puede ser una herramienta algo intimidante, tiene muchas funciones.

En su forma más simple (para archivos COM normales de 32 bits con todas las dependencias disponibles en la ruta o carpeta local), puede ejecutar esta línea de comando heat.exe para generar un archivo fuente de salida de WiX llamado YourFileName.wxs con todo el registro COM requerido datos.

 heat.exe file YourFileName.ocx -o YourFileName.wxs 

Hace varios años, escribí una respuesta que muestra cómo incorporar los datos de registro de WiX exportados a su fuente principal de WiX: cómo hacer referencia a una salida de calor (wx) en Wix (línea de comando) . Creo que esta es una descripción precisa del procedimiento, pero por alguna razón alguien votó negativamente la respuesta. Por favor pruébalo y mira si funciona para ti.

¡Importante! : heat.exe todavía no procesa correctamente los binarios COM de 64 bits (diciembre de 2017).

Me informaron que el paquete de expansión WiX ( no gratuito ) maneja binarios de 64 bits y brinda muchas otras funciones. Supongo que puedo vincularme (no estoy afiliado a FireGiant): https://www.firegiant.com/wix/wep-documentation/harvesting/ . De alguna manera la gente necesita saber sobre estas cosas, pero no estoy seguro acerca de la etiqueta de stackoverflow de vinculación.

¿Son tus binarios de 64 bits? (No se ve así desde su carpeta de instalación, pero lo agrego para otros que puedan encontrarlo). Para un componente de 64 bits, supongo que hemos cerrado el círculo y tenemos que aconsejarle que utilice la función de paquete de expansión anterior o simplemente intente configurar el archivo para que se autoregistre como se describe aquí . Odio esta “solución” de auto registro, pero no puedo pensar en ninguna otra solución rápida en este momento (ninguna que recomendaría de todos modos). Revisaré nuevamente. Asegúrese de consultar la última versión de WiX para ver si el problema de 64 bits se ha solucionado antes de ir a este “arreglo de autorregistro” . Al menos es mejor que tratar de registrar usando acciones personalizadas y archivos por lotes (que nunca deberían intentarse). Hay tantos problemas potenciales relacionados con la compleja secuencia de acción personalizada de MSI, suplantación / elevación, acondicionamiento, modos de instalación silenciosos e interactivos, no mencionar la posible interferencia del software de seguridad, y la lista continúa).


Algunos enlaces:

  • ¿Cómo se registra un archivo DLL COM de Win32 en WiX 3?
  • No se puede registrar DLL usando WiX
  • Use wix para realizar la función de REGSVR32
  • Heat.exe no puede aprovechar la información de TypeLib de una DLL COM de 64 bits
  • Heat.exe: .dll de 64 bits no se puede convertir a .msi de 64 bits

Simplemente agregue otra respuesta con información sobre cómo usar procmon.exe de una manera eficiente para depurar dependencias faltantes durante el autoregistro usando regsvr32.exe .

Esencialmente, debe establecer un filtro de inclusión para los eventos que desea monitorear y registrar, de lo contrario obtendrá una lista todopoderosa de eventos relevantes y es difícil encontrar lo que necesita en el mar de información inútil:

Aplicar incluir filtro en procmon.exe

  1. Para limitar la información del proceso capturado a lo que necesita, simplemente vaya a Filter => Filter...
  2. Establezca el menú desplegable de la izquierda en Process Name y luego la segunda columna en y, finalmente, escriba regsvr32.exe en el cuadro de la derecha como se ilustra arriba en la imagen.
  3. Crucially estableció el cuadro de la derecha para Include . Luego presione OK.
  4. Ahora deben suprimirse todos los eventos innecesarios y solo se muestran los eventos regsvr32.exe (cuando se ejecuta).
  5. Ejecute regsvr32.exe la manera normal y busque las entradas ” NAME NOT FOUND ” (o similar) en la lista.
  6. En la ilustración a continuación, MMUtilities.dll no se puede encontrar. En otras palabras, es una dependencia faltante.

MMUtilities.dll no se puede encontrar


La otra forma de depurar dependencias faltantes durante el autoregistro es usar Dependency Walker como se ilustra en mi otra respuesta en este “hilo” o pregunta o lo que sea para llamarlo. En general, encuentro que Dependency Walker es la opción más rápida, pero ProcMon es quizás mejor en general, a menos que esté depurando un archivo EXE, entonces Dependency Walker tiene la característica de Profile superior ( Profile => Start Profiling... ).

La idea es no usar un archivo bat para registrar el dll. Deje que Windows installer / WiX lo haga por usted. Esto ha sido respondido en el pasado también aquí .