Production vs Test environment setups

[MdotButler]

This is a question more about the test environment using VS 2008 than ASP.NET but this seemed the best place to ask the question. I know this is something everyone has done in one way or another, but what I am looking for is a better solution than I currently use.

Currently I keep the connection string, SMTP server settings, debug mode, custom 404 error screens and such in the WEB.CONFIG file. When testing I alter this file to the test settings, and then alter it back to the production settings before uploading to the production server. My fear is that I publish the test WEB.CONFIG file to the production server or use the production settings in test mode. I also encrypt various sections which even complicates the switch back and forth.

I have thought about putting a hook into the masterpage or my login script to check for something and alter the WEB.CONFIG settings appropriately. For instance keep two connection strings and when in test mode, overlay the production string with the test string. Don't know what to check for to detect "Test Mode", or if everything in the config file is updateable.

Has anyone devised a better method they wish to share?

TIA
Mark

 

[jmeckley]

look into pre/post build events in Visual Studio builds. This will probably be the easiest to integrate since you are using the default build process in visual studio.

I would create a web.config.template file which is the skeleton of your config; static content + variable place holders. then create 3 files to hold the variables.
local.values
test.values
production.values

copy the web.config.template file to web.config.
replace the variables in the newly created web.config with the local/test/production values.

your web.config is now automatically generated. now all this sounds good in theory. I haven't done anything quite this elaborate myself, but I have seen other build scripts which do this. Hopefully this gets you started though.


Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[jbenson001]

We just create separate web.configs for each environment.

 

[jmeckley]

@jbenson001 - KISS, I like it

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[dinger2121]

I do the same - I don't deploy the web.config to production. I write all updated files, but leave web.config the same.

carl
MCSD, MCTS:MOSS

 

[MdotButler]

It appears that there is no one good answer. In googling around there are many suggestions to the same problem with no concensus as to the best way to accomplish. In my case I am using a "Web Site" instead of a "Project" so the various compilation methods are out.

I am leaning toward a combination of both your suggestions. Because of third party assemblies I end up having to update the web.config file too often. The following is what I have come up with so far.

<connectionStrings configSource="connections.config"/>
<mailSettings configSource="mailsettings.config"/>

Then on my development machine keep both test and production versions of the "configsource" files.

connections.Test.config
connections.Prod.config
mailsettings.Test.config
mailsettings.Prod.config

The above sections are fairly static so removing them to alternate files seems to be an answer. Because both these secions have passwords I now need to see if I can encrypt them and still get away with just copying the corect file to the web.config name in both environments.

Any comments or suggestions?

TIA
Mark

 

[jbenson001]

LOL, thanks Jason

Mark,
Separate web.configs does make it easier because you don't have to worry about chaning settings back and forth, which can cause many problems, especially if your web.configs start to get large. The only thing you have to keep in mind is that if you create new settings in your dev environment, you have to add them to your test and prod environments as well.

 

[MdotButler]

My entire dilema started when I forgot to upload the web.config when an assembly had changed. By keeping the static items in separate config files allows me to upload the web.config file each time it is distributed. I would only have to upload the "configsource" files and rename them on the production server if they indeed changed.

Any comment on encrypting the "configsource" files? Do I have to encrypt the sections while they are in the web.config file and cut/paste them into the "configsource" files? At least that is my thinking currently.

Mark

 

[ca8msm]

The ideal solution is whichever method you choose to use, you go via a staging server (you shouldn't be going direct from dev to live as it's just too prone for mistakes like the one you mention above). Ideally, a staging server should be identical to production and will allow you to test out anything like this prior to publishing to live. If you can't afford to make an identical copy of production, at least use a virtual environment that will allow you to replicate having one.

So, choose one of the methods that suits your application, and then publish from dev to staging. Once you have tested in staging, you publish the files from staging to production. This way you'll safeguard yourself against making any mistakes and it allows you to implement the most suited method for deployment.



Mark,

Darlington Web Design
Experts, Information, Ideas & Knowledge
ASP.NET Tips & Tricks

 

[MdotButler]

Point well taken ca8msm. Unfortunately the live web server is on a hosted environment and the stage and development environment are on local servers. Unfortunately they use different SQL servers and SMPT servers than the production enviroment.

I have decided to use the multiple web.config files for each environment (KISS).

Just to share for those reading along: The configsource method looked promising. I thought I would get smart and build a web.config file with the production connection string, encrypt it, then cut and paste it to the configsource file. That in itself worked but would not decrypt when the substitution was made.

Second point was that I wanted to also use the configsource method to specify the SMTP parameters. Part of which has name and password for authentication, different in each environment. Well the <mailSettings> section does not support the configsource method of inclusion.

With that said there appears to be no one good answer. One thing I will be looking into for connectin strings is a method of attaching the machine name to the connection name each time it is used. You would set up the config.web with multiple connections with the machine names appended. The web.config could then be encrypted and the correct connection string selected via code. Don't know how this works for tableadapters though....

Thanx to those who offered advice...
Mark


for the comnection strings but caused problems when the source files were encrypted.

 

[ca8msm]

Unfortunately the live web server is on a hosted environment and the stage and development environment are on local servers. Unfortunately they use different SQL servers and SMPT servers than the production enviroment.

In that case just set up a staging site on the same hosted server. Publish to it from dev and then from there copy over to the live site. At least that way your staging site will show any potential errors first.

Mark,

Darlington Web Design
Experts, Information, Ideas & Knowledge
ASP.NET Tips & Tricks