¿Aplicación autoinstalable o instalador separado?

Question

para conseguir una aplicación instalada en un equipo nuevo parece que hay dos enfoques principales en el uso actual:

1. instalador independiente: Crear un paquete de instalación independiente que crea todos los directorios, archivos entradas de registro requeridos por su aplicación (es decir, un MSI, InstallSheild, etc.) y luego finalmente copia su aplicación a la computadora de destino.
2. Auto instalador: incluya todos los pasos de instalación requeridos en un componente que es parte de su aplicación. Luego use este componente para verificar y crear las configuraciones requeridas cada vez que se ejecuta el ejecutable principal de la aplicación. es decir, solo ejecuta la aplicación para instalar.

He utilizado algunas aplicaciones que corrompen su configuración con el tiempo, y la mayoría tenía un instalador separado. Por lo tanto, la única solución era reinstalar, a veces con la configuración e incluso la pérdida de datos (muy frustrante).

También durante los proyectos de software en los que he trabajado, el enfoque del instalador separado a menudo dictaba la difusión del conocimiento específico de la aplicación tanto en el paquete del instalador como en la aplicación real. Luego, cuando se realizaron los cambios de código/funcionalidad, tanto el instalador como la aplicación necesitaron actualizarse. Siempre se sintió demasiado frágil y propenso a errores humanos.

Por lo tanto, actualmente me estoy inclinando por el enfoque de autoinstalador debido a una instalación/configuración más sencilla y robusta, es decir, simplemente ejecute la aplicación. Este enfoque de autoinstalación que siento también se presta a una aplicación más robusta.

La integración con las configuraciones de la aplicación (opciones) también sería mucho más limpia, en muchos casos el mismo componente podría realizar tanto la instalación como la administración de configuraciones.

En lo negativo, sin embargo, la realización de estas comprobaciones/pasos adicionales cada vez que se inicia la aplicación podría afectar negativamente los tiempos de inicio, y la integración del sistema operativo podría ser un poco más trabajo que usar un instalador estándar.

¿Qué enfoque recomiendan las personas y por qué?

(estoy más interesado en la instalación de aplicaciones de cliente de escritorio en la actualidad.)

Answer 1

hay pros y los contras de ambos enfoques:

• Tener un instalador es la forma correcta de instalar los componentes necesarios del sistema, como los controladores, bibliotecas, componentes COM y así sucesivamente. Dado que muchas de estas actividades necesitan permisos elevados, la instalación puede ser realizada por el administrador, mientras que la aplicación puede ser utilizada por todos los usuarios.

• En realidad, puede haber requisitos para un procedimiento de instalación programable en entornos corporativos.

• No tener un instalador abre el camino a las aplicaciones portátiles. Si el programa tiene todo en un directorio, entonces esto simplemente puede copiarse en un dispositivo USB y ejecutarse en cualquier sistema. Esto, por supuesto, puede no tener sentido para su tipo particular de aplicación, pero eso es para que usted decida.

No estoy seguro de que el problema de la configuración dañada sea realmente importante aquí. Si la configuración está dañada (¿por qué?): ¿Cómo sabe la aplicación qué hacer al respecto? OTOH, por supuesto, el instalador también puede escribirse para no sobrescribir ciegamente ninguna configuración anterior. Todo depende ...

Editar: Usted escribe en su comentario:

Incluso ciertas aplicaciones portátiles requieren la configuración/ajuste, ¿No es mejor tener la comprobación de la aplicación principal de que los ajustes son válidos/existen en cada inicio y solo avisan al usuario cuando sea necesario.

y nuevamente, realmente depende de sus necesidades. Hay diferentes tipos de ajustes de configuración o preferencias, y usted tiene que decidir individualmente:

ajustes de configuración

• por usuario no podrá contar si la aplicación se ejecuta por primera vez por el usuario actual. Puede ser útil mostrar un mensaje que falta y cómo crearlo. Por ejemplo, en FlameRobin (un programa de administración de bases de datos para Firebird), tenemos un mensaje que se muestra cuando no se encuentran servidores y bases de datos registrados en el inicio del programa, y ​​cómo registrarlos.

• La configuración de usuario para el comportamiento de la UI también faltará, pero hay valores predeterminados para ellos. El usuario obtendrá el comportamiento predeterminado de la aplicación, y luego puede cambiar las cosas en el cuadro de diálogo de opciones. Como lo mejor es minimizar el número de tales configuraciones, y dado que los valores predeterminados deberían ser lo que la mayoría de los usuarios esperan o lo que funciona mejor en el caso general, tampoco hay necesidad de molestar al usuario al inicio del programa.

• Algunas configuraciones pueden no ser por usuario, sino por programa. Esto generalmente se almacena en una ubicación donde los usuarios estándar no tienen acceso de escritura, por lo que consultar esto e indicarle al usuario que ingrese no es realmente útil. Lo que se puede hacer es iniciar un programa externo, preguntando al usuario estándar por la cuenta con suficientes privilegios y su contraseña.

Answer 2

recomendaría un instalador independiente que se puede hacer lo siguiente:

• Instalar una nueva instalación
• reparar una instalación existente
• Eliminar una instalación existente

La razón por la que recomiendo estas opciones es porque eso es lo que esperaba de los instaladores en entornos Windows.

Las razones que recomiendo que separan la instalación y la lógica de la aplicación en el área de dos aplicaciones diferentes:

• puede haber conflictos entre dependencias utilizado Utilizado por el instalador y aplicación.
• Quiero asegurarme de que mi equipo no use inadvertidamente clases en las dependencias del marco de instalador al desarrollar la aplicación.

Answer 3

Ir con un instalador separado es la "mejor" manera desde mi punto de vista.Hacer que una aplicación se instale automáticamente no solo agrega carga de trabajo adicional a la aplicación en sí misma, sino que también "funciona alrededor" de cualquier sistema de instalación del sistema operativo subyacente (como MSI en Windows).

Y si la aplicación corrupta su configuración con el tiempo se ha roto y necesita ser arreglado. ¿Cómo debe manejar la configuración corrupta el autoinstalador? ¿Simplemente sobrescribirlo con los valores predeterminados? Los usuarios también se molestarán con eso, por lo que tenerlos para ejecutar un instalador por separado y elegir una opción de "reparación" hace que esto sea al menos más transparente.

Answer 4

Gracias por sus comentarios. Estoy empezando a pensar en algo en este sentido sería una buena solución de compromiso:

• elegir el enfoque de instalación de uno mismo mediante la creación de un componente de instalación (biblioteca de clases) que hace referencia a la aplicación principal.
• Este componente es una parte central de la aplicación y es responsable de garantizar que todas las configuraciones/configuraciones existan y sean válidas.
• La aplicación principal. el ejecutable, en cada ejecución, le pide a este componente que verifique la existencia/validez de las configuraciones, y solo solicita al usuario cuando sea necesario. Esto podría hacerse fácilmente de una manera fácil de usar agrupando todos los problemas de configuración y presentándolos en una sola GUI (evita una secuencia de diálogos molestos).
• Para la integración del sistema operativo, el componente de instalación (en el caso de Windows) asegura una entrada se agrega a la lista de "Agregar o quitar programas" para la aplicación, así como cualquier otra convención operativo requerido.
• Dentro de la aplicación, la pantalla de opciones/ajustes estándar también es proporcionada por el componente instalador. Esto evita duplicar el código de administración de configuraciones.

He hecho esta pregunta porque he conocido a muchos usuarios no técnicos que preguntan por qué no pueden simplemente copiar una aplicación de una computadora a otra, pueden hacerlo con sus datos (por ejemplo, fotos, documentos, etc.) Es una pregunta extremadamente válida, en particular para aplicaciones de escritorio orientadas a GUI.

instaladores separados son, sin duda "la forma en que se ha hecho" en Windows desde hace muchos años. Para controladores/componentes del sistema, obviamente son a menudo una necesidad. Pero para las aplicaciones de estilo GUI de escritorio, no creo que sean las mejores en términos de simplicidad y realismo para el usuario/cliente.