2009-03-12 6 views
7

Recientemente tuve que luchar con un proyecto de instalación (que usa el producto más popular para crear instalaciones: InstallShield) para hacerlo funcionar para las actualizaciones del producto (migración de una versión a otra). Al final resultó que necesitaba usar un código de paquete largo pero estaba usando otro. Perdió mis 8 horas (probar y depurar instaladores es un dolor).¿No crees que escribir programas de instalador podría/debería haber sido más simple?

Ahora, si lo pienso, una vez que haya terminado con la parte difícil de la codificación, todo lo que desea es que las aplicaciones correctas, las bibliotecas se copien en la computadora de destino y el usuario simplemente la ejecute. Período. Esta tarea aparentemente simple normalmente resulta complicada y "estar cerrado hasta la fecha de finalización" hace aún más difícil.

  1. ¿No crees que desplegar un producto es muy difícil en Windows, lo que debería haber sido más simple? (¿o el instalador realmente merece tanta atención y solo estoy loco por eso?)

  2. ¿Alguna vez ha utilizado esquemas de implementación más simples como "copiar la carpeta a donde quiera y ejecutar el exe" cuando quiera eliminar ¡simplemente elimine la carpeta! "? ¿Fue efectivo y simplificó las cosas?

+1

8 horas? ¡Eso es bastante rápido! Mi última codificación de instalación de InnoSetup tomó DIEZ DÍAS, y todavía no funcionará en Vista. Instaló una biblioteca de aplicaciones, algunas aplicaciones de muestra, creó una base de datos, instaló e inició 2 servicios de Windows y publicó un sitio web, pero 10 días es demasiado largo ... –

Respuesta

7

Doloroso, es necesario luchar con el instalador de Windows para el beneficio de sus clientes. De lo contrario, tendrá que trabajar mucho más para

  1. Manejar situaciones donde por algún motivo se produce un error durante la instalación. ¿Qué vas a hacer después?
  2. Maneja problemas como la seguridad. ¿Qué ocurre si el usuario que realiza la instalación no tiene derechos sobre determinadas carpetas/claves de registro?
  3. correctamente la limpieza después de la instalación
  4. parches y gestión de parches
  5. Realizar tareas adicionales - registro de objetos COM, la creación de bases de datos, creación de accesos directos, creando un shotcut de desinstalación y así sucesivamente
  6. Instalando requisitos previos
  7. Letting los usuarios eligen qué características instalar

¡Sus propias secuencias de comandos personalizadas para resolver todos estos problemas eventualmente se convierten en un problema mayor que la instalación misma!

Le recomiendo que consulte Wix. No es exactamente un juego de niños, pero hace el trabajo bien. Si instala Votive como un complemento de estudio visual obtendrá Intellisense para ayudarlo a estructurar correctamente las etiquetas. Con el archivo de ayuda puede crear instalaciones flexibles bastante funcionales

+1

He utilizado constructores de instalación de GUI y WiX. Descubrí que WiX es mucho más fácil de usar, ya que el script de instalación se convierte en otra pieza de código escrita en lenguaje declarativo. Puede ver la lógica en un solo lugar en lugar de navegar constantemente por la estructura de un árbol intentando unir la lógica – Ferruccio

+0

Todo con Ferruccio en este. WIX es el método de implementación del desarrollador, sin dudas. MSI no lo hace, y no tendrá sentido para la mayoría de los desarrolladores. La implementación es un campo que se encuentra entre el desarrollo y la administración del sistema. Como tal, es "cruzar el abismo" entre el mundo del usuario final y el de los desarrolladores de aplicaciones. WIX está "escrito como código fuente" (si podemos llamar a la fuente XML) y luego compilado y enlazado con el "modo desarrollador" normal. También es muy estable y está bien escrito. Si usted es un desarrollador y necesita hacer una implementación y tiene una opción, no hay otra opción, es WIX. –

0

por exactamente las razones por las que Estado, que hemos hecho comunicados internos, manejados por el equipo de desarrollo copiando los archivos necesarios, y luego hecho el resto de la configuración utilizando guiones y nuestras propias utilidades.

Sin embargo, para los usuarios finales tiene que tener algún tipo de asistente de mano, he usado el instalador de MS desde VS y me pareció confuso y poco práctico. Después de esa experiencia evité el dolor haciendo que otros hicieran el paso de instalación. ¿Alguien puede recomendar un buen instalador .Net?

0

Uso Installshield y si no está tratando de hacer algo demasiado elegante (¿por qué lo haría?), Entonces es bastante sencillo: configure la configuración inicial, seleccione archivos, configure accesos directos y cree setup.exe.

Todas las actualizaciones futuras que manejo dentro de mi código - mucho más cómodo para el usuario

+0

Entonces, si la versión 1.0 está instalada en la máquina de un usuario y ahora quiere instalar la versión 2.0. ¿Qué pasos debe tomar en tu caso? (Creo que primero tendrá que desinstalar la versión 1.0 si no usa las actualizaciones del instalador) – Hemant

+0

No funciona en Vista. A diferencia de los instaladores, su propia aplicación no puede (y no debe) escribir en \ Archivos de programa \ – MSalters

+0

@MSalters: funciona bien en Vista (y en todas las otras versiones de NT cuando no es administrador) - debe dar su configuración/actualización.exe un manifiesto de UAC para decir "Necesito elevación" para ser amable con el usuario, sin embargo. La auto-actualización solo necesita usar un proceso externo (* después de * verificar la nueva versión). –

3

Bueno, es mucho más fácil si usted construye su instalación primero, que sea parte de su sistema de construcción, y se deja crecer con su proyecto.

Estoy de acuerdo, el instalador de Windows me vuelve loco. Pero hay muchas situaciones que xcopy simplemente no resuelve. Algunas veces desea instalar para múltiples usuarios, no solo para el usuario actual. A veces tienes que registrar objetos COM. En ocasiones debe realizar un montón de cambios en el sistema, como registrar servicios para ejecutar al inicio, conectarse a servidores de red, etc. Algunas veces tiene usuarios que no pueden usar un símbolo del sistema. Y siempre quiere poder devolver todo cuando algo falla a mitad de camino.

¿Se acercaba toda la base de datos MSI a la mejor manera de hacerlo? No estoy seguro. ¿Prefiero golpearme las uñas en la cabeza antes que escribir otra línea de código de WiX? Probablemente. Pero debes admitir que hace un buen trabajo al hacer todo lo que podrías desear. Y cuando no, siempre hay la opción CustomAction.

Realmente, lo que me gustaría ver es una mejor documentación (en realidad, ¿qué es una acción tipo 50? ¿Qué le parece darle un nombre?) Y muchas más plantillas fáciles de usurpar.

Y el alias del grupo de usuarios de WiX hace un buen trabajo respondiendo preguntas.

Debe leer RobMen's blog. Él hace un buen trabajo explicando por qué las cosas son como son. Él ha pensado mucho (más que cualquier humano debería) sobre los problemas de configuración.

+0

Tiene razón al hacer que el instalador forme parte del sistema de compilación, pero cuando dije "más cerca de la fecha de finalización" quise decir "más cerca de la fecha de finalización del desarrollo", lo que significa antes de dar la primera compilación para las pruebas beta. He escuchado recientemente sobre WiX. ¿Es más simple o más transparente? ¿Debería intentarlo? – Hemant

+0

Bueno, deberías leer el tutorial y decidir por ti mismo. Ver: http://www.tramontana.co.hu/wix/ –

+0

Personalmente creo que InnoSetup es más fácil de usar: http://www.innosetup.com/isinfo.php –

1

"Una vez que haya hecho toda la parte difícil de la codificación", no ha hecho nada si no se instala todo su trabajo duro. Los instaladores deben construirse y probarse en todas las construcciones nocturnas, todas las noches, casi desde el primer día. Debe probar que el instalador se puede generar y ejecutar, y debe verificar la instalación.

De lo contrario, ¿quién le importa cuánto trabajo duro ha hecho la codificación - nadie verá su trabajo si no se instala!

Tenga en cuenta que esto también se aplica a XCOPY.

Otra cosa: ¿cuál es su prueba de control de calidad si no están probando lo que instala su instalador? ¡Tienes que probar lo que recibirá el cliente!

+0

No estoy seguro de qué le da la impresión de que * nuestras * pruebas de control de calidad no implican probar a los instaladores. Cuando dije "cerca de la fecha de finalización", me refiero a "cerca de la fecha de finalización del desarrollo", seguido de la fase de validación del producto que hace exactamente esto> "probar lo que el cliente obtiene". – Hemant

+2

Interesante. Estoy más acostumbrado a probar durante todo el ciclo de desarrollo; no esperar hasta que el desarrollo esté "completo" para comenzar a encontrar errores. –

2

Personalmente, casi siempre estoy de acuerdo con @Conrad y @John Saunders. Escribí sobre este tema hace mucho tiempo en mi old blog. Creo que @jeffamaphone tiene un punto sobre la complejidad de Windows Installer (y mi excesiva atención a la configuración, en general), pero creo que Windows Installer sigue siendo la mejor opción para instalar en Windows.

4

No creo que veas demasiados desacuerdos aquí, especialmente con respecto a MSI. Creo que una cosa a tener en cuenta es observar la forma en que muchos programas usan archivos MSI en estos días. Mostrar diálogos de IU y tomar decisiones de configuración complejas con un MSI es muy débil simplemente por la forma en que se diseñó Windows Installer, así que he notado que muchos programas se dividen en un montón de MSI para bebés que se instalan con la IU mínima por programa de instalación para padres. El asistente de instalación de SQL Server 2008 hace esto. UPS WorldShip hace esto. Y pintar.NET también lo hace: el asistente que ve es una aplicación de Windows Forms e inicia el propio msiexec (puede ver la IU mínima del Windows Installer emergente sobre la ventana del asistente blanco), pasando los parámetros de configuración como propiedad argumentos a msiexec.

Un escenario común en el que esto surge es cuando alguien tiene la tarea de construir un instalador para una aplicación que tenga contrapartes de servidor y cliente. Si el usuario elige la opción de servidor, puede que quieran o no que se instale una nueva base de datos, lo que significa instalar SQL Server. Pero no puedes simplemente instalar SQL Server mientras estás en el medio de tu propia instalación porque Windows Installer no te permitirá hacerlo. Por lo tanto, una solución frecuente es escribir una aplicación que muestre un asistente que permita al usuario configurar todas las opciones de configuración, y luego su aplicación iniciará los archivos MSI según sea necesario para SQL Server, su aplicación de servidor y su aplicación cliente en el mínimo Modo UI; Básicamente, evitando por completo el aspecto de "características" de Windows Installer y moviéndolo al nivel de MSI. Las instalaciones de paquetes múltiples de 4.5 parecen ser un paso más en esta dirección. Este formato también es especialmente útil si también necesita realizar un bucle en instaladores que no sean MSI de terceros como parte de su proceso de instalación, como instalar un controlador de impresora para alguna extraña impresora de punto de venta.

También estoy de acuerdo en que Windows Installer carece de compatibilidad integrada para escenarios de implementación comunes. Está destinado para cuando la configuración no es XCOPY, pero parecen pasar por alto el hecho de que la configuración generalmente no es solo "archivos + accesos directos + claves de registro". No hay acciones integradas para configurar los sitios web de IIS, registrar certificados, crear y actualizar bases de datos, agregar ensamblajes al GAC, y más. Supongo que tienen la opinión de que algo de esto debería ocurrir en la primera ejecución en lugar de ser una parte transaccional de la instalación. Las herramientas y la documentación de libre acceso han sido terribles, absolutamente horribles, durante la mayor parte de una década. Ambas cuestiones se abordan en gran parte por el proyecto WiX y DTF (que le permite finalmente usar acciones personalizadas de código administrado), por lo que estamos muy agradecidos con el trabajo de Rob Mensching y otros en ese proyecto.

He tenido la misma experiencia. La instalación puede absorber rápidamente su tiempo a medida que avanza por el agujero del conejo de "Oh Dios, supongo que tengo que convertirme en un experto en este también". En segundo lugar, creo que es mejor abordarlo desde el principio en su proyecto y mantenerlo como parte de su proceso de construcción. De esta manera, puede ayudar a evitar ese escenario de haber desarrollado un producto prácticamente imposible de desinstalar. (Trac fue un ejemplo de esto por un tiempo, requiriendo rastrear versiones específicas de bibliotecas de Python extrañas).

(podría seguir sobre cómo el instalador de Windows a veces decide usar mi disco duro USB externo lento como un lugar) descomprimir sus archivos, cómo parece estar sentado sin hacer nada durante minutos en computadoras que han tenido muchas instalaciones de MSI en ellos, y cómo esa barra de progreso se reinicia una miríada de veces durante una única instalación es la cosa más idiota que tengo Alguna vez visto, pero voy a guardar esas diatribas para otro día. =)

Mis dos centavos; tenga en cuenta que realmente sé lo suficiente sobre Windows Installer como para hacer daño, pero esta es mi evaluación proveniente de un desarrollador de pequeñas empresas que simplemente intenta usarla. ¡Buena suerte!

Cuestiones relacionadas