Geeks With Blogs

News Ashraful Alam Joy

Create Your Badge

Ashraful Alam is a Software Architect, who has 8 years of professional experience in Software Development industry. This Bangladeshi national is involved with project management and development of several US based software projects from his country. Already he has managed and developed several software projects, which are being used by several users of different countries, such as USA, Canada, Australia, and Bangladesh. While developing and managing a team, he contains and maintains a set of well defined engineering practices developed by him and other online developer communities.

Due to his willingness to give effort to improve and share better software development practices, Ashraf has been awarded as “Most Valuable Professional” (MVP) in ASP.NET category by Microsoft since year 2007 multiple times, which is a rare honor and prestigious reorganization among the developers around the world.

Check his portfolio to know more about him and his works.

.NETTER Characters... Every part of your life is best, if you can know yourself and thus create your life like an artist!

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 in 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, just copy App_Code.dll ( so far I learned!).
  • c. For code change in Global.asax, no need to copy App_global.asax.compiled, just copy App_global.asax.dll ( so far I learned!).
  • 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.


kick it on Posted on Saturday, November 25, 2006 1:53 AM Implementation , Project Management , .NET , Software Development | Back to top

Comments on this post: ASP.NET 2.0 Deployment: Some Common Considerations

# re: ASP.NET 2.0 Deployment: Some Common Considerations
Requesting Gravatar...
Good article. very useful. Here is everything what i looking for.
Left by Ehsan on Dec 06, 2006 9:37 AM

# ASP.NET 2.0 Deployment: Some Common Considerations
Requesting Gravatar...
You've been kicked (a good thing) - Trackback from
Left by on Dec 09, 2006 3:25 AM

# re: ASP.NET 2.0 Deployment: Some Common Considerations
Requesting Gravatar...

Im using Visual Studio 2005, and have used Single Assembly deployment. There are also .compiled files each corresponding to a page. Is there any way i can remove those files and just deploy the single assembly. If i remove the .compiled file I get error when I try to access the page .compiled file refers to.
Left by Mercede on Dec 24, 2008 12:46 PM

# re: ASP.NET 2.0 Deployment: Some Common Considerations
Requesting Gravatar...
yo Great article. It clears up some of the mysteries
Left by Paul on Apr 01, 2009 7:04 PM

Your comment:
 (will show your gravatar)

Copyright © Ashraf Alam | Powered by: