What are different types of directives in .NET?
@Page: Defines page-specific attributes used by the ASP.NET page parser and compiler. Can be included only in .aspx files <%@ Page AspCompat="TRUE" language="C#" %>
@Control:Defines control-specific attributes used by the ASP.NET page parser and compiler. Can be included only in .ascx files. <%@ Control Language="VB" EnableViewState="false" %>
@Import: Explicitly imports a namespace into a page or user control. The Import directive cannot have more than one namespace attribute. To import multiple namespaces, use multiple @Import directives. <% @ Import Namespace="System.web" %>
@Implements: Indicates that the current page or user control implements the specified .NET framework interface.<%@ Implements Interface="System.Web.UI.IPostBackEventHandler" %>
@Register: Associates aliases with namespaces and class names for concise notation in custom server control syntax.<%@ Register Tagprefix="Acme" Tagname="AdRotator" Src="AdRotator.ascx" %>
@Assembly: Links an assembly to the current page during compilation, making all the assembly's classes and interfaces available for use on the page. <%@ Assembly Name="MyAssembly" %><%@ Assembly Src="MySource.vb" %>
@OutputCache: Declaratively controls the output caching policies of an ASP.NET page or a user control contained in a page<%@ OutputCache Duration="#ofseconds" Location="Any | Client | Downstream | Server | None" Shared="True | False" VaryByControl="controlname" VaryByCustom="browser | customstring" VaryByHeader="headers" VaryByParam="parametername" %>
@Reference: Declaratively indicates that another user control or page source file should be dynamically compiled and linked against the page in which this directive is declared.
ASP.NET Page Life Cycle Overview
| Stage | Description |
| 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 (therefore beginning the life of a page), or whether a cached version of the page can be sent in response without running the page. |
| Start | In the start step, page 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 theIsPostBack property. Additionally, during the start step, the page's UICulture property is set. |
| Page initialization | During page initialization, controls on the page are available and each control's UniqueIDproperty is set. Any themes are also applied to the page. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state. |
| Load | During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state. |
| Validation | During validation, the Validate method of all validator controls is called, which sets the IsValidproperty of individual validator controls and of the page. |
| Postback event handling | If the request is a postback, any 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. |
ASP.NET Interview Questions: ViewState
(1) Does the performance for view state vary according to User controls?
Performance of view state varies depending on the type of server control to which it is applied. Label, Text Box, Check Box, Radio Button, and Hyper Link are server controls that perform well with View State. Drop Down List, List Box, Data Grid, and Data List suffer from poor performance because of their size and the large amounts of data making roundtrips to the server.
(2) What is View State?
View state is a built-in structure for automatically retaining values amongst the multiple requests for the same page. The view state is internally maintained as a hidden field on the page but is hashed, providing greater security than developer-implemented hidden fields do.
(3) What are benefits and Limitation of using View state for state management?
Following are the benefits of using View state:-
. No server resources are required because state is in a structure in the page code.
. Simplicity.
. States are retained automatically.
. The values in view state are hashed, compressed, and encoded, thus representing a higher state of security than hidden fields.
. View state is good for caching data in Web frame configurations because the data is cached on the client.
Following are limitation of using View state:-
. Page loading and posting performance decreases when large values are stored because view state is stored in the page.
. Although view state stores data in a hashed format, it can still be tampered because it is stored in a hidden field on the page. The information in
the hidden field can also be seen if the page output source is viewed directly, creating a potential security risk.
Below is sample of storing values in view state.
this. ViewState ["Enter Time"] = Date Time. Now. To String();
asp.net interview questions: state management
- What is the lifespan for items stored in ViewState?
Item stored in ViewState exist for the life of the current page. This includes postbacks (to the same page). - What is ViewState?
ViewState allows the state of objects (serializable) to be stored in a hidden field on the page. ViewState is transported to the client and back to the server, and is not stored on the server or any other external source. ViewState is used the retain the state of server-side objects between postabacks. - What are the different types of Session state management options available with ASP.NET?
ASP.NET provides In-Process and Out-of-Process state management. In-Process stores the session in memory on the web server. This requires the a "sticky-server" (or no load-balancing) so that the user is always reconnected to the same web server. Out-of-Process Session state management stores data in an external data source. The external data source may be either a SQL Server or a State Server service. Out-of-Process state management requires that all objects stored in session are serializable. - What does the "EnableViewState" property do? Why would I want it on or off?
It allows the page to save the users input on a form across postbacks. It saves the server-side values for a given control into ViewState, which is stored as a hidden value on the page before sending the page to the clients browser. When the page is posted back to the server the server control is recreated with the state stored in viewstate.
What are benefits and Limitation of using View state for state management in asp.net?
Following are the benefits of using View state:-
. No server resources are required because state is in a structure in the page code.
. Simplicity.
. States are retained automatically.
. The values in view state are hashed, compressed, and encoded, thus representing a higher state of security than hidden fields.
. View state is good for caching data in Web frame configurations because the data is cached on the client.
Following are limitation of using View state:-
. Page loading and posting performance decreases when large values are stored because view state is stored in the page.
. Although view state stores data in a hashed format, it can still be tampered because it is stored in a hidden field on the page. The information in the hidden field can also be seen if the page output source is viewed directly, creating a potential security risk.
Below is sample of storing values in view state.
How can you cache different version of same page using ASP. NET cache object?
Output cache functionality is achieved by using "OutputCache" attribute on ASP. NET page header. Below is the syntax
1: <%@ Output Cache Duration="20" Location="Server" Vary By Param="state" Vary By Custom="minor version" Vary By Header="Accept-Language"%>
-
Vary By Param: - Caches different version depending on input parameters send through HTTP POST/GET.
-
Vary By Header: - Caches different version depending on the contents of the page header.
-
Vary By Custom: -Lets you customize the way the cache handles page variations by declaring the attribute and overriding the Get Vary By Custom String handler.
-
Vary By Control: -Caches different versions of a user control based on the value of properties of ASP objects in the control.
What is the difference between Server.Transfer and Response.Redirect? Why would I choose one over the other?
Some of we developers may confused about these 2 method,
Server.Transfer() : client is shown as it is on the requesting page only, but the all the content is of the requested page. Data can be persist accros the pages using Context.Item collection, which is one of the best way to transfer data from one page to another keeping the page state alive.
Response.Dedirect() :client know the physical loation (page name and query string as well). Context.Items loses the persisitance when nevigate to destination page.
In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional integrity, Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the Request object. Sure, there are workarounds, but they’re difficult. Finally, Response.Redirect necessitates a round trip to the client, which, on high-volume sites, causes scalability problems. As you might suspect, Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client.
AutoPostBack Property in asp.net
There is Cancel button and OK button on page. When we click Cancel button it skips all validation controls and goes to next page.
(a)Page AutoPostback of Cancel is True.
(b)Page AutoPostback of Cancel is False.
(c)Page AutoPostback of OK is True.
(d)Page AutoPostback of OK is False.
Which option is correct?
Answers: A button control does not have AutoPostBack property it has click event. so once you click on cancel and if its CausesValidation Property is false it will skips all validations and if it is true it will validate the controls on the page.
AutoPostBack property is for say DropDown textbox etc... whnever you change/enter value/keyed some caharcter in textbox or change your selection in drop down postback will happen if that control's is AutoPostBack property is true depending on that postback you can fill values or set some values for other controls or you can do somevalidation against enterd or selcted values.
e.g. say tehre are 2 drop down. DropDown1 and DropDown2
DropDown2 is currently holding states of US country as in DropDown1 you have selcted US. Now you want to fill DropDown2 with state value of India.
Now if
DropDown1.AutopostBack True;
and you change DropDown1's value from Us to India.
Page will post back to server and you can fill DropDown2 with Indian States.
