Settings.settings vs. app.config en la aplicación de escritorio.NET

app-config (2)

Posible duplicado:
¿Cuál es la diferencia entre el archivo app.config y el archivo XYZ.settings?

Estoy bastante confundido por la aparente redundancia de estos dos mecanismos en Visual Studio para almacenar y administrar la configuración de la aplicación de escritorio:

Puede usar el archivo XML app.config y agregar elementos a la sección <appSettings> . Estos se pueden recuperar del código utilizando la clase ConfigurationManager .
Alternativamente, puede usar el archivo Settings.settings para agregar configuraciones individuales a través de un editor. Visual Studio generará una clase de Settings para la recuperación segura de configuraciones en tiempo de ejecución.

Estos dos mecanismos parecen tener el mismo (o casi el mismo) propósito. Soy consciente de que hay algunas diferencias, pero también estoy desconcertado por la superposición y sus consecuencias. Por ejemplo, cuando uso Visual Studio para agregar configuraciones al archivo Settings.settings , toda la información que app.config termina como entradas en el archivo app.config también. Aparentemente, existe un mecanismo de sincronización: si cambio una configuración en el archivo app.config , Visual Studio me pedirá que actualice el archivo Settings.settings la próxima vez que lo abra en el editor.

Mis preguntas son:

¿Por qué dos mecanismos y no solo uno?
¿Cuáles son los escenarios más comunes para usar app.config sobre Settings.settings , y viceversa?
¿Qué sucede si mi aplicación usa Settings.settings y cambio un valor en app.config después de que se implementó? No se puede sincronizar las Settings.settings . Ya se ha compilado y distribuido.

Nota. He buscado preguntas sobre este tema, pero estoy aún más confundido. Por ejemplo, las respuestas a esta pregunta aquí son bastante contradictorias y no arrojan demasiada luz.

Nota 2. Soy consciente de que app.config es un nombre de archivo en tiempo de diseño, y estoy familiarizado con la dinámica de la copia de Visual Studio y su cambio de nombre a la carpeta ejecutable.

¿Por qué dos mecanismos y no solo uno?

Ellos sirven diferentes propósitos. La API de configuración ofrece acceso de lectura / escritura desde la aplicación, mientras que la configuración es de solo lectura (a menos que escriba el archivo en el código).

Los ajustes se pueden definir por usuario o por aplicación, y están diseñados para ser volátiles. La configuración del usuario se escribe en la carpeta oculta dentro del almacenamiento de Perfil de Usuario que está permitido bajo UAC.

App.config es solo por aplicación. Los cambios en App.config no se recogen automáticamente. Requiere reiniciar o codificar para actualizar los valores. Debajo de UAC, los usuarios no pueden escribir en los directorios de la aplicación, como Archivos de programa, por lo que este archivo debe considerarse de solo lectura.

¿Cuáles son los escenarios más comunes para usar app.config sobre Settings.settings, y viceversa?

Puede usar Configuración en una aplicación de escritorio para almacenar preferencias de usuario o configuraciones que cambian en tiempo de ejecución.

Utilizaría App.config para configuraciones estáticas más genéricas, como cadenas de conexión, etc., o para definir la configuración de los componentes utilizados en su aplicación.

¿Qué sucede si mi aplicación usa Settings.settings y cambio un valor en app.config después de que se implementó?

Si la aplicación se vuelve a desplegar, recuperará la nueva configuración, a menos que haya personalizaciones de usuario / aplicación en la máquina, en cuyo caso continuará usándolas, a menos que las limpie.

Si agrega una nueva configuración, estos serán recogidos. De hecho, los valores predeterminados se hornean en la clase de configuración, por lo que incluso si el app.config está vacío, la configuración aún funciona.

Desde el punto de vista de .NET Framework (sin hablar de herramientas, Visual Studio, por el momento), históricamente, solo había [app.exe].config (de hecho, es lo que el AppDomain define como el archivo de configuración. está definido por AppDomain, por eso es web.config para aplicaciones web ...) y machine.config . ''aplicación'' se implementa junto con la aplicación, ''máquina'' es para toda la máquina. Se suponía que debían ser "bastante" leídos, solo para el usuario promedio. Es posible cambiarlos, pero no fue la idea.

Pero, ¿cómo puedo guardar las preferencias del usuario final? Es por eso que se introdujo [user] .config (creo con .NET 2). La documentación oficial dice esto:

El sistema de configuración que se lanzó originalmente con .NET Framework permite proporcionar datos de configuración de la aplicación estática a través del archivo machine.config de la computadora local o dentro de un archivo app.exe.config que implemente con su aplicación. La clase LocalFileSettingsProvider expande este soporte nativo de las siguientes maneras:
1) La configuración con ámbito de aplicación se puede almacenar en los archivos machine.config o app.exe.config. Machine.config siempre es de solo lectura, mientras que app.exe.config está restringido por consideraciones de seguridad a solo lectura para la mayoría de las aplicaciones.
2) La configuración del usuario puede almacenarse en archivos app.exe.config, en cuyo caso se tratan como valores predeterminados estáticos.
3) Las configuraciones no predeterminadas del usuario se almacenan en un nuevo archivo, user.config, donde el usuario es el nombre de usuario de la persona que está ejecutando la aplicación. Puede especificar un valor predeterminado para una configuración de ámbito de usuario con DefaultSettingValueAttribute. Dado que la configuración del usuario suele cambiar durante la ejecución de la aplicación, user.config siempre es de lectura / escritura.

Entonces, desde el punto de vista de .NET Framework, solo hay un mecanismo de 3 capas.

Ahora, Visual Studio simplemente intenta ayudarlo generando el código de tipo seguro para la configuración final de lectura / escritura. La mayoría de las veces, ese archivo .config [usuario] no existe y un valor de configuración se definirá por lo que está en DefaultSettingValueAttribute (definido para cada configuración), o usará lo que se ha definido estáticamente en la aplicación.config. Es por eso que Visual Studio también actualiza el archivo app.config para que pueda definir valores predeterminados estáticos para la configuración. Pero puedes borrar perfectamente todas las cosas de app.config.