ASP.Net 2.0 Compilation Model

The ASP.NET compiler (aspnet_compiler.exe) was originally introduced in ASP.NET 2.0 as a way of completely precompiling an entire site, making it possible to deploy nothing but binary assemblies (even .aspx and .ascx files are precompiled).
This is compelling because it eliminates any on-demand compilation when requests are made, eliminating the first postdeployment hit seen in some sites today. It also makes it more difficult for modifications to be made to the deployed site (since you can't just open .aspx files and change things), which can be appealing when deploying applications that you want to be changed only through a standard deployment process.
The compiler that ships with the release version of ASP.NET 2.0 supports this binary-only deployment model, but it has also been enhanced to support an updatable deployment model, where all source code in a site is precompiled into binary assemblies, but all .aspx and .ascx files are left basically intact so that changes can be made on the server (the only changes to the .aspx and .ascx files involve the CodeFile attribute being removed and the Inherits attribute being modified to include the assembly name). This model is possible because of the reintroduction of inheritance in the codebehind model, so that the sibling partial classes containing control declarations can be generated and compiled independently of the actual .aspx file class definitions.

So, there are three Deployment Mode; vs2005 deploys a site using updatable mode by default but using aspnet_compiler.exe utility one can use other two option as well that is all source and all binary.

All Source Mode: This mode is generally used while in development phase.

All Binary Mode
When the binary deployment option is used
aspnet_compiler -v /MyWebSite -p "F:\Samples\MyWebSite" "C:\Inetpub\wwwroot\MyWebSite". It results in
1) The .aspx files in the deployment directory, they are just marker files with no content. They have been left there to ensure that a file with the endpoint name is present in case the "Check that file exists" option for the .aspx extension in an IIS app is set.
2) The PrecompiledApp.config file is used to keep track of how the app was deployed and whether ASP.NET needs to compile any files at request time.
3) A precompiled dll which includes all the codebehind files for .aspx(separate assembly per directory) , .ascx(separate assembly per directory) , .master files and App_Code folder.

Updatable (mixed) Mode

To generate the "updatable" site, you would add a -u to the command line, and the resulting .aspx files would contain their original content (and not be empty marker files). Note that this functionality can also be accessed graphically through the Build | Publish Web Site menu item of Visual Studio 2005, as you can see in Figure 5. Both the command-line tool and Visual Studio rely on the ClientBuildManager class of the System.Web.Compilation namespace to provide this functionality.

Deploying a website executing the following command
aspnet_compiler -v /MyWebSite -p "F:\Samples\MyWebSite" -u "C:\Inetpub\wwwroot\MyWebSite"

results in a precompiled dll which includes all the codebehind files for .aspx(separate assembly per directory) , .ascx(separate assembly per directory) , .master files and App_Code folder.


Things to be cautious
Another thing to keep in mind when considering the file-to-assembly mapping is that the use of the internal keyword to prevent external assemblies from accessing methods in your classes may work in some deployment scenarios and not others, because of the different assembly mapping options. Unless you plan ahead of time which deployment option you will be using, it is probably best to avoid internal methods in your pages and stick to the type-scoped protection keywords: public, protected, and private.