I came across a situation a while back, where I needed to setup a build process for a Visual Studio 2008 solution that contained multiple projects:
- A bunch of Console Applications,
- A mobile app (targeted at an enterprise-class rugged Windows Mobile 6.5 device to be used on field),
- A desktop Windows Forms application &
- An ASP.NET web application.
We have 3 server environments: Dev, QA & Production on which each of these applications should be capable of running. (Except for the mobile app, which will run on its own SQLCE database file sitting on each hand-held unit). What I needed to come up with, was a way to manage the environment-specific configuration info in a manner that let me do a single build, and “apply” the right set of configuration data according to where I was doing the deployment.
The direct way to do this would be to use the VS Solution/Project Configuration functions. You would create one configuration for each environment. Then you would set up a pre-build event like <code> copy “$(ProjectDir)$(ConfigurationName).<<configfilename>>” “$(ProjectDir)$(OutDir)<<configfilename>>” /Y </code> to copy the right config file over to your build output directory. You can check out this excellent (albeit really old, considering this is VS 2008!) article from Bil Simser –
http://weblogs.asp.net/bsimser/handling-multiple-environment-configurations-with-net-2-0
or this one from Scott Hanselman –
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
The disadvantage here is that you need to do a build with the appropriate configuration selected, in order to get the right set of files selected. I would prefer to have a single build output file, like a TAR/ZIP archive, which includes all the config files for all environments. Then when I deploy/unpack it to the right environment, I want to deploy the right config files based on an argument that I’ll pass into my deployment script. Personally, that makes it easier to control for me, rather than pick the right build configuration on the VS IDE every time. It also enables me to do everything on the command-line too if I want, which is good to have.
Being a .NET newbie, I didn’t have the time to figure out Nant (which is free & open-source btw), so I used Visual Studio’s pre-build & post-build events to make things work the way I needed them to. Here is how it went.
Kicking Tech 