All of us have already dealt with the problem of promoting configuration files in different application life cycles. this problem can be as simple as managing different connection strings for different databases in each environment to managing the other complicated settings in each environment.
so many times it happens that we forget to update the configuration file (web.config or app.config) before promotes. what we had already done was to keep one configuration file for each environment (development, testing, staging …) and after promote before build overwrite the the existing configuration file. but even in this case we used to miss to update the configuration file with the latest information. anyway i came across the very good solution in Scott Hanselman's blog. ok here is the solution.
- In your project Click the configuration management dropdown and select "Configuration Manager."
You'll probably have Debug and Release configurations, but you can also make custom ones and base them on existing configuration. In this dialog I've made a new "Deploy" and I'll base it on the "Release" configuration.
Make sure to create a Solution Configuration AND a Project Configuration, as they are different. Here I've made one called Deploy for the Project also. If you get an error message, be aware of the "Create new project configurations" checkbox. You might get a warning if you are making a new configuration and the dialog tries to make another configuration with the same name; uncheck the checkbox if that happens. Of course, you can have as many Configurations as you'd like.
2. Add some custom configuration stuff in web.config, like connectionStrings:
1: <connectionStrings>
2: <add name="Foo"
3: connectionString="Data Source=localhost;Initial Catalog=DatabaseName;
4: User Id=sa;Password=debug;"
5: providerName="System.Data.SqlClient" />
6: </connectionStrings>
See now I've made the password in my nonsense connectionString = "debug"? Now, create three new web.config's by CTRL-dragging the web.config on top of the project. Name them web.config.debug, web.config.deploy, and web.config.release. Make the password equal to "deploy" and "release" respectively.
3. Ok, now we've got different configuration and different configuration files. Let's create a batch file called "copyifnewer.bat" and here's the contents:
1: @echo off
2: echo Comparing two files: %1 with %2
3:
4: if not exist %1 goto File1NotFound
5: if not exist %2 goto File2NotFound
6:
7: fc %1 %2
8: if %ERRORLEVEL%==0 GOTO NoCopy
9:
10: echo Files are not the same. Copying %1 over %2
11: copy %1 %2 /y & goto END
12:
13: :NoCopy
14: echo Files are the same. Did nothing
15: goto END
16:
17: :File1NotFound
18: echo %1 not found.
19: goto END
20:
21: :File2NotFound
22: copy %1 %2 /y
23: goto END
24:
25: :END
26: echo Done.
Basically this batch file will copy a file over another if the files don't match. It's not strictly "copyifnewer" (like, not at all) but it does the job.
Why bother with a batch file to check for changes and not just copy over the file every time? Well, each time you copy over a web.config it restarts all the designers and running AppDomains that are watching that file. No need to copy over a file if it hasn't changed...everything will churn less.
Put this copyifnewer.bat file in the root of your project.
4. Create a Pre-build Event. Right-click on your Project and select Properties. Click Build Events and in the "Pre-build event command line" and enter this value:
"$(ProjectDir)copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config"
Notice the magic dust, the $(ConfigurationName) project variable, that contains "Debug" or "Release" or "Deploy."
5. Build. Now if you build, you'll see in the Build Output the batch file being run and the files being copied. Because it's a Pre-Build Event it'll be seen in both the Build Output in Visual Studio .NET.
When you build within Visual Studio the currently selected item in the drop-down list is the current configuration. now you have different configuration file for each build
there is catch here and that is we have to remember that we've got to keep web.config's in sync if there's lots of settings, but we could totally break it apart via "include files."
Subscribe