Encontré un ejemplo en el registro de archivos DLL, Registering an Assembly for COM Interop in a MSI file with the Windows Installer XML toolset., y WiX se queja del atributo "AssemblyRegisterComInterop".¿Cómo se registra un archivo DLL COM Win32 en WiX 3?
Lo eliminé y cambié el atributo "Assembly" a win32, y dice que necesito especificar el atributo AssemblyManifest, pero ¿qué debo poner allí?
La forma más fácil (y Rob M va a despotricar acerca de cómo esto es incorrecto ) es sólo para usar SelfRegCost=1 en la etiqueta del archivo de la DLL.
Esto está mal, porque deberíamos controlar explícitamente el registro de la DLL, no permitiéndole simplemente ejecutar código arbitrario a través de DllRegisterServer. La teoría es que una DLL no debería hacer nada más que colocar las entradas apropiadas en el registro cuando se llama a DllRegisterServer. Desafortunadamente, muchos de ellos hacen más que eso, por lo que el registro automático podría ser la única forma de hacer que su instalación funcione.
También es incorrecto, porque eso significa que el sistema de instalación de Windows no sabe nada acerca de esas claves de registro, y lo que debería y no debería estar allí. Eso significa que la reparación no funcionará, y posiblemente la desinstalación no se limpiará correctamente, etc.
De lo contrario, puede generar el código de WiX apropiado apuntando heat.exe a su DLL e integrando su salida en su WiX actual proyecto. Obtendrá una variedad de etiquetas Class, ProgID, TypeLib y Registry. Es posible que deba editar manualmente esa salida para que compile.
Espero que ayude.
No soy solo yo que despotricaré sobre cómo SelfReg es malo. El MSI SDK te da a list of seven reasons why not to use SelfReg.
Ejemplo:
<Component Id="Component" Guid="*">
<File Source="ComServer.dll">
<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>
</File>
</Component>
En última instancia, la respuesta de Troya es todo correcto.
[** Autoregistro considerado nocivo **] (http://stackoverflow.com/questions/6129816/msi-register-dll-self-registration-considered-harmful/6141538#6141538) (perdón por la alusión a Dijkstra) . –
Puede intentar utilizar el programa heat.exe y luego hacer referencia al fragmento en su código wix.
heat.exe file <filename> -out <output wxs file>
Como en:
heat.exe file my.dll -out my.wxs
-1 para ningún ejemplo sobre cómo hacer referencia a un fragmento en wix. –
Así que, básicamente copiar/pegar la salida de heat.exe y cambiar las rutas apropiadas, etc? – Davy8
Me gusta poner el wxs que el calor creado en un fragmento al que hace referencia la wx principal. ¿Cuáles fueron las opciones que pasaste al heat, que no registraron el dll? – CheGueVerra
Por lo general, tengo que mover la clase y las etiquetas de programación en la etiqueta de archivo y, posiblemente, editar algunas de las claves de registro. Específicamente, si la DLL es una DLL .NET, deberá proporcionar identificadores únicos para las claves de registro que hacen referencia a mscoree.dll o las colisiones con las generadas automáticamente. –