Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Compilation and Deployment in ASP.NET 2.0 : Page 2

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.


advertisement
How Things Work in ASP.NET 1.x
If you're like me, you probably come from an ASP.NET 1.x background and you're very familiar with that model. To put things in perspective, let's first review how things work in ASP.NET 1.x and Visual Studio 2003. ASP.NET 1.1 uses a CodeBehind model based primarily on inheritance. When using the default CodeBehind model that Visual Studio 2003 promotes, you have a CodeBehind class that acts as the base class for the final ASPX page class that ASP.NET 1.x generates at run time. So there are two classes: One class contains your user code, the control definitions, as well as event hookups. At run time, ASP.NET generates the second class that contains the page parse tree, which is a code representation of all the HTML markup and control definitions in the ASPX page.

The ASP.NET 2.0 compiler can compile Web sites directly from source code without an explicit compilation step.
The CodeBehind base class includes control definitions, event hookups, and of course page-specific code, which handles page-level events such as Page_Load and event triggers such as button clicks or change events. Visual Studio generates control definitions and event hookups at design time. This has been a sore point in Visual Studio 2003 because it occasionally mangles the event hookups, mysteriously losing events you had previously mapped to page handlers. Then, when you run the application for the first time, ASP.NET dynamically creates a new class that contains the page control tree, which is responsible for turning the HTML markup, script tags, and control definitions on the page into executable code. Basically, each control is parsed into a method that assigns the control attributes to properties. Containers call child methods to set up controls, which is why it's called a parse tree. This tree can potentially be many levels deep depending on the page control hierarchy. The generated class inherits from your CodeBehind class; your control definitions and event handling code are accessible to this class. The additional code generated is responsible for rendering the page.

Visual Studio (or the command-line compilers) explicitly handles the compilation of all the CodeBehind code in ASP.NET 1.x, which creates a single assembly from all your CodeBehind code of all pages, controls, and classes defined in the project. On the other hand, any markup pages (ASXP/ASCX/ASHX etc.) always parse and compile at run time. ASP.NET dynamically creates this page class and compiles it into an individual assembly in the Temporary ASP.NET Files folder, one assembly per page. This assembly in turn imports a reference to the CodeBehind assembly, so all the CodeBehind pages, control classes, and support types are always accessible to the generated page class. Although each page and control compiles into a single individual assembly, each page or control has a dependency on the single CodeBehind assembly that contains the user code for all the pages and controls in the project. It's a relatively simple yet elegant model and it has worked well for ASP.NET 1.x. Single Page, Inline Markup Pages
In addition to the CodeBehind model, ASP.NET 1.x also supports single page, inline markup pages. In this model, the ASPX page (or ASCX control) contains both the HTML markup and all the required script code, placed between code markup (<% %>) or <script runat="server"> tags. In this page model, all compilation occurs at run time and ASP.NET parses the single page into the control tree class directly inherited from System.Web.UI.Page. The class contains embedded user code inside script tags, which ASP.NET parses into the appropriate class areas. Server <script> tags become class members, so event handler methods, custom methods, and property definitions are created inside server <script> tags. You can also use inline code snippets which use <% %> (for code blocks) or <%= %> (expressions). The compiler parses the <% %> segments inline to the rendering code.



Like the CodeBehind model, this class compiles into a single assembly stored in the Temporary ASP.NET files folder. The single page model is very simple and requires no explicit compilation step. Unfortunately, Visual Studio 2003 did not support the single page model very well. Most developers rarely used it—and maybe for good reason, because using the CodeBehind model encourages separating your markup and code. This single page model has carried over to ASP.NET 2.0 and changed very little in the process, but Visual Studio 2005 now supports creating single inline pages.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

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