Archive for the ‘ASP.NET’ Category

Why I cannot access classes in .aspx codebehind from the classes in app_code in

December 25, 2008

This is a fantastic problem that I faced. I was having a user control in my application as MSDD.ascx. I wanted to dynamically display this user control from the code written in the Dynamic.cs file in app_code folder of my applicaiton. But at this movement, I was unable to access the MSDD class written in codebehind file from my class in app_code. How can we proceed now???


The best solution is to write an Interface. Place this interface in the app_code folder of you application. The aspx codebehind class should implment this particular interface. Now via interface you can access the codebehind class from you class in app_code folder. See the scenario below:

I have following files:

ASPX: A user control/class named MSDD.

app_code: A call named Dynamic, in which I want to access the above user control class MSDD.

Now write an interface IMSDD and make the codebehind class MSDD to implement this IMSDD interface. So you MSDD class will look like:

public class MSDD : IMSDD


// Code here…


And your Dynamic class which uses the Interface will look like:

public class Dynamic


IMSDDctrl = (IMSDD) Page.LoadControl(“../MSDD.ascx”);

// Now using this interface you can invoke any method/property of the MSDD class this is exposed via the interface.



Hope this helps you…

App_Offline.htm – How to Redirect user to "Down for Maintenance" page in ASP.NET ?

August 13, 2008

Usually there arises a scenario when we want to upgrade our production site to a new release, and want the users to be redirected to the “Down for Maintenance” page.

The best way to implement this is using the app_offline.htm file. ASP.NET 2.0 has provided a fantastic functionality using which the users will automatically be redirected to the “Down for Maintenence” page. Just add a HTML file named “app_offline.htm” to the root directory of your web site. Adding this file will clear the server cache. When ASP.NET sees the app_offline.htm file, it will shut-down the app-domain for the application (and not restart it for requests) and instead send back the contents of the app_offline.htm file in response to all new dynamic requests for the application.

Please take a note that the size of the file should be more that 512 KB to be displayed. If the size of the file is less that 512 KB, then manually IE Browser settings need to be changed. The “Show Friendly Http Errors” check box from the Tools->Internet Options->Advanced tab within IE needs to be unchecked. If this check-box is not unchecked and the app_offline.htm file size is less that 512 KB, then the IE “Page cannot be displayed” message will be shown.

To start the web site again, just remove this file from the root folder of your web site. This will trigger the engine to cache all the page contents and display the pages. This has really made life simple 🙂

Hope this helps! Your comments are always welcome!

ASP.NET Page Life Cycle

August 7, 2008
When an ASP.NET page is requested by the client-browser, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. Moreover, for custom controls, understanding the page life cycle is very important in order to correctly initialize controls, populate control properties with view-state data, and run any control behavior code.

Page Life-cycle Stages
When a web page is requested it goes through a number of stages to get completely built. In addition to the page life-cycle stages, there are application stages that occur before and after a request to the page. Following are the stages under which a page goes before getting rendered to the client.

Page Request: The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled or whether a cached version of the page can be sent in response without running the page.

Start: In this step, the HTTP properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the
IsPostBack property. The page’s UICulture property is also set.

Page initialization: During page initialization, controls on the page are available and each control’s UniqueID property is set. Any themes are also applied to the page. For the page post backs the controls values are not set in this stage from the view state.

Load: During load stage, if the current request is a postback, control properties are loaded with information recovered from view state and control state.

Validation: The Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page.
Postback event handling: If the request is a postback, any relevant event handlers are called.

Rendering: Before rendering, view state is saved for the page and all controls. During the rendering phase, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream of the page’s Response property.

Unload: Unload is called after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and any cleanup is performed.

Life-cycle Events
At each stage of the page life cycle, the page raises certain events that can be used for custom coding. For control events, the event handlers must be bound to the enets. The following lists the page life-cycle events:
1. PreInit
2. Init
3. InitComplete
4. PreLoad
5. Load
6. Control events
7. LoadComplete
8. PreRender
9. SaveStateComplete
10. Render
11. Unload