Procedimientos recomendados del instalador de Windows

En esta sección se enumera una lista de recomendaciones, vinculadas a la documentación principal del SDK de Windows Installer, para ayudar a los desarrolladores de aplicaciones, autores de instalación, profesionales de TI y desarrolladores de infraestructura a descubrir los procedimientos recomendados para utilizar Windows Installer:

Actualice la versión de Windows Installer.

  • Utilice Windows Installer 5.0 en Windows Server 2008 R2 y Windows 7. Esta es la versión de Windows Installer proporcionada con el sistema operativo.
  • Utilice Windows Installer 4.5 en Windows Server 2008, Windows Server 2003 con Service Pack 1 (SP1), Windows Vista con Service Pack 1 (SP1) o Windows XP con Service Pack 2 (SP2). Para obtener información sobre cómo obtener la versión más reciente de Windows Installer, consulte Redistribuibles de Windows Installer.
  • Utilice Windows Installer 3.1 en Windows 2000 con Service Pack 3 (SP3). La versión 3.1 de Windows Installer tiene características que facilitan un mejor mantenimiento de aplicaciones y la aplicación de revisiones.
  • Muchas características importantes se introdujeron con la versión 3.0 y se enumeran en la sección No compatible con la versión 2.0 de Windows Installer. Los paquetes de instalación y las actualizaciones que se crearon para Windows Installer 2.0 se pueden instalar con Windows Installer 3.0 y versiones posteriores. Los paquetes de revisión que contienen las nuevas tablas utilizadas por Windows Installer 3.0 todavía se pueden aplicar con versiones anteriores de Windows Installer, pero sin la funcionalidad de aplicación de revisiones de Windows Installer 3.0. También es posible crear revisiones que requieran explícitamente Windows Installer 3.0 que no se pueda aplicar en versiones anteriores de Windows Installer. Si un usuario no puede actualizar la versión del instalador, asegúrese de que la aplicación o la actualización sean compatibles con una actualización futura de Windows Installer.
  • Para obtener una lista de las características de Windows Installer que no son compatibles con versiones anteriores de Windows Installer, consulte Novedades de Windows Installer.

Cumpla los requisitos de certificación del logotipo de Windows.

  • Incluso si no tiene intención de enviar la aplicación al programa de logotipos, seguir las directrices de certificación del logotipo puede ayudar a mejorar el paquete de Windows Installer. Para obtener información general sobre los requisitos de logotipo y vínculos a programas específicos de certificación de logotipos, consulte Windows Installer y requisitos de logotipo.

Prepare el paquete para la localización.

  • Se recomienda prepararse para la futura localización al crear el paquete de instalación original. Puede seguir el procedimiento de localización de paquetes sugerido en Localizar un paquete de Windows Installer.

Actualice las herramientas de desarrollo y la documentación de Windows Installer.

  • Las herramientas de desarrollo de Windows Installer no son redistribuibles y solo debería utilizar las versiones de estas herramientas disponibles en Microsoft. Están disponibles en los componentes de Windows SDK para desarrolladores de Windows Installer en el Kit de desarrollo de software de Microsoft Windows (SDK).
  • Varios proveedores de software independientes ofrecen herramientas para crear o modificar paquetes de Windows Installer. Estas herramientas pueden proporcionar un entorno de creación de paquetes que puede ser más fácil de usar que las herramientas proporcionadas en el SDK de Windows Installer. Puede obtener más información sobre estas herramientas de los recursos de información descritos en Otros orígenes de información de Windows Installer.
  • La capacidad de crear un paquete a partir de archivos de texto puede ser más intuitiva para algunos desarrolladores. El conjunto de herramientas de Windows Installer XML (WiX) disponible en Sourceforge.net compila paquetes de instalación de Windows desde el código fuente XML.
  • La documentación del SDK de Windows Installer es la que se revisa con más frecuencia.
  • Utilice la versión reciente de Msizap.exe (versión 3.1.4000.2726 o posterior) que está disponible en los componentes de Windows SDK para desarrolladores de Windows Installer para Windows Vista o superior. Las versiones menores de Msizap.exe pueden eliminar información sobre todas las actualizaciones que se han aplicado a otras aplicaciones en el equipo del usuario. Si se elimina esta información, es posible que estas otras aplicaciones deban eliminarse y volver a instalarse para recibir actualizaciones adicionales.
  • El editor de tablas de base de datos Orca.exe es un editor de tablas de base de datos para crear y editar paquetes de Windows Installer y módulos de combinación. Tiene una interfaz GUI básica, pero admite la edición avanzada de bases de datos de Windows Installer. Incluso si utiliza otra aplicación como herramienta de desarrollo principal, puede que el uso de Orca.exe sea conveniente al solucionar problemas y probar un paquete.
  • Consulte Otras fuentes de información de Windows Installer para obtener información actual de Windows Installer disponible en blogs, chats técnicos, grupos de noticias, artículos técnicos y sitios web.

Si decide reempaquetar una aplicación de configuración heredada, siga los procedimientos recomendados de reempaquetado.

Muchos proveedores de aplicaciones proporcionan paquetes nativos de Windows Installer para la instalación o sus productos. El software que convierte una aplicación de instalación heredada existente en un paquete de Windows Installer se conoce como una herramienta de reempaquetado. Reempaquetar una aplicación de configuración existente no es el procedimiento de desarrollo recomendado. Las aplicaciones que se han diseñado desde el principio para aprovechar las características de Windows Installer pueden ser más fáciles de instalar y mantener. Si decide utilizar un software de reempaquetado, los siguientes procedimientos pueden ayudarle a generar un paquete de Windows Installer mejor.

  • Reempaquetar herramientas convierte las instalaciones heredadas en un paquete de Windows Installer tomando una foto de un sistema provisional antes y después de la instalación. Los cambios del registro, los cambios de archivo o la configuración del sistema que se produce durante el proceso de captura se incluyen en la instalación. Configure el hardware y el software del equipo que se utiliza para reempaquetar la instalación lo más cerca posible del sistema del usuario deseado. Cree un paquete independiente para cada configuración de hardware diferente. Vuelva a crear el paquete con un equipo provisional limpio. Elimine las aplicaciones innecesarias. Detenga todos los procesos innecesarios. Cierre todos los servicios del sistema no esenciales.
  • Realice siempre una copia de la instalación original antes de empezar a trabajar en ella. Trabaje siempre en la copia. Nunca detenga un reempaquetado antes de que termine de compilar el paquete. Si la persona que realiza el reempaquetado daña el paquete, seguirá teniendo el original.
  • No reempaquete las actualizaciones de software de Microsoft en un paquete de Windows Installer. Microsoft publica actualizaciones de software, por ejemplo, Service Packs, como archivos autoextraíbles que ejecutan automáticamente la instalación. Estas actualizaciones utilizan instaladores diferentes a los de Windows Installer para reemplazar los recursos protegidos de Windows y no se pueden convertir en un paquete de Windows Installer. Para obtener información sobre cómo implementar Service Packs de Windows, consulte la guía de implementación del Service Pack en Microsoft TechNet.
  • No utilice una herramienta de reempaquetado para convertir un paquete de Windows Installer en un paquete nuevo. Windows Installer agrega información de configuración al sistema, así como a los recursos de la aplicación. Cuando una herramienta de reempaquetado compara el sistema antes y después de la instalación, el encargado de reempaquetar malinterpreta la información de configuración como parte de la aplicación. Esto suele dañar la aplicación reempaquetada. En su lugar, utilice transformaciones de personalización para modificar un paquete de Windows Installer existente o crear un nuevo paquete. Puede crear transformaciones de personalización mediante la herramienta Msitran.exe.
  • No utilice una herramienta de reempaquetado para consolidar varios paquetes de Windows Installer en un único paquete. En su lugar, puede utilizar la herramienta Msistuff.exe para configurar el ejecutable de arranque de Setup.exe a fin de instalar los paquetes uno después de otro.
  • Convierta el paquete de Windows Installer para que el cliente pueda personalizarlo fácilmente. Las variables globales que utiliza Windows Installer durante una instalación se pueden establecer mediante propiedades públicas o transformaciones de personalización. Proporcione documentación para el uso de esas propiedades y valores predeterminados prácticos para todos los valores personalizables. Para obtener información sobre la obtención y configuración de propiedades, consulte Uso de propiedades. Para obtener un ejemplo de una transformación de personalización, consulte Ejemplo de transformación de personalización.

No intente reemplazar los recursos protegidos.

Los paquetes de Windows Installer no deberían intentar reemplazar los recursos protegidos durante la instalación o actualización. Windows Installer no elimina ni reemplaza estos recursos porque Windows impide la sustitución de archivos de sistema esenciales, carpetas y claves del Registro. La protección de estos recursos evita errores de aplicación y sistema operativo.

  • Cuando se ejecuta en Windows Server 2008 o Windows Vista, Windows Installer omite la instalación de cualquier archivo o clave del Registro que esté protegida por la Protección de recursos de Windows (WRP), el instalador escribe una advertencia en el archivo de registro y continúa con el resto de la instalación sin un error. Para obtener información, consulte Uso de Windows Installer y Protección de recursos de Windows.
  • WRP es el nuevo nombre de Protección de archivos de Windows (WFP). WRP protege las claves del Registro y las carpetas, así como los archivos de sistema esenciales. En Windows Server 2003, Windows XP y Windows 2000, cuando Windows Installer encuentra un archivo protegido por WFP, el instalador solicita a WFP que instale el archivo. Para obtener información, consulte Uso de Windows Installer y Protección de recursos de Windows.

No dependa de recursos no críticos.

La instalación o actualización no debe depender de la instalación de recursos no críticos por los siguientes motivos.

  • Las acciones personalizadas pueden producir un error si dependen de un componente que pertenezca a una característica que el usuario anuncia en lugar de instalar.
  • Las acciones personalizadas secuenciadas antes de la acción InstallFinalize pueden fallar si dependen de un componente que contenga un ensamblado en proceso de instalación. Windows Installer no confirma ensamblados en la caché global de ensamblados (GAC) hasta que se complete la acción InstallFinalize.

Use la API para recuperar la información de configuración de Windows Installer.

La instalación de la aplicación o actualización no debería depender del acceso directo a la información de configuración de Windows Installer guardada en el equipo. En su lugar, utilice la interfaz de programación de aplicaciones de Windows Installer para recuperar información de configuración. El servicio Windows Installer administra la ubicación y el formato de la información de configuración y puede cambiar.

Organice la instalación de la aplicación en torno a los componentes.

El servicio Windows Installer instala o elimina colecciones de recursos a los que se hace referencia como componentes. Dado que los componentes se comparten normalmente, el autor de un paquete de instalación debe seguir las reglas al especificar los componentes de una característica o aplicación.

  • Siga las reglas de componente al organizar aplicaciones en componentes para asegurarse de que se pueden instalar y eliminar nuevos componentes o versiones de componentes sin dañar otras aplicaciones. Puede seguir el procedimiento descrito en Definición de componentes del instalador.
  • El instalador realiza un seguimiento de todos los componentes por el GUID del id. de componente correspondiente especificado en la tabla Componente. Es esencial para el funcionamiento del mecanismo de recuento de referencias de Windows Installer que el GUID del id. del componente sea correcto. Siga las instrucciones de Cambio del código de componente.
  • Si el paquete debe interrumpir las reglas de componente, tenga en cuenta las posibles consecuencias y asegúrese de que la instalación nunca instala estos componentes en los que puedan dañar los componentes en el sistema del usuario. Para obtener información, consulte ¿Qué ocurre si no se cumplen las reglas de componente?.
  • Tenga en cuenta cómo Windows Installer aplica las reglas de control de versiones de archivos al reemplazar los archivos existentes. Windows Installer determina primero si el archivo de clave del componente ya está instalado antes de intentar instalar cualquiera de los archivos del componente. Si el instalador encuentra un archivo con el mismo nombre que el archivo de clave del componente instalado en la ubicación de destino, compara la versión, la fecha y el idioma de los dos archivos de clave y utiliza reglas de control de versiones de archivos para determinar si se debe instalar el componente proporcionado por el paquete. Si el instalador determina que necesita reemplazar la base del componente en el archivo de clave, utiliza las reglas de control de versiones de archivo en cada archivo instalado para determinar si se debe reemplazar el archivo.

Reduzca el tamaño de los paquetes de Windows Installer grandes.

Los paquetes de Windows muy grandes toman recursos del sistema y pueden ser difíciles de instalar para los usuarios. Se recomienda reducir el tamaño de los paquetes de Windows Installer muy grandes mediante los siguientes métodos.

  • Comprima los archivos de la instalación y almacénelos en un archivo .cab. El instalador permite almacenar el archivo .cab como un archivo externo independiente o como un flujo de datos en el propio paquete MSI. Para obtener información, consulte Uso de gabinetes y orígenes comprimidos.
  • Elimine el espacio de almacenamiento desperdiciado en el archivo .msi mediante una de las opciones que se describen en Reducir el tamaño de un archivo .msi.
  • Si el paquete de Windows Installer contiene más de 32 767 archivos, debe cambiar el esquema de la base de datos. Para obtener información, consulte Creación de un paquete grande.

Si utiliza acciones personalizadas, siga los procedimientos recomendados de acciones personalizadas.

Windows Installer tiene muchas acciones estándar integradas para la instalación y el mantenimiento de aplicaciones. Los desarrolladores deben intentar confiar tanto en las acciones estándar como en las prácticas, en lugar de crear sus propias acciones personalizadas. Sin embargo, hay situaciones en las que el desarrollador de un paquete de instalación encuentra que es necesario escribir una acción personalizada.

Si utiliza ensamblados, siga los procedimientos recomendados para ensamblados.

Si el paquete utiliza ensamblados de software, siga las instrucciones para agregar ensamblados a un paquete, actualizar ensamblados e instalar y eliminar ensamblados.

No envíe instalaciones simultáneas.

Las instalaciones simultáneas, también denominadas Instalaciones anidadas, instalan otro paquete de Windows Installer durante una instalación que se está ejecutando actualmente. El uso de instalaciones simultáneas no es un procedimiento recomendado porque son difíciles de mantener por parte de los clientes. Es posible que la aplicación de revisiones y la actualización no funcionen con instalaciones simultáneas. La alternativa recomendada al uso de instalaciones simultáneas es utilizar en su lugar una aplicación de configuración y un controlador de interfaz de usuario externo para instalar varios paquetes de Windows Installer secuencialmente.

Para obtener más información sobre el uso de un controlador de interfaz de usuario externo, consulte Supervisión de una instalación mediante MsiSetExternalUI. Para obtener más información sobre el uso de un controlador externo basado en registros, consulte Supervisión de una instalación mediante MsiSetExternalUIRecord.

A veces, las instalaciones simultáneas se utilizan en entornos corporativos controlados para instalar aplicaciones que no están pensadas para el público. Siga estas instrucciones si decide utilizar instalaciones simultáneas.

  • No utilice instalaciones simultáneas para instalar o actualizar un producto de envío.
  • Las instalaciones simultáneas no deberían compartir componentes.
  • Una instalación administrativa no debería contener una instalación simultánea.
  • Las barras de progreso integradas no deben utilizarse con instalaciones simultáneas.
  • Los recursos que se van a anunciar no deberían instalarse mediante una instalación simultánea.
  • Un paquete que realiza una instalación simultánea de una aplicación también debería desinstalar la aplicación simultánea cuando se desinstala el producto primario. Existe una instalación anidada en el contexto del producto primario en la opción de agregar o eliminar programas en el Panel de control.

Mantenga coherencia con los nombres de paquete y los códigos de paquete.

Se le puede asignar cualquier nombre al archivo .msi que ayude a los usuarios a identificar el paquete, pero el nombre no debe cambiarse sin cambiar también el código del producto.

  • Asigne a su archivo .msi un nombre descriptivo que permita al usuario identificar el contenido del paquete de Windows Installer.
  • El código del producto es la identificación principal de una aplicación y debe cambiar siempre que haya una actualización completa de la aplicación. Para obtener información, consulte ProductCode y Cambio del código de producto. El cambio del nombre del archivo .msi de la aplicación se considera un cambio completo y siempre requiere un cambio correspondiente del código del producto para mantener la coherencia.
  • El código del paquete es el identificador principal que utiliza el instalador a fin de buscar y validar el paquete correcto para una instalación determinada. Bajo ningún concepto deben tener dos archivos .msi no idénticos debe el mismo código de paquete. Si se cambia un paquete sin cambiar el código del paquete, es posible que el instalador no utilice el paquete más reciente si ambos siguen siendo accesibles para el instalador. El código del paquete se almacena en la propiedad Revision Number Summary (Resumen de número de revisión) del flujo de información de resumen.
  • Tenga en cuenta que las letras del código de producto y los GUID de código de paquete deben estar en mayúsculas.

No utilice las tablas SelfReg y TypeLib.

  • Se desaconseja encarecidamente que los autores de paquetes de instalación utilicen el registro propio y la tabla SelfReg. En su lugar, deberían registrar módulos mediante la creación de una o varias de las tablas en el grupo de tablas del Registro. Muchas de las ventajas de Windows Installer se pierden con el registro automático porque las rutinas de registro automático tienden a ocultar información de configuración crítica. Para obtener una lista de las razones para evitar el registro propio, consulte la tabla SelfReg.
  • Se desaconseja encarecidamente que los autores de paquetes de instalación utilicen la tabla TypeLib. En lugar de usar la tabla TypeLib, registre bibliotecas de tipos mediante la tabla Registro. Si se produce un error en una instalación al utilizar la tabla TypeLib y debe revertirse, es posible que la reversión no restaure el equipo al mismo estado que existía antes de la reversión.

Proporcione la opción de instalar sin una interfaz de usuario.

Los administradores suelen preferir implementar aplicaciones dentro de una corporación sin necesidad de interacción del usuario. Es recomendable permitir que la aplicación proporcione la opción de instalarse con el nivel de interfaz de usuario Ninguno.

  • Utilice propiedades públicas para obtener información de configuración. Los administradores pueden proporcionar esta información en la línea de comandos.
  • No requiera que la instalación dependa de la información recopilada de la interacción del usuario con los cuadros de diálogo. Esta información no está disponible durante una instalación silenciosa.
  • No reinicie automáticamente el equipo del usuario durante una instalación silenciosa.
  • Los administradores pueden establecer el nivel de interfaz de usuario al instalar mediante la opción de línea de comandos "/q". El nivel de interfaz de usuario también se puede establecer mediante programación con una llamada a MsiSetInternalUI.

Evite utilizar la directiva AlwaysInstallElevated.

Si no se establece la directiva AlwaysInstallElevated, las aplicaciones no distribuidas por el administrador se instalan mediante los privilegios del usuario y solo las aplicaciones administradas obtienen privilegios elevados. Al establecer esta directiva, Windows Installer usa permisos del sistema cuando instala la aplicación en el sistema. Este método puede hacer que un equipo corra un riesgo de seguridad, ya que cuando se establece esta directiva, un usuario que no es administrador puede ejecutar instalaciones con privilegios elevados y acceder a ubicaciones seguras en el equipo. Se recomienda utilizar un método diferente al de la directiva AlwaysInstallElevated al instalar un paquete con privilegios elevados para un usuario que no sea administrador o para la aplicación de revisiones para aplicaciones administradas por usuario.

Habilite la directiva DisableMedia para limitar la instalación no autorizada.

La directiva DisableMedia puede impedir la instalación no autorizada de aplicaciones. Cuando esta directiva está habilitada, se impide que los usuarios y administradores que ejecutan una instalación de mantenimiento de un producto utilicen el cuadro de diálogo Examinar para examinar soportes multimedia, como un CD-ROM, para buscar el origen de otros productos que se puedan instalar. La búsqueda de otros productos se impide independientemente de si la instalación se realiza con privilegios elevados. Igualmente, es posible que el usuario vuelva a instalar el producto desde el soporte multimedia si cuenta con un soporte etiquetado correctamente.

Proteja los archivos de origen del paquete original y haga que estén disponibles para los usuarios.

En algunos casos, es posible que se necesite el soporte original del paquete de Windows Installer para instalar a petición, reparar o actualizar una aplicación. Si el instalador no puede encontrar un origen disponible, se le pedirá al usuario que proporcione medios o que vaya a una ubicación de red que contenga los orígenes necesarios. Se recomienda asegurarse de que el instalador tenga los orígenes que necesita sin tener que preguntar al usuario.

  • Utilice firmas digitales y archivos .cab externos para asegurarse de que los soportes originales que utiliza el instalador sean seguros. Una imagen de origen sin comprimir almacenada en una ubicación pública no es segura.
  • Incluya una lista completa de rutas de acceso de origen de red o dirección URL al paquete de instalación de la aplicación en la propiedad SOURCELIST.
  • Utilice un recurso compartido del sistema de archivos distribuido (DFS) para la ruta de acceso de origen.
  • Utilica la API de Windows Installer para recuperar y modificar la información de la lista de origen de las aplicaciones y revisiones de Windows Installer. Para obtener información, consulte Administración de orígenes de instalación.
  • Utilice los métodos y propiedades del objeto del instalador, el objeto del producto y el objeto de la revisión a fin de recuperar y modificar la información de lista de orígenes para las aplicaciones y revisiones de Windows Installer.
  • Siga los puntos que se enumeran en Impedir que una revisión requiera acceso al origen de instalación original para minimizar la posibilidad de que la revisión requiera acceso a los soportes originales.
  • Almacene los archivos de origen del paquete en una ubicación que no sea la carpeta temporal del sistema. Los archivos de origen de Windows Installer almacenados en la carpeta temporal pueden dejar de estar disponibles para los usuarios.

Habilite el registro detallado en el equipo del usuario al solucionar problemas de implementación.

El registro de Windows Installer incluye una opción de registro detallada que se puede habilitar en el equipo de un usuario. La información de un registro detallado puede resultar útil al intentar solucionar problemas de implementación de paquetes de Windows Installer.

  • Puede habilitar el registro detallado en el equipo del usuario mediante opciones de línea de comandos, la propiedad MsiLogging, la directiva de registro, MsiEnableLog y el método EnableLog.
  • Un recurso muy útil para interpretar los archivos de registro de Windows Installer es Wilogutl.exe. Esta herramienta ayuda al análisis de archivos de registro y muestra soluciones sugeridas a errores que se encuentran en un archivo de registro.
  • La opción de registro detallado debe utilizarse solamente para solucionar problemas y no debe dejarse porque puede tener efectos adversos en el rendimiento del sistema y el espacio en disco. Cada vez que utilice la herramienta Agregar/Eliminar programas en Panel de control, se crea un nuevo archivo.

La desinstalación deja el equipo del usuario en un estado limpio.

La eliminación de la aplicación es tan importante como la instalación. Cuando se desinstala un paquete de Windows Installer, no debe dejar partes inútiles en el equipo del usuario.

  • Si un archivo que debe haberse eliminado del equipo del usuario permanece instalado después de ejecutar una desinstalación, es posible que el instalador no elimine el componente que contiene el archivo por uno o varios de los motivos descritos en Eliminar archivos inmovilizados.
  • Si se debe registrar una aplicación, cree el paquete para eliminar la información del Registro cuando se desinstale la aplicación. Para obtener información, consulte Agregar o eliminar claves del Registro en la instalación o eliminación de componentes. Si una aplicación no está registrada, la aplicación no aparece en la característica Agregar o Eliminar programas en Panel de control y no se puede administrar mediante Windows Installer.
  • Para ocultar una aplicación de la característica Agregar o Eliminar programas en Panel de control y seguir siendo capaz de utilizar Windows Installer para administrar la aplicación, siga las instrucciones descritas en Agregar y eliminar una aplicación y no dejar rastro en el Registro.
  • Las acciones personalizadas deben estar condicionadas para ejecutarse o no según sea necesario tras la desinstalación. Es posible que sea necesario ejecutar diferentes acciones personalizadas en la instalación y desinstalación.
  • La información de personalización específica del usuario se puede almacenar en un archivo de texto en el equipo. Esto tiene la ventaja de que el archivo se puede eliminar cuando se desinstala la aplicación, incluso si el usuario de esta personalización no ha iniciado sesión actualmente.

Pruebe los paquetes para la implementación de instalación por usuario y por máquina.

Se recomienda permitir que los clientes decidan si implementar un paquete para la instalación en el contexto de instalación por máquina o por usuario.

  • Tenga en cuenta si la aplicación debe estar disponible solo para usuarios concretos o para todos los usuarios del equipo durante el proceso de desarrollo.
  • Pruebe que el paquete funcione correctamente para los contextos de instalación por usuario y por máquina.
  • Haga que el paquete se personalice fácilmente y permita a los clientes decidir si quieren implementarlo por usuario o por máquina.

Planifique y pruebe una estrategia de mantenimiento antes de enviar la aplicación.

Debe decidir cómo quiere mantener la aplicación antes de implementarla por primera vez.

Reduzca la dependencia de las actualizaciones de los soportes originales.

Si los archivos de origen son necesarios para actualizar la aplicación, esto puede dificultar el mantenimiento de la aplicación. Los siguientes métodos pueden ayudar a reducir la dependencia de las actualizaciones de los archivos originales.

No distribuya módulos de combinación que no se pueden usar.

Las aplicaciones no deben depender de los módulos de combinación para la instalación del componente si el propietario del módulo de combinación y el propietario de la aplicación son diferentes. Esto puede dificultar el servicio de la aplicación porque ambos propietarios deben coordinarse para actualizar la aplicación o el módulo. Sin conocer todas las aplicaciones que han utilizado el módulo de combinación, el propietario de la aplicación no puede actualizar el módulo de combinación sin arriesgarse a que la actualización pueda ser incompatible con otra aplicación. El propietario del módulo de combinación no tiene ningún método directo para actualizar paquetes de Windows Installer que ya han instalado el módulo de combinación.

  • Considere la posibilidad de proporcionar los componentes necesarios a los usuarios como otra instalación de Windows Installer.

Evite la aplicación de revisiones a las instalaciones administrativas.

En una red, proporcione una instalación administrativa del paquete original de Windows Installer de la aplicación para permitir que los miembros de un grupo de trabajo instalen la aplicación. Los usuarios de esta imagen administrativa deben aplicar actualizaciones en la instancia local de la aplicación ubicada en su equipo. Esto mantiene a los usuarios sincronizados con la imagen administrativa. No se recomienda aplicar actualizaciones a la instalación administrativa por los siguientes motivos.

  • El tamaño y la latencia de la descarga necesarios para que los usuarios obtengan una actualización se incrementan en comparación con la descarga de una revisión. El paquete completo actualizado de Windows Installer y los archivos de origen deben descargarse, volver a guardarse en la memoria caché y reinstalarse.
  • Los usuarios no podrán instalar aplicaciones a petición ni repararlas desde una instalación administrativa actualizada hasta que se vuelvan a guardar en caché y reinstalar.
  • Al aplicar una revisión a una instalación administrativa, se elimina la firma digital del paquete. Un administrador debe volver a firmar el paquete. Para obtener más información sobre el uso de firmas digitales, consulte Firmas digitales y Windows Installer.
  • Muchas revisiones binarias tienen como destino la imagen RTM de la aplicación y requieren una versión de archivo anterior. Es posible que la instancia local de una aplicación instalada desde una instalación administrativa actualizada no funcione con otras actualizaciones. Muchas aplicaciones de revisión binaria pueden producir un error.
  • La aplicación de una revisión a una instalación administrativa actualiza los archivos de origen y el archivo .msi, pero no marca la imagen de red con información sobre la actualización. Es decir, los usuarios no pueden determinar qué actualizaciones han recibido de la instalación administrativa. Esto hace que sea imposible secuenciar actualizaciones aplicadas en el lado del usuario con las que ya se han aplicado en la imagen administrativa.
  • Las revisiones aplicadas a una instalación administrativa no son revisiones que se puedan desinstalar. Esto puede impedir que el código del paquete almacenado en caché en el equipo del usuario sea diferente del código del paquete en la instalación administrativa. Si el código del paquete almacenado en caché en el equipo del usuario es en algún punto diferente del de la instalación administrativa, vuelva a instalar la aplicación desde la instalación administrativa y, a continuación, aplique la revisión al ordenador cliente.
  • Si decide aplicar pequeñas actualizaciones mediante la aplicación de revisiones a una imagen administrativa, siga las instrucciones descritas en el tema Aplicación de pequeñas actualizaciones mediante la aplicación de revisiones a una imagen administrativa.

Registre las actualizaciones para que se ejecuten con privilegios elevados.

A partir de Windows Installer 3.0, es posible aplicar revisiones a una aplicación que se ha instalado en un contexto administrado por usuario después de que la revisión se haya registrado con privilegios elevados. No se pueden aplicar revisiones a las aplicaciones instaladas en un contexto administrado por usuario mediante versiones de Windows Installer anteriores a la versión 3.0.

Utilice la tabla MsiPatchSequence para secuenciar revisiones.

Incluya una tabla MsiPatchSequence en el paquete y agregue información de secuenciación de revisiones. A partir de la versión 3.0 de Windows Installer, el instalador puede usar la tabla MsiPatchSequence al instalar varias revisiones para determinar la mejor secuencia de aplicaciones de revisión. Use las instrucciones descritas en las notas del producto Secuenciación de revisiones en Windows Installer versión 3.0 para definir familias de revisiones.

  • Si es práctico, especifique todas las revisiones como pertenecientes a una sola familia de revisiones. En muchos casos, una sola familia de revisiones proporciona suficiente flexibilidad para secuenciar revisiones. La complejidad de la creación aumenta cuando se usan varias familias de revisiones. Asigne un nombre descriptivo a la familia de revisiones y asigne valores de secuencia en esa familia de revisiones que aumenten con el tiempo. Siga el ejemplo de aplicación de revisión múltiple para aplicar revisiones en el orden en que se han emitido.
  • Use la tabla PatchSequence en Patchwiz.dll para generar la información en la tabla MsiPatchSequence. La versión de PATCHWIZ.DLL que se publicó con Windows Installer 3.0 puede generar automáticamente información de secuenciación de revisiones. Para obtener más información sobre cómo agregar una nueva revisión, consulte Generación de información de secuencia de revisiones. Para obtener más información sobre los escenarios de secuenciación de revisiones, consulte las notas del producto: Secuenciación de revisiones en Windows Installer versión 3.0.

Pruebe exhaustivamente el paquete de instalación.

Pruebe la instalación, reparación y eliminación del paquete de Windows Installer. Puede dividir el proceso de prueba en las siguientes partes.

  • Pruebas de instalación: pruebe la instalación con todas las combinaciones posibles de características de la aplicación. Pruebe todos los tipos de instalación, incluida la instalación administrativa, la instalación de reversión y la instalación a petición. Pruebe todos los métodos posibles de instalación, incluido hacer clic en el archivo .msi, las opciones de la línea de comandos y la instalación desde el panel de control. Pruebe que los usuarios pueden instalar el paquete en todos los contextos de privilegios posibles. Intente instalar el paquete una vez implementado por todos los métodos posibles. Habilite el registro de Windows Installer para cada prueba y resuelva todos los errores encontrados en el registro del instalador y el registro de eventos.
  • Pruebas de interfaz de usuario: pruebe el paquete cuando se instale con todos los niveles de interfaz de usuario posibles. Pruebe el paquete instalado sin interfaz de usuario y con toda la información proporcionada a través de la interfaz de usuario. Asegúrese de la accesibilidad de la interfaz de usuario y de que la interfaz de usuario funcione según lo previsto para diferentes resoluciones de pantalla y tamaños de fuente.
  • Pruebas de mantenimiento y reparación: pruebe que el paquete puede controlar la aplicación de revisiones y actualizaciones entregadas por una actualización pequeña, una actualización secundaria y actualizaciones principales. Antes de implementar el paquete, escriba una actualización de prueba de cada tipo e intente aplicarla al paquete original.
  • Desinstalar pruebas: compruebe que cuando se elimina el paquete no quedan atrás partes inútiles en el equipo del usuario y que solo se ha eliminado la información que pertenece al paquete. Reinicie el equipo de prueba después de desinstalar el paquete y verifique la integridad de las herramientas comunes del sistema y otras aplicaciones estándar. Pruebe que los usuarios pueden eliminar el paquete en todos los contextos de privilegios posibles. Pruebe todos los métodos para eliminar el paquete, haga clic en el archivo .msi, pruebe las opciones de la línea de comandos e intente eliminar el paquete del panel de control. Habilite el registro de Windows Installer para cada prueba y resuelva todos los errores encontrados en el registro del instalador y el registro de eventos.
  • Pruebas de funcionalidad del producto: asegúrese de que la aplicación funciona según lo previsto después de la instalación, reparación o eliminación del paquete.

Corrija todos los errores de validación antes de implementar un paquete de instalación nuevo o revisado.

Ejecute la validación de paquetes en un paquete de Windows Installer nuevo o revisado antes de intentar instalarlo por primera vez. La validación comprueba si hay errores de creación en la base de datos de Windows Installer. Si intenta instalar un paquete que no supera la validación, puede dañar el sistema del usuario.

  • Puede validar el paquete mediante Orca.exe o Msival2.exe. Ambas herramientas se proporcionan con Windows SDK. Los proveedores de terceros también pueden incorporar el sistema de validación ICE en su entorno de creación.
  • Puede utilizar el conjunto estándar de evaluadores de coherencia interna: ICE incluidos en los archivos .cub proporcionados con el SDK, o personalizar la validación mediante la creación de un ICE y su adición al archivo .cub.
  • Puede utilizar Evalcom2.dll para implementar la automatización de validación para paquetes de instalación y módulos de combinación.

Cree una instalación segura.

Siga estas instrucciones al desarrollar el paquete para ayudar a mantener un entorno seguro durante la instalación.

Utilizar PMSIHANDLE en lugar de HANDLE

Las variables de tipo PMSIHANDLE se definen en msi.h. Se recomienda que la aplicación utilice el tipo PMSIHANDLE porque el instalador cierra los objetos PMSIHANDLE a medida que salen del ámbito, mientras que la aplicación debe cerrar objetos MSIHANDLE llamando a MsiCloseHandle. PMSIHandle proporciona un operador de conversión a MSIHANDLE para la compatibilidad con firmas de API.

Por ejemplo, si el código que utiliza tiene el siguiente aspecto:

MSIHANDLE hRec = MsiCreateRecord(3);

Cámbielo por esto:

PMSIHANDLE hRec = MsiCreateRecord(3);