Methods for managing multiple application environments

I'd like to know what people have to say about managing an application within different environments. Imagine that you have four different machines, one is a Live webserver, Live dB server, Testing webserver and a Testing dB server. Now, you would like to create the same application in both webservers where they work with their respective dB server. My question regards how people manage this whether through 3rd party tools or methods/tricks.

From my research, I've found two ways of doing this and although both work, I figure there may be a better solution.
Has a nice article on achieving this goal. Basically this amounts to a dialog that allows you to chose a configuration file when deploying an application.

2. In my case, I created the application on the testing server and used the <appSettings> tag in the web.config file to define a key called 'connection' that houses the dB connection string. This way, in my app I use the following command to run a query:
myConnection = new System.Data.SqlClient.SqlConnection(ConfigurationSettings.AppSettings["connection"]);
Then I used the command, Project->Copy Project to copy this app to the Live server and made sure to change the key 'connection' to point to the Live dB

Although number 2. works great, it would be annoying in the case that there are more changes than just the connection string. In that case, I could see that the article I mentioned would be an improvement. Regardless, everytime you write a new application you'd have to work this scheme into it. Is there a better way? Does Configuration Manager provide a way to manage this? I've played around with it and all I see is the ability to turn 'Build' off in a particular configuration.

Any help/suggestion is welcome.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

wsbdc-questionsAuthor Commented:
I forgot to mention that I am using VS 2003. If possible, would anyone point out if there is a considerable improvement in VS 2005 concerning my question?
I use a 3rd party tool.

Beyond Compare:

It is fairly cheap, and very nice.
I don't spend any money at all to do this. You are most of the way there with your web.config appsettings. If you extend this slightly, you can have your key as:
<add key="ConnectionString.MACHINENAME1" value="..."/>
<add key="ConnectionString.MACHINENAME2" value="..."/>
<add key="ConnectionString.MACHINENAME3" value="..."/>

Then, create a class with a static method GetConnectionString(). This will get your machine name, append it to "ConnectionString." and pick the appropriate key.

I use this method to get round the same problem with multiple development machines, and a checked-in web.config file. It just happened to solve my deployment problems as well.

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

I think both mrichmon and myself offer solutions.

wsbdc-questionsAuthor Commented:
Thank you AGBrown. I see your point. Do you see any problems with taking your approach but rather than fetching the machine name and appending it to the connectionstring fetching the connectionstring from either an active or debug release? The reason I ask is because I have not found a way to figure out, within the code, what release mode you are in. I think it would be better doing it this way since different environments require different tweaks simply changing the machinename may not account for all changes. I feel as though MS dropped the ball with this but who knows, maybe 2005 takes care of it.
You can use preprocessor directives to determine your release mode (assuming C# here):
     // debug code
     // non-debug code
#end if

I have a "Production" build defined through Visual Studio that defines a PRODUCTION symbol, so just before release to server I use:
     // debug code
     // Production release
    // other non-debug code
#end if

Using this you can run different code depending on your release, pick up different values from the config file etc. I actually run a class with a bunch of static properties that access the web.config file, they use both the preprocessor and machine name methods to get the right values.

Of course, I can see this becoming unattractive if you don't want to distribute connection strings for servers to all your developers. But I can't think of a better way in that case.

Here's the MSDN reference for the processor directive #if:


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Fonts Typography

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.