Handling Connection Strings
This issue comes up periodically in the newsgroups and I figured I'd address it so I can just point back to it in the future. In essence, the question comes up "Should I use app/web.config files to store connection strings or should I hard code it in the application?"
Now there's two schools of thought, 1) Hard code them and recompile whenever necessary b/c they shouldn't change very option 2) Store them in configuration files or hide them in the registry. A former coworker of mine told me he worked with a guy who actually proposed storing it in the database but that has obvious shortcomings so I won't address it (and let me forewarn you, if you write me an email telling me that storing connectionstrings in a database isn't a bad idea, I'm not going to respond).
The only 'real' merit from my point of view in the #1 approach is security but I think that's dubious at best in a .NET scenario. The argument I've heard is that it would take someone getting a hold of the .dll, knowing which dll and class contained the connection string and knowing how to use Reflector or read IL to get it out. To me, this oozes of security through obscurity and is a bit lame.
The only 'real' criticism I've heard hard coding advocates make about using Web.config/app.config or the registry is that if someone has access to the web.config file, that they can see your connection string and change it. This assumes that you haven't encrypted your connection string and if you aren't going to do that, then you probably deserve to be hacked. So, let me go on record saying that I think it's dumb to have a plaintext connection string anywhere in your application, unless you have data that doesn't matter if it's compromised. Similarly, make sure that unless you have a strong reason to do so, that you don't have any of your connection objects stored as public properties in your DALC classes. A former coworker of mine told me of a case where they did everything right with respect to storing the connection string, but had the connection as a public property. So all you needed to do was Debug.WriteLine(DalcClass.Connection.ConnectionString); and there it was plaiin as day. Not much you can do about this though - although some db's have native support for encyrpted connection strings.
Another thing I hear brought up is that you don't have to change back ends very often so using a config file is useless. Well, the first part is probably true. But in most instances, you have at a minimum a test and production database. Many of us have unit test databases, and staging dbs as well. Having to recompile the application each time just so you can point to a different db seems kind of lame to me.
In short, I don't see any real benefit to hard coding your connection strings. Most of the points I've heard for it seem to be based on the fact that somehow an evildoer would not be able to figure out which class your connection string was in. More and more though, bad guys may not be outsiders and a lot of these obscurity based assumptions may not be valid. Salt + Hash + Config seems like a pretty good approach to me.
Your thoughts?