Configuration Source other than App.Config?

[Shawn B.]

Greetings,

Is is possible to use a configuration source other than App.Config? I mean,
when you use ConfigurationManager it assumes app.config. Can we use a text
stream instead? Further, for stuff like EnterpriseLibrary, it assumes xml
files, too, as does service.model WCF configuration. Essentially, what I
would like to do is have an API that I query that can return a string
indicating the configuration to use, so I can manage our configurations from
a central location. It would be nice if I can override the default of
assuming app.config and provide a string instead, that originated from
somewhere else.

 

[krach aran]

Greetings,

Is is possible to use a configuration source other than App.Config?  I mean,
when you use ConfigurationManager it assumes app.config.  Can we use a text
stream instead?  Further, for stuff like EnterpriseLibrary, it assumes xml
files, too, as does service.model WCF configuration.  Essentially, whatI
would like to do is have an API that I query that can return a string
indicating the configuration to use, so I can manage our configurations from
a central location.  It would be nice if I can override the default of
assuming app.config and provide a string instead, that originated from
somewhere else.

maybe this will help you :

http://www.codeproject.com/KB/dotnet/configmanager_net.aspx

 

[Shawn B.]

Is is possible to use a configuration source other than App.Config? I

maybe this will help you :

http://www.codeproject.com/KB/dotnet/configmanager_net.aspx

Thanks for the link. I was thinking more along the lines of reading a
configuration definition from a stream or source other than the file system,
and having the System.Configuration.ConfigurationManager participate with
it, but doesn't seem that is possible.

I can foresee two courses of action to resolve this:

1) Create an encapsulation of some kind that looks and feels like the
ConfigurationManager and decides whether to pull the configuration content
from the alternate source I speak of, and then revise the physical files on
the the file system, then uses the actual configuration API's to read from
them and return the results back. But that has limitation in that, for
example, 3rd party or intrinsic functionality (such as Enterprise Library
blocks or <service.model> wouldn't participate in it. These are primarily
the types of configurations I need to simplify because they become out of
sync across the thousands of servers we struggle to maintain.

2) Use something like PostSharp to inject an AOP wrapper into the
System.Configuration.ConfigurationManager class to changes its behavior.
This is likely what I'll do, even if I make it behave like #1 above, it has
the added benefit of working globally.


Thanks for the link above, that was an interesting read.

Thanks,
Shawn