Lo que quiero lograr es muy simple: tengo una aplicación de Windows Forms (.NET 3.5) que usa una ruta para leer información. El usuario puede modificar esta ruta mediante el formulario de opciones que proporciono.
Ahora, quiero guardar el valor de la ruta en un archivo para su uso posterior. Esta sería una de las muchas configuraciones guardadas en este archivo. Este archivo se ubicaría directamente en la carpeta de la aplicación.
Entiendo que hay tres opciones disponibles:
- Archivo de configuración (appname.exe.config)
- Registro
- Archivo XML personalizado
Leí que el archivo de configuración .NET no está previsto para guardar valores de nuevo en él. En cuanto al registro, me gustaría alejarme lo más posible.
¿Significa esto que debo usar un archivo XML personalizado para guardar la configuración?
Si es así, me gustaría ver un ejemplo de código de eso (C #).
He visto otras discusiones sobre este tema, pero todavía no me queda claro.
Respuestas:
Si trabaja con Visual Studio, es bastante fácil obtener configuraciones persistentes. Haga clic derecho en el proyecto en el Explorador de soluciones y elija Propiedades. Seleccione la pestaña Configuración y haga clic en el hipervínculo si la configuración no existe.
Use la pestaña Configuración para crear configuraciones de aplicaciones. Visual Studio crea los archivos
Settings.settings
ySettings.Designer.settings
que contienen la clase singletonSettings
heredada de ApplicationSettingsBase . Puede acceder a esta clase desde su código para leer / escribir la configuración de la aplicación:Esta técnica es aplicable tanto para consola, Windows Forms y otros tipos de proyectos.
Tenga en cuenta que debe establecer la propiedad de alcance de su configuración. Si selecciona Ámbito de aplicación, entonces Configuración.Por defecto. <Su propiedad> será de solo lectura.
Referencia: Cómo: Escribir la configuración del usuario en tiempo de ejecución con C # - Microsoft Docs
fuente
Settings.Default.SomeProperty = 'value'; Settings.Default.Save();
Funciona de maravilla. ¿O es porque tengo la configuración de usuario?Settings.Default.Save()
no hace nada es incorrecta. Como @aku dice en la respuesta, la configuración del alcance de la aplicación es de solo lectura: guardar es ineficaz para ellos. Use ese PortableSettingsProvider personalizado para guardar la configuración del alcance del usuario en la app.config ubicada donde está el exe en lugar del que está en la carpeta AppData del usuario. No, en general no es bueno, pero lo uso durante el desarrollo para usar la misma configuración de compilación en compilación (sin él, van nuevas carpetas de usuario únicas con cada compilación).Si planea guardar en un archivo dentro del mismo directorio que su ejecutable, aquí hay una buena solución que utiliza el formato JSON :
fuente
DEFAULT_FILENAME
, solo llamesettings.Save(theFileToSaveTo)
; Al ser todo en mayúsculas,DEFAULT_FILENAME
se supone que es una constante . Si desea una propiedad de lectura y escritura, cree una y haga que el constructor la establezcaDEFAULT_FILENAME
. Luego haga que el valor de argumento predeterminado seanull
, pruebe esto y use su propiedad como valor predeterminado. Es un poco más de tipeo, pero le brinda una interfaz más estándar.System.Web.Extensions.dll
si aún no lo ha hecho.El registro es un no-go. No está seguro de si el usuario que usa su aplicación tiene suficientes derechos para escribir en el registro.
Puede usar el
app.config
archivo para guardar configuraciones de nivel de aplicación (que son las mismas para cada usuario que usa su aplicación).Almacenaría configuraciones específicas del usuario en un archivo XML, que se guardaría en Almacenamiento aislado o en el directorio SpecialFolder.ApplicationData .
Además de eso, a partir de .NET 2.0, es posible almacenar valores de nuevo en el
app.config
archivo.fuente
La
ApplicationSettings
clase no admite guardar configuraciones en el archivo app.config . Eso es mucho por diseño; Las aplicaciones que se ejecutan con una cuenta de usuario debidamente protegida (piense en Vista UAC) no tienen acceso de escritura a la carpeta de instalación del programa.Puedes luchar contra el sistema con la
ConfigurationManager
clase. Pero la solución trivial es ir al diseñador de Configuración y cambiar el alcance de la configuración a Usuario. Si eso causa dificultades (por ejemplo, la configuración es relevante para cada usuario), debe colocar su función de Opciones en un programa separado para que pueda solicitar la solicitud de elevación de privilegios. O renunciar a usar una configuración.fuente
El argumento Registry / configurationSettings / XML todavía parece muy activo. Los he usado todos, ya que la tecnología ha progresado, pero mi favorito se basa en el sistema de Threed combinado con el almacenamiento aislado .
El siguiente ejemplo permite el almacenamiento de objetos denominados propiedades en un archivo en almacenamiento aislado. Como:
Las propiedades pueden recuperarse usando:
Es solo una muestra, que no sugiere las mejores prácticas.
fuente
Quería compartir una biblioteca que he construido para esto. Es una pequeña biblioteca, pero una gran mejora (en mi humilde opinión) sobre los archivos .settings.
La biblioteca se llama Jot (GitHub) . Aquí hay un viejo artículo de The Code Project que escribí al respecto.
Así es como lo usaría para realizar un seguimiento del tamaño y la ubicación de una ventana:
El beneficio en comparación con los archivos .settings: hay considerablemente menos código, y es mucho menos propenso a errores ya que solo necesita mencionar cada propiedad una vez .
Con los archivos de configuración, debe mencionar cada propiedad cinco veces: una vez cuando crea explícitamente la propiedad y cuatro veces más en el código que copia los valores de un lado a otro.
El almacenamiento, la serialización, etc. son completamente configurables. Cuando los objetos de destino son creados por un IoC contenedor de , puede [conectarlo] [] para que aplique el seguimiento automáticamente a todos los objetos que resuelve, de modo que todo lo que necesita hacer para que una propiedad sea persistente es abofetear a [Rastreable] atributo en él.
Es altamente configurable y puede configurar: - cuando los datos se conservan y se aplican globalmente o para cada objeto rastreado - cómo se serializan - dónde se almacenan (por ejemplo, archivo, base de datos, en línea, almacenamiento aislado, registro) - reglas que pueden cancelar la aplicación / datos persistentes para una propiedad
Confía en mí, ¡la biblioteca es de primera categoría!
fuente
Una manera simple es usar un objeto de datos de configuración, guardarlo como un archivo XML con el nombre de la aplicación en la carpeta local y al iniciarlo, volver a leerlo.
Aquí hay un ejemplo para almacenar la posición y el tamaño de un formulario.
El objeto de datos de configuración está fuertemente tipado y es fácil de usar:
Una clase de administrador para guardar y cargar:
Ahora puede crear una instancia y usarla en los eventos de carga y cierre de su formulario:
Y el archivo XML producido también es legible:
fuente
c:\program files\my application
carpeta, por lo que guardar la configuración arroja un error. Estoy buscando guardar el archivo xml en AppData, pero me preguntaba si había una forma obvia de solucionar este problema, ya que este enfoque parece haber funcionado para usted.No me gusta la solución propuesta de usar
web.config
oapp.config
. Intenta leer tu propio XML. Eche un vistazo a los archivos de configuración XML: no más web.config .fuente
Otras opciones, en lugar de usar un archivo XML personalizado, podemos usar un formato de archivo más fácil de usar: archivo JSON o YAML.
Puede almacenar su archivo de configuración en múltiples carpetas especiales (para todos los usuarios y por usuario) como se detalla aquí. Entorno. Enumeración de carpeta especial y múltiples archivos (solo lectura predeterminada, por rol, por usuario, etc.)
Si elige usar múltiples configuraciones, puede fusionar esas configuraciones: por ejemplo, fusionando la configuración por defecto + BasicUser + AdminUser. Puede usar sus propias reglas: la última anula el valor, etc.
fuente
"¿Esto significa que debo usar un archivo XML personalizado para guardar la configuración?" No, no necesariamente Utilizamos SharpConfig para tales operaciones.
Por ejemplo, si un archivo de configuración es así
Podemos recuperar valores como este
Es compatible con .NET 2.0 y superior. Podemos crear archivos de configuración sobre la marcha y podemos guardarlos más tarde.
Fuente: http://sharpconfig.net/
GitHub: https://github.com/cemdervis/SharpConfig
fuente
Por lo que puedo decir, .NET admite configuraciones persistentes utilizando la función de configuración de aplicación integrada:
fuente
A veces, desea deshacerse de la configuración guardada en el archivo web.config o app.config tradicional. Desea un control más detallado sobre la implementación de sus entradas de configuración y el diseño de datos separados. O el requisito es habilitar la adición de nuevas entradas en tiempo de ejecución.
Me imagino dos buenas opciones:
La ventaja de la versión fuertemente tipada son los nombres y valores de configuración fuertemente tipados. No hay riesgo de mezclar nombres o tipos de datos. La desventaja es que se deben codificar más configuraciones, no se pueden agregar en tiempo de ejecución.
Con la versión orientada a objetos, la ventaja es que se pueden agregar nuevas configuraciones en tiempo de ejecución. Pero no tiene nombres y valores fuertemente tipados. Debe tener cuidado con los identificadores de cadena. Debe conocer el tipo de datos guardado anteriormente al obtener un valor.
Puede encontrar el código de ambas implementaciones completamente funcionales AQUÍ .
fuente
Sí, es posible guardar la configuración, pero depende en gran medida de la forma en que elija hacerlo. Permítame describir las diferencias técnicas para que pueda comprender las opciones que tiene:
Primero, debe distinguir si desea usar applicationSettings o AppSettings en su archivo
*.exe.config
(también conocidoApp.config
en Visual Studio): existen diferencias fundamentales que se describen aquí .Ambos proporcionan diferentes formas de guardar los cambios:
config.Save(ConfigurationSaveMode.Modified);
, donde se define como configconfig = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
).Properties.Settings.Default.Save();
) se escribirá por usuario, almacenados en un lugar especial (por ejemploC:\Documents and Settings\USERID\Local Settings\Application Data\FIRMNAME\WindowsFormsTestApplicati_Url_tdq2oylz33rzq00sxhvxucu5edw2oghw\1.0.0.0
). Como Hans Passant mencionó en su respuesta, esto se debe a que un usuario generalmente tiene derechos restringidos a los Archivos de programa y no puede escribir en él sin invocar la solicitud de UAC. Una desventaja es que si agrega claves de configuración en el futuro, debe sincronizarlas con cada perfil de usuario.Nota: Como se menciona en la pregunta, hay una tercera opción: si trata el archivo de configuración como documento XML, puede cargarlo, modificarlo y guardarlo utilizando la
System.Xml.Linq.XDocument
clase. No es necesario usar un archivo XML personalizado, puede leer el archivo de configuración existente; para consultar elementos, incluso puede usar consultas Linq. He dado un ejemplo aquí , mira la funciónGetApplicationSetting
allí en la respuesta.Si necesita cifrado para proteger sus valores, consulte esta respuesta.
fuente
fuente