Escenarios de instalación de VSPackage
Es importante diseñar el instalador de VSPackage para mayor flexibilidad. Por ejemplo, es posible que tenga que publicar una revisión de seguridad en el futuro o puede cambiar una estrategia empresarial que requiera compatibilidad exhaustiva con el control de versiones en paralelo.
En Compatibilidad con varias versiones de Visual Studio, puede leer las ventajas y problemas de admitir instalaciones en paralelo de Visual Studio con instalaciones compartidas o en paralelo de VSPackage. En resumen, VSPackages en paralelo le ofrece la mayor flexibilidad para admitir nuevas características de Visual Studio.
Los escenarios descritos en este tema no son las únicas opciones, sino que se presentan como procedimientos recomendados sugeridos.
Componentes, privacidad y uso compartido
Hacer que los componentes sean independientes
Una vez que identifique y rellene un componente, asigne un GUIDelemento e implemente el componente, no puede cambiar su composición. Si cambia la composición de un componente, el componente resultante debe ser un nuevo componente con un nuevo GUID. Dados estos hechos, la mayor flexibilidad de control de versiones se ofrece al hacer que cada componente sea independiente y independiente de la unidad dependiente. Para obtener más información sobre las reglas que rigen los componentes, vea Cambio del código de componente y ¿Qué ocurre si las reglas de componente están rotas?.
No mezclar recursos compartidos y privados en un componente
El recuento de referencias se produce en el nivel de componente. Por lo tanto, mezclar recursos compartidos y privados en un componente hace imposible actualizar recursos privados, como un archivo ejecutable, sin sobrescribir también los recursos compartidos. Este escenario crea problemas de compatibilidad con versiones anteriores y le restringe la creación de funcionalidades en paralelo.
Por ejemplo, los valores del Registro que se usan para registrar el VSPackage con el SDK de Visual Studio deben mantenerse en un componente independiente de uno que se usa para registrar el VSPackage con Visual Studio. Los archivos compartidos o los valores del Registro van en otro componente.
Escenario 1: VSPackage compartido
En este escenario, se incluye un VSPackage compartido (un único binario que admite varias versiones de Visual Studio en un paquete de Windows Installer. El registro con cada versión de Visual Studio se controla mediante características seleccionables por el usuario. También significa que, cuando se asignan a características independientes, cada componente se puede seleccionar individualmente para la instalación o desinstalación, colocando al usuario en el control de integrar VSPackage en diferentes versiones de Visual Studio. (Consulte Características de Windows Installer para obtener más información sobre el uso de características en paquetes de Windows Installer).
Como se muestra en la ilustración, los componentes compartidos forman parte de la característica Feat_Common, que siempre se instala. Al hacer visibles las características de Feat_VS2002 y Feat_VS2003, los usuarios pueden elegir en tiempo de instalación en qué versiones de Visual Studio quieren que se integre vsPackage. Los usuarios también pueden usar el modo de mantenimiento de Windows Installer para agregar o quitar características, que en este caso agrega o quita la información de registro de VSPackage de diferentes versiones de Visual Studio.
Nota:
Al establecer la columna Mostrar de una característica en 0, se oculta. Un valor de columna de bajo nivel, como 1, garantiza que siempre se instalará. Para obtener más información, vea INSTALLLEVEL Property and Feature Table.
Escenario 2: Actualización de VSPackage compartida
En este escenario, se incluye una versión actualizada del instalador de VSPackage en el escenario 1. Por motivos de discusión, la actualización agrega compatibilidad con Visual Studio, pero también podría ser una revisión de seguridad más sencilla o service pack de corrección de errores. Las reglas de Windows Installer para instalar componentes más recientes requieren que los componentes sin cambios que ya estén en el sistema no se vuelvan a copiar. En este caso, un sistema con la versión 1.0 ya presente sobrescribirá el componente actualizado Comp_MyVSPackage.dll y permitirá a los usuarios elegir agregar la nueva característica Feat_VS2005 con su componente Comp_VS2005_Reg.
Precaución
Siempre que un VSPackage se comparte entre varias versiones de Visual Studio, es esencial que las versiones posteriores de VSPackage mantengan la compatibilidad con versiones anteriores de Visual Studio. Si no puede mantener la compatibilidad con versiones anteriores, debe usar VSPackages privados en paralelo. Para obtener más información, vea Compatibilidad con varias versiones de Visual Studio.
En este escenario se presenta un nuevo instalador de VSPackage, aprovechando la compatibilidad de Windows Installer con actualizaciones secundarias. Los usuarios simplemente instalan la versión 1.1 y actualizan la versión 1.0. Sin embargo, no es necesario tener la versión 1.0 en el sistema. El mismo instalador instalará la versión 1.1 en un sistema sin la versión 1.0. La ventaja de proporcionar actualizaciones menores de esta manera es que no es necesario pasar por el trabajo de desarrollo de un instalador de actualización y un instalador de producto completo. Un instalador realiza ambos trabajos. Una corrección de seguridad o Service Pack podría aprovechar las revisiones de Windows Installer. Para obtener más información, consulte Aplicación de revisiones y actualizaciones.
Escenario 3: VSPackage en paralelo
En este escenario se presentan dos instaladores de VSPackage, uno para cada versión de Visual Studio .NET 2003 y Visual Studio. Cada instalador instala un VSPackage en paralelo o privado (uno creado e instalado específicamente para una versión determinada de Visual Studio). Cada VSPackage se encuentra en su propio componente. Por lo tanto, cada uno se puede atender individualmente con revisiones o versiones de mantenimiento. Dado que el archivo DLL de VSPackage ahora es específico de la versión, es seguro incluir su información de registro en el mismo componente que el archivo DLL.
Cada instalador también incluye código compartido entre los dos instaladores. Si el código compartido se instala en una ubicación común, la instalación de ambos archivos .msi instalará el código compartido solo una vez. El segundo instalador simplemente incrementa un recuento de referencias en el componente. El recuento de referencias garantiza que si se desinstala uno de los VSPackages, el código compartido permanecerá para el otro VSPackage. Si también se desinstala el segundo VSPackage, se quitará el código compartido.
Escenario 4: Actualización en paralelo de VSPackage
En este escenario, VSPackage para Visual Studio sufrió una vulnerabilidad de seguridad y debe emitir una actualización. Como en el escenario 2, puede crear un nuevo archivo .msi que actualice una instalación existente para incluir la corrección de seguridad, así como implementar nuevas instalaciones con la corrección de seguridad ya implementada.
En este caso, VSPackage es un VSPackage administrado instalado en la caché global de ensamblados (GAC). Al volver a generarlo para incluir la corrección de seguridad, debe cambiar la parte del número de revisión del número de versión del ensamblado. La información de registro del nuevo número de versión del ensamblado sobrescribe la versión anterior, lo que hace que Visual Studio cargue el ensamblado fijo.
Para obtener más información sobre la implementación de ensamblados en paralelo, consulte Simplificación de la implementación y resolución del infierno de DLL con .NET Framework.