I work for a company that is building a web application with ASP.NET & MVC, which was last worked on a few months ago. I am part of the team working on the project and have encountered values (such as place names) being hard-coded in the project's web.config file.

In my opinion this is bad practice as multiple developers have different versions of the web.config so hard-coding values in this file would result in inconsistencies. Additionally, non-developers may need to add/remove values and have a higher chance of causing unstable behaviour if they accidentally break the web.config (as code cannot be compiled with errors such as missing quotes around strings, but such errors in the web.config may not be caught as they are seen as "valid").

The understanding of my colleagues is that hard-coding values in this way makes it easier for others to change these values, as opposed to maintaining a centralised class containing the values (of which any syntax errors will be caught).

The web.config can be modified on-the-fly without requiring re-compilation, whereas code changes require recompilation. Any changes to these values would be made when the web application is not in use and the deploy environment would automatically recompile before re-deploy anyway.

Am I correct that storing such values in the web configuration file for the application is bad practice?

  • Technically, what you are doing with a configuration file is "soft-coding," not hard-coding. If you have things that should not change from machine to machine, then don't put them in the web.config. Aug 8, 2018 at 13:34

1 Answer 1


Hmm. I think the strict answer to your question

"Is it bad practice to hard-code values in ASP.NET's web.config file?"

is: No. That's what it is for.

However, you do highlight some bad practices

  • non-developers adding and removing values.
  • on-the-fly modification of web.config

You should set the config settings of an app/website when you deploy that app. They should be part of the deployment script/process. No mucking around with them manually!!

  • multiple developers have different versions of the web.config

web.config with some 'dev' values should be stored with the source code. unless a developer is working on a specific feature which changes the config, they should all have the same version.

  • this way makes it easier for others to change these values, as opposed to maintaining a centralised class containing the values

I think this is really your problem with the methodology. It sounds like you are putting more than just config in the web.config file. Enums should be Enums and magic strings/numbers are bad wherever you have them.

But to judge we would have to know what the values were and how they were used.

  • 1
    shrug. The whole point of having a config file is so that you can change values without having to go through your entire release cycle. Non-developers should not have access to web.config anyway. Aug 8, 2018 at 13:31
  • avoiding change controls is bad!
    – Ewan
    Aug 8, 2018 at 13:38
  • Web config is a local file anyway. It should almost certainly never change on the server unless you change the server's configuration or add a new item to the config. It's not code. Aug 8, 2018 at 13:39
  • change control doesn't just apply to code
    – Ewan
    Aug 8, 2018 at 14:08
  • No, it doesn't. But if your configuration file contains local settings (which is what the purpose of a configuration file is, after all), putting it under change control is going to be highly inconvenient, and probably not all that useful. Aug 8, 2018 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.