Comment On Configuration Disfiguration

Man, I hate it when I have to hard code values into configuration files. If only there were some way to have them read in from an external source...

Actually, if you implement your configuration classes so the runtime image is a separate dll, you don't need to check everything out and do a full rebuild.

This comment doesn't address the WTFness of the post, of course.

Of course, if the software product is sold to a client and installed on their system, and they need to configure things... then the developer has to compile a version just for them. And probably keep track of each client's version. And any changes would also have to go through the developer team, instead of on-site IT staff. Great model.

We have a configuration file compiler for our systems; it allows individual contributors to create sections of the final config file that will be distributed with the product, but it's mostly just an exercise in catenation.

(For example, if the host command to perform a given operation is "4LT-*", that's how it is in the subset config file; if that needs to change for whatever reason [to the much clearer "4L3-$," perhaps], then the module owners can just update the subset config item and the next release of the entire product inherits that config item automatically during the build.)

I can't imagine what kind of insane minds think that configuration items ought to be built into the code. That I can't do so is probably a good thing.

So you are saying that just because its a config change in the web.config, you can skip the "test" step. That makes no sense.

Reminds me of a co-worker that wrote a huge class to output HTML because he didn't like having to write it out by hand. Now not only is it impossible for non-programmer web designers to work on pages he has touched, but even programmers have to scratch their heads when they want to make a simple unordered list.

Oh for the days when configuration files were in the format:

MailServerName=mail.somerandomcompany.com

and you could read them once at the beginning of the application into a singleton settings hashmap that could be accessed from any part of the application when required without having to initialise and run a whole set of XML libraries (during application startup too, thus further delaying the load process).

Configuration files should be simple, and easily alterable without have to invoke a compiler or do any shenanigans apart from !wq and an application restart after your edits.

It seems like they might be trying to solve a problem I've run up against in the past: having several applications that need to share the same configuration data. Since programmers don't like to have duplicated data, having several similar copies of web.config files is annoying.

I maintain about 12 asp.net applications that all share about 80% of their configuration data. What I've taken to doing is to create a configuration table in the database, which all of the applications load data from. Then I store just the connection string in the web.config files.

htg:

Oh for the days when configuration files were in the format:

MailServerName=mail.somerandomcompany.com

Well, the problem with the key-value pair config files is that they are not Turing complete and therefore cannot be extended until they consume all of the program logic.

When someone notices that the configuration class has hardcoded the string, they'll demand that it be read in from an XML file? And then someone will notice that the string was hardcoded in the XML file...

htg:

Oh for the days when configuration files were in the format:

MailServerName=mail.somerandomcompany.com

and you could read them once at the beginning of the application into a singleton settings hashmap that could be accessed from any part of the application when required without having to initialise and run a whole set of XML libraries (during application startup too, thus further delaying the load process).

Configuration files should be simple, and easily alterable without have to invoke a compiler or do any shenanigans apart from !wq and an application restart after your edits.

What a surprise, then, that .Net automatically reads these configuration file settings into the singleton hashtable Configuration.AppSettings, which you can access from any part of your application without having to initialize or run any XML libraries.

And, as a bonus, the config file is parsed the first time you access it, rather than on application startup, so that the load process is not delayed.

Is XML.

No excuses, no comebacks. A solution to a non-problem.

Although I do not agree with using dlls for something that should obviously be added to a config file, the only extra step I can see that this adds ( I don't agree that finding the file is an extra step) is to run the unit tests.

I would say that was a benefit, but what do I know :-)

rmr:

It seems like they might be trying to solve a problem I've run up against in the past: having several applications that need to share the same configuration data. Since programmers don't like to have duplicated data, having several similar copies of web.config files is annoying.

I maintain about 12 asp.net applications that all share about 80% of their configuration data. What I've taken to doing is to create a configuration table in the database, which all of the applications load data from. Then I store just the connection string in the web.config files.

You could use Machine.config for the 80% and individual Web.config for the other 20%.

Damn, I think I worked with these guys at A-B

Doug:

And, as a bonus, the config file is parsed the first time you access it, rather than on application startup, so that the load process is not delayed.

When do you think the first access will occur? During application startup, perhaps?

Not that it was being used this way here, but I can see a valid use for this type of "compiled config". Your application is still relatively easily reconfigured for different installs, but it prevents the end user from mistakenly (or purposely) viewing and/or changing configuration data.

Yes, there are alternative ways of accomplishing that, but having config in a separate compiled DLL isn't so bad, especially since the creation of these DLLs can be automated and created without ever cracking open the source code (such as CodeDom in .NET).

OneMHz:

Of course, if the software product is sold to a client and installed on their system, and they need to configure things... then the developer has to compile a version just for them. And probably keep track of each client's version. And any changes would also have to go through the developer team, instead of on-site IT staff. Great model.

Yeah - my company we have a policy where developers cannot touch the QA servers, UAT servers or PROD servers. We put all code on a buildbox with config changes etc. and a network support person does the build. Xcopy Deployment.

joe_bruin:

Well, the problem with the key-value pair config files is that they are not Turing complete and therefore cannot be extended until they consume all of the program logic.

Which must be the reason OpenAL uses LISP in config files (on linux anyway)...

"So there you have it; a shining example of a common trend in software development. Solving a problem that doesn't exist with the worst possible solution."

Hey - I think my company has the patent on that ... I am going to sue your infringeing ass...

Prior art notwithstanding.

http://en.wikipedia.org/wiki/Reinventing_the_square_wheel

"This is an anti-pattern which occurs when the engineer is unaware or contemptuous of the standard solution and also does not understand the problem or the standard solution sufficiently to avoid problems overcome by the standard. It is mostly an affliction of inexperienced engineers."

There's certain advantages to doing things this way. For example, configuration values are type-checked and you can enforce certain properties, ensuring the correctness of the configuration.

The extra build-step can be avoided too if the code is loaded dynamically rather than expecting an explicitely built assembly.

Still, there's no reason doing this in a language with such a (relatively) complex syntax as C# which on top of things already have a prefectly good solution provided for handling configurations. Then there's the problem with code injection..

joe_bruin:

htg:

Oh for the days when configuration files were in the format:

MailServerName=mail.somerandomcompany.com

Well, the problem with the key-value pair config files is that they are not Turing complete and therefore cannot be extended until they consume all of the program logic.

Says who? It all depends on what's parsing them. For instance,

ins1=mov $eax, $ecx
ins2= .....

assembler.readProgram(file).compile().run()

J.:

There's certain advantages to doing things this way. For example, configuration values are type-checked and you can enforce certain properties, ensuring the correctness of the configuration.

The extra build-step can be avoided too if the code is loaded dynamically rather than expecting an explicitely built assembly.

Still, there's no reason doing this in a language with such a (relatively) complex syntax as C# which on top of things already have a prefectly good solution provided for handling configurations. Then there's the problem with code injection..

.NET 2.0 introduced typed-checked configuration values. So unless running on a pre .NET 2.0 framework, I don't see any advantage.

dpm:

Doug:

And, as a bonus, the config file is parsed the first time you access it, rather than on application startup, so that the load process is not delayed.

When do you think the first access will occur? During application startup, perhaps?

Not necessarily. In the example from this article, the config setting is a mail server address. So you probably wouldn't read it until you needed to send an email. If a given session of your application doesn't send any email, you never need to load the configuration file.

Where do you store the db connection string?

J.:

The extra build-step can be avoided too if the code is loaded dynamically rather than expecting an explicitely built assembly.

Loading an Assembly dynamically is a very expensive operation. I've struggled with the piece of crap that is the default .NET assembly loading rules and ended up having to load some assemblies dynamically.

Along these same lines, if you don't load the assembly dynamically and put an assembly reference in your application, then any time you change a configuration, EVERYTHING has to be recompiled. I believe this was listed in the original WTF post.

Bottom line: Don't do this. You are indeed reinventing a square wheel.

J.:

There's certain advantages to doing things this way. For example, configuration values are type-checked and you can enforce certain properties, ensuring the correctness of the configuration.

The extra build-step can be avoided too if the code is loaded dynamically rather than expecting an explicitely built assembly.

Still, there's no reason doing this in a language with such a (relatively) complex syntax as C# which on top of things already have a prefectly good solution provided for handling configurations. Then there's the problem with code injection..

Config files are the bomb (am I allowed to use that word anymore?)
Especially for values that might potentially change, like say your mail server.

But for values that will never change, like maybe your domain name (no one ever changes your domain name, right?) hardcoding values is ok. But use const's or at least make the readonly's static!

I really hate editing config files too and I just wish I could put arbitrary code in my config files so they could self modify themselves as needed.

chrismcb:

But for values that will never change, like maybe your domain name (no one ever changes your domain name, right?) hardcoding values is ok. But use const's or at least make the readonly's static!

Companies get bought, merged, whatever. We had a healthcheck on a stock system that used our company symbol. The comments in the check code were something like "if this goes away, we have more important problems than the quote system." Needless to say, due to a merger our symbol changed...

And what about java package names? That can get messy real quick. Part of a company gets sold off, so the web service names do what? Change to the new domain? All your customers / clients have to rebuild their code? gah!

chrismcb:

J.:

There's certain advantages to doing things this way. For example, configuration values are type-checked and you can enforce certain properties, ensuring the correctness of the configuration.

The extra build-step can be avoided too if the code is loaded dynamically rather than expecting an explicitely built assembly.

Still, there's no reason doing this in a language with such a (relatively) complex syntax as C# which on top of things already have a prefectly good solution provided for handling configurations. Then there's the problem with code injection..

Config files are the bomb (am I allowed to use that word anymore?)
Especially for values that might potentially change, like say your mail server.

But for values that will never change, like maybe your domain name (no one ever changes your domain name, right?) hardcoding values is ok. But use const's or at least make the readonly's static!

Then there is still the problem with code injection...

There is a place for everything. This is a bad solution to a simple problem, but if this is a place where "They really are after me"-style paranoid security is an issue, then it could be seen as a good thing.

Then again, I've got no problems with a quick recompile of my window manager to change a hotkey set...

Of course this is actually the problem which the Lua language is supposed to solve (of course it's now been 'borrowed' by everyone else as it's a nice lightweight scripting system...)

Always keep it on paper.

Always keep it on paper.

exaxe:

Where do you store the db connection string?

The last place I worked, the guy kept it in a table in the database itself.

YA RLY

chrismcb:

Config files are the bomb (am I allowed to use that word anymore?)
Especially for values that might potentially change, like say your mail server.

But for values that will never change, like maybe your domain name (no one ever changes your domain name, right?) hardcoding values is ok. But use const's or at least make the readonly's static!

Bah! My company recently acquired another company. The massive, home grown order entry system that runs said company is completely tied to the original company's domain name and user name convention.
CAPTCHA ewww ... Ewww is right!

rmr:

It seems like they might be trying to solve a problem I've run up against in the past: having several applications that need to share the same configuration data. Since programmers don't like to have duplicated data, having several similar copies of web.config files is annoying.

I maintain about 12 asp.net applications that all share about 80% of their configuration data. What I've taken to doing is to create a configuration table in the database, which all of the applications load data from. Then I store just the connection string in the web.config files.

Ever heard of machine.config?

Hmmm both are wrong actually. the correct way to store email settings with asp.net is

<system.net>
<mailSettings>
<smtp>
<network host="mail.contoso.com"
userName="email@contoso.com" password="password" />
</smtp>
</mailSettings>
</system.net>

Where do you store the db connection string?

The company I'm working for at the moment (no names no packdrill) insist I write every JavaScript function as an injection function in a .NET class. Not only does this make incremental development of the Javascript a PITA (since I have to do a compile-build-deploy cycle every time I change the JS) it also makes it almost impossible for any subsequent JavaScript sepcialist to change or add to the code without the whole development solution being available a full knowledge of the .NET Helper pattern.

Why not just put it in the aspx file? If it needs to be reused, include the JS file?

Why am I complaining, it ekes out my (per hour) work to a week instead of a day :)

Doug:

What a surprise, then, that .Net automatically reads these configuration file settings into the singleton hashtable Configuration.AppSettings, which you can access from any part of your application without having to initialize or run any XML libraries.

Where .NET, obviously, uses some desperate Perl hacker's collection of regexps.

htg:

Oh for the days when configuration files were in the format:

MailServerName=mail.somerandomcompany.com

and you could read them once at the beginning of the application into a singleton settings hashmap that could be accessed from any part of the application when required without having to initialise and run a whole set of XML libraries (during application startup too, thus further delaying the load process).

Configuration files should be simple, and easily alterable without have to invoke a compiler or do any shenanigans apart from !wq and an application restart after your edits.

Ah, the Java way. However you have to remember this is the .Net way where XML is king (MicroSoft gave us the disaster known as SOAP lest we forget). I'm sure there's something in this wonderful .Net IDE I keep on hearing about that hides the XML format behind a nice table widget that lists name value pairs. If not, then when faced with XML format then the originators of the compiled class of configuration options probably thought they were just replacing one WTF with another.

Watson:

Doug:

What a surprise, then, that .Net automatically reads these configuration file settings into the singleton hashtable Configuration.AppSettings, which you can access from any part of your application without having to initialize or run any XML libraries.

Where .NET, obviously, uses some desperate Perl hacker's collection of regexps.

Yes, because

"([^=]+)=(.+)"

is so desparate and such a huge collection ...

Where do you store the db connection string?

J.:

There's certain advantages to doing things this way. For example, configuration values are type-checked and you can enforce certain properties, ensuring the correctness of the configuration.

The extra build-step can be avoided too if the code is loaded dynamically rather than expecting an explicitely built assembly.

Still, there's no reason doing this in a language with such a (relatively) complex syntax as C# which on top of things already have a prefectly good solution provided for handling configurations. Then there's the problem with code injection..

That's why I like when people use the simple Perl language to store their settings... That way, we get no extra complexity while still getting all type safety of Perl itself.

Should I mark it as ironical? Or is it clear enough? If I wan't to ensure correction of a setting at runtime, I check it, it is not only the compiler that can do that.

Although no excuse, one of the reasons some developers need configuration classes like this is if any environment-detection or other code needs to be executed at the configuration level.

IMO, one of the flaws with using web.config is that it offers nothing in the way of environment detection - each time a web application is deployed, the developer needs to make a conscious effort to exclude this file, or if changes have been made to it, then merge the changes.

Personally, I use a custom configuration library with environment detection, but something like this should be built into the .net framework.

I don't see a problem hard-coding configuration parameters in the code files. That's what constants are for. However, I'm sick of hard-coding my code in the code files. That's why I developed a generic RunIt() function that takes as a parameter a string of code stored in the config file.
--Rank

There is a big problem with storing configuration values in a file: updating them centrally.

Config files are fine for personal use apps, but if an app is for business use, then configuration should be in the registry, so it can be updated in an AD integated way using Group Policies.

And with .Net being meant for business applications, I can't understand why they started using xml files other than hype.

Rank Amateur:

I'm sick of hard-coding my code in the code files.

Yeh, me too. I prefer to code them somewhere else.

We overcame that problem in our systems by having a web.config.template file - when you run the build script, the .template file is compiled into the final .config file, depending on whether you're compiling for dev, test or release. So, eg. running "build release" creates a web.config using the production values, whereas "build dev" will build one using the developer's local database.

Shell scripting combined with .NET is the way forward!