RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Compilation and Deployment in ASP.NET 2.0 : Page 3

Compilation and deployment are key features that ASP.NET developers should understand quite well. Find out how the process works and what options are available to compile and deploy your applications effectively.

Page Compilation in ASP.NET 2.0
At the core of the changes in ASP.NET 2.0 is the new way that page compilation works. The key difference is that ASP.NET itself asserts much more control when compiling your Web application. By doing so, the ASP.NET compiler is more self-contained and can produce more modular output than ASP.NET 1.x was able to accomplish. This feature makes it possible for Visual Studio to provide an easy model for creating or changing an ASP.NET page or control and being able to run that page or control immediately without first having to recompile it. ASP.NET uses its new compilation model at run time and Visual Studio uses it at design time, which allows it to dynamically compile pages and provide IntelliSense information about the pages and controls you're working on.

The ASP.NET Compiler
The key compilation feature is the new ASP.NET pre-compiler, which compiles Web applications. You use the pre-compiler instead of explicit compilation using the C# or Visual Basic .NET compilers. The compiler comprises a set of internal APIs in the System.Web assembly, as well as a new command-line utility called ASPNET_COMPILER.EXE.

The ASP.NET compiler manages the compilation process of pages and controls dynamically, and decides how to compile them individually. It parses the content of the site and passes off the compilation of each page/control to the appropriate C# or Visual Basic .NET compiler. In fact, in ASP.NET 2.0 it's possible to mix .NET languages in a single Web project, so you can create pages and controls in either C# or Visual Basic .NET in the same directory. ASP.NET figures out which language the developer used and creates a separate assembly for the C# and Visual Basic pages/controls.

The ASP.NET 2.0 compiler is much more thorough in compiling pages because it picks up related resources; specifically the CodeBeside classes (using the CodeFile= attribute discussed a little later) that contain your user code as well as the traditional markup that is stored inside the ASPX, ASCX, ASHX, or MASTER pages. This makes it possible for the ASP.NET to compile all code at run time-or more accurately, at pre-compile time-without requiring an explicit compilation step by Visual Studio or another development environment. Remember that in ASP.NET 1.x with CodeBehind you had to explicitly compile your CodeBehind classes. In ASP.NET 2.0 this explicit compilation step is no longer necessary, because the ASP.NET compiler compiles everything related to the Web project on its own.

Your application-specific code can go inline in the ASPX page or control, it can go into a CodeBeside partial class, or you can create completely autonomous classes in the APP_CODE folder. The APP_CODE folder is a special folder in an ASP.NET 2.0 project; any non-page or control-related source code in your Web project must go into this folder. ASP.NET treats the content of APP_CODE like a library project, compiling the content into a separate assembly. This assembly is then referenced by all the page or directory-level assemblies that ASP.NET creates from your ASPX/ASCX pages that use any of the classes defined in APP_CODE.

By default, ASP.NET 2.0 compiles pages and controls on a per-directory level. This means that your application probably contains pages in multiple separate assemblies.
By default, ASP.NET compiles pages and controls on a per-directory level. The compiler takes all pages, controls, and master pages written in a given language (C# or Visual Basic .NET) in a directory and compiles them into a single assembly containing everything that the page or control requires. If you have multiple directories you will have one assembly for each. By default, each directory compiles into a separate assembly, but the compiler can also create one assembly per page/control. When running Visual Studio using directory-level compilation, every time you make a change in a page or control, the directory-level assembly recompiles. If you make a change in any files in the APP_CODE folder, the APP_CODE assembly also recompiles.

Each of the directory/page assemblies references the APP_CODE assembly, as well as any explicit references added to the page via the @Reference, @Import, or @Register directives, and any external assembly references stored in the BIN directory. Because your entire Web application is no longer contained in a single assembly, these explicit directives are often required to make content from other directories available to pages in the current directory. This has a number of implications in terms of being able to reference other pages and controls from a page, which I'll discuss a little later.

As a result of this more full-featured and complex approach to compilation, the compiler can completely handle site compilation on its own. If you take all your ASP.NET ASPX/ASCX/MASTER Pages and .cs or vb.net files and copy them to the server, ASP.NET 2.0 will compile everything completely at run time on the server and execute the site.

This is a nice development feature that makes it very easy to share applications with others. However, for real-life deployment scenarios, this all-code deployment method is less than optimal, so ASP.NET also supports pre-compilation of your Web site, including the markup code in ASPX/ASCX/MASTER files. Pre-compilation is a separate step that creates a copy of your Web site or development Web site and compiles the site into a ready-to-deploy installation. The scope of pre-compilation depends on the options you choose, which can range from no pre-compilation to pre-compiling both code and ASPX pages using the ASPNET_COMPILER.EXE command-line utility. There are many different compilation options and I'll come back to this later in the article when I talk specifically about deployment.

At this point you have a high-level view of how the compilation process works, so let's dig a little deeper into the actual page compilation mechanisms.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date