When large numbers of developers are involved in creating different applications that have separate web.config files for each application that may hit the same databases, a management issue comes into play. Scott Guthrie posted about this topic and links to a post that provides great details if you'd like to go this route. VS.NET build events are another popular way to handle this problem. While this works well it involves an unnecessary step that should be more automated to avoid human error and involves keeping data in-sync between two or more web.config files. When code has been tested in development and needs to be deployed to staging/test, the staging web.config file can be renamed to "web.config" and then moved over to the staging Web Server(s). For example, while in development the staging web.config file may be named. One way to manage this task is to have multiple web.config files and simply name them differently. Because developers typically have development, staging, and production connection strings to manage (depending upon the environment they are working in), many different strategies have been created to handle switching from development to staging/test to production. If you work with a large number of applications then you know what a pain it can be to manage multiple web.config files and multiple connection strings for development, staging/test, and production databases.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |