What is the preferred way of reading an application's configuration file in .NET 4? I've seen several articles on how to do with .NET 2. I don't know if things have changed/improved with .NET 4.
The ConfigurationManager is still the preferred way of reading the application config and web config files.
To use it you will first need to add a reference in your project to System.Configuration.
Then you will need to add a reference to it in your class with:
using System.Configuration;
Once you have done this you will be able to access things like your AppSettings and ConnectionStrings by calling these static properties on the ConfigurationManager class.
e.g.
ConfigurationManager.AppSettings["settingname"];
Most developers seem to be happy with the string-based ConfigurationManager.AppSettings style of configuration, but there is another way: strongly typed configuration.
The MSDN reference is here: http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx
In a nutshell, you can define your own configuration setting section and have your own strongly typed configuration items in there. Amongst other things this
(as the name implies) can force use of enumerated options
allows you to define user-based or application-based settings
allows you to define defaults
The main downside is that it's a bit of a faff to get going as there's quite a bit of code to implement and test.
Related
QUESTION: How can I instantiate a model based on a config file?
BACKGROUND: I have a model simulator application consisting of dozens of different types of objects, each composed of other objects (in a complex compositional hierarchy). I would like to be able to instantiate the model based on an external configuration file. Is there a "standard approach" for this sort of task?
So for example, if I had a config.xml file like this:
<site>
<facility name="F1">
<tank name="t1"/>
<pipe name="p1"/>
</facility>
<facility name="F2">
...
I want a Configurator that can parse that file and create a Site object composed of a collection of Facility objects composed of various Tank & Pipe equipment, etc. (Eventually I will also do this in reverse to persist the model.) The model configuration will change frequently; users will collect many different versions of the config file.
Here are some options I've seen suggested, but I haven't used any of these tools much yet, and I'm hoping to get some advice as to which (if any) of these approaches might be most appropriate for this problem.
Role my own xml config file, parse it using XmlTextReader, and instantiate the model using reflection to map strings to types. (But is this re-inventing the wheel?)
Use ConfigurationManager from System.Configuration, storing settings in app.config. (But not sure how to support the "many different versions of the config file" requirement.)
Use XmlSerializer. (But I understand this requires default constructors, which would rule out constructor-based Dependency Injection which I had hoped to use.)
Use an IoC Container. (But I have several inexperienced programmers who will be interacting with the program; I'd rather not overwhelm them with unnecessary complexity.)
(Bottom line: I hope to "do the simplest thing that could possibly work". But my unfamiliarity with these tools prevents me from determining which one is simplest.)
Option 1:
#JohnSaunders says that a specific way to create a XmlTextReader is deprecated, not XmlTextReader per se. That's true. See here:
http://msdn.microsoft.com/en-us/library/9khb6435(v=vs.110).aspx
While a long list of cases is one option, one would probably not create such a knot in the code. Alternatives:
factory objects that register themself with a key to be used in the XML to identify the factory object
using a type name in the XML and working with reflection:
http://msdn.microsoft.com/en-us/library/vstudio/f7ykdhsy(v=vs.100).aspx
Option 2:
I can't see how saving the configuration in app.config instead of some other XML file relates to or solves your original problem.
Option 3:
Then don't scatter the serialization code.
Option 4:
How about looking into the source code of a not so big DI Framework to get ideas how to do it then?
HTH
I have a class library that has a function with this code:
this.apikey = ConfigurationManager.AppSettings["ApiKey"];
When I call this function in a console application, it says AppSettings has no keys. also it states the connection string is aspnet... whereas mine is sqlserver. So it is certainly not reading my library app config even though Im calling that in a library function.
Is this normal or am I doing something wrong?
I was hoping to avoid having to make and parse an xml and reinvent the wheel.
Thanks
Is this normal or am I doing something wrong?
It is normal and you are doing something wrong.
A library does not, usually, have its own configuration - it is subject to the configuration of the running application.
If you add your appSettings and connectionStrings to the application configuration all will work.
In other words, when an application loads and the libraries it uses are loaded, the application configuration is read - no other configuration file is read. When calling the static methods of ConfigurationManager, the loaded configuration is what's in effect.
There are ways to load specific configuration files, but that's not the default behaviour.
You are certainly wrong at some place. May be you have written your keys in different section than the appSettings. Just check it, and if it is correct then , you will need to reinvent the wheel as below:
XDocument.Load(HttpContext.Current.Server.MapPath("~/web.config"));
Be sure to add System.Web namespace to your project before using HttpContext
OK, so this is not the most useful question since I can't remember the feature in .net that does this. Basically, that's what I'm asking; what feature is this?
A year or so ago, I was working on a project and we used configuration files that mapped directly to a class using the specific attributes on the class members. This is not the standard app.config, but assemblyname.dll.xml instead.
Perhaps it's a feature within the unity framework? Just a stab in the dark.
It is not critical I figure this out today, but it is just weighing on my brain and annoys me that i can't remember!
thanks!
It's not the standard XML config, but it is built into .NET. Basically, XML serialization allows you to project an XML document from a hydrated class instance, that will map 1:1 to the class it came from and can be used to re-hydrate a new instance of that class.
This can, in the majority of cases, be done without much effort on your part. All that's usually necessary for XML serialization to work is that the object must have a public default constructor, and that all the state information you want to serialize must be public and read-write. In a few cases, some attributes are necessary to define certain behaviors, like derived classes in arrays of their parent class, and defining non-default names for field and property element tags.
One of the major uses of this is for custom configuration files as you stated; you can load the configuration from a persistent state by simply deserializing the file into an instance of the configuration object.
Article: MSDN How To Serialize an Object
This isn't part of the .Net bcl or Unity as far as I am aware. Perhaps it's some other third party or open source component? That being said, it wouldn't be too difficult to build something like this on your own using XmlSerialization.
.net allows for multi layered configuration.
Every machine has the machine.config file. each application has the app.config file (which gets renamed to applicationname.exe.config upon building), but each dll can also have it's own config file. so, if I have the following binaries in my executable folder:
flexitris.exe
flexitrisHelpers.dll
thirdPartyContent.dll
each of them can have their own config file:
flexitris.exe.config
flexitrisHelpers.dll.config
thirdPartyContent.dll.config
and all of them will be read at runtime and accessible using the normal System.Configuration namespace.
We have lot of configuration files used in our application. Atleast 100 different xml files for each customer containing at least 50-80 name/value pairs of configuration and all they are often change (atleast every month).
The configuration file looks something similar like below,
<property id="url" value="s123"/>
<property id="input-element-name" value="name" />
<property id="input-element-xpath" value="//body;//form;//table[3];" />
Currently to read this values from xml file we use XmlReader et al and store it in a cache once the application starts (and this could be huge tomorrow when our customer base increases). To access the property ids we have created const variables in a static class to avoid typo etc.,
This approach was great when we had less configurations. Now, it is painful to maintain and add any new to this configuration file. Need to do rebuild etc., just kills the concept of keeping configurable values outside code.
I was just wondering if any recent developments in .NET space such as M language, IronPython could help here to have dynamically typed and compiled configuration values on demand when configuration file gets changed. We don't have any reservations in having xml format for configuration.
In summary, what I need is to have some .XXX files having our configuration values and if anything is changed or added that should be automatically compiled and can be used in our application without creating constants etc., I know something similar happens with .T files in VS.
I hope this could be doable ..
UPDATE
The idea of this question was not seems to be understood correctly or I wouldn't have spelled out correctly. Sorry for the trouble.
The custom configuration section may not appropriate for this problem, the reason is using ConfigurationSection requires code modification if I add any new name/value pair. However, this approach will work if only change values as name part is being mapped to property in the code.
I was wondering if i use any dynamic language breeds such as IronPython or M Language I could be able to move all XML to it and in my application I would able to see any changes to this file (using `FileSystemWatcher') and execute it to read the newly added configuration name/value pairs.
You can implement as many custom ConfigurationSections as you'd like.
This will allow you to model your configuration model as strongly typed objects.
I've used this typed configuration class from Rick Strahl - it worked very well for me.
Vadi, the purpose of external configuration is to obviate the need to recompile for configuration changes.
If the xml you present is representative of the type of information you need to use, a custom ConfigurationSection would serve you nicely and provide the type safety you want.
Please look at the classes in the System.Configuration namespace. They have been there since .NET 2.0, and give you strongly-typed access to XML configuration files, complete with validation.
Could someone tell me the advantages to using the ConfigurationManager class which load's a config file for manipulation VS an XML file with a class you build to read it yourself?
Recently, I built a class which inherits from ConfigurationSection in order to manipulate a custom section within app.config. This was quite a bit of work compared to just opening and reading an XML file.
Some people chose the first approach, others chose the second.
What's good practice?
This is an old question, but what the hell... so yes, there is quite some code overhead in writing configuration sections and elements, but what you get as compared to using your own class with an XML serializer include:
Type conversions and validations: if one of your configuration settings is, say, a "Type" (maybe you store in your configuration what kind of implementation you need to create for some provider), then the ConfigurationManager will not only convert whatever was written in the .config file to a System.Type, but you can also add validation attribtues on your ConfigurationElement's property, like "SubclassTypeValidatorAttribute", which will check that the given type derives from your base provider class/interface. You can of course add your own validators, so that in the rest of your code, you just "get" the configuration and you know everything's valid.
Multi-level settings hierarchy: you can play around with storing settings at the machine, application or user levels, which gives you a mechanism to handle default vs. user-specific settings. You also have APIs to load configurations from custom locations.
No duplication in config files: if you're using other .NET features like TraceSources and stuff, the configuration for that is already in the .config file (say you're troubleshooting a problem and you want to turn on some debug trace that's off by default... you do that by just modifying the .config). If you're using your own config file for your custom settings, then you end up with 2 configuration files, which is not so good.
There's probably other benefits, but that's what comes to mind so far.
It's just a recommended and easier way of reading and writing data to configuration files. Using XML DOM is too low level.
You can always get raw xml configuration from ConfigurationSection using section.SectionInformation.GetRawXml() if needed. Likewise use SetRawXml to set this.
There are a few gotchas though when using ConfigurationManager, for example when you load a config file using OpenMappedExeConfiguration, you get an in memory configuration which is "merged" and has sections from machine.config. You can check if a section came from the file you provided using section.ElementInformation.Source.Equals(source.FilePath).
Reference: MSDN