views:

374

answers:

8

I have a set of configuration items I need to persist to a "human readable" file. These items are in a hierarchy:

Device 1
   Name
   Channel 1
     Name
     Size
     ...
   Channel N
     Name
...
Device M
   Name
   Channel 1

Each of these item could be stored in a Dictionary with a string Key and a value. They could also be in a structure/DTO.

I don't care about the format of the file as long as it's human readable. It could be XML or it could have something more like INI format

[Header]
  Key=value
  Key2=value
...

Is there a way to minimize the amount of boiler plate code I would need to write to manage storing/reading configuration items?

Should I just create Data Transfer Objects (DTO)/structures and mark them serializable (Does that generate bloated XML still human readable?)

Is there other suggestions?

Edit: Not that the software has to write as well as read the config. That leaves app.config out.

+2  A: 

YAML for .NET

Mark Cidade
+1  A: 

I suspect that what you'll want to use is an app.config file which contains your settings in an XML format that .NET will be able to load in using the System.Configuration namesapce.

More info here: http://geekswithblogs.net/akraus1/articles/64871.aspx

theraccoonbear
A: 

I've generally used the registry for storing configurations (I know, bad me!), but using System.Xml to read/write a lightweight XML file isn't hard. In fact, I've done just that recently for a plugin project that uses XML documents to communicate with its host as well as store its own persistent settings.

There is also the System.Configuration namespace, but I've not really dealt with it.

Chris Charabaruk
+2  A: 

I think both the XmlSerializer and NetDataContractSerializer create human readable XML. I prefer the NetDataContractSerializer because it can do things the XmlSerializer cannot, but those extra features are probably more than you need for this. If you already have classes written for your configurations, one of these two are probably your shortest path to victory.

You could also write your configurations to the local app.config file, or a sub-config file using custom ConfigSections and the Configuration class.

Jason Jackson
A: 

My preference in this situation is to create a DataSet with DataTables for the configuration data arranged in a nice relational way - then use DataSet.WriteXML() to save it to a configuration file.

Then to load it again, you just use DataSet.ReadXML() and it's back in a nice query-able object.

This is an example config file that my app allows the user to edit in a Text Editor window:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<!--****************************************************************
 Config File: FileToExcel_test.cfg
      Author: Ron Savage
        Date: 06/20/2008

 Description: 
 File to test parsing a file into an Excel workbook.

 Modification History: 
 Date       Init Comment
 06/20/2008 RS   Created.
******************************************************************-->

<!--********************************************************************
 Global Key Definitions
********************************************************************-->
   <config key="sqlTimeout"      value="1800"/>
   <config key="emailSMTPServer" value="smtp-server.austin.rr.com"/>
   <config key="LogFile"         value="FiletoExcel_test_{yyyy}{mm}{hh}.log"/>
   <config key="MaxEntries"      value="1"/>

<!--********************************************************************
 Delimiter Configurations
********************************************************************-->
   <config key="pipe"           value="|"/>


<!--********************************************************************
 Source / Target Entries
********************************************************************-->
   <config key="source_1"  value="FILE, c:\inetpub\ftproot\filetoexcel.txt, pipe, , , , , "/>
   <config key="target_1"  value="XLS, REPLACE, c:\inetpub\ftproot\filetoexcel1.xls, , , , , , , ,c:\inetpub\ftproot\filetoexcel_template.xls, ,3"/>
   <config key="notify_1"  value="store_error, store_success"/>
</configuration>

When I load it into the DataSet, all the non-comment tags reside in a table named Config with fields Key & value. Very easy to search.

Ron

Ron Savage
Can a human actually grok a DataSet's XML serialization?
Benoit
Sure, just depends on the complexity of your config table structure. My config loads into a single DataTable named Config with two fields (key, value). I just use the DataSet to read it and access the settings - my app loads it into a text editor to edit it.
Ron Savage
+2  A: 

If you serialize your structure to JSON you get a simpler representation of your object than in XML.

Here's a sample from James Netwon-King's JSON.Net site:

Product product = new Product();    
product.Name = "Apple";    
product.Expiry = new DateTime(2008, 12, 28);    
product.Price = 3.99M;    
product.Sizes = new string[] { "Small", "Medium", "Large" };    

string json = JavaScriptConvert.SerializeObject(product);
//{
//  "Name": "Apple",
//  "Expiry": new Date(1230422400000),
//  "Price": 3.99,
//  "Sizes": [
//    "Small",
//    "Medium",
//    "Large"
//  ]
//}   

Product deserializedProduct = JavaScriptConvert.DeserializeObject<Product>(json);

You can read his blog and download JSON.Net here.

David Robbins
+1  A: 

See the FileHelpers library. It's got tons of stuff for reading from and writing to a lot of different formats - and all you have to do is mark up your objects with attributes and call Save(). Sort of like ORM for flat files.

Justice
I used the FileHelpers lib on a project - it was pretty good stuff.
David Robbins
This is exactly what I was looking for! Simple to use, yet powerful. Directly maps between DTOs and human readable format.
Benoit
A: 

I'd use a data structure that can be serialized into XML - in fact, since I'm lazy, I'd use an ADO.NET DataSet, since it has a simple serialization format that you can produce without having to think terribly hard.

As far as making it human-readable goes: if it just has to be human-readable (and not human-modifiable, which I think is what you're describing here), I'd build an XSLT transform and use it to produce an HTML version of the configuration data whenever I wrote out the XML. That gives you as fine-grained control over the visual presentation of the data as you could possibly ask for.

Robert Rossney