Instalador con registro en línea para la aplicación de Windows

Hemos desarrollado un software en vb.net utilizando Visual Studio 2013. Ahora queremos construir un instalador personalizado con los siguientes pasos / características:

  1. Usuario Comience a instalar nuestro software.
  2. En la opción ‘Ingresar clave serie’, el usuario ingresa la serie de 16 dígitos que le hemos proporcionado.
  3. Al hacer clic en el botón ‘Aceptar’, nuestro software se conecta a nuestra IP y guarda la clave en serie con la información de otro usuario en nuestra base de datos.
  4. Se devuelve una clave de confirmación a nuestro software.
  5. El software escribe un archivo y lo guarda en la carpeta del sistema.

Es casi como el proceso de registro de Adobe o Corel. También estamos abiertos a otras técnicas que deben asegurar que nuestro software se debe instalar en una sola máquina. Tenga en cuenta que somos un grupo de progtwigdores novatos (nivel no tan avanzado), entonces; si el proceso se elabora, será muy útil para nosotros.

Quitaría todas las características de licencia de la configuración y las agregaría a la aplicación . Su configuración aún puede escribir una licencia en el disco o en el registro pasando a msiexec.exe como una propiedad pública – MAYÚSCULAS propiedades (o puede “ocultar” las cosas un poco más mediante el uso de una transformación para aplicar la propiedad en serie – tiene exactamente el mismo efecto que establecer la propiedad en la línea de comando). También puede establecer la propiedad LICENCIA desde un diálogo en la configuración cuando se ejecuta de forma interactiva , pero mi enfoque favorito es permitir agregar la clave de licencia no validada al registro en modo de implementación silenciosa y, en su lugar, ingresar la clave de licencia directamente en la aplicación , y no la configuración, para implementaciones interactivas (la descripción anterior es para implementación silenciosa):

msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" LICENSE="123-456-789" 
  • Esto permitirá que la licencia se agregue fácilmente a cada máquina en un escenario de implementación corporativa . El valor de la licencia simplemente se escribe en el disco o registro sin validación. La aplicación lo verificará (más seguro que un dll de validación en la configuración).
  • No hay necesidad de meterse con ningún diálogo de configuración complejo , pero necesitará un diálogo de licencia en su aplicación como se explica a continuación.
  • Como desarrollador de instalación, debe ofrecer ayuda para implementar la característica en la aplicación en lugar de la configuración, por lo que no parece ser un caso de ” pasar el dinero “. Esto es todo por la fiabilidad general del software y la infalibilidad , y varias razones se enumeran a continuación.
  • Casi todas las grandes corporaciones despliegan archivos MSI en silencio , por lo que la GUI de configuración será ignorada la mayor parte del tiempo de todos modos. Entonces, simplemente está agregando riesgo y desperdiciando recursos si maneja las licencias en la configuración .
  • Un inconveniente : una aplicación que se ejecuta como un usuario que no es administrador después de la instalación no puede escribir en HKLM para compartir una serie entre todos los usuarios en la computadora (una configuración que se ejecuta con derechos elevados puede). Debe escribir en HKCU o la configuración debe tener preparado el acceso de escritura a una ubicación HKLM específica en el registro para que la aplicación escriba. Prefiero escribir a HKCU para cada usuario ya que la licencia está menos disponible para copiar por otros, y se guarda como datos específicos del usuario (permite el roaming, aunque es una característica odiada por la mayoría de los profesionales de TI). Sin embargo, una clave de licencia HKLM escrita por la aplicación o la configuración durante la instalación (como se explicó anteriormente con un conjunto de propiedades públicas) permite a todos los usuarios compartir una licencia al iniciar la aplicación.

Existen varias razones más concretas para mantener el manejo y la validación de la licencia fuera de su configuración:

  • Una gran cantidad de solicitudes de soporte siempre resultan de personas que tienen problemas para registrar sus claves de licencia en la configuración. Una configuración se ejecuta una vez, una aplicación puede reiniciarse si hay problemas . Esto es más importante de lo que piensas para usuarios inexpertos. También tiene mejores características disponibles para manejar excepciones y condiciones de error y cualquier problema inesperado que pueda ocurrir en la aplicación.
  • La validación en serie en la configuración expone un dll / método de validación que piratean fácilmente. No evitarás la piratería eliminándola de tu configuración, pero al menos la harás más difícil. Es más seguro en la aplicación si oculta un poco las cosas (enlace estático, cifrado, ofuscación, poner el proceso de validación en línea y / o lo que sea hecho por profesionales de la seguridad con los que no estoy familiarizado).
  • Permitir la versión de prueba de la aplicación : si la configuración necesita una versión de prueba de la aplicación , debe permitir que el usuario ingrese una clave de licencia si termina comprando el producto, preferiblemente sin tener que volver a ejecutar la configuración o desinstalar / reinstalar solo para agregar la clave de licencia. En otras palabras, es probable que necesite lidiar con la licencia en su aplicación de todos modos, ¿por qué complicar su configuración también? Más riesgo, más control de calidad, más solicitudes potenciales de soporte y potencial para múltiples soluciones necesarias tanto en la configuración como en la aplicación. ¿Alto costo total?
  • Si su aplicación se ejecuta con diferentes ediciones , ¿qué sucede si el usuario compra una licencia actualizada ? Solo deberían poder ingresar al cuadro de diálogo de licencia y desbloquear funciones, si es posible, y no desinstalar y volver a instalar con todo el ruido que esto implica. Sin embargo, para algunas actualizaciones esto es difícil de lograr, y a menudo terminas con configuraciones separadas para diferentes ediciones.
  • Si la red está utilizando un servidor proxy para el acceso a Internet , tendrá problemas para registrar la licencia a través de Internet durante la instalación (a menudo solicitada por marketing). Usted tiene más características para verificar y tratar esto en la aplicación; puede volver a intentarlo y esperar el acceso (generalmente, si lo puede conectar a IE para una configuración automática de proxy). Para la implementación corporativa, también necesita una opción de instalación silenciosa que no valida la clave sino que simplemente la escribe en el registro. Intentar acceder a Internet desde una instalación silenciosa de un MSI es, en mi opinión, un anti-patrón de despliegue bastante extremo . También me parece dudoso en la GUI de configuración. Realice el registro en la aplicación, mucho menos controvertido, y puede configurar reglas de firewall para permitirle el acceso a Internet (es probable que msiexec.exe esté bloqueado, y por una buena razón). También podría haber firewalls de hardware y / o software de seguridad con los que lidiar, lo que hace que el acceso a Internet sea difícil o incluso imposible sin una configuración de servidor administrativo torpe. Esto podría matar la consideración de su software, según mi experiencia : ” Solo sáquelo de nuestra red y estado de las aplicaciones; deben existir mejores opciones, demasiado torpe y propenso a errores “.
    • ACTUALIZACIÓN : A medida que la tecnología de implementación madure y se vuelva más “basada en Internet”, esta “verdad” puede cambiar, y podríamos terminar haciendo todo “en línea” con una implementación diseñada específicamente para ejecutarse a través de “repositorys” en línea, por ejemplo. Tendremos que esperar y ver. Por ahora, mi opinión es que cualquier requisito de configuración de acceso a Internet es erróneo e indeseable.
  • Es posible que, en ocasiones, los ajustes que afectan a las licencias provoquen que los datos de licencia se eliminen durante las actualizaciones , los parches y los escenarios de migración debido a errores en la configuración. Esto es mucho más serio a veces de lo que se podría pensar: el paquete podría llegar a miles de estaciones de trabajo en grandes compañías y ser complicado de arreglar.
    • Existe un ” patrón de protección ” bastante malo en la tecnología MSI en sí misma por el cual la reparación automática o la reparación activada manualmente restablecerán los valores en el registro que la aplicación ha modificado. Esto puede borrar las claves de licencia. Vemos esto todo el tiempo, y es culpa de la tecnología. Simplemente no es lógico en esta área.
    • Hay algunas soluciones, o más bien soluciones, para esto (usar un componente permanente, escribir una licencia de una acción personalizada en lugar de un componente, etc.), pero las encuentro bastante torpes y tienes que tener mucha experiencia para conocer todos los peligros, e incluso los usuarios experimentados lo estropean.
  • La licencia es un gran dolor de cabeza corporativo : a menudo lo que desean las compañías o corporaciones es que las licencias se administren centralmente en un servidor y no se basen en números de serie de texto (por ejemplo, licencias simultáneas o flotantes adquiridas al lanzar la aplicación a través de la red) . Solo mencionar esto, aunque está fuera del scope de la pregunta. En estos casos, lo que usted especifica durante la instalación generalmente es una dirección IP que apunta al servidor de licencias, o simplemente un nombre de host regular que WINS o DNS debe resolver.

Como ya habrás adivinado, Windows Installer no proporciona ninguna función de caja para administrar licencias. Pero existen soluciones de licencias comerciales a las que puede acceder si es asequible.

  1. LogicNP
  2. DESAWARE

Dado que esta es una pregunta muy amplia, es difícil explicar detalles de implementación de bajo nivel. Puedo darte una dirección.

En primer lugar, necesitará una interfaz de usuario personalizada donde el usuario pueda escribir la clave de licencia / activación. Hay formas de incorporar una interfaz de usuario personalizada en el instalador de Windows, ya he explicado algunos enfoques en SO, consulte los siguientes temas.

  • Mostrar formulario personalizado durante la instalación
  • Cómo agregar una ventana personalizada adicional a los flujos de IU de los proyectos de configuración de VS

Al seguir los enfoques anteriores, debe poder agregar una IU donde el usuario escriba una clave. Una vez que el usuario haya agregado la clave, presionará el botón Activar en la interfaz de usuario personalizada. El controlador de evento de clic de botón invocará la lógica necesaria para Insertar / Validar la clave de activación ingresada por el usuario.

Tal vez podrías probar Inno Setup, que es un sistema de instalación gratuito (incluso de código abierto).

¡Está basado en un script que te permite sintonizar tu instalador y realizar en él todo!

Crear página personalizada con ingresar el número de serie es realmente fácil, vea este ejemplo: CustomPage for Serial Number in Inno Setup

y también hay integración para Visual Studio.