.net - Replicar el registro COM de Visual Studio con un instalador de WiX

windows typelib (4)

Érase una vez, un ingeniero ingenuo y joven pensó que sería una buena idea separar parte de la funcionalidad de su aplicación en un componente COM, escrito en C #. Visual Studio tenía todas las herramientas para hacer eso, ¿verdad? .NET fue hecho prácticamente para esto, ¿verdad? ¡DECIR AH! Él dijo, esto será fácil. Tendré una separación de componentes decente, manteniendo la lógica comercial lejos de la interfaz, y con COM, ¡podré usarlo desde cualquier lugar! Comprobó alegremente el register for COM interop casilla de verificación de register for COM interop en las propiedades del proyecto, expuso las clases que quería y siguió su camino.

Oh, las pruebas como una elección hecha. El joven ingeniero ahora, con más experiencia, ahora no le desearía esto a nadie. Sin embargo, la carga había sido puesta sobre sus hombros, y la carga seguía siendo pesada. Él miró para aligerar la carga.

A lo largo vino WiX, una herramienta para generar archivos de Windows Installer desde XML. Esto lo intrigó: podría replicar, simplemente, la mayor parte del código necesario para un archivo de instalación de Windows adecuado simplemente a partir de un puñado de archivos de configuración. Su mirada estaba mirando hacia arriba.

Con WiX 2.0, pudo generar con bastante facilidad los archivos necesarios para registrar un objeto COM de C #. Esto implicó usar la herramienta sebo. Haría algo como lo siguiente:

tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs

que luego se arreglaría (al principio esto se hizo de forma manual, pero al final grabé los pasos en una pequeña herramienta, establecí el ID del directorio final, ID del componente, ID de archivo, GUID y base de código).

Luego, el instalador resultante se instalaría, y habría una feliz celebración, si la aplicación funcionara.

Lo cual no fue

Durante días el joven ingeniero superó las diferencias en su PC de desarrollo y la de la PC de instalación de prueba. "¡Todas las claves de registro son iguales!" Él exclamaría. "Todo para MyComExposedLibrary está registrado, ¡lo juro!"

Excepto, no fue.

Al amanecer del tercer día, después de muchos rocíos de montaña, se dio cuenta de que había un objeto más que Visual Studio estaba registrando que su instalador no era: el archivo MyComExposedLibrary.tlb.

Al parecer, Visual Studio había estado registrando este archivo todo el tiempo, creando subclaves adicionales en la HKLM/Software/Classes/Interface registro HKLM/Software/Classes/Interface y registrando typelib en HKLM/SOFTWARE/Classes/TypeLib .

Tallow no brindó ayuda, quejándose de que un .tlb no era un archivo que reventaba. Tampoco la versión beta de WiX 3.0: esto parecía tener aún más problemas para que las cosas funcionen.

También le di una oportunidad a Heat. Esto genera elementos de registro y elementos de clase. Limpié la salida de calor, y luego fui a compilarlo, pero obtuve un error diferente: error LGHT0130 : The primary key <uuid here> is duplicated in table ''Registry'' . El problema es que, por lo que puedo decir, ese uuid realmente no existe en ninguno de mis archivos fuente wxs. Si cambio alrededor de la orden de ref componente en mi elemento de función, un componente dll diferente da ese error. Como no he podido obtener una versión de WiX 3.0 del proyecto para compilar, no he podido confirmar si el calor proporciona el resultado correcto o no.

Eliminé todo del instalador excepto uno de los ensamblados que hacen que aparezca este error e intenté compilar de nuevo. Tengo el mismo error. Arrugh!

Entonces, mis buenos compañeros, entusiastas de Windows y usuarios de WiX, hay dos preguntas:

¿Es algo de tipo algo que WiX puede registrar de forma nativa? ¿Si es así, cómo?
Si no, ¿cuál es la forma correcta de registrar una biblioteca de tipos con un instalador de Windows?

Además, supongo que como otra parte de esto, ¿cómo determina Visual Studio cómo registrar el typelib? (Editar: mira el artículo de la biblioteca de MSDN sobre el registro de typelib tiene los nombres de las claves necesarias , pero aún necesito averiguar cómo obtener el uuid. (Esto es de esta publicación de blog en typelib y registro COM de Larry Osterman .)) Leyendo un poco más, me corresponde a mí registrar estos bits manualmente, pero espero que no ...

regasm /regfile:MyDll.dll MyDll.dll la salida de regasm /regfile:MyDll.dll MyDll.dll . Parece que estas son las mismas claves que genera wix para el dll. El otro modo de Regasm, regasm /tlb:<filename> genera y registra el typelib para el ensamblado, pero,

/ regfile [: FileName] Genera un archivo reg con el nombre especificado en lugar de registrar los tipos. Esta opción no se puede usar con las opciones / u o / tlb

parece que el modificador / regfile es incompatible con el modificador / tlb. Khaaaaaaaan!

Actualización adicional: parece que en realidad no necesita incluir el archivo .tlb. De acuerdo con este post en el elemento typelib de wix , un MSI puede crear / registrar esto como parte del proceso de configuración. Todo se reduce a configurar el documento de WiX para que realmente lo instale obteniendo los atributos correctos.

Más tarde descubrí que puedes obtener los atributos correctos usando calor en .tlb directamente. Vea esta pregunta SO para más información .

Para extraer la información COM, sebo utilizará la herramienta regasm.exe incluida con .NET framework. Es probable que Visual Studio use la misma herramienta para registrar ensamblajes cuando habilite "registrar para interoperabilidad COM".

La diferencia es que sebo usará el conmutador regasm / regfile para enviar la información a un archivo .reg en lugar de registrar el ensamblado. Lamentablemente, el archivo .reg generado por regasm.exe no está completo. Se saltea las entradas typelib que escribe en el registro durante un registro real. Esto puede ser un error en Regasm.

Para que funcione su instalador, tiene tres opciones:

Agregue las claves de registro faltantes a la salida de sebo manualmente. La salida de sebo está destinada a ser editada manualmente y guardada junto con sus otros archivos wxs de todos modos. Parece que estás intentando generar automáticamente un archivo wxs en funcionamiento, pero creo que nunca fue un objetivo de diseño del sebo.
Use una acción personalizada para invocar regasm desde su instalador. Esto es un poco malo porque puede perder algunas de las fuertes garantías transaccionales proporcionadas por el motor de instalación de Windows. Estoy pensando en retrocesos provocados por una falla a mitad de camino durante la instalación aquí.
Evite el registro por completo mediante el uso de COM sin registro. Esto requerirá la creación de archivos manifiestos tanto para la aplicación como para la biblioteca COM.

Recientemente me encontré con este problema, y la solución más simple que pude encontrar sigue estos pasos en la máquina de desarrollo:

Ejecutar: Regasm MyDLL.dll /tlb:MyDLL.tlb
Ejecutar: archivo de calor MyDLL.dll -out MyDll-1.wxs
Ejecutar: archivo de calor MyDll.tlb -out MyDll-2.wxs

MyDll-2.wxs contiene un elemento <Typelib> que deseará copiar y anidar dentro del elemento <File> que se generó en MyDll-1.wxs. Esto le dará un elemento <Component> completo que puede usar en el proyecto del instalador.

Sé que esta es una pregunta anterior, pero a otros les puede resultar útil ...

Después de luchar con esto por mí mismo, descubrí que puede capturar la información de la biblioteca de tipos utilizando tlbexp.exe y luego calentar tanto el archivo dll como el archivo tlb. Incluya los resultados de ambos en su proyecto wix y debería estar listo para comenzar.

tlbexp.exe dllFile.dll /out:dllFile.tlb heat.exe dllFile.dll ... heat.exe dllFile.tlb ...

Debería utilizar Heat (WIX 3.0) ubicado en el directorio bin de la versión que está utilizando. Eche un vistazo a esta entrada de blog , la usamos aquí para registrar todos nuestros objetos COM, al crear un fragmento wix ...

algo como

heat file MyComExposedLibrary.dll -out MyComExposedLibrary.wxs

Después de leer tu edición, crearía un msi básico con wix que instala solo el objeto com, mira si funciona ... entonces sabrás qué campo de batalla atacar ...