A reader recently sent some emails asking about one of my articles, Application Settings in VB.NET 2008. To answer the question, I read the article with fresh eyes and decided two things:
- It needs some work! (Click here to read the new article.) Every writer should be forced to review his own work.
- Microsoft has some work to do in Applications Settings architecture too.
I've read everything I can find about it and it seems to me that it just doesn't do what they say it does. In fact, I can find half a dozen message threads in forums between Microsoft forum watchers (MSFW) and programmers with problems (PWP) that read something like this.
PWP: This doesn't work.
MSFW: Yes it does. Do this.
PWP: No, it doesn't. I tried what you said and it doesn't work.
MSFW: Do this and it works.
< ... End of thread - I assume PWP got tired of talking to a wall and went away. ... >
Oooo! That's frustrating! Past experience reporting these kinds of problems through official channels to Microsoft has generally resulted in them saying something like, "The software works as designed." (In other words, "I've got a secret and I won't tell - I won't tell - I won't tell!")
In an effort to at least not repeat the same error, I've rewritten the article to both clarify what I do understand and clearly state what I don't understand (and suspect that Microsoft needs to rework). Read the article and if you can explain something, let me know and I will tell. And if you have experienced bugs trying to use application settings, let us know that too. There's a survey at the end of the article.
Dudes, why store all your settings in .config files? You will then have never ending problems for example:
1) Require to keep separate config files between development -> QA -> production
2) Can easily forget to change a config and let a production server points to a QA config etc.
I highly suggest that you store configs in a database and only have connection strings in config files.
Kind Regards,
Lennie