c# windows wix windows-installer profiles

c# - Crear carpeta y archivo en el perfil de usuario actual, desde el perfil de administrador



windows wix (3)

No cree el archivo de configuración en la instalación, verifique y vea si existe en la ejecución del programa; si no, créelo en la carpeta de perfil de usuarios en ejecución. Si existe, utilice los datos que contiene y continúe.

Nuestro cliente solo permite la instalación de aplicaciones cuando inicia sesión como administrador. La aplicación que debe instalarse debe instalarse para el usuario actual de la máquina. La aplicación se instala bien, mi problema surge cuando necesito colocar un archivo de configuración en la carpeta appdata / user profile del usuario. Como aquí es donde lo quieren, actualmente la configuración se descarta en el perfil de administrador en la instalación. ¿Cómo puedo superar esto? ¿Hay alguna manera de verificar la instalación si hay otros perfiles y tal vez escribirles, pero esto se siente sucio?

Puede hacer que esto funcione con la función de reparación. El panorama general es que el archivo se instaló para un usuario en el momento de la instalación en una ubicación de perfil de usuario, y en una instalación por sistema que significará que faltará el archivo cuando otro usuario inicie sesión para usar la aplicación. Depende de la estructura de los componentes, características y accesos directos de MSI, pero iniciar la aplicación con un acceso directo anunciado puede hacer que el archivo faltante se instale con una reparación automática. Obviamente, esto requiere que la fuente MSI permanezca disponible.

Sin embargo, la forma más segura de instalar el archivo para cualquier usuario nuevo es llamar explícitamente a MsiProvideComponent pase el ProductCode del MSI, el nombre de la función, la identificación del componente, etc., tal como se describe en la documentación. Como dicen los documentos, esto instalará el componente si falta, y nuevamente requerirá que el MSI de origen esté disponible.

Esta funcionalidad trata el caso en el que hay cuentas de usuario que aún no se han creado, por lo que, obviamente, aún no puede colocar archivos en sus carpetas de perfil.

Si es el mejor enfoque en comparación con otros dependerá de los detalles específicos de la aplicación.

Simplemente resumiré lo que otros han mencionado básicamente, desarrollando un poco las cosas tratando de hacer una "pequeña referencia".

Tal vez eche un vistazo a la mención de la función de protección de ransomware Win10 a continuación para obtener un dato importante sobre cómo este cambio de Windows puede afectar la implementación de archivos de perfil de usuario .

ENFOQUES COMUNES

  • Hay muchas formas de implementar los archivos en cada computadora en cada usuario, pero hay muchos inconvenientes y problemas con la mayoría de los enfoques. Con toda honestidad, hay problemas con todos los enfoques, de una forma u otra.

  • A continuación hay una lista de algunos enfoques de implementación comunes primero, y luego una mención de algunos "enfoques basados ​​en la nube". En el futuro, esta discusión puede volverse irrelevante ya que la configuración se basa completamente en la nube y se sincroniza sobre la marcha y la implementación puede cambiar completamente de una implementación por máquina a otra por usuario. Tendremos que esperar y ver cómo resulta.

    • 1: Plantilla por máquina

      • Instale el archivo de configuración en una ubicación por máquina que sea legible para todos los usuarios, luego copie el archivo desde allí y póngalo en el perfil de usuario al iniciar la aplicación utilizando la aplicación para hacer el trabajo de copia una vez por usuario.
      • Este es el enfoque recomendado. Incluso puede actualizar su aplicación con lógica para aplicar actualizaciones por usuario si necesita utilizar un enfoque como este: http://forum.installsite.net/index.php?showtopic=21552 .
      • Siempre se ejecutará en el contexto de usuario correcto cuando se realice la copia, y no tiene que preocuparse por la complejidad de la suplantación, el condicionamiento y la secuencia de MSI.
      • Una buena ventaja de este enfoque es que funcionará incluso si falta la fuente de instalación (MSI) en el momento del inicio de la aplicación.

    • 2: Crear archivo al iniciar - "Valores predeterminados internos"

      • Como sugiere gilliduck, simplemente cree el archivo de configuración en el inicio utilizando los valores predeterminados internos de la aplicación y no instale el archivo en absoluto . Ocurre una vez por usuario, a partir de entonces usa el archivo que está allí. Mantener dicho archivo fuera de su instalador significa que elimina el riesgo de que el instalador lo sobrescriba o desinstale accidentalmente.
      • La pregunta obvia es por qué necesitaría un archivo de este tipo, si puede crearlo a partir de valores predeterminados internos. Obviamente, la respuesta es que es posible que desee aplicar algunos valores específicos que son únicos para el entorno del usuario una vez que se crea el archivo. Sin embargo, ¿configuraciones como estas también podrían guardarse en el registro?
      • Puede establecer la configuración personalizada en cuestión en la sección HKLM del registro a través de PUBLIC PROPERTIES durante la instalación (configurable por el usuario en la línea de comandos o mediante una transformación, consulte: Cómo hacer un mejor uso de los archivos MSI para obtener información sobre esto), y hacerlos cumplir para todos los usuarios en el lanzamiento de la aplicación; en otras palabras, escribirlos en HKCU. ¿O podría simplemente mantener la configuración "solo lectura" en HKLM y aplicarla a todos los usuarios de esa manera en su aplicación? (ajustes configurables que no son de usuario, como el nombre de un servidor de red o similar).
      • Todavía puede usar el método del enlace anterior para aplicar actualizaciones a los archivos de configuración existentes en el inicio de la aplicación haciendo que su configuración escriba un indicador en HKLM para notificar que una implementación ha "ocurrido" desde el último lanzamiento.
      • O, como se indicó, en su lugar, use el registro para mantener la configuración.
      • Cómo leer el archivo de texto de recursos incrustado

    • 3: MSI Self-Repair

      • Coloque el archivo de configuración en su lugar por usuario utilizando la reparación automática de MSI . Esto sucede al invocar un punto de entrada anunciado , como un acceso directo anunciado utilizado para iniciar la aplicación.
      • Requiere acceso a la fuente de instalación en el momento de la reparación. Asegúrese de guardar en caché su archivo MSI en la caja.
      • La reparación automática puede no funcionar en los servidores de Terminal Server (función deshabilitada). Han pasado años desde la última vez que probé esto. No estoy seguro de cómo se configuran los servidores fuera de la caja en estos días.
      • A menos que esté configurado para no hacerlo, la desinstalación puede desinstalar el archivo de configuración para el usuario que ejecuta la desinstalación real o, críticamente, esto puede ocurrir durante una actualización importante (que es realmente una desinstalación y reinstalación de su producto). En otras palabras: establezca el componente de forma permanente (y nunca sobrescriba), o su archivo puede aparecer sobrescrito durante la actualización (pero realmente se desinstala y reinstala).
      • Para la configuración del registro HKCU, no necesariamente necesita tener la fuente de instalación disponible. Verifique la explicación de Stefan Kruger : http://www.msifaq.com/a/1011.htm . El procedimiento es el mismo para activar la instalación de archivos de perfil de usuario (pero luego se necesita la fuente de instalación). Una discusión asociada, en caso de que sea útil .
      • Aunque no lo he probado, he considerado establecer un valor de ruta de clave de registro en: HKCU/Software/MyCompany/MyApplication/Version/HKCU_KeyPath = [ComputerName] para hacer que el valor de la ruta de clave sea un "objetivo móvil" para que la reparación automática sea se activa de manera confiable cuando el usuario inicia sesión en una computadora nueva (a pesar de que los perfiles móviles tienen la configuración HKCU existente).
      • Como dije, no se ha probado ya que prácticamente he abandonado este enfoque, ya que es menos confiable depender de cada nueva actualización de Windows. Algo extraño cambia cada vez, con resultados impredecibles.
      • Aunque no está 100% relacionado, puedo mencionar la nueva característica de protección contra ransomware en Windows 10 como ejemplo: parece causar errores de tiempo de ejecución intermitentes para cualquier MSI que intente escribir en las carpetas de datos del usuario. Queda por ver cuántos problemas de implementación resultarán, mientras vemos resultados intermitentes hasta ahora, ¿qué sucederá cuando y si activan la función por defecto?
      • Y, en la misma línea que anteriormente, el software de seguridad de terceros también proporciona obstáculos para la implementación al bloquear ciertas actividades del sistema de archivos y poner en cuarentena los archivos que están marcados por alguna razón (incluidos los falsos positivos), lo que provoca una reparación automática que nunca puede completarse, pero se mantiene corriendo en vano
      • Como breve resumen , aquí hay algunas razones por las cuales se vuelve cada vez más útil evitar la implementación de archivos de perfil de usuario a través de la reparación automática:
        • Complicaciones del perfil itinerante .
        • Protección contra ransomware característica de interferencia .
        • Interferencia de software de seguridad (particularmente falsos positivos de malware).
        • Restricciones de Terminal Server en la reparación automática .
        • El restablecimiento de datos o la configuración desinstalan problemas durante la actualización principal .
        • Tal vez tenga la misma sensación que yo tengo: hay más, y seguirá empeorando.
        • Mis dos centavos : hable con su gerente de inmediato sobre una mejor administración de archivos de datos para su aplicación y abandone todos los intentos de ser "inteligente" durante la implementación. Implemente por archivo de máquina solo con MSI, si es posible.
        • En el futuro, esta preferencia puede cambiar a medida que la tecnología de implementación cambie y las instalaciones se realicen solo por usuario (tal vez).
        • Una descripción más larga del problema escrita anteriormente: ¿Por qué es una buena idea limitar la implementación de archivos al perfil de usuario o HKCU cuando se usa MSI?
        • Y toda una conversación desordenada sobre problemas de implementación en general : ¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI?

    • 4: Configuración activa ( ya no se recomienda, por favor lea )

      • Coloque el archivo de configuración en su lugar utilizando la Configuración activa . Esto ocurre en el inicio de sesión del usuario (que luego requiere un cierre de sesión y un inicio de sesión para que ocurra a menos que se asegure de que el archivo también esté instalado en el perfil de usuario actual en la instalación).
      • Esto es, en efecto, una variación del enfoque 1. Debe instalar el archivo de configuración en una ubicación por máquina, legible por todos los usuarios.
      • Luego registra una tarea en el registro para ejecutar "algo ejecutable" una vez por usuario. Puede ejecutar cualquier cosa, como un archivo por lotes, un archivo ejecutable, un script o mi reparación MSI de enfoque preferido que logrará colocar el archivo de perfil de usuario en su lugar (en este caso, no necesita un archivo en una ubicación por máquina, pero acceda a la fuente de instalación mientras se ejecuta Active Setup).
      • Tenga cuidado de no sobrescribir un archivo de configuración establecido durante la instalación para el usuario actual. O deshabilite la ejecución de Active Setup para este usuario escribiendo la clave HKCU que se escribe después de que Active Setup se haya ejecutado para el usuario en cuestión (consulte el enlace a continuación).
      • El procedimiento se intenta explicar en mi respuesta aquí: Actualizar el registro de cada perfil en Windows Server 2003 . Todo se basa en una clave HKLM que se ejecuta una vez por usuario. Verifique la respuesta vinculada para obtener detalles, y hay algunos enlaces externos que proporcionan muchos más detalles.
      • ACTUALIZACIÓN : Al instalar en Terminal Server, coloca el servidor en "modo de instalación" y luego las entradas de registro por usuario se escriben en HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Terminal Server/Install y luego se escriben en la sección HKCU de cada usuario cuando inician sesión. Esto puede entrar en conflicto con ActiveSetup, por lo que sé. Nunca he tenido la oportunidad de probarlo. El empaquetado para Terminal Server generalmente lo realiza un equipo de servidores especializado y dedicado.

    • 5: MsiProvideComponent

      • El componente MsiProvideComponent de Phil es interesante, nunca lo he usado. Yo debería.

ENFOQUES DE ESTILO EN LA NUBE

  • Con el almacenamiento de datos aparentemente en movimiento hacia la nube, los enfoques comunes para la implementación de archivos de datos pueden quedar rápidamente obsoletos.

    • 6: Descargue el archivo de configuración

      • Descargue el archivo de configuración , una vez para cada usuario al iniciar la aplicación, desde una base de datos / recurso compartido de red local o desde Internet , si es una opción.
      • El administrador puede mantener el archivo remoto para actualizar los valores si hay nuevos valores predeterminados o si es necesario eliminar algo.
      • Los mecanismos de configuración en el archivo de configuración comprendido por su aplicación podrían forzar la aplicación de nuevos valores "forzados" para todos los usuarios.
      • ¿Permitir la configuración de una lista de servidores en HKLM? Configurable en el MSI a través de PROPIEDADES PÚBLICAS ?
      • O establezca una única URL en su configuración durante la instalación y mantenga una lista de servidores a través de esa URL (redirige a qué servidor apunta a través de DNS, por lo que la configuración es una tarea de administrador de sistemas sin necesidad de volver a implementarla). Selección actual establecida en HKCU.

    • 7: Configuración de lectura / escritura desde la base de datos remota

      • Leer / escribir configuraciones directamente a / desde una base de datos local de AD o Internet continuamente en su lugar.
      • ¿No hay ningún archivo de configuración local o una copia en caché de solo lectura para cuando no se puede acceder al servidor? ¿O simplemente se ejecuta con los valores predeterminados de la aplicación interna si no se puede acceder al servidor? No hay ningún archivo para administrar en este último enfoque.
      • Puede escribir una lista de servidores (URL) para usar en HKLM (¿incluso mediante una política de grupo?) E incluso mantener el servidor seleccionado actualmente en HKCU para cada usuario. Entonces el resto sucede en línea.
      • Generalmente se usa en aplicaciones corporativas cliente / servidor hasta ahora, pero las plataformas basadas en la nube cambiarán la implementación para siempre, especialmente para los usuarios domésticos. Hemos visto navegadores que conservan la configuración a través de Internet durante mucho tiempo (Chrome, Opera, Firefox, etc.).
      • El almacenamiento remoto de la base de datos significa que puede mantener la configuración del usuario como una tarea de administración de la base de datos e incluso puede versionar los datos del usuario en la base de datos y aplicar fácilmente nuevos valores predeterminados o forzar la actualización de los valores existentes para todos los usuarios como una tarea DBO centralizada .
        • No más problemas molestos con el perfil de roaming.
        • No más despliegues fallidos de archivos de perfil de usuario.
        • En resumen: no hay ninguna configuración de usuario para implementar, y los datos nunca se perderán de sincronización en diferentes máquinas.
        • ¿Problemas de firewall / proxy y conectividad de red?

Resumen

Ya no me gusta la opción 3 (Auto reparación) y la opción 4 (Configuración activa), aunque las he usado muchas veces, y funcionan cuando se hacen correctamente. Sin embargo, no son inmunes a los problemas de perfil móvil (los archivos no se copian en todos los sistemas en los que el usuario inicia sesión) y carecen de acceso a la fuente de instalación de MSI cuando se está ejecutando la reparación, lo que puede causar problemas de implementación. También hay complicaciones frecuentes durante las actualizaciones importantes con la configuración de reinicio, y la auto reparación falla en los servidores de terminal. La reparación automática podría fallar para la instalación en el perfil de usuario debido a la protección del ransomware o la interferencia del software de seguridad. La línea de comando especificada en la opción 4 (Configuración activa) podría tener errores y borrar datos (por ejemplo, habilita el indicador incorrecto para la reparación de msiexec.exe y fuerza la sobrescritura del archivo de configuración por accidente; esto a menudo no se descubre hasta que también es tarde y el daño está hecho). Y hay otros problemas que se me escapan en este momento. Ambos enfoques tienen limitaciones similares, pero ligeramente diferentes.

Prefiero cada vez más los enfoques basados ​​en la nube para hacer que los archivos de configuración de usuarios locales (y aislados) sean cosa del pasado, pero rara vez he podido implementar cosas de esta manera. Sin embargo, estos enfoques en la nube pueden enfrentar problemas con el firewall / proxy y problemas de conectividad de red , y probablemente varias otras cosas que aún no conozco (ahora los desarrolladores discutirán con DBO en lugar de especialistas en implementación, etc.) ;-)). La informática distribuida tiene sus falacias: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing . Además: en los enfoques basados ​​en la nube, puede ser una buena idea que las aplicaciones permitan hacer una copia de seguridad de la configuración en el disco, por lo que obviamente todavía se necesita algo de administración de archivos, ¿o simplemente exporta un par de tablas de base de datos? Además: si instala una versión de prueba de su aplicación, es posible que desee que funcione sin conectividad de red, en caso de que el usuario esté detrás de un firewall muy ajustado. Es un error muy costoso cometer no permitir que su usuario pruebe las características de su aplicación debido a un tecnicismo.

El gran beneficio de las opciones 1 y 2 es que funcionarán incluso si faltan los medios de instalación originales cuando se inicia la reparación. Esto es particularmente importante para la implementación en el hogar y en la pequeña oficina, donde la implementación puede ocurrir de manera bastante casual sin un paquete compartido centralizado. Puede solucionar este problema (MSI de origen faltante) mediante el uso de métodos de almacenamiento en caché para almacenar en caché todo el MSI en el sistema durante la instalación (disponible en Installshield, no he verificado WiX o Advanced Installer).