There's been a lot of talk about this subject going all the way back to before the initial
release of .NET 2.0, but no one seems to be able to come up with a definitive solution. It seems that application configuration in .NET is very confusing, especially when it comes to deployment.
To my way of thinking, you ought to be able to simply include a different app.config file in your deployment package (most commonly, to use a different connection string when deployed), and have those settings picked up at runtime on the target. Otherwise,
what the heck is app.config good for?
Some people have suggested placing the settings in web.config instead, but contrary to what many believe, IF your DAL is in a
class library project, you CANNOT access the web.config file from the TableAdapter wizard nor the property setting of a TableAdapter (I'm trying it even as I write this just to be sure... nope, can't.)
Certainly, during the build process, any changes you make in app.config, it being one of your source files, ought to be compiled into the project settings (the settings.settings file and/or the x.exe.config file). You should not have to reopen Visual Studio,
open the properties form and answer a pop-up message box to make this happen.
My conclusion: It's probably true that Typed Data Sets should not be used in production except in very simple applications and in situations where the developer also has control over the deployment target environment.
I'm just starting to use the newer tools now, and am hoping that this situation is addressed in VS2008 some way or another, either by improving application configuration, or by providing better direction to developers in the form of documentation that is clearer,
consistent and -- just as important -- easy to find.
I should have mentioned: If you do use Typed Data Sets, don't put the Data Access Layer in a separate (class library) project. Instead, just add it to your Web project. If you do it that way, your table adapter WILL be able to read the web.config file, will
do so at runtime, and you won't run into the deployment problem.
This is the approach taken by Scott Mitchell in his excellent tutorial series on the ASP.NET community site. In one of the tutorials, Scott recommends placing the DAL in a separate project, even though the sample application is all in one project, for simplicity.
Recommendation: check out the data tutorials, but do as he DOES, not as he SAYS