¿Cuál es el beneficio y el verdadero propósito de la instalación del progtwig?

De todos los progtwigs que escribí hasta ahora, si quiero que funcione en otra estación de trabajo, solo tengo que copiar y pegar el ejecutable y los archivos necesarios para que se ejecute (por ejemplo: archivos .o, archivos binarios …).

Pero todo el progtwig creado para uso comercial siempre viene con un instalador. Por ejemplo, juegos de PC. Entonces mi pregunta es: ¿Cuáles son los principales beneficios / razones de hacer la instalación cuando simplemente podemos copiar los archivos a la estación de trabajo objective?

– Una de las razones es probablemente para prevenir la piratería. Pero aparte de eso, estoy seguro de que hay otras razones más fuertes.

La complejidad de la implementación

Solo las aplicaciones más sencillas pueden funcionar con una simple copia de archivo , e incluso entonces debe tener una manera conveniente de descargar y hacer la copia de los archivos en la ubicación correcta, y para esto es la configuración. La configuración también es una herramienta de marketing que se puede utilizar para la creación de marca y la coherencia entre productos, además de permitir la instalación de una versión de prueba del producto, una parte muy importante de la venta de software.

Finalmente, una configuración proporciona características de actualización y parchado para las nuevas versiones, así como la desinstalación y limpieza del sistema cuando el usuario desea eliminar su software. También se puede firmar una buena configuración con certificados digitales para garantizar que no se obstaculice el archivo en tránsito y que el proveedor sea certificable y, por lo tanto, grave. Todas estas cosas son cruciales para un producto serio.

Es importante recordar que la experiencia de configuración es el primer encuentro del usuario con la calidad de su producto . Si la configuración falla, el producto no se puede evaluar en absoluto. Este parece ser el error más costoso en el desarrollo de software.

Los errores en la implementación son acumulativos en el sentido de que una vez que tiene un error implementado, generalmente no tiene acceso a la máquina en cuestión para la depuración, y la solución podría causar más daño. Está administrando un proceso de entrega , no solo código de depuración y binarios. Cada entrega agrega riesgo y complejidad y muy pronto puede tener la imposibilidad de mantener en sus manos si no tiene cuidado . Además, todas las máquinas en las que se ejecute su configuración casi con certeza estarán en un estado totalmente diferente al de otra computadora.

La implementación (configuraciones) es, por lo tanto, el complejo proceso de migrar cualquier computadora de un estado estable a otro . Esto requiere un enfoque disciplinado. La configuración debe instalar todos los archivos y configuraciones necesarios y asegurarse de que el producto esté configurado para el primer lanzamiento o listo para ser configurado al momento del lanzamiento sin fallas. Esta puede ser una tarea muy compleja. La lista de cosas que una instalación puede necesitar hacer es crecer todo el tiempo , y para cada nueva versión de Windows parece que se ponen nuevos obstáculos para hacer que la implementación sea más difícil . Dichos obstáculos incluyen las solicitudes UAC , locking de autorreparación en servidores de terminal, comportamiento de almacenamiento en caché MSI central modificado , redireccionamientos de carpetas nuevas, características de virtualización, funciones de firma nuevas y modificadas con cifrado y certificados digitales, cierre de seguridad Active X killbits , complejidades de 64 bits , etc. … La lista continua.

La virtualización de aplicaciones es un gran problema en estos días. En esencia, encapsula los progtwigs informáticos del sistema operativo subyacente en el que se ejecuta. Esto esencialmente todavía implica un paquete de implementación para su aplicación, pero una aplicación completamente virtualizada no está instalada en el sentido tradicional. La aplicación se comporta en tiempo de ejecución como si estuviese interactuando directamente con el sistema operativo original y todos los recursos administrados por él, pero puede aislarse o sandbox en diversos grados.

Una descripción general de las tareas de implementación

Las tareas y características necesarias en un rango de instalación van desde lo fundamental y básico con Windows Installer incorporado o soporte de herramientas de terceros, hasta las soluciones ad hoc altamente personalizadas donde usted tiene que codificar realmente algo para lidiar con los requisitos de implementación únicos .

Las herramientas de implementación realmente contienen lo más que necesitaría para cualquier implementación, pero ciertas cosas aún están codificadas caso por caso. Estas soluciones ad hoc se implementan como ” acciones personalizadas ” en Windows Installer, y son sin ninguna duda la principal causa de fallas en el despliegue . Consulte la sección “Muy avanzado” para obtener más información sobre acciones personalizadas.

El uso excesivo de acciones personalizadas y una gran cantidad de códigos ad hoc tiende a indicar un diseño defectuoso de la aplicación , pero en ciertos casos solo se trata de nuevas tecnologías y tiene que implementar su propia solución para implementar su solución. Esto es exactamente para lo que son las acciones personalizadas. Con el tiempo, las soluciones estandarizadas deben ser creadas y preferidas. Y pequeños cambios en el diseño de la aplicación a menudo pueden eliminar acciones personalizadas complicadas. Este es un hecho muy importante sobre la implementación del software: hay tantas variables que uno debería optar por la simplicidad siempre que sea posible.

En un nivel general básico, la implementación debe tener en cuenta:

Fundamentos de configuración

Todas las herramientas de terceros brindan un buen soporte para estos fundamentos de configuración, pero existen algunas diferencias. La instalación de requisitos previos puede ser el área donde las herramientas de terceros y los marcos libres como WiX difieren más en términos de facilidad de uso, al momento de la redacción. El soporte está ahí, pero puede ser un poco difícil de configurar.

  • Verifique si el sistema es adecuado para la instalación del paquete en cuestión.
    • Espacio del disco.
    • Tipo de sistema operativo y versión.
    • Versión de idioma
    • Arquitectura de computadora x86 / x64.
    • Plataformas inadecuadas: Thin Client / Citrix / Terminal Services
      • Se requiere una configuración personalizada debido al locking personalizado.
    • Tal vez incluso la situación del malware (deseo, puede causar misteriosos problemas de despliegue).
    • etc …
  • Busque presencia y, si es necesario, instale requisitos previos y tiempos de ejecución .
    • Permitir la implementación sencilla de requisitos previos y tiempos de ejecución es una tarea con amplio soporte en herramientas de implementación de terceros. Hay soporte limitado para esto en Windows Installer. La característica básica para la distribución del tiempo de ejecución en Windows Installer es el módulo de fusión , esencialmente el “incluir archivo equivalente” para los archivos MSI. La forma estándar de implementar archivos compartidos. Un módulo de fusión se comstack en su MSI en tiempo de comstackción, una especie de enlace anticipado en términos de desarrollador.
    • Algunos prerrequisitos se instalan a través de los módulos de combinación de Windows Installer. Otros generalmente se instalan usando su propio archivo de configuración (varios formatos).
    • Ejemplos: Active X para juegos, Crystal Reports , Microsoft Report Viewer Runtime , MySQL , SQL Server Runtime , VB6 Runtime , ASP.NET MVC Runtime , Java Runtime , Silverlight , Microsoft XNA , VC ++ Runtime , .NET runtime versions, Visual Studio Tools For Office Runtime , Visual F # Runtime , MSXML Runtime , MS Access Runtime , Apache Tomcat , varios ensamblados primarios de interoperabilidad , versiones de PowerShell , etc.
    • Finalmente, varios componentes básicos de Microsoft , como las versiones de Windows Installer y PowerShell, generalmente se obtienen a través de Windows Update y es mejor excluirlos de su configuración (solo verifique su existencia y dígale al usuario que ejecute Windows Update si falta el componente). La práctica real aquí varía.
  • Proporcione una GUI adecuada para la entrada de las configuraciones requeridas por parte del usuario.
    • Es una práctica común ingresar y validar claves de licencia en una configuración.
    • Personalmente creo que esto se hace mejor desde la propia aplicación por razones prácticas y de seguridad, lo que dificulta la piratería, permite instalaciones de prueba, reduce las llamadas excesivas al soporte de configuración (no lo creería …), etc.
    • Para configuraciones complejas, se podría necesitar mucha GUI para recostackr configuraciones de implementación, particularmente para configuraciones de servidor con IIS, MS SQL, COM + y otros componentes avanzados.
  • Permitir la instalación en modo silencioso para uso corporativo.
    • Extremadamente importante : toda la implementación corporativa es automática y silenciosa (no se muestra GUI durante la instalación), excepto ciertas instalaciones del servidor.
    • Las empresas más pequeñas pueden ejecutar su configuración en modo GUI. En mi experiencia, generalmente lo hacen.
    • Los usuarios domésticos generalmente siempre ejecutan su configuración en modo GUI.
    • Conozca a su grupo objective, y definitivamente asegúrese de apoyar el funcionamiento silencioso si se dirige a clientes corporativos. Sin embargo, todas las configuraciones deberían funcionar en modo silencioso, y si sigue las reglas de diseño de MSI y las mejores prácticas, “se recibe de forma gratuita”.

Agregar cosas básicas

Estas tareas básicas cuentan con soporte total en el motor de Windows Installer, y todas las herramientas de terceros proporcionan un soporte bastante equivalente para todas ellas a pesar de las variaciones en las características de la GUI y su facilidad de uso.

  • Instale archivos y configuraciones de registro .
  • Instale odbc , asociaciones de archivos , accesos directos e icons .
  • Actualizar la aplicación y la configuración de ruta de todo el sistema.
  • Actualice y combine archivos basados ​​en texto como archivos INI .
  • Registre los archivos COM y habilite .NET COM Interop si es necesario.
  • Instale ensamblados .NET en el GAC y ejecute clases de instalador .NET personalizadas.
  • Instale ensamblajes de ventanas uno al lado del otro en WinSxS .
  • Entregar archivos firmados y certificados (también se aplica al archivo de configuración en sí).
  • Instalar y controlar servicios de Windows .
  • Instala los applets del panel de control .
  • Actualizar las variables de entorno .

No me detendré en estos temas ni los detallaré con demasiados detalles. Todas estas tareas de implementación deberían contar con un soporte razonable en todas las herramientas y marcos de implementación disponibles. Sin embargo, muchas personas desordenan su implementación al no usar las funciones integradas de implementación y, en cambio, confiar en acciones personalizadas para tareas tan triviales. Totalmente agregado riesgo de ninguna ganancia en absoluto.

En particular, a menudo vemos acciones personalizadas para instalar servicios de Windows , y esto suele ser un signo de un servicio muy mal diseñado o, en otros casos, simplemente ignorar cómo hacer la implementación. Ambas cuestiones juntas también son comunes. La implementación de dicho servicio a menudo implica la aplicación de permisos ACL personalizados y privilegios NT modificados para hacer que un servicio se ejecute con derechos de usuario en lugar de LocalSystem, que generalmente es la única forma correcta de ejecutar servicios de Windows. Ejecutar un servicio con credenciales de usuario es un ” despliegue anti-patrón ” que vale la pena mencionar de pasada (más sobre esto más adelante).

Otro uso común de acción personalizada que siempre es incorrecto es instalar archivos en el GAC a través de una acción personalizada . Hay un buen soporte integrado para esto en Windows Installer y cualquier excusa para instalar a través de una acción personalizada es casi seguro que esconde un mal diseño o alguna locura generalizada :-). También es un hecho que muchos despliegan demasiadas cosas al GAC en general, pero ese es un problema de desarrollo: ¿ cuándo debería implementar mis ensamblajes en el GAC?

Por último, las clases de instalador .NET están destinadas a que los desarrolladores prueben sus componentes durante el desarrollo , no deben usarse para la implementación . Es esencialmente solo el equivalente .NET de autorregistro (que tampoco es aceptable para MSI; necesita extraer la información COM y agregarla a las tablas MSI ; ver el enlace para más detalles). Un MSI es declarativo: debe contener todos los cambios que se aplicarán al sistema para garantizar la correcta reversión y administración. Entonces, el mensaje es que las clases de instalador .NET solo deben usarse para el desarrollo y las pruebas . Una vez que construya un MSI para implementar su aplicación, debe usar construcciones MSI para lograr una implementación adecuada con soporte de reversión y administración inteligente. Vemos que estas clases de instalador .NET se usan principalmente para el servicio y la instalación de GAC. En una MSI, esto se traduce en utilizar las tablas ServiceInstall y ServiceControl para servicios, y simplemente marcar un componente para la instalación de GAC para instalar en el GAC (debe ser un ensamblaje firmado). Una vez que sepa cómo, es fácil y no se perderá las clases de instalador de .NET porque MSI funciona como ” automático ” cuando hace esto bien. Obtiene reversión confiable de forma gratuita, con facilidad.

Agregar cosas avanzadas (a menudo cosas del servidor)

A pesar del soporte en todas las herramientas de implementación para la mayoría de estos problemas, a menudo he descubierto que necesitaba implementar acciones personalizadas y soluciones ad hoc para lograr una implementación adecuada en ciertos casos. Este es particularmente el caso para la implementación de COM + e IIS . WiX brinda asistencia altamente personalizada para ambos tipos de implementación, pero tengo una experiencia limitada en su uso.

La actualización y la instalación de archivos XML es una tarea admitida por cada herramienta de implementación, ya que no hay soporte integrado para esto en el motor de Windows Installer, lo cual es bastante sorprendente en este momento.

Con respecto a la instalación de la base de datos y particularmente las actualizaciones , estoy en la incertidumbre pensando que se debe hacer desde aplicaciones con autenticación de usuario y uso interactivo adecuados, en lugar de una operación de implementación “one shot” y suplantada (que podría fallar aparentemente sin una buena administración de excepciones o opciones de recuperación). O en otros casos, parece que las actualizaciones deben ser un proceso administrado que involucre a los usuarios que generan tickets corporativos administrados por DBO profesionales. Algunos más detalles a continuación.

  • Configuración de IIS , Apache u otros servidores web .
    • Esto es todo un mundo propio, particularmente con respecto a IIS. He encontrado herramientas de implementación que carecen de funciones para implementar sitios según lo solicitado por los desarrolladores y los equipos corporativos.
    • Aunque no lo he probado en gran medida, el marco de WiX proporciona una implementación muy flexible de la configuración e implementación de IIS.
    • Espero que se usen muchas acciones personalizadas para lograr configuraciones de implementación especiales.
  • Ejecutar scripts de SQL Server contra bases de datos.
    • Cree db, conéctese a db, actualice db, ejecute procedimientos almacenados, tal vez incluso desencadene copias de seguridad o programe nuevas tareas, etc … No sé todo lo que la gente hace aquí.
    • ¿Debería hacerse esto en la aplicación en su lugar, o por un DBO? Eso parece mucho más confiable. Una configuración es “one shot”, se puede reiniciar una aplicación y volver a intentarlo: un mejor manejo de excepciones.
    • Además, una configuración de MSI tiene una GUI muy limitada severamente limitada debido al diseño general de MSI (los diálogos de Win32 adecuados se pueden generar a partir de la GUI de MSI limitada, pero requiere un gran esfuerzo; solo lo he hecho una vez).
    • Fundamentalmente, una configuración puede ejecutarse con derechos elevados , pero eso solo ocurre en la máquina local. La autenticación aún se necesita en la base de datos (a menos que se use la Autenticación de Windows).
    • Una actualización de base de datos es una transacción en sí misma que se ejecutaría como parte de la transacción general de Windows Installer. No es obvio cómo manejar los errores o qué hacer en términos de reversión si falla la instalación.
    • Huelga decir que esto puede ser muy complejo de manejar en su configuración. Es una tarea de configuración (empresarial) en mi opinión, no solo una tarea de implementación. Comentarios perspicaces muy bienvenidos sobre este tema – Estoy en la cerca con respecto a las mejores prácticas.
    • Si está entregando una solución cliente / servidor a sus clientes y necesita una forma de configurar las bases de datos (actualizadas en el servidor) “actualizadas” para ayudar a sus clientes a “ponerse en marcha” con su solución, entonces la implementación de la base de datos definitivamente tiene sentido yo. Pero las secuencias de comandos de actualización que se ejecutan como parte de la instalación dirigida a las bases de datos existentes me preocuparían en términos de confiabilidad y administración, sin mencionar la seguridad.
    • Para las actualizaciones de bases de datos corporativas, parecería que un proceso adecuado que involucra un DBO sería más seguro. Pueden ejecutar una copia de seguridad adecuada antes de que se apliquen las actualizaciones y, a continuación, se realiza una verdadera reversión si se encuentran problemas en UAT.
  • Instalar componentes del navegador ActiveX (certificado basado en el navegador).
    • La instalación de un archivo CAB firmado descargado de una página web (solo administrador, puede capturarse como un MSI para implementación masiva con derechos elevados).
    • Predeterminado para instalar en “C: \ Windows \ Instalaciones descargadas”.
    • Pueden surgir complicaciones si la versión en el archivo CAB difiere de la versión solicitada por la página web (desencadena las carpetas CONFLICT que se generarán a medida que las instalaciones sigan volviendo a ejecutarse).
  • Actualice y fusione archivos XML .
    • Avanzado porque (asombrosamente) no es compatible nativamente con Windows Installer .
    • Compatible con extensiones de WiX y herramientas de implementación de terceros.
  • Configure y controle los componentes COM + .
    • Nota técnica: he fallado varias veces para lograr esto correctamente con varias herramientas de terceros. Parece que hay una falta general de características requeridas.
    • Normalmente termino configurando manualmente la aplicación COM + y luego exportando una MSI desde la herramienta administrativa de Servicios de componentes que luego se usa para la implementación.
    • Este MSI exportado no es bueno en absoluto; es frágil si intenta realizar modificaciones. Contiene un archivo .apl no documentado con los atributos de la aplicación y cualquier DLL dependiente o archivos de datos no se incluyen automáticamente.
    • WiX proporciona soporte para COM + (no probado en absoluto por mí). Espero que sea bueno :-).
    • Solo como referencia: comprender la instalación de la aplicación COM + .
  • Agregue registros de eventos personalizados , configure monitores de rendimiento , agregue reglas de firewall y otras extensiones de Windows. Compatible con la mayoría de las herramientas de implementación en estos días, incluido WiX. Estas características no son compatibles de forma nativa con el motor de Windows Installer.
  • Configure las conexiones a los dispositivos móviles y despliegue.
    • Puede implicar “alguna extrañeza” y extrañas soluciones patentadas.
    • Es posible que se requiera una dll nativa personalizada para lograr una implementación fluida (Pocket PC de vuelta en el día; no estoy seguro de cómo funcionan las cosas en estos días).
  • Instale controladores de varios tipos.
    • Ahora es mucho más fácil y más confiable para los controladores firmados que antes.
    • Compatible con todas las herramientas de terceros y WiX (usando dpinst.exe en segundo plano).
  • Conexión de la aplicación a funciones avanzadas del servidor (implementadas por separado).
    • Sistemas de actualización automática .
    • Servidores de licencias Licencias flotantes o licencias regulares.
    • Recursos en línea de varios tipos. Ayuda, plantillas, debates, SDK, herramientas de desarrollador, etc.
    • Tiendas en línea .
    • La mayoría de las veces esto solo implica establecer un enlace o clave de registro para apuntar a los recursos del servidor, pero a veces es más complejo.

Agregar cosas muy avanzadas (acciones personalizadas)

  • Cuando no existe soporte integrado para una determinada operación o tarea en Windows Installer, o en cualquiera de las diversas herramientas de terceros disponibles, usted tiene que implementar la función usted mismo.
  • Cuando utiliza Windows Installer, esto implica ejecutar acciones personalizadas de varios tipos (mecanismo de Windows Installer para ejecutar ejecutables, lógica de instalación personalizada durante la instalación).
  • Las acciones personalizadas son ejecutables creados especialmente (binarios: dll, exe) y scripts capaces de realizar modificaciones avanzadas al sistema durante la instalación que no son compatibles con el instalador de Windows de forma nativa o con la herramienta de implementación en uso (WiX, Installshield, Advanced Installer, etc. ..).
  • Acciones personalizadas que hacen que las modificaciones en el sistema se ejecuten con derechos elevados para que se puedan realizar cambios en el sistema incluso si el usuario que inició sesión no tiene derechos de administrador. Básicamente, no hay límite para lo que estas acciones personalizadas pueden hacer. Ellos están armados y son peligrosos .
  • Las acciones personalizadas son las principales causas de fallas y errores de implementación .
    • Manos abajo. Si falla una instalación de MSI, generalmente está relacionada con una acción personalizada anómala.
    • Las acciones personalizadas son difíciles de escribir y depurar debido a la complejidad de Windows Installer. Se deben usar solo cuando sea necesario y se deben escribir con soporte completo de reversión para que sean capaces de deshacer todos los cambios que se aplicaron al sistema en caso de que el instalador falle y deba deshacer los cambios.
    • Este es un trabajo difícil y difícil y las acciones personalizadas son un problema grande, complejo y propenso a errores: una lata de gusanos.
    • A menudo, los cambios menores en el diseño de la aplicación pueden permitir que las acciones personalizadas sean reemplazadas por funciones MSI estándar o varias extensiones MSI disponibles en herramientas de terceros y en WiX.
    • Los ejecutables y las secuencias de comandos que se ejecutan correctamente por sí solos pueden fallar cuando se ejecutan como parte de una MSI debido a la suplantación compleja, la elevación y el diseño en tiempo de ejecución de Windows Installer. Estas no son cosas triviales para hacer bien. Una instalación de MSI es una transacción intrincada con secuencias elevadas y suplantadas que es muy difícil de tratar.
  • Tipos de acciones personalizadas
    • Windows Installer admite acciones personalizadas implementadas como archivos ejecutables y dlls nativos (win32), así como scripts como JavaScript o VBScript .
    • Algunos incluso usan binarios .NET (C #, VB.NET, DTF, etc.) para ejecutar acciones personalizadas; esto no es recomendable debido a su requisito previo de .NET Framework. Estos binarios se conocen como ” código administrado ” y no se pueden ejecutar sin el .NET framework correcto instalado.
    • Por último, hay acciones personalizadas de PowerShell que son scripts y código administrado combinados, y no deben utilizarse porque requieren el framework .NET.
    • En el futuro, cuando se pueda garantizar la existencia del framework .NET en todas las computadoras con Windows, este código administrado podría ser una opción viable para uso general, pero a partir de ahora el consenso parece ser que estas acciones son demasiado arriesgadas y poco confiables.
  • Acciones personalizadas comunes de ejemplo (algunas tareas comunes y personalizadas se implementan con frecuencia como acciones personalizadas porque Windows Installer no las admite de forma nativa, pero se necesitan con frecuencia).
    • Administre las Acciones de Windows (generalmente crea).
    • Aplique permisos de ACL personalizados (hay algo de compatibilidad con MSI incorporada para esto).
    • Modificar los privilegios de NT .
    • Configurar DCOM .
    • Administrar grupos y usuarios .
    • Configurar complementos de Office por usuario.
    • Persistir las propiedades del instalador (para reparar y reinstalar).
    • Condiciones de lanzamiento específicas de la empresa y personalizadas.
    • Redireccionamientos de configuración de IP para IIS
    • Encriptar u ofuscar contenido para la seguridad de los datos
    • Etc …
  • La mayoría de las funcionalidades personalizadas mencionadas anteriormente ahora están disponibles en el marco de WiX como un dll personalizado de C ++ , y otras herramientas tienen características personalizadas similares. Siempre debe preferir estas soluciones preparadas para sus propias acciones personalizadas, ya que Rollback se implementa correctamente en WiX y la implementación está bien probada.
  • La aplicación de los permisos de ACL personalizados y la modificación de los privilegios de NT se consideran ” antipatrones de implementación ” por parte de la mayoría de los especialistas en implementación. El requisito de hacerlo indica un diseño de aplicación deficiente (flojo).
  • Resumen de acción personalizado .
    • Escribir una acción personalizada por su cuenta debe ser un evento raro que sea único y que no se haya realizado antes (mejor).
    • El rediseño de las aplicaciones menores a menudo puede eliminar construcciones de implementación poco inteligentes y complejas. De hecho, casi siempre.
      • Por ejemplo: la configuración de la aplicación debería ocurrir en el primer lanzamiento de la aplicación, y no durante la configuración.
      • La configuración debe preparar la aplicación para el primer lanzamiento y realizar tareas que requieren derechos elevados (solo).
      • La inicialización de los datos del usuario es particularmente malo para usar scripts de configuración para realizar. Todo esto debe hacerse en la secuencia de inicio de la aplicación.
    • Debería hacer cumplir el soporte correcto de reversión .
      • Este es un trabajo complejo y duro.
      • Casi todas las acciones personalizadas de script que he visto no implementan la reversión en absoluto.
    • Debe escribir con dependencias mínimas .
      • Preferiblemente use C ++ o Installscript o tal vez JavaScript (solo para implementación interna y corporativa en mi opinión). Evite VB Script y definitivamente evite el código .NET en los scripts C # / DTF o PowerShell . Existe alguna discusión sobre el tema del código administrado. Expertos de MSI como Chris Painter creen que las acciones personalizadas de C # / DTF están listas para el horario de máxima audiencia, mientras que el consenso general parece ser de prudencia y confiar en los dlls de C ++ hasta que se garantice un entorno de tiempo de ejecución .NET apropiado. Aquí hay una “discusión” prolija de este problema: Windows Installer falla en Win 10 pero no en Win 7 usando WIX
      • El código robusto es difícil de escribir en el script . Los scripts son frágiles, difíciles de depurar, carecen de funciones avanzadas de lenguaje (especialmente manejo de errores) y son vulnerables al locking de antivirus.
      • Las únicas ventajas reales de los scripts son que son transparentes e inspeccionables y que toda la fuente está integrada en el archivo MSI (sin problemas de control de versiones). Los equipos corporativos que se reparten el trabajo entre sí con frecuencia pueden usar JavaScript (también hay mucho uso del Script VB heredado, pero ese lenguaje es muy pobre para el manejo de errores).
      • El código administrado tiene requisitos de tiempo de ejecución que no se pueden garantizar en el momento de la escritura, y esta es la situación desde hace mucho tiempo.
      • PowerShell es código administrado y script. Evítalo. Installshield lo admite como un tipo de acción personalizada. Queda por ver qué tan exitoso será. Nunca lo usaría a menos que me obligaran.
  • Y mucho más…

Complicaciones adicionales para la implementación

Existen muchas complicaciones adicionales al brindar una configuración profesional, como entregar configuraciones en diferentes idiomas (localización), configuraciones de marca para diferentes revendedores ( OEM ), asegurar que la configuración funcione en todos los sistemas operativos requeridos en diferentes idiomas , entregando configuraciones separadas para x86 y x64 máquinas, entregando una versión reducida de “viewer” de la aplicación, haciendo configuraciones combinadas para instalaciones de clientes y servidores (puede ejecutarse tanto en el servidor como en el cliente instalando diferentes componentes – no recomendado si me preguntas – detalles ), y no mencionar la implementación en diferentes dispositivos integrados como teléfonos, pocket PC, teléfonos inteligentes, etc.

Ciertos ” Antiaplazamientos de implementación ” también son problemáticos de tratar (la respuesta vinculada es un “experimento” y no estoy muy contento con ella, un trabajo en progreso, pero pretende ser una lista de verificación para los desarrolladores por sus esfuerzos de implementación). para evitar problemas realmente comunes). Estas son malas construcciones necesarias en las configuraciones para que las aplicaciones mal diseñadas se ejecuten correctamente . Incluyen cosas como aplicar permisos personalizados (acceso de escritura en rutas bloqueadas, etc.), personalizar privilegios NT (normalmente “ejecutar como servicio” para una cuenta de usuario, o mucho peor), o aplicar un uso excesivo de personalizaciones complejas acciones que hacen cambios impredecibles en el sistema (estos pueden ser cualquier cosa y ser muy peligrosos). Desordenar la instalación silenciosa también es un problema enorme y común: es terrible para el uso corporativo de su configuración. Desplegar cantidades excesivas de datos específicos del usuario con su configuración también puede ser problemático (complicaciones difíciles de controlar). Y hay muchos otros problemas más específicos para relacionarse.

Aquí hay una publicación con el problema general de configuración e implementación visto en el contexto más amplio de marketing y ventas de aplicaciones.

Hacer su propia implementación

Necesitará una herramienta o un marco para entregar sus propias configuraciones. Aquí hay una respuesta que describe diferentes herramientas utilizadas para crear instaladores: ¿Qué producto de instalación usar? InstallShield, WiX, Wise, instalador avanzado, etc. Se han hecho todos los bashs para que las descripciones sean lo más objetivas posible, describiendo la experiencia del mundo real con aspectos positivos y negativos.

Las herramientas comerciales descritas en el enlace anterior son herramientas excelentes, y tienden a acelerar las cosas con buenas GUI y soluciones listas para requisitos comunes, pero los desarrolladores deben considerar probar WiX , la nueva forma de crear archivos MSI . Lea esta publicación para obtener información básica: Windows Installer y la creación de WiX ( léalo si está tratando de ” encontrar sus pies con WiX ” y quiere entender de qué se trata la tecnología y de dónde viene).

WiX tiene una curva de aprendizaje pero es ” amigable para el desarrollador ” de muchas maneras. Para uno, es un tipo de proyecto en Visual Studio (una vez que lo instale), y permite que una configuración se defina en XML y se compile en MSI como lo haría con un binario normal. Esto permite un control de fuente adecuado , ramificación y colaboración. Además, es gratis y de código abierto. Siento que está bien recomendar un marco libre, especialmente porque está bien mantenido. Sin embargo, espera una experiencia de aprendizaje. Aquí hay algunas sugerencias para un “buen comienzo” con WiX .

Muchos progtwigs hacen uso de gráficos, sonido y otros controladores que son suministrados y mantenidos por terceros. En muchos casos, estos controladores pueden usar hardware subyacente u otras características del sistema de forma que Windows mismo no sabe nada. Si dos progtwigs, cada uno con su propio controlador e inconsciente de la existencia del otro, intentaran usar el mismo hardware, probablemente interferirían entre sí de maneras impredecibles e indeseables (por ejemplo, uno podría sobreescribir texturas gráficas cargadas por el otro). Para evitar estos problemas, Microsoft recomienda que las aplicaciones instalen controladores de tal manera que los dos progtwigs que necesitan el mismo controlador puedan compartir la misma instancia del controlador.

El enfoque que adopta Microsoft no es el único medio de garantizar que múltiples progtwigs que utilizan el mismo hardware pasen por el mismo controlador. Un sistema también podría tener progtwigs que carguen temporalmente los controladores cuando se inician y que los controladores descarguen automáticamente cuando terminen. La dificultad con este enfoque es que si se lanza un progtwig que usa un controlador anterior y mientras se ejecuta un progtwig que necesita una versión más nueva de ese controlador, el nuevo progtwig no podrá ejecutarse a menos que o hasta que el viejo progtwig apaga su controlador y cambia a usar uno nuevo. Tal inconveniente es probablemente inevitable, pero tener que lidiar con tales cosas cada vez que se lanza un progtwig es probablemente menos molesto que lidiar con él solo una vez cuando se instala un progtwig.

Dicho todo esto, si bien puede ser útil poder instalar un progtwig una vez y tener todos los problemas del “controlador” resueltos de una vez por todas, también hay algo que decir para poder simplemente ejecutar un progtwig sin tener que para hacer modificaciones “permanentes” al sistema. No debería haber ningún obstáculo particular para que los progtwigs puedan usar controladores “temporales” o permanentes, pero no conozco ningún esfuerzo particular para facilitar dichos diseños.

Además de copiar los archivos para Usted, el instalador también puede agregar entradas de registro necesarias para el progtwig (si corresponde), agregar valores a las variables de entorno (RUTA), crear icons en el escritorio, por lo que no tiene que hacer esto manualmente, etc.

Para citar Wikipedia, “La instalación generalmente implica que el código se copie / genere desde los archivos de instalación a nuevos archivos en la computadora local para un acceso más fácil por el sistema operativo”. Para progtwigs simples, no hay necesidad de instalar nada, pero los más complejos pueden actualizar, agregar enlaces, etc. de manera automática si están instalados.