Regarding the previous ages of VS.NET 2005, web project deployment was pretty simple, but with limited options. For different types of projects, you may have different types of deployment requirements. For example, you may wish only to update the dll or contents for each component of the project separately, specially if the project is too big to take much time to upload the components  each time. For smaller projects, it would be great if we can upload only one file to reflect the new changes of a project.

In the age of VS.NET 2005, I found that there several options have been offered to developers, initially which may make the developers confused. Basically there are two basic issues which should be considered at the top level of deployment design. One is content based and the another one is assembly based. When publishing a web site, there are two options are in place in this issue, which are being discussed here respectively.

1. Allow this precompiled site to be updatable

in ASP.NET deployment, we can put the aspx files is corresponding locations, just as a place holder, where the contents will be placed in the corresponding .compile file in the bin folder, which can be enabled by making this option false. In that case, the following issues should be reminded:

a. .compile file and the corresponding file should be placed for each update of a given aspx, master file. If there is only change is code-behind class (i.e. code), this file should be included too.
b. For code change in App_Code, no need to copy App_Code.compiled for each change, just copy App_Code.dll for each change and copy App_Code.compiled once.
c. For code change in Global.asax, no need to copy App_global.asax.compiled for each change, just copy App_global.dll for each change and copy App_global.compiled once.
d. For changes in CSS files of App_themes CSS should be copied manually. (I don't have tested image and skin files yet!).
Any way, if this option is true, the deployment still requires .compiled file, but not for the pages, but for App_Code folder, App_global.asax files, which will be used as a resource locator. So any changes to these contents doesn't require to upload this files for the maximum time. I am not sure when the updated version of these files should be deployed, but to deploy the updated version of these files is a recommended practice!

2. Use fixed naming and single page assemblies

For deploying assemblies of a ASP.NET 2.0 projects there are three ways to do:

a. Single page assembly:

In Visual Studio 2005, for a ASP.NET 2.0 web application, we can deploy separate assemblies for each pages of the site! This can be done by enabling the above option.

If the ' Allow this precompiled site to be updatable' is disabled, that means a corresponding .compile file should also be deployed with the assembly of each page. In this case, if there is any change  in the content (i.e. text etc) of the page, we need not to deploy the updated .compile file in the web, as all contents are placed in the dll, but as the resource locator or for the basic rule, Atlas one version of .compile file should be placed in the bin directory of the deployment site. Any way, no matter, whether the change has been done in content or code, the page dll MUST be deployed! For a change in content, if only .compiled is provided, there is no error, but change will not take effect!

b. Batch assembly:

For different type of contents and codes, different sets of assemblies will be generated, if we make the above option false. So any change in the code of a page, requires the corresponding set of assemblies to be deployed. For aspx pages, there are few assemblies will be generated, with ' App_Web' prefix. Since, we don't know, Exactly which ' App_Web..' assembly belongs the code for the updated page, we need to deploy all the assemblies prefixed ' App_Web' if there is any change of a page.

For batch assembly, each dll includes a encrypted key in it's name (for instance App_Web_pr_login.aspx.16ec59e1.dll), and for separate web publishing, there are separate keys for the same type of contents, thus separate file name for the newer version. One interesting thing about these assemblies is,  newer version of assemblies can reside in the same deployment directory with the previous set of versions, without any conflict, and the newer version will automatically take place during execution of the corresponding content!

Also, if the 'Allow this precompiled site to be updatable' is disabled, and no updated version of .compile file is provided for the change on content side of the page, only deployment of the assemblies will not reflect the change in content side, unlike "Single page assembly" deployment. For change in the content side, both assembly and .compiled file MUST be deployed.

c. Merged assembly:

All of the coding contents can be embeded to a single assembly, like VS 2003 age, using a VS add-in named 'aspnet_merge.exe' provided by Microsoft. Unfortunately, this tool is not provided by default and should be downloaded and installed separately.