Tengo dos proyectos independientes en mi solución Visual Studio 2008. Ambos tienen su propia App.config. Pero en un proyecto, necesito una o dos propiedades definidas en App.config de otro proyecto. ¿Es posible compartir parte de los contenidos de App.config de otro proyecto?C#, ¿podemos compartir algunos contenidos de App.config entre proyectos?
Sí, por supuesto. Cualquier sección de configuración se puede "exterioriza" - por ejemplo:
<appSettings configSource="AppSettings.DEV.config" />
<connectionStrings configSource="MyConnection.config" />
o
<system.net>
<mailSettings>
<smtp configSource="smtp.TEST.config" />
vs
<system.net>
<mailSettings>
<smtp configSource="smtp.PROD.config" />
cualquier sección de configuración se puede poner en un archivo separado que puede ser compartido entre proyectos, pero no la sección de configuración grupos, y desafortunadamente, a veces es un poco difícil saber cuál es cuál.
Además, en algunos casos, Visual Studio se quejará (usando subrayados rojos ondulados) de que el "configSource" supuestamente no es válido, pero está definido en el objeto ConfigurationSection en el sistema de configuración .NET.
ACTUALIZACIÓN:
otra característica que apenas suficientes desarrolladores parecen saber y uso es la capacidad en Visual Studio para agregar archivos existentes de un proyecto diferente como un enlace:
alt text http://i44.tinypic.com/2vl5wls.png
Con esto, puede agregar enlaces a archivos en su proyecto local, y siempre se mantendrán actualizados. ¡Un gran refuerzo de productividad si necesita compartir archivos (como archivos de configuración comunes o similares)!
pero el archivo de destino, como "MyConnection.config" en su ejemplo, debe estar en el mismo directorio o subdirectorio? – 5YrsLaterDBA
@ 5YrsLaterDBA: sí, tiene que estar en el mismo directorio o en un subdirectorio del mismo. Puede ser un archivo "vinculado" en Visual Studio, sin embargo, o un enlace rígido en el disco (enlace NTFS, un "puntero" a otro archivo que se ve y actúa como "The Real Thing") –
Hmmm ... Me gustaría había pensado en mencionar enlaces. lol. pero dejaste algo importante, orujo. –
En esa situación, yo pensaría que usar una base de datos para almacenar algunos datos de configuración sería ideal. Cada aplicación hace lo suyo, pero buscan en una base de datos compartida para obtener esas piezas comunes de información.
EDIT: ¡hablé demasiado pronto! Parece que tanto el OP como yo aprendí algo sobre los archivos de configuración = D
Prueba esto:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="PROD.config">
<add key="common.Currency" value="GBP" />
</appSettings>
</configuration>
sí, pero el atributo "file =" solo es válido en la sección
Sólo el "funcionamiento" se utiliza app.config, pero se puede ir externo como marc_s dice.
También puede crear un archivo .Settings que sea "compartido". Vaya a las propiedades del proyecto "compartido", a la pestaña Configuración a la izquierda, cree una configuración con Ámbito de aplicación y establezca el Modificador de acceso en la parte superior como Público. En su otro proyecto, puede usar ClassLibrary1.Properties.Settings.Default.SettingName para acceder a él. Será fuertemente tipado, pero puede necesitarlo en tiempo de compilación.
Pero el código de Configuración que se genera no depende de la aplicación. config de la carrera para la persistencia? Entonces aún necesitarías una copia de ese archivo para cada aplicación en ejecución. – ProfK
@ProfK: Sí, tienes razón. Los archivos .settings pueden tener valores predeterminados que terminan como 'DefaultSettingValueAttribute' en el código, a diferencia de la configuración de la aplicación regular en app.config. Sin embargo, cualquier desviación de los valores predeterminados terminaría en cada app.config individual. Dado que la configuración se almacena en una sección de app.config, puede usar una combinación de los dos y externalizarlo con configSource, manteniendo los valores predeterminados compilados y la escritura fuerte. Supongo que todo depende de lo que estés buscando. –
Algo que me gusta hacer, especialmente cuando trato de coordinar elementos de ServiceModel entre bibliotecas y pruebas es usar configSource para fragmentar la configuración en la biblioteca de destino y simplemente link/copy always los fragmentos en mis proyectos de prueba.
De esta manera, solo mantengo en un solo lugar.
Puede ir un paso más allá y simplemente tener un directorio común en la solución y vincular los fragmentos en todos los proyectos.
Ditto [link] (http://stackoverflow.com/questions/426245/how-to-share-app-config) – nawfal