Replicar el registro COM de Visual Studio con un instalador de WiX

Question

É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 la casilla 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.

Along 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 C# COM. Esto implicó usar la herramienta sebo. Que iba a hacer algo como lo siguiente:

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

que luego sería fijo hacia arriba (al principio esto se realiza de forma manual, pero con el tiempo he grabado los pasos en una pequeña herramienta establecen la final directorio ref id, identificación de componentes, fileID, 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 que no fue así.

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 así.

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.

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

Tallow no dio ninguna ayuda, quejándose de que un .tlb no era un archivo que groked. 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!

Por lo tanto, mis buenos amigos, aficionados y usuarios de Windows, WiX, no cae dos preguntas:

• ¿Es una biblioteca de tipos algo que WiX puede registrar de forma nativa? ¿Si es así, cómo?
• Si no es así, ¿cuál es la forma correcta de registrar un typelib 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: se ve el MSDN library article on typelib registration has the names of the keys needed, pero todavía tengo que averiguar cómo obtener el uuid. (Esto es de this blog post on typelib and COM registration by Larry Osterman.)) Leyendo un poco más, Puede caer en mí para registrar estos bits manualmente, pero espero que no ..

Evalué la salida de regasm /regfile:MyDll.dll MyDll.dll. Parece que estas son las mismas claves que genera wix para el dll. otro modo de regasm, regasm /tlb:<filename> genera y registra la biblioteca de tipos para el montaje, pero,

/regfile[:FileName] Generate a reg file with the specified name instead of registering the types. This option cannot be used with the /u or /tlb options

parece el modificador/regfile es incompatible con el modificador/TLB. Khaaaaaaaan!

actualizarse una vez más: Parece que en realidad no necesidad de incluir el archivo .tlb. According to this post on wix's typelib element, 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.

¡Descubrí más tarde que puedes obtener los atributos correctos usando calor en .tlb directamente! Ver this SO question for more information.

Answer 1

Debe usar Heat (WIX 3.0) ubicado en el directorio bin de la versión que está utilizando. Tener un vistazo a este blog post, usarlo aquí para registrar todos los objetos COM, mediante la creación de un fragmento wix ...

algo así como

heat file MyComExposedLibrary.dll -out MyComExposedLibrary.wxs 

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

Answer 2

Para extraer la información COM, sebo utilizará el regasm.exe tool incluido 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 utilizará 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 obtener su instalador de trabajo tiene tres opciones:

1. agregar las claves del registro que faltan 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 intente generar totalmente automáticamente un archivo wxs en funcionamiento, pero creo que fue nunca un objetivo de diseño de sebo.

2. Use un custom action 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í.

3. Evitar el registro completo mediante haciendo uso de registration-free COM. Esto requerirá la creación de archivos de manifiesto tanto para la aplicación y la biblioteca COM.

Answer 3

Hace poco me encontré con este problema, y ​​la solución más simple que pude encontrar es la siguiente estos pasos en la máquina de desarrollo:

1. Run: Regasm MYDLL.DLL /tlb:MyDLL.tlb
2. Run: archivos de calor MYDLL.DLL salida privado MyDll-1.wxs
3. Run: archivos de calor MyDll.tlb salida privado MyDll-2.wxs

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

Answer 4

Sé que esto es una cuestión mayor, pero otros pueden encontrar útil ...

Después de luchar con esto mismo, he encontrado que se puede capturar la información de la biblioteca mediante el uso de tlbexp.exe luego calentar tanto el DLL y 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 ...