Omniscient's Foundation - Blog

Silverlight is about cutting off fat from .NET. However sometimes, I think it cuts where it shouldn't, leading to awkward voids. As mentioned in a previous post, bound commands are probably the most visible void. The way I discuss to work around the problem works perfectly however, so much that I truly think it's a shame that controls still don't support bound commands out of the box after 3 versions. By the way, please go here to vote for commands in the next version. While you're at it, wsHttpBinding would be great as well ;-)

Today, I discuss such harshly missing parts, and again, propose a nice implementation of something close enough to be used almost normally, the client-side configuration file. Most of you may have noticed that there's no ConfigurationManager class in Silverlight. Point of fact, there's no System.Configuration.dll assembly altogether. You cannot do something like this:

MyConfig config = (MyConfig)ConfigurationManager.GetSection("myConfig");

Moreover, there's no upfront "configuration file" in a Silverlight application. That being said, it's easy to add random text file to the .xap, since it's nothing else than a zip file (try renaming the extension, and open it as any other zip archive. While you're at it, try the same with .docx files...). The trick is to compile the file as "Content". Right-click the file in the solution explorer, Properties, and then Build Action = Content. The file will be put in the .xap file. Here's an example of a Silverlight configuration file:

Then you create DTO (Data Transfer Objects) to hold your section's data:

        [XmlType("mything")]
        [XmlRoot("mything")]
        public class Mything
        {
            public Mything()
            {
                this.Subthings = new List<Subthing>();
            }

            [XmlElement("subthing")]
            public List<Subthing> Subthings { get; set; }
        }

        [XmlType("subthing")]
        public class Subthing
        {
            [XmlAttribute("name")]
            public string Name { get; set; }
        }

Then, you use the new ConfigurationManager class to get your section:

All that mimics as much as possible the ConfigurationManager's behavior from .NET. It does add strongly-typed return values though. But keep in mind that this is all fake: the configuration file as shown above is nothing more than an XML file, and won't obey to the rules of a "real" configuration file. For example, I don't even have the mandatory <configSections> tag.

The new ConfigurationManager class I've added to Foundation has two methods: the one you see above, plus an extra overload that takes a second type param of type IConfigurationSectionHandler<TSection> (again, this has been added to Foundation and is not part of Silverlight's code base). That allows you to more control over what's going on, and resembles .NET configSection's "type" attribute. The overload I use in this example uses an XmlSerializer behind the scene (thus the xml attributes on the DTO classes).

Download the code here:
http://omni-foundation.googlecode.com/svn/foundation/trunk

Enjoy!