ASP.net using Resource (resx) for Configuration

Question

Let me start with the fact that I'm prepared for this question to be closed as opinion based, but I am going to attempt to phrase it in such a way to keep it less based on opinions.

The Short Version

Are there any practical or best practice resons why configuration settings should not be stored in a Resource (resx) file?

The Long Version

Until recently we were storing application settings in an app.config file and everything was fine as far as I was concerned. A descision was then made to move these settings to a resource(resx) file. The argument being that it provided easier acces to the settings in code as you don't have to remember the key in the resource file (could be overcome with Custom configuration Sections). We also had other settings in the resource file so the additional argument is that we now only have to manage settings in one place. To me this doesn't quite seem right. We have other, in house, components that have been able to be configured via a standard .config file, but this has now changed to fit the new pattern.

Are there any practical or best practice resons why configuration settings should not be stored in a Resource (resx) file?

Answer 1

In my opinion this is a No-No.

There are plenty reasons but from the top of my head, it violates the separation of concerns rule. Resx files are for storing your resources, which are static assets, used mostly for localization/internationalization and have nothing to do with your application's flow; while configuration has a significant impact to how your application behaves.

The benefits of putting configuration keys in resx files: None. Yes, you can refer to resource by using strongly-typed keys and don't have to worry about remembering magic string. But I can do basically the same thing with configuration and a little bit of code (it took me less than an hour to write a custom ConfigurationManager to cast arbitrary config file to strongly-typed object, and this is non-recurring engineering cost because I can use it in any of my future projects).

Drawbacks: Many. For example, maybe later on your team decides to support multi-language and have multiple versions of resx files. That may affect your configuration settings in the way it should not. Or if you compile resx files together with your code, you will lose the freedom of changing config in run-time. More importantly, organizing and managing both resource and config in one place can only be harder overtime.

For me, it may give you a little convenience now, but put a huge technical debt in your shoulder.