appSettings vs applicationSettings. appSettings desactualizado?

Tengo algunas preguntas sobre dos formas de guardar configuraciones en el archivo web.config.appSettings vs applicationSettings. appSettings desactualizado?

AppSettings: Buscar en web.config

<appSettings> 
<add key="key1" value="value1"/> 
<add key="key2" value="value2"/> 
</appSettings>

Uso de código subyacente:

ConfigurationManager.AppSettings["key1"];

ApplicationSettings/Propiedades (generados automáticamente mediante el uso de la 'pestaña properties' en el proyecto)
Buscar en web.config

<applicationSettings> 
    <Projectname.Properties.Settings> 
     <setting name="TestEnvironment" serializeAs="String"> 
      <value>True</value> 
     </setting> 
    </Projectname.Properties.Settings> 
</applicationSettings>

Uso de código subyacente:

Properties.Settings.Default.TestEnvironment

Así que, ¿cuál es la diferencia entre estos dos almacenamiento posibilidades de configuración en la web.config?
Por lo que puedo ver, una desventaja de la configuración de la aplicación es que usted ha modificado la configuración web.config usted mismo y las configuraciones de la aplicación no están bien tipadas, mientras que las aplicaciones son las configuraciones.

Ambos son reemplazables dentro de un proyecto de despliegue web.

Por lo que a mí respecta, hay sin uso para las configuraciones de la aplicación. ¿Me estoy perdiendo de algo? ¿Cuál es el más antiguo visto históricamente?

Fuente

2010-02-28 citronas

Esto se ha discutido antes aquí: Pros and cons of appSettings vs applicationSettings (.NET app.config).

En cuanto a sus preguntas: La anterior es <appSettings>, era alrededor de 2.0, <applicationSettings> estuvo disponible en 2.0.

¿Ventajas? Cuando estoy editando un valor, o agregando un valor en un servidor donde la mejor herramienta es el bloc de notas <applicationSettings> es muy detallado, y a veces I solo quiero una cadena. Tal vez sea un ejemplo tonto, pero cuando estoy ajustando la configuración de configuración entre niveles para obtener la configuración de implementación automática correctamente, es tremendamente útil que sea simple.

Tengo que estar de acuerdo con marc_s de la otra discusión, sin embargo, si está haciendo algo que es realmente complejo, probablemente esté llegando al punto en que debería tener su propia sección de configuración. Como está deserializando en su tipo de configuración al inicio ... obtiene el mismo tipo de comprobación de esa manera, solo a través del Serializador XML directamente es la única diferencia.

Esto también tiene la ventaja de que yo haga Config.LDAPServer o tal vez una configuración para diferentes áreas de cada uno, como Security.Config y Themes.Config (adivinanzas aquí!), Se puede obtener un esquema muy útil/clara denominación de allí como un beneficio adicional.

Fuente

2010-02-28 12:02:36

Una cosa que he notado es que los valores de AppSettings pueden referenciarse a través de <%$ AppSettings: name %> etiquetas en línea en páginas aspx, pero parece que no hay una forma equivalente de acceder a los valores ApplicationSettings a través de etiquetas en línea.

Fuente

2011-10-26 05:35:14 Loophole

¡Gracias por esta información! Leí internet para encontrar esta respuesta. – Germstorm

Gracias por esta respuesta. Me preguntaba por qué no puedo acceder a las cosas almacenadas en ApplicationSettings en una Vista usando ASP.NET MVC. – user850010

Parece que los archivos DLL de la biblioteca pueden acceder a las configuraciones de aplicaciones de valor-clave antiguas en el archivo de configuración principal, pero no a las nuevas ApplicationSettings fuertemente tipadas. Si desea mantener todos sus parámetros de configuración (tanto para la aplicación como para sus bibliotecas) fuertemente tipados y en un solo lugar, debe pasar las necesidades de las bibliotecas a través de propiedades o constructores. Si tiene una clase de biblioteca estática, p. una que envía correos electrónicos y tiene muchos parámetros de configuración, es más fácil pasarlos una vez usando el antiguo bloque appSettings. En mi humilde opinión ... –

ApplicationSettings son espacios de nombres, por lo que dos conjuntos diferentes pueden tener un ajuste para "timeout" sin conflictos, y ApplicationSettings son opcionales ya que el valor predeterminado se establece mediante un atributo en la configuración del código.

Fuente

2011-10-26 05:40:46

Probablemente la única respuesta que señala algunas diferencias importantes y razones para usar o no las configuraciones de la aplicación. –

me gustaría añadir que IIS 8.0 interfaz gráfica de usuario (y versiones anteriores, así) no puede editar la sección <applicationSettings> (es invisible, es decir, parece como si no hay parámetros configurables) mientras que <appSettings> son editables con IIS 8.0.

Habría sido bueno si VS2012/IIS 8.0 utilizara el mismo sistema de configuración de GUI, pero los productos no parecen estar sincronizados en ese aspecto. De una forma u otra, es posible que deba editar la configuración de la aplicación con el bloc de notas.

Las cadenas de conexión aparecen en ambas interfaces gráficas de usuario, pero si se utiliza <applicationSettings> en IIS que incluyen ruta completa (Espacio de nombres .Properties.Settings. connectionStringName).

Fuente

2013-08-07 13:37:16 galmok

appSettings vs applicationSettings. appSettings desactualizado?

Respuesta

Cuestiones relacionadas