Incrementally updating a asp.net web site?

Is there a good way to make i开发者_开发技巧ncremental changes to an asp.net website without re-publishing the whole site?

I'm moving an old website from classic asp to asp.net, and one of the things that used to happen on the site was individual pages being changed in isolation. The site is only on a single server, and has a lot of files so doing a re-publish would take the whole site down for a while. I'd like to avoid that, or at least make that time as short as possible.

Each page does have a code behind file, and there's some stuff used by each page in App_Code (just in case that changes the answer).

If you're building a Web Site (rather than a Web Application, where all code is compiled into a .dll in the /bin folder), and it sounds like you are then you can indeed deploy only those files that have changed to the server - up to the value set in numRecompilesBeforeAppRestart in the <compilation> element of the machine or web.config files - this defaults to 15.

If you deploy a change to the /app_code folder this will cause a re-compilation of the site as this is a shared area.

One thing to point out: In VS2008 and below, the publish site command will often publish the entire site - I believe that this is much better in VS2010 where it's easier to publish just the changed files - so this will require a manual deployment of the changes.

You can set Visual Studio to generate fixed assembly names. For each page (master, ascx) a single assembly is generated, and it will have always the same name. With this option you can update only the changed files. Anyway bear in mind that this operation is error prone because you lose the automatic control over the assembly interactions (if any), so you could experience a runtime error if something goes wrong. Lastly if you have a lot of pages this mode will be less performant.

http://msdn.microsoft.com/en-us/library/aa992037.aspx

Can divide the web application into seperate class libraries. This way you can just recompile and drop the relevant DLL into the published bin directory without publishing the whole site. Adding a version number to the class library will help in identifying it. Keep the code behind files minimal by calling methods in those class libraries.

Why not have multiple document roots for the website, one 'live' and one for 'staging'. Publish the changes to the 'staging' area, check and test, and then switch the document roots around in IIS (live becomes staging, staging becomes live) - this should take the site down for the amount of time it takes to recycle the app pool and little more. Update the old 'live' to the new codebase, and wait for the next time you need to update.

By default ASP.NET pages and corresponding codebehind are compiled dynamically when a user first requests a page so you don't really need to republish the whole site when you do just a couple of updates. You can publish only those files.

Dividing application into Muti-Layered architecture, Deploy only changed assemblies. To identify the dependencies and should we deploy their referenced libraries/services also not depends on compatibility issues.. like did we change interface internal code only OR did we change signatures of the methods(interfaces) also... A good article with details http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips#How to Deploy N-Tier Application Correctly

HIH, Phani