Tengo una solución de aplicación web existente en Visual Studio 2010. Parte de esta solución es un proyecto de WiX responsable de generar un instalador .msi.Mantenimiento automático del instalador de WiX actualizado con archivos recién creados
estaba leyendo el tutorial WiX en un intento de aprender a automáticamente cosecha de archivos cuando me encontré con lo siguiente:
Una herramienta de WiX, calor sirve para recoger datos de diversas fuentes (carpetas, archivos, DLL, controles ActiveX, contadores de rendimiento, sitios web) donde el número de entradas puede ser demasiado grande para crear manualmente el archivo de origen de WiX correspondiente. Su intención principal es ejecutarse una vez, recopilar los datos que se utilizarán más adelante en el mantenimiento habitual de los archivos fuente, no ser parte de un entorno de compilación donde se ejecuta en un conjunto cambiante de datos de entrada una y otra vez. Si todavía desea utilizarlo de esta segunda manera, debe tener mucho cuidado para asegurarse de que los cambios en la entrada no introducen efectos no deseados (sobre todo al romper las reglas de los componentes). El calor tiene características que lo ayudan a lograr este objetivo, pero tenga cuidado al usarlas.
Parece que me gustaría no utilizar su función principal, pero el tutorial solo me molesta con sugerencias sobre cómo hacer lo que me gustaría lograr.
¿Realmente es una mala idea tratar de mantener automáticamente los archivos instalados por una instalación de WiX? Estoy cansado de compilaciones rotas donde alguien ha comprado un nuevo archivo, pero olvidé actualizar los instaladores de WiX con una referencia a ese nuevo archivo.
¿Cómo se manejan los demás en esta situación?
Gracias.
Re: burlas: el tutorial indica que "Heat tiene características que te ayudan a lograr este objetivo", pero no puedo encontrar las funciones a las que se hace referencia. Después de cosechar un proyecto, ¿qué sigue? ¿El calor se vuelve responsable de crear el archivo .wxs que eventualmente usaré, o se supone que debo consumir esta lista de archivos y crear un archivo .wxs con más funciones después del hecho?
El archivo .wxs que usamos actualmente tiene mucho más que solo referencias a archivos. Sin embargo, el calor genera un archivo .wxs. ¿Se supone que debo consumir un archivo .wxs y generar otro archivo wxs usándolo? La estructura de instalación no imita la estructura de los archivos en el proyecto: definimos la propiedad 'fuente' para cada archivo. Entiendo que puedo personalizar un poco el destino de los archivos pasando los parámetros de la línea de cmd al calor, pero esto no parece suficiente. Tengo un proyecto para cosechar calor, pero el.El archivo de wxs que me queda no es tan completo como nuestros .wxs actuales. –
ver http://stackoverflow.com/a/8598296/351614. La salida generada por el calor solo será para los archivos que requiera, aún necesita otros archivos wxs para los diversos metadatos sobre su instalador. Piense en la salida de calor como una clase a la que sus referencias principales de Proudct.wxs y el contenido del archivo de calor pueden cambiar. En términos de la estructura de directorios, si tiene requisitos específicos, probablemente deba obtener su msbuild/cmd-fu y crear una secuencia de comandos de tal manera que genere la estructura de directorios que desee. –
esto http://www.codeproject.com/KB/install/asp_wix.aspx puede darle una mejor idea de cómo funciona y todo se une –