Script-Based Configuration in .net?

One of the downsides of web.config/app.config is that it's just Magic Strings everywhere, since it's just an XML file.

Interpreted languages like PHP or Ruby have the advantage that the configuration is just code that is executed. In .net, doing stuff in code requires a redeployment, which defeats the purpose.

Now, before I build my own web.config replacement based on Boo or PowerShell I wanted to know if there is an existing one?

As an example, this here is trivial in code but really hard/awkward in web.config:

IList<TimeZoneInfo> allowedTimeZones =
         System.TimeZoneInfo.GetSystemTimeZones()
           .Where(tz => tz.DisplayName.Contains("Central"));

Basically every time you need to perform complex actions to create an object, XML/String based configurations become extremely messy.

For example, if the allowedTimeZones really should be all that "Start With 'Central' but do not contain 'Europe'", then you start building your own DSL essent开发者_运维技巧ially on top of XML (Rules <add action="startswith" value="Central"/> <add action="doesnotcontain" value="Europe/>). In code, I then need to loop through all of those and either have a large switch statement that translates every line into code, or I could use LINQ-Method Names as Names and use Reflection to invoke them.

If the config file where executable code, I would just modify it to

IList<TimeZoneInfo> allowedTimeZones =
         System.TimeZoneInfo.GetSystemTimeZones()
           .Where(tz => tz.DisplayName.StartsWith("Central") &&
                  !tz.DisplayName.Contains("Europe"));

Of course, since C# is not a scripting language this example would be in a language like Boo or PowerShell that can just be executed by the application.

---

Ended up building my own. Essentially, make use of the App_Code folder (which automatically recycles the Application Pool and thus restarts the application) and use a bit of Reflection in the Application_Start event to get classes that implement a certain interface/base class and run them.

Obvious Disclaimer: Executing random code in your AppDomain can be a security issue as it's far more dangerous than modifying the web.config, but in trusted environments it's quite nice.

---

I haven't seen anything like that. As you said, you could host a scripting language and then simply read a startup script.

Of course, with IOC, you could deploy modified DLLs and point the web.config at them, which would be similar but have a bit of compiling (of the new configuration DLL) to check the code instead of the runtime script having runtime errors. But with all IOC container work, you have more likelihood of runtime errors vs. static errors.

I guess most people are currently putting their dynamic risk in those two buckets right now - magic config files which can have subtle errors or magic IOC which can have subtle errors. Your suggestion would be scripts which you won't know if they fail until they get parsed - a slightly different place to put the troubleshooting - I can see the benefits, though.