views:

518

answers:

5

Hi guys,

We have a mixed development environment of three servers running: Win Server 2003 & 2008, IIS 7 & IIS 6, ASP.NET 2.0 & ASP.NET 3.5. Previously, all three servers were Server 03/IIS6/ASP.NET 2.0, but with this new change, I am finding that pushing/moving any applications from server to server is always a terrifying experience because there are always a variety of problems with the web.config from server to server. I used to consider myself a confident ASP.NET developer but now I am frightened to come to work every day.

I have always used the web.configs that VS generates for me on the Win 2003/ ASP.NET 2.0 server. None of our web.configs are "leet", they are just normal, although we do use ScriptManager and UpdatePanel.

To get by, as a temporary fix, I'm having to remember that when projects are moved/tested/deployed, never to move or overwrite any web.configs and things get confusing very fast. I've tried "ducttaping" like suggested here my web.configs with the new IIS7 stuff but even that doesn't work all the time.

What can I do here, what's going on? Is there a standard web.config that will work on all of the servers and do the UpdatePanel and ScriptManager ?

[edited question]

+1  A: 

Knowledge is a great way to get over fear. Figure out what's going on (you're currently grasping at straws) and the fear will go away.

It's my guess that you'll do better if you refactor the code that uses the config file. Sloppiness there can definitely explain your weirdness and inconsistencies. You can't control much with your config settings if the code isn't behaving properly.

Paul Sasik
+9  A: 

Since IIS6 is the baseline install for your application, you should make sure to run the application in "Classic" mode under IIS7. This makes configuration the same as an IIS6 box. This is how we run our web applications for now until we have fully migrated to 100% IIS7 server environments and we have zero problems with deployment/runtime.

To do this you can either choose to run your app under the built in "Classic .NET AppPool" that comes with IIS7 or, assuming you create your own custom application pools, just make sure you set the "Managed Pipeline Mode" to "Classic" under the "Advanced Settings" dialog for the app pool.

Drew Marsh
I tried this and it did not work. What I ended up doing was shuffling multiple web.configs around.
rlb.usa
You're going to have to define "did not work" because I do this in several environments (including production ones), so I know for a fact it does work. It's precisely why the "Classic" mode option exists in IIS7. If you provide some more information, I will gladly try to assist.
Drew Marsh
@Drew Marsh this was a long time ago... The problem was the different server boxes, IIS versions, and assemblies; turns out a separate config was needed for each box. BUT, I use your advice now every day in the office, "Classic .Net AppPool" all the way!
rlb.usa
+2  A: 

You can use the Classic mode under IIS6 by changing the process. That is actually pretty simple and it should work.

Another approach would be to automating your deployment process and have it so that it deploys the correct web.config to the server when you need to update your application.

Min
+3  A: 

You should seriously look at web deployment projects for visual studio 2008.

This is an official add-on for Visual Studio that gives you a new project type called web deployment project. Among the most useful features is the ability to do web.config search/replace as well as pre-compiled builds of your web sites or web application projects.

In your case, what you'd do is create a solution configuration in visual studio for all of your target web servers. Then you'd create a web deployment project for your web app. In the properties for the deployment project you tell it how you want to compile the project and what web.config replacements you want to use for each solution configuration.

The end result should be that you can open Visual Studio, pick a solution configuration, build the deployment project. The build will create a folder with everything you need for that environment including the correctly configured web.config files. Then you just copy the folder to your server and you are up-and-running.

Best of all, since the different config files are all stored in the projecct, it lets you manage your configuration in one place and check it all into source control.

Do note that there is no equivalent in Visual Studio 2010. Instead, VS 2010 has a whole new deployment mechanism called MSDeploy. With 2010 you don't need a seperate project for deployments, and MSDeploy goes a lot further allowing you to package your SQL databases and other stuff too.

Stephen M. Redd
+2  A: 

If you run your IIS 7 websites using the Classic .NET App Pool, then the config files will match what you would use for IIS 6. That's probably the easiest thing to do until you're ready to migrate everything to IIS 7.

Haacked