Daily .Net Feeds - ASP.Net 2.0 - Advanced - Day 4

Artykuł
07/11/2007

Hi Everyone,

Welcome back!!!

Today and in next few days we will discuss the automatic dynamic page compilation. Each web application has its own copy of the Http runtime and runs in a separate AppDomain. The runtime object creates the Http context for the request, and it initializes the cache and the file system monitor used to detect changes in the application files. The worker process (either aspnet_wp or aspnet_isapi inside w3wp) activates the HTTP pipeline by creating a new instance of the HttpRuntime class and then calling its ProcessRequest method.

As mentioned earlier the ultimate goal of the HTTP pipeline is finding in the current AppDomain a managed class that fully represents the requested ASP.Net resource. For pages, this class derives either directly or indirectly from Page class and follows a particular naming convention. For a page named xxx.aspx, the default class name is ASP.xxx_aspx (if the page features the ClassName attribute in the @Page directive, the actual class name will be ASP.ClassName). If such a class is available in the current AppDomain, it is instantiated and invoked through the methods of the IHttpHandler interface. Otherwise, such a class is dynamically created by the page handler factory object. As we will see tomorrow ASP.Net knows exactly from the contents of temporary files if the page class exists and where it is located.

Note: The dynamic creation of a page class occurs at least the first time the page is requested, right after deployment. The class is shared by all sessions, and only the very first user to hit it after the application is started experiences the compilation delay. After that, the page is recompiled only in case of changes to its source code or any of its dependencies, such as a master page. This first-hit delay can be avoided if the site is deployed in a precompiled form. If the page is precompiled, no dynamic creation occurs. We'll have more to say on precompilation later.

The Page Handler Factory:

The HttpApplication object retrieves from machine.config the name of the handler object to serve requests of a particular type. The following code snippet shows the standard setting that associates the PageHandlerFactory class with .aspx resources. Similar mappings are shown for .asmx (Web Services) and .ashx (custom HTTP handler) resources.

...

</httpHandlers>

The PageHandlerFactory class implements the IHttpHandlerFactory interface, detailed below:

The IHttpHandlerFactory Interface:

Method	Description
GetHandler	Returns an instance of a class that implements the IHttpHandler interface and can serve the requested resource. For pages, this class would derive from Page class. Arguments to this method include the HTTP verb, the raw URL and the context of the request.
ReleaseHandler	Does whatever is needed to enable the factory to reuse the specified handler instance. The default page HTTP handler's implementation of this method simply returns void.

The page handler factory is responsible for either finding the assembly that contains the page class or dynamically creating an ad hoc assembly. The source code for the class is created by parsing the souce code of the requested .aspx resource, and its temporarily saved in the following ASO.Net temporary folder:

%systemroot%\Microsoft.Net\Framewor\[version]\Temporary ASP.Net Files

That's it for today. Thanks for joining!!! See you tomorrow. Tomorrow we will continue with the discussion of dynamic compilation of pages.

Thanks,

Sukesh Khare

Coordinator Daily .Net Feed Program

Comments

Anonymous
July 11, 2007
I think the past four articles really provided some insight for me and all of my team members. This is the kind of articles we are looking for!! Keep up the excellent work!
Anonymous
July 11, 2007
Thanks! Sukesh is doing a really good job summarizing those topics and I’m glad he allowed me to host this session! Best Regards Daniel

Udostępnij za pośrednictwem

Daily .Net Feeds - ASP.Net 2.0 - Advanced - Day 4

Comments

Dodatkowe zasoby