0

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?

AStopher
  • 101
  • 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. – Robert Harvey Aug 08 '18 at 13:34

1 Answers1

3

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.

Ewan
  • 75,506
  • 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. – Robert Harvey Aug 08 '18 at 13:31
  • avoiding change controls is bad! – Ewan Aug 08 '18 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. – Robert Harvey Aug 08 '18 at 13:39
  • change control doesn't just apply to code – Ewan Aug 08 '18 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. – Robert Harvey Aug 08 '18 at 14:51
  • perhaps we are talking at cross purposes. for the last few years 90% of configs I've worked on have had change control implemented via octopus deploy or custom deployment scripts of some kind. If i want to change a setting I have to create a new deployment version and deploy it. Editing the config directly would bypass this 'change control' – Ewan Aug 08 '18 at 15:01
  • If i want to change a setting I have to create a new deployment version and deploy it. -- Which sort of defeats the purpose of a config file, doesn't it? If you have to go to the trouble of making a new deployment every time you change a setting, you might as well just put the settings directly in the code. – Robert Harvey Aug 08 '18 at 15:25
  • well no, because A. different servers have the same code, but different config and B. the purpose of config is not to avoid the change controls you have on your code. – Ewan Aug 08 '18 at 15:28
  • So just to be clear on this, you're going to go through an entire release cycle (including a version change) for every one of your servers, just because there are some differences in configuration settings for each server? – Robert Harvey Aug 08 '18 at 15:40
  • its a bit more complicated than that. if its on octopus you can change the setting there, scope it to environment or machine, create a new release version and deploy it with a few clicks – Ewan Aug 08 '18 at 15:42
  • if you have some custom deploy scripts, then maybe you have a json file on a git repo which you would update, push then pull and run the script from teamcity or something. – Ewan Aug 08 '18 at 15:43
  • the point is every change gets audited and you can roll back to a previous version. unlike the old skool, open config with notepad, hit save, go for beer – Ewan Aug 08 '18 at 15:44
  • Yeah, I like the scripting idea a lot better than doing a release for every server. – Robert Harvey Aug 08 '18 at 15:44
  • i never said do a seperate release per server – Ewan Aug 08 '18 at 15:45
  • You said "put the config file in source control," which implies a release for every change. – Robert Harvey Aug 08 '18 at 15:48
  • ahh, the base config file with dev settings, these are then replace by the deployment script with the correct ones for the machine its deploying to – Ewan Aug 08 '18 at 15:49
  • Ok, that makes sense. – Robert Harvey Aug 08 '18 at 17:01