2009-08-31 20 views
7

Descubrí que una aplicación que escribí no funciona correctamente en Windows Vista/7 si UAC está habilitado en cualquier nivel, porque escribe archivos en el directorio de instalación del programa, por defecto es "C: \ Program Files \ MyProgram". Si UAC está deshabilitado (o en cualquier otra versión de Windows), funciona correctamente: he leído que UAC niega el acceso de escritura de las aplicaciones al directorio Archivos de programa de forma predeterminada.¿Manera correcta de diseñar según las limitaciones de Windows UAC?

Mi pregunta es, bueno, ¿cómo debo escribir mi aplicación para que pueda ser utilizada sin ningún "derecho" necesario en absoluto. No quiero que los usuarios tengan que ejecutarlo con privilegios elevados o como administrador. Solo quiero que funcione. ¿Hay ciertos directorios a los que cualquier aplicación tenga acceso de escritura bajo UAC donde podría ser mejor escribir mis archivos? En su mayoría son archivos de configuración que se crean/destruyen/actualizan dinámicamente.

Gracias por su ayuda!

+3

No llamaría a las restricciones de UAC "limitaciones" en su aplicación. Técnicamente lo son, pero más o menos simplemente te guía a no hacer algo que nunca deberías hacer, en primer lugar, –

+0

"nunca debería hacer", ¿por qué no? – JimDaniel

+3

¿Por qué demonios querrías escribir datos de configuración en Archivos de programa? Ese es el directorio de instalación. Ahí es donde van los ejecutables y las bibliotecas. Los datos no van allí ... –

Respuesta

12

Los datos específicos de la aplicación por usuario se deben escribir en la carpeta AppData.

Debe usar SHGetKnownFolderPath con FOLDERID_LocalAppData.

En el código administrado, debe usar System.Environment.GetFolderPath con System.Environment.SpecialFolder.LocalApplicationData.

+2

Si usa las capacidades de configuración de .NET (espacio de nombres 'System.Configuration', estos son los archivos .settings en un proyecto C#), sus datos se colocarán en la ubicación correcta y tendrá formas muy elegantes de acceder y actualizar eso. –

4

Sí, hay ubicaciones específicas. Considere this msdn article como primera referencia. Menciona los lugares:

  • CSIDL_APPDATA
  • CSIDL_LOCAL_APPDATA
  • CSIDL_COMMON_APPDATA

en código nativo, el método SHGetKnownFolderPath puede ser muy útil.

En código administrado puede usar Environment.GetFolderPath(). Si se encuentra en un marco de aplicación específico, como formularios de Windows, puede obtener un acceso aún más fácil a través de propiedades directas, como Application.LocalUserAppDataPath (que es mi técnica favorita). La ruta del marco incluirá calificadores específicos de la aplicación en la ruta que devuelve para distinguir entre (por ejemplo) diferentes versiones de su aplicación.

Cuestiones relacionadas