2009-11-27 8 views
5

Tengo una aplicación (32 bit C++) ejecutándose bajo XP que necesito adaptar para ejecutar bajo Windows 7 y Vista. Necesita almacenar unas pocas docenas de bytes de datos en algún lugar independiente del usuario. En XP, almacené los datos en el registro en HKEY_LOCAL_MACHINE \ Software. Cuando ejecuto la aplicación en Windows 7, las entradas del registro se virtualizan y cada usuario obtiene una copia separada de los datos.windows 7: ¿dónde y cómo puedo almacenar datos independientes del usuario de la máquina?

El registro no virtualizado parece un lugar lógico para los datos, pero no tengo idea de cómo hacerlo. Observo que hay una multitud de aplicaciones que realmente almacenan datos allí; ¿cómo lo hacen?

También estoy dispuesto a almacenar los datos en otro lugar, ¿hay algún repositorio global bien conocido para ello? Un solo archivo pequeño es todo lo que necesito.

Soy más o menos ignorante de todo el negocio de los derechos/privilegios, por lo que cualquier sugerencia, consejos, etc. es muy apreciada.

+0

¿Podría proporcionar más información acerca de estos datos? ¿Se escribe una vez durante la instalación y nunca cambia después? ¿Podría cambiar en cualquier momento que se ejecute su aplicación? – reuben

+0

@Reuben: actualmente se crea inicialmente en la primera ejecución y se actualiza con poca frecuencia, probablemente solo unas pocas veces. Podría inicializarse en la instalación, pero debería actualizarse más tarde. –

+0

¿Por qué necesita ser independiente del usuario? ¿Por qué cada usuario que tenga su propia copia será malo? –

Respuesta

2

Uno de los objetivos de diseño de Windows 7 es aislar los datos y las aplicaciones de los usuarios. Esto es para mejorar la privacidad, la seguridad y la personalización. De hecho, los usuarios estándar en Win 7 no pueden cambiar los datos de otros usuarios.

La enumeración System.Environment.SpecialFolder devuelve los lugares estándar para almacenar los datos de la aplicación. Tenga en cuenta que no todas las carpetas son legibles o editables por todos los usuarios. Por ejemplo, CommonApplicationData es legible por todos los usuarios, pero solo puede escribirlo quien tenga una política adecuada, como Administradores.

Si absolutamente debe tener datos compartidos entre los usuarios, un administrador o uno con permiso debe instalarlo en una ubicación compartida. Si los usuarios necesitan actualizar estos datos, deben copiarlos en una ubicación en la que puedan escribir, como ApplicationData, y actualizar sus propias copias privadas. Esta copia privada no puede ser modificada por otros usuarios. No debe instalar datos en ubicaciones compartidas a menos que su aplicación no funcione de otro modo.

De hecho, en Win7 debe instalar todas las aplicaciones y datos en la aplicación del usuario y en las carpetas de datos, no en las ubicaciones compartidas. Si varios usuarios instalan la aplicación, cada usuario obtendrá su propia copia de la aplicación y los datos. Esto es casi siempre lo que quieres. Si varios usuarios ejecutan una aplicación o un juego, no querrás que un usuario cambie a los demás. Si varios usuarios realmente necesitan el mismo cambio, permita que cada usuario actualice su copia privada cuando la necesite. Si la cuenta de un usuario es pirateada o se vuelve malvada, no querrás que destruya las aplicaciones y los datos de los demás.

También tenga en cuenta que en Win7, los usuarios pueden iniciar sesión remotamente en una máquina, por lo que no es una buena idea almacenar datos específicos de la máquina, como resoluciones de pantalla o direcciones IP, por usuario. En cambio, verifique esto cada vez que se ejecute su aplicación.

+1

En realidad, el enfoque recomendado en la guía de certificación de Vista para el caso cuando necesita datos compartidos escribibles, es que el instalador de la aplicación cree una carpeta bajo CommonApplicationData y establezca sus permisos según corresponda (es decir, mundialmente editable). –

+0

... lo que quiere decir que no hay prohibición de compartir datos de escritura ni nada de eso. Es deliberadamente no trivial, pero no es imposible, y hay casos de uso válidos. –

+0

Buen comentario Pavel; no es imposible, pero estoy de acuerdo con la sugerencia de que no deberías hacer esto. –

0

En mi humilde opinión, no es razonable pensar que mucha gente va a tener que los usuarios individuales instalen sus propias copias de un paquete de software. De hecho, muchos paquetes no se instalarán a menos que se realicen bajo ADMIN (ALLUSERS = 1). Si no se proporcionan los medios razonables para facilitar las instalaciones de todo el sistema en algún nivel de protección inferior a ADMIN, las instalaciones de nivel ADMIN seguirán siendo la norma.

Por ejemplo, ¿por qué no se podrían permitir algunas instalaciones de usuarios que no sean ADMIN (con privilegios intermedios) para crear claves de registro en alguna parte restringida del registro (HKLM \ SOFTWARE \ package) y directorios en TODOS LOS USUARIOS \ DATOS DE APLICACIÓN \¿paquete?

He decidido hacer un ADMIN requerido (ALLUSERS = 1) .msi y crear claves de registro con protección modificada.

0

Entonces, en una situación en la que mi cliente tiene una estación de trabajo dedicada, nuestra aplicación (que obtiene datos de un buen archivo INI al que enviaremos r + w) nuestro mensaje al personal de TI es que necesitarán instalarlo en la misma máquina para cada usuario que tienen?

Tenemos que leer/escribir (en Windows 7/Vista): Environment.GetFolderPath (Environment.SpecialFolder.CommonApplicationData) + @ "\ GoScan \ GoScan.ini"

pero al igual que otros de haber descubierto los permisos para un usuario típico no son suficientes para r + w. ¿Es una práctica "aceptable" cambiar los permisos de directorio/archivo después de que el instalador finalice o quizás durante la instalación (no estoy seguro de dónde hacer esto en el proyecto de configuración de VS 2008).

-Paul

Cuestiones relacionadas