CAC Abhinav .Net Notes Entries (RSS)

  Comments (RSS)

Home .Net   Framework Ado.Net Asp.Net C#   .net C#   Notes Java   Script Project   2011

Asp.NetASP.NET State Management OverviewA new instance of the Web page class is created each time the page is posted to the server. In traditional Web programmin  g, this would typically mean that all information associated with the page and the controls on the page would be lost with each round trip. For example, if a user enters information into a text box, that information would be lost in the round trip from the browser or client device to the server.To overcome this inherent limitation of traditional Web programming, ASP.NET includes several options that help you preserve data on both a per-page basis and an application-wide basis. These features are as follows:    

View state Control state Hidden fields Cookies Query strings Application state Session state Profile Properties

View state, control state, hidden fields, cookies, and query strings all involve storing data on the client in various ways. However, application state, session state, and profile properties all store data in memory on the server. Each option has distinct advantages and disadvantages, depending on the scenario.Client-Based State Management OptionsThe following sections describe options for state management that involve storing information either in the page or on the client computer. For these options, no information is maintained on the server between round trips.View StateThe ViewState property provides a dictionary object for retaining values between multiple requests for the same page. This is the default method that the page uses to preserve page and control property values between round trips.When the page is processed, the current state of the page and controls is hashed into a string and saved in the page as a hidden field, or multiple hidden fields if the amount of data stored in the ViewState property exceeds the specified value in the MaxPageStateFieldLength property. When the page is posted back to the server, the page parses the view-state string at page initialization and restores property information in the page.You can store values in view state as well. For more information on using View State, see ASP.NET View State Overview. For recommendations about when you should use view state, see ASP.NET State Management Recommendations.Control StateSometimes you need to store control-state data in order for a control to work properly. For example, if you have written a custom control that has different tabs that show different information, in order for that control to work as expected, the control needs to know which tab is selected between round trips. The ViewState property can be used for this purpose, but view state can be turned off at a page level by developers, effectively breaking your control. To solve this, the ASP.NET page framework exposes a feature in ASP.NET called control state.The ControlState property allows you to persist property information that is specific to a control and cannot be turned off like theViewState property.Hidden FieldsASP.NET allows you to store information in a HiddenField control, which renders as a standard HTML hidden field. A hidden field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in the HTTP form collection along with the values of other controls. A hidden field acts as a repository for any page-specific information that you want to store directly in the page.

 Security Note It is easy for a malicious user to see and modify the contents of a hidden field. Do not store any information in a hidden field that is sensitive or that your application relies on to work properly. For more information, seeASP.NET State Management Recommendations.A HiddenField control stores a single variable in its Value property and must be explicitly added to the page. For more information, see HiddenField Web Server Control Overview.In order for hidden-field values to be available during page processing, you must submit the page using an HTTP POST command. If you use hidden fields and a page is processed in response to a link or an HTTP GET command, the hidden fields will not be available. For usage recommendations, see ASP.NET State Management Recommendations.CookiesA cookie is a small amount of data that is stored either in a text file on the client file system or in-memory in the client browser session. It contains site-specific information that the server sends to the client along with page output. Cookies can be temporary (with specific expiration times and dates) or persistent.You can use cookies to store information about a particular client, session, or application. The cookies are saved on the client device, and when the browser requests a page, the client sends the information in the cookie along with the request information. The server can read the cookie and extract its value. A typical use is to store a token (perhaps encrypted) indicating that the user has already been authenticated in your application.  

 Security Note The browser can only send the data back to the server that originally created the cookie. However, malicious users have ways to access cookies and read their contents. It is recommended that you do not store sensitive information, such as a user name or password, in a cookie. Instead, store a token in the cookie that identifies the user, and then use the token to look up the sensitive information on the server.For more information about using cookies, see Cookies and ASP.NET State Management Recommendations.Query StringsA query string is information that is appended to the end of a page URL. A typical query string might look like the following example:Copyhttp://www.contoso.com/listwidgets.aspx?category=basic&price=100In the URL path above, the query string starts with a question mark (?) and includes two attribute/value pairs, one called “category” and the other called “price.”Query strings provide a simple but limited way to maintain state information. For example, they are an easy way to pass information from one page to another, such as passing a product number from one page to another page where it will be processed. However, some browsers and client devices impose a 2083-character limit on the length of the URL.

 Security Note Information that is passed in a query string can be tampered with by a malicious user. Do not rely on query strings to convey important or sensitive data. Additionally, a user can bookmark the URL or send the URL to other users, thereby passing that information along with it. For more information, see ASP.NET State Management Recommendations and How to: Protect Against Script Exploits in a Web Application by Applying HTML Encoding to Strings.In order for query string values to be available during page processing, you must submit the page using an HTTP GET command. That is, you cannot take advantage of a query string if a page is processed in response to an HTTP POST command. For usage recommendations, see ASP.NET State Management Recommendations.Server-Based State Management Options Once you add your application-specific information to application state, the server manages it. For usage recommendations, see ASP.NET State Management Recommendations.Session StateASP.NET allows you to save values by using session state — which is an instance of the HttpSessionState class — for each active Web-application session. For an overview, see ASP.NET Session State Overview.Session state is similar to application state, except that it is scoped to the current browser session. If different users are using your application, each user session will have a different session state. In addition, if a user leaves your application and then returns later, the second user session will have a different session state from the first.Session state is structured as a key/value dictionary for storing session-specific information that needs to be maintained between server round trips and between requests for pages. For more information, see ASP.NET Session State Overview.You can use session state to accomplish the following tasks:

Uniquely identify browser or client-device requests and map them to an individual session instance on the server. Store session-specific data on the server for use across multiple browser or client-device requests within the same session.

Raise appropriate session management events. In addition, you can write application code leveraging these events.Once you add your application-specific information to session state, the server manages this object. Depending on which options you specify, session information can be stored in cookies, on an out-of-process server, or on a computer running Microsoft SQL Server. For usage recommendations, see ASP.NET State Management Recommendations.Profile PropertiesASP.NET provides a feature called profile properties, which allows you to store user-specific data. This feature is similar to session state, except that the profile data is not lost when a user’s session expires. The profile-properties feature uses an ASP.NET profile, which is stored in a persistent format and associated with an individual user. The ASP.NET profile allows you to easily manage user information without requiring you to create and maintain your own database. In addition, the profile makes the user information available using a strongly typed API that you can access from anywhere in your application. You can store objects of any type in the profile. The ASP.NET profile feature provides a generic storage system that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner.To use profile properties, you must configure a profile provider. ASP.NET includes a SqlProfileProvider class that allows you to store profile data in a SQL database, but you can also create your own profile provider class that stores profile data in a custom format and to a custom storage mechanism such as an XML file, or even to a web service.Because data that is placed in profile properties is not stored in application memory, it is preserved through Internet Information Services (IIS) restarts and worker-process restarts without losing data. Additionally, profile properties can be persisted across multiple processes such as in a Web farm or a Web garden. For more information, see ASP.NET Profile Properties Overview.ASP.NET State Management RecommendationsState management is the process by which you maintain state and page information over multiple requests for the same or different pages. As is true for any HTTP-based technology, Web Forms pages are stateless, which means that they do not automatically indicate whether the requests in a sequence are all from the same client or even whether a single browser instance is still actively viewing a page or site. Furthermore, pages are destroyed and re-created with each round trip to the server; therefore, page information will not exist beyond the life cycle of a single page. For more information about server round trips and the life cycle of Web Forms pages, see ASP.NET Page Life Cycle Overview.ASP.NET provides multiple ways to maintain state between server round trips. Which of these options you choose depends heavily upon your application, and it should be based on the following criteria:

How much information do you need to store? Does the client accept persistent or in-memory cookies? Do you want to store the information on the client or on the server? Is the information sensitive? What performance and bandwidth criteria do you have for your application? What are the capabilities of the browsers and devices that you are targeting? Do you need to store information per user? How long do you need to store the information? Do you have a Web farm (multiple servers), a Web garden (multiple processes on one machine), or a single process that

serves the application?Client-Side State Management OptionsStoring page information using client-side options doesn’t use server resources. These options typically have minimal security but fast server performance because the demand on server resources is modest. However, because you must send information to the client for it to be stored, there is a practical limit on how much information you can store this way.The following are the client-side state management options that ASP.NET supports:

View state Control state Hidden fields Cookies Query strings

View StateWeb Forms pages provide the ViewState property as a built-in structure for automatically retaining values between multiple requests for the same page. View state is maintained as a hidden field in the page. For more information, see ASP.NET State Management Overview.You can use view state to store your own page-specific values across round trips when the page posts back to itself. For example, if your application is maintaining user-specific information — that is, information that is used in the page but is not necessarily part of any control — you can store it in view state.Advantages of using view state are:

No server resources are required   The view state is contained in a structure within the page code. Simple implementation   View state does not require any custom programming to use. It is on by default to maintain

state data on controls. Enhanced security features   The values in view state are hashed, compressed, and encoded for Unicode

implementations, which provides more security than using hidden fields.Disadvantages of using view state are:

Performance considerations   Because the view state is stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it. This is especially relevant for mobile devices, where bandwidth is often a limitation.

Device limitations   Mobile devices might not have the memory capacity to store a large amount of view-state data. Potential security risks   The view state is stored in one or more hidden fields on the page. Although view state stores

data in a hashed format, it can still be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.For more information about using view state, see View State Overview.Control StateThe ASP.NET page framework provides the ControlState property as way to store custom control data between server trips. For example, if you have written a custom control that has different tabs showing different information, in order for that control to work as expected, the control needs to know which tab is selected between round trips. View state can be used for this purpose, but developers can turn view state off at the page level, effectively breaking your control. Unlike view state, control state cannot be turned off, so it provides a more reliable way to store control-state data.Advantages of using control state are:

No server resources are required   By default, control state is stored in hidden fields on the page. Reliability   Because control state cannot be turned off like view state, control state is a more reliable method for

managing the state of controls. Versatility   Custom adapters can be written to control how and where control-state data is stored.

Disadvantage of using control state are: Some programming is required   While the ASP.NET page framework provides a foundation for control state, control

state is a custom state-persistence mechanism. To fully utilize control state, you must write code to save and load control state.Hidden FieldsYou can store page-specific information in a hidden field on your page as a way of maintaining the state of your page.If you use hidden fields, it is best to store only small amounts of frequently changed data on the client.

 Note If you use hidden fields, you must submit your pages to the server using the HTTP POST method rather than requesting the page via the page URL (the HTTP GET method).Advantages of using hidden fields are:    

No server resources are required   The hidden field is stored and read from the page. Widespread support   Almost all browsers and client devices support forms with hidden fields. Simple implementation   Hidden fields are standard HTML controls that require no complex programming logic.

Disadvantages of using hidden fields are: Potential security risks   The hidden field can be tampered with. The information in the hidden field can be seen if the

page output source is viewed directly, creating a potential security issue. You can manually encrypt and decrypt the contents of a hidden field, but doing so requires extra coding and overhead. If security is a concern, consider using a server-based state mechanism so that no sensitive information is sent to the client. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.

Simple storage architecture   The hidden field does not support rich data types. Hidden fields offer a single string value field in which to place information. To store multiple values, you must implement delimited strings and the code to parse those strings. You can manually serialize and de-serialize rich data types to and from hidden fields, respectively. However, it requires extra code to do so. If you need to store rich data types on the client, consider using view state instead. View state has serialization built-in, and it stores data in hidden fields.

Performance considerations   Because hidden fields are stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it.

Storage limitations   If the amount of data in a hidden field becomes very large, some proxies and firewalls will prevent access to the page that contains them. Because the maximum amount can vary with different firewall and proxy implementations, large hidden fields can be sporadically problematic. If you need to store many items of data, consider doing one of the following:

o Put each item in a separate hidden field.

o Use view state with view-state chunking turned on, which automatically separates data into multiple hidden fields.

o Instead of storing data on the client, persist the data on the server. The more data you send to the client, the slower the apparent response time of your application will be because the browser will need to download or send more data.CookiesCookies are useful for storing small amounts of frequently changed information on the client. The information is sent with the request to the server. For details about creating and reading cookies, see ASP.NET Cookies Overview.Advantages of using cookies are:

Configurable expiration rules   The cookie can expire when the browser session ends, or it can exist indefinitely on the client computer, subject to the expiration rules on the client.

No server resources are required   The cookie is stored on the client and read by the server after a post. Simplicity   The cookie is a lightweight, text-based structure with simple key-value pairs. Data persistence   Although the durability of the cookie on a client computer is subject to cookie expiration processes on

the client and user intervention, cookies are generally the most durable form of data persistence on the client.Disadvantages of using cookies are:

Size limitations   Most browsers place a 4096-byte limit on the size of a cookie, although support for 8192-byte cookies is becoming more common in newer browser and client-device versions.

User-configured refusal   Some users disable their browser or client device’s ability to receive cookies, thereby limiting this functionality.

Potential security risks   Cookies are subject to tampering. Users can manipulate cookies on their computer, which can potentially cause a security risk or cause the application that is dependent on the cookie to fail. Also, although cookies are only accessible by the domain that sent them to the client, hackers have historically found ways to access cookies from other domains on a user’s computer. You can manually encrypt and decrypt cookies, but it requires extra coding and can affect application performance because of the time that is required for encryption and decryption. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications. 

 Note Cookies are often used for personalization, where content is customized for a known user. In most of these cases, identification is the issue rather than authentication. Thus, you can typically secure a cookie that is used for identification by storing the user name, account name, or a unique user ID (such as a GUID) in the cookie and then using the cookie to access the user personalization infrastructure of a site.Query StringsA query string is information that is appended to the end of a page URL. For more information, see ASP.NET State Management Overview.You can use a query string to submit data back to your page or to another page through the URL. Query strings provide a simple but limited way of maintaining some state information. For example, query strings are an easy way to pass information from one page to another, such as passing a product number to another page where it will be processed.Advantages of using query strings are: 

No server resources are required   The query string is contained in the HTTP request for a specific URL. Widespread support   Almost all browsers and client devices support using query strings to pass values. Simple implementation   ASP.NET provides full support for the query-string method, including methods of reading query

strings using the Paramsproperty of the HttpRequest object.Disadvantages of using query strings are:

Potential security risks   The information in the query string is directly visible to the user via the browser’s user interface. A user can bookmark the URL or send the URL to other users, thereby passing the information in the query string along with it. If you are concerned about any sensitive data in the query string, consider using hidden fields in a form that uses POST instead of using query strings. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.

Limited capacity   Some browsers and client devices impose a 2083-character limit on the length of URLs.Client-Side Method State Management SummaryThe following table lists the client-side state management options that are available with ASP.NET, and provides recommendations about when you should use each option.

State management option

Recommended usage

View state Use when you need to store small amounts of information for a page that will post back to itself. Using the ViewStateproperty provides functionality with basic security.

Control state Use when you need to store small amounts of state information for a control between round trips to the server.

Hidden fields Use when you need to store small amounts of information for a page that will post back to itself or to another page, and when security is not an issue.NoteYou can use a hidden field only on pages that are submitted to the server.

Cookies Use when you need to store small amounts of information on the client and security is not an issue.

Query string Use when you are transferring small amounts of information from one page to another and security is not an issue.NoteYou can use query strings only if you are requesting the same page, or another page via a link.

Server-Side State Management Options    

Application state Session state Profile properties Database support

Application StateASP.NET provides application state via the HttpApplicationState class as a method of storing global application-specific information that is visible to the entire application. Application-state variables are, in effect, global variables for an ASP.NET application. For more information, see ASP.NET Application State OverviewYou can store your application-specific values in application state, which is then managed by the server. For more information, see ASP.NET State Management Overview.Data that is shared by multiple sessions and does not change often is the ideal type of data to insert into application-state variables.Advantages of using application state are:

Simple implementation   Application state is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.

Application scope   Because application state is accessible to all pages in an application, storing information in application state can mean keeping only a single copy of the information (for instance, as opposed to keeping copies of information in session state or in individual pages).Disadvantages of using application state are:

Application scope   The scope of application state can also be a disadvantage. Variables stored in application state are global only to the particular process the application is running in, and each application process can have different values. Therefore, you cannot rely on application state to store unique values or update global counters in Web-garden and Web-farm server configurations.

Limited durability of data   Because global data that is stored in application state is volatile, it will be lost if the Web server process containing it is destroyed, such as from a server crash, upgrade, or shutdown.

Resource requirements   Application state requires server memory, which can affect the performance of the server as well as the scalability of the application.Careful design and implementation of application state can increase Web application performance. For example, placing a commonly used, relatively static dataset in application state can increase site performance by reducing the overall number of data requests to a database. However, there is a performance trade-off. Application state variables containing large blocks of information reduce Web server performance as server load increases. The memory occupied by a variable stored in application state is not released until the value is either removed or replaced. Therefore, it is best to use application-state variables only with small, infrequently changed datasets. For more information, see ASP.NET Performance Overview.Session StateASP.NET provides a session state, which is available as theHttpSessionState class, as a method of storing session-specific information that is visible only within the session. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides the ability to persist variable values for the duration of that session. For more information, see ASP.NET State Management Overviewand ASP.NET Session State Overview.You can store your session-specific values and objects in session state, which is then managed by the server and available to the browser or client device. The ideal data to store in session-state variables is short-lived, sensitive data that is specific to an individual session.Advantages of using session state are:

Simple implementation   The session-state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.

Session-specific events   Session management events can be raised and used by your application. Data persistence   Data placed in session-state variables can be preserved through Internet Information Services (IIS)

restarts and worker-process restarts without losing session data because the data is stored in another process space. Additionally, session-state data can be persisted across multiple processes, such as in a Web farm or a Web garden.

Platform scalability   Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.

Cookieless support   Session state works with browsers that do not support HTTP cookies, although session state is most commonly used with cookies to provide user identification facilities to a Web application. Using session state without

cookies, however, requires that the session identifier be placed in the query string, which is subject to the security issues stated in the query string section of this topic. For more information about using session state without cookies, see ASP.NET Web Site Administration.

Extensibility   You can customize and extend session state by writing your own session-state provider. Session state data can then be stored in a custom data format in a variety of data storage mechanisms, such as a database, an XML file, or even to a Web service. For more information, seeImplementing a Session-State Store Provider.Disadvantage of using session state are:

Performance considerations   Session-state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session-state variables that contain blocks of information, such as large datasets, can adversely affect Web-server performance as server load increases.Profile PropertiesASP.NET provides a feature called profile properties, which allows you to store user-specific data. It is similar to session state, except that unlike session state, the profile data is not lost when a user’s session expires. The profile properties feature uses an ASP.NET profile, which is stored in a persistent format and associated with an individual user. The ASP.NET profile allows you to easily manage user information without requiring you to create and maintain your own database. In addition, the profile makes the user information available using a strongly typed API that you can access from anywhere in your application. You can store objects of any type in the profile. The ASP.NET profile feature provides a generic storage system that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner. For more information, see ASP.NET Profile Properties Overview.Advantages of using profile properties are:

Data persistence   Data placed in profile properties is preserved through IIS restarts and worker-process restarts without losing data because the data is stored in an external mechanism. Additionally, profile properties can be persisted across multiple processes, such as in a Web farm or a Web garden.

Platform scalability   Profile properties can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.

Extensibility   In order to use profile properties, you must configure a profile provider. ASP.NET includes a SqlProfileProvider class that allows you to store profile data in a SQL database, but you can also create your own profile provider class that stores profile data in a custom format and to a custom storage mechanism, such as an XML file, or even to a Web service. For more information, see ASP.NET Profile Providers and Implementing a Profile Provider.Disadvantages of using profile properties are:

Performance considerations   Profile properties are generally slower than using session state because instead of storing data in memory, the data is persisted to a data store.

Additional configuration requirements   Unlike session state, the profile properties feature requires a considerable amount of configuration to use. To use profile properties, you must not only configure a profile provider, but you must pre-configure all of the profile properties that you want to store. For more information, see ASP.NET Profile Properties Overview and Defining ASP.NET Profile Properties.

Data maintenance   Profile properties require a certain amount of maintenance. Because profile data is persisted to non-volatile storage, you must make sure that your application calls the appropriate cleanup mechanisms, which are provided by the profile provider, when data becomes stale.Database SupportIn some cases, you might want to use database support to maintain state on your Web site. Typically, database support is used in conjunction with cookies or session state. For example, it is common for an e-commerce Web site to maintain state information by using a relational database for the following reasons:

Security Personalization Consistency Data mining

The following are typical features of a cookie-supported database Web site: Security   The visitor types an account name and password into a site logon page. The site infrastructure queries the

database with the logon values to determine whether the user has rights to utilize your site. If the database validates the user information, the Web site will distribute a valid cookie containing a unique ID for that user on that client computer. The site grants access to the user.

Personalization   With security information in place, your site can distinguish each user by reading the cookie on the client computer. Typically, sites have information in the database that describes the preferences of a user (identified by a unique ID). This relationship is known as personalization. The site can research the user’s preferences using the unique ID contained in the cookie, and then place content and information in front of the user that pertains to the user’s specific wishes, reacting to the user’s preferences over time.

Consistency   If you have created a commerce Web site, you might want to keep transactional records of purchases made for goods and services on your site. This information can be reliably saved in your database and referenced by the user’s unique ID. It can be used to determine whether a purchase transaction has been completed, and to determine the course of action if a purchase transaction fails. The information can also be used to inform the user of the status of an order placed using your site.

Data mining   Information about your site usage, your visitors, or your product transactions can be reliably stored in a database. For example, your business development department might want to use the data collected from your site to determine next year’s product line or distribution policy. Your marketing department might want to examine demographic information about users on your site. Your engineering and support departments might want to look at transactions and

note areas where your purchasing process could be improved. Most enterprise-level relational databases, such as Microsoft SQL Server, contain an expansive toolset for most data mining projects.By designing the Web site to repeatedly query the database by using the unique ID during each general stage in the above scenario, the site maintains state. In this way, the user perceives that the site is remembering and reacting to him or her personally.Advantages of using a database to maintain state are:

Security   Access to databases requires rigorous authentication and authorization. Storage capacity   You can store as much information as you like in a database. Data persistence   Database information can be stored as long as you like, and it is not subject to the availability of the

Web server. Robustness and data integrity   Databases include various facilities for maintaining good data, including triggers and

referential integrity, transactions, and so on. By keeping information about transactions in a database (rather than in session state, for example), you can recover from errors more readily.

Accessibility   The data stored in your database is accessible to a wide variety of information-processing tools. Widespread support   There is a large range of database tools available, and many custom configurations are available.

Disadvantages of using a database to maintain state are: Complexity   Using a database to support state management requires that the hardware and software configurations be

more complex. Performance considerations   Poor construction of the relational data model can lead to scalability issues. Also,

leveraging too many queries to the database can adversely affect server performance.Server-Side Method State Management SummaryThe following table lists the server-side state management options that are available with ASP.NET, and provides recommendations about when you should use each option.

State management option

Recommended usage

Application state

Use when you are storing infrequently changed, global information that is used by many users, and security is not an issue. Do not store large quantities of information in application state.

Session state Use when you are storing short-lived information that is specific to an individual session and security is an issue. Do not store large quantities of information in session state. Be aware that a session-state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalability.

Profile properties

Use when you are storing user-specific information that needs to be persisted after the user session is expired and needs to be retrieved again on subsequent visits to your application.

Database support

Use when you are storing large amounts of information, managing transactions, or the information must survive application and session restarts. Data mining is a concern, and security is an issue.

 .NET Framework 4 – ASP.NETASP.NET Cookies OverviewA cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The cookie contains information the Web application can read whenever the user visits the site.A Visual Studio project with source code is available to accompany this topic:Download.This topic contains the following:

Scenarios Background Code Examples Class Reference Additional Resources What’s New

ScenariosCookies provide a means in Web applications to store user-specific information. For example, when a user visits your site, you can use cookies to store user preferences or other information. When the user visits your Web site another time, the application can retrieve the information it stored earlier.Back to topBackgroundA cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The

cookie contains information the Web application can read whenever the user visits the site.For example, if a user requests a page from your site and your application sends not just a page, but also a cookie containing the date and time, when the user’s browser gets the page, the browser also gets the cookie, which it stores in a folder on the user’s hard disk.Later, if user requests a page from your site again, when the user enters the URL the browser looks on the local hard disk for a cookie associated with the URL. If the cookie exists, the browser sends the cookie to your site along with the page request. Your application can then determine the date and time that the user last visited the site. You might use the information to display a message to the user or check an expiration date.Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site. As the user visits different sites, each site might send a cookie to the user’s browser as well; the browser stores all the cookies separately.Cookies help Web sites store information about visitors. More generally, cookies are one way of maintaining continuity in a Web application—that is, of performing state management. Except for the brief time when they are actually exchanging information, the browser and Web server are disconnected. Each request a user makes to a Web server is treated independently of any other request. Many times, however, it’s useful for the Web server to recognize users when they request a page. For example, the Web server on a shopping site keeps track of individual shoppers so the site can manage shopping carts and other user-specific information. A cookie therefore acts as a kind of calling card, presenting pertinent identification that helps an application know how to proceed.Cookies are used for many purposes, all relating to helping the Web site remember users. For example, a site conducting a poll might use a cookie simply as a Boolean value to indicate whether a user’s browser has already participated in voting so that the user cannot vote twice. A site that asks a user to log on might use a cookie to record that the user already logged on so that the user does not have to keep entering credentials.

Cookie LimitationsMost browsers support cookies of up to 4096 bytes. Because of this small limit, cookies are best used to store small amounts of data, or better yet, an identifier such as a user ID. The user ID can then be used to identify the user and read user information from a database or other data store. (See the section “Cookies and Security” below for information about security implications of storing user information.)Browsers also impose limitations on how many cookies your site can store on the user’s computer. Most browsers allow only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute limit, usually 300, on the number of cookies they will accept from all sites combined.A cookie limitation that you might encounter is that users can set their browser to refuse cookies. If you define a P3P privacy policy and place it in the root of your Web site, more browsers will accept cookies from your site. However, you might have to avoid cookies altogether and use a different mechanism to store user-specific information. A common method for storing user information is session state, but session state depends on cookies, as explained later in the section “Cookies and Session State.”

 Note For more information on state management and options for saving information in a Web application, see ASP.NET State Management Overviewand ASP.NET State Management Recommendations.Although cookies can be very useful in your application, the application should not depend on being able to store cookies. Do not use cookies to support critical features. If your application must rely on cookies, you can test to see whether the browser will accept cookies. See the “Checking Whether a Browser Accepts Cookies” section later in this topic.    

Writing CookiesThe browser is responsible for managing cookies on a user system. Cookies are sent to the browser via the HttpResponse object that exposes a collection called Cookies. You can access the HttpResponse object as theResponse property of your Page class. Any cookies that you want to send to the browser must be added to this collection. When creating a cookie, you specify a Name and Value. Each cookie must have a unique name so that it can be identified later when reading it from the browser. Because cookies are stored by name, naming two cookies the same will cause one to be overwritten.You can also set a cookie’s date and time expiration. Expired cookies are deleted by the browser when a user visits the site that wrote the cookies. The expiration of a cookie should be set for as long as your application considers the cookie value to be valid. For a cookie to effectively never expire, you can set the expiration date to be 50 years from now.

 Note Users can clear the cookies on their computer at any time. Even if you store cookies with long expiration times, a user might decide to delete all cookies, wiping out any settings you might have stored in cookies.If you do not set the cookie’s expiration, the cookie is created but it is not stored on the user’s hard disk. Instead, the cookie is maintained as part of the user’s session information. When the user closes the browser, the cookie is discarded. A non-persistent cookie like this is useful for information that needs to be stored for only a short time or that for security reasons should not be written to disk on the client computer. For example, non-persistent cookies are useful if the user is working on a public computer, where you do not want to write the cookie to disk.

You can add cookies to the Cookies collection in a number of ways. The following example shows two methods to write cookies:VBC#C++F#JScriptCopyResponse.Cookies["userName"].Value = “patrick”;Response.Cookies["userName"].Expires = DateTime.Now.AddDays(1);HttpCookie aCookie = new HttpCookie(“lastVisit”);aCookie.Value = DateTime.Now.ToString();aCookie.Expires = DateTime.Now.AddDays(1);Response.Cookies.Add(aCookie);The example adds two cookies to the Cookies collection, one named userName and the other named lastVisit. For the first cookie, the values of the Cookies collection are set directly. You can add values to the collection this way because Cookies derives from a specialized collection of typeNameObjectCollectionBase.For the second cookie, the code creates an instance of an object of typeHttpCookie, sets its properties, and then adds it to the Cookies collection via the Add method. When you instantiate an HttpCookie object, you must pass the cookie name as part of the constructor.Both examples accomplish the same task, writing a cookie to the browser. In both methods, the expiration value must be of type DateTime. However, the lastVisited value is also a date-time value. Because all cookie values are stored as strings, the date-time value has to be converted to a String .

Cookies with More Than One ValueYou can store one value in a cookie, such as user name and last visit. You can also store multiple name-value pairs in a single cookie. The name-value pairs are referred to as subkeys. (Subkeys are laid out much like a query string in a URL.) For example, instead of creating two separate cookies named userName and lastVisit, you can create a single cookie named userInfo that has the subkeys userName and lastVisit.You might use subkeys for several reasons. First, it is convenient to put related or similar information into a single cookie. In addition, because all the information is in a single cookie, cookie attributes such as expiration apply to all the information. (Conversely, if you want to assign different expiration dates to different types of information, you should store the information in separate cookies.)A cookie with subkeys also helps you limit the size of cookie files. As noted earlier in the “Cookie Limitations” section, cookies are usually limited to 4096 bytes and you can’t store more than 20 cookies per site. By using a single cookie with subkeys, you use fewer of those 20 cookies that your site is allotted. In addition, a single cookie takes up about 50 characters for overhead (expiration information, and so on), plus the length of the value that you store in it, all of which counts toward the 4096-byte limit. If you store five subkeys instead of five separate cookies, you save the overhead of the separate cookies and can save around 200 bytes.To create a cookie with subkeys, you can use a variation of the syntax for writing a single cookie. The following example shows two ways to write the same cookie, each with two subkeys:VBC#C++F#JScriptCopyResponse.Cookies["userInfo"]["userName"] = “patrick”;Response.Cookies["userInfo"]["lastVisit"] = DateTime.Now.ToString();Response.Cookies["userInfo"].Expires = DateTime.Now.AddDays(1);HttpCookie aCookie = new HttpCookie(“userInfo”);aCookie.Values["userName"] = “patrick”;aCookie.Values["lastVisit"] = DateTime.Now.ToString();aCookie.Expires = DateTime.Now.AddDays(1);Response.Cookies.Add(aCookie);

Controlling Cookie ScopeBy default, all cookies for a site are stored together on the client, and all cookies are sent to the server with any request to that site. In other words, every page in a site gets all of the cookies for that site. However, you can set the scope of cookies in two ways:

Limit the scope of cookies to a folder on the server, which allows you to limit cookies to an application on the site. Set scope to a domain, which allows you to specify which subdomains in a domain can access a cookie.

Limiting Cookies to a Folder or ApplicationTo limit cookies to a folder on the server, set the cookie’s Path property, as in the following example:

VBC#C++F#JScriptCopyHttpCookie appCookie = new HttpCookie(“AppCookie”);appCookie.Value = “written ” + DateTime.Now.ToString();appCookie.Expires = DateTime.Now.AddDays(1);appCookie.Path = “/Application1″;Response.Cookies.Add(appCookie);

 Note You can also write cookies by adding them to the Cookies collection directly as shown in earlier examples.The path can either be a physical path under the site root or a virtual root. The effect will be that the cookie is available only to pages in the Application1 folder or virtual root. For example, if your site is called www.contoso.com, the cookie created in the previous example will be available to pages with the path http://www.contoso.com/Application1/ and to any pages beneath that folder. However, the cookie will not be available to pages in other applications such as http://www.contoso.com/Application2/ or just http://www.contoso.com/.      

 Note In some browsers, the path is case sensitive. You cannot control how users type URLs into their browsers, but if your application depends on cookies tied to a specific path, be sure that the URLs in any hyperlinks you create match the case of the Path property value.     

Limiting Cookie Domain ScopeBy default, cookies are associated with a specific domain. For example, if your site is www.contoso.com, the cookies you write are sent to the server when users request any page from that site. (This might not include cookies with a specific path value.) If your site has subdomains—for example, contoso.com, sales.contoso.com, and support.contoso.com—then you can associate cookies with a specific subdomain. To do so, set the cookie’sDomain property, as in this example:VBC#C++F#JScriptCopyResponse.Cookies["domain"].Value = DateTime.Now.ToString();Response.Cookies["domain"].Expires = DateTime.Now.AddDays(1);Response.Cookies["domain"].Domain = “support.contoso.com”;When the domain is set in this way, the cookie will be available only to pages in the specified subdomain. You can also use the Domain property to create a cookie that can be shared among multiple subdomains, as shown in the following example:Response.Cookies["domain"].Value = DateTime.Now.ToString();Response.Cookies["domain"].Expires = DateTime.Now.AddDays(1);Response.Cookies["domain"].Domain = “contoso.com”;The cookie will then be available to the primary domain as well as to sales.contoso.com and support.contoso.com domains.

Reading CookiesWhen a browser makes a request to the server, it sends the cookies for that server along with the request. In your ASP.NET applications, you can read the cookies using the HttpRequest object, which is available as theRequest property of your Page class. The structure of the HttpRequestobject is essentially the same as that of the HttpResponse object, so you can read cookies out of the HttpRequest object much the same way you wrote cookies into the HttpResponse object. The

following code example shows two ways to get the value of a cookie named username and display its value in a Label control:if(Request.Cookies["userName"] != null)    Label1.Text = Server.HtmlEncode(Request.Cookies["userName"].Value);if(Request.Cookies["userName"] != null){    HttpCookie aCookie = Request.Cookies["userName"];    Label1.Text = Server.HtmlEncode(aCookie.Value);}Before trying to get the value of a cookie, you should make sure that the cookie exists; if the cookie does not exist, you will get aNullReferenceException exception. Notice also that the HtmlEncode method was called to encode the contents of a cookie before displaying it in the page. This makes certain that a malicious user has not added executable script into the cookie. For more about cookie security, see the “Cookies and Security” section.

 Note Because different browsers store cookies differently, different browsers on the same computer won’t necessarily be able to read each other’s cookies. For example, if you use Internet Explorer to test a page one time, but then later use a different browser to test again, the second browser won’t find the cookies saved by Internet Explorer.Reading the value of a subkey in a cookie is likewise similar to setting it. The following code example shows one way to get the value of a subkey:VBC#C++F#JScriptCopyif(Request.Cookies["userInfo"] != null){    Label1.Text =        Server.HtmlEncode(Request.Cookies["userInfo"]["userName"]);    Label2.Text =        Server.HtmlEncode(Request.Cookies["userInfo"]["lastVisit"]);}In the preceding example, the code reads the value of the subkey lastVisit, which was set earlier to the string representation of a DateTime value. Cookies store values as strings, so if you want to use the lastVisitDateTime dt;dt = DateTime.Parse(Request.Cookies["userInfo"]["lastVisit"]);The subkeys in a cookie are typed as a collection of typeNameValueCollection. Therefore, another way to get an individual subkey is to get the subkeys collection and then extract the subkey value by name, asif(Request.Cookies["userInfo"] != null){    System.Collections.Specialized.NameValueCollection        UserInfoCookieCollection;    UserInfoCookieCollection = Request.Cookies["userInfo"].Values;    Label1.Text =        Server.HtmlEncode(UserInfoCookieCollection["userName"]);    Label2.Text =        Server.HtmlEncode(UserInfoCookieCollection["lastVisit"]);}

Changing a Cookie’s Expiration DateThe browser is responsible for managing cookies, and the cookie’s expiration time and date help the browser manage its store of cookies. Therefore, although you can read the name and value of a cookie, you cannot read the cookie’s expiration date and time. When the browser sends cookie information to the server, the browser does not include the expiration information. (The cookie’s Expires property always returns a date-time value of zero.) If you are concerned about the expiration date of a cookie, you must reset it, which is covered in the “Modifying and Deleting Cookies” section.

 Note You can read the Expires property of a cookie that you have set in theHttpResponse object, before the cookie has been sent to the browser. However, you cannot get the expiration back in the HttpRequest object.

     

Reading Cookie CollectionsYou might occasionally need to read through all the cookies available to the page. To read the names and values of all the cookies available to the page, you can loop through the Cookies collection using code such as the following.System.Text.StringBuilder output = new System.Text.StringBuilder();HttpCookie aCookie;for(int i=0; i<Request.Cookies.Count; i++){    aCookie = Request.Cookies[i];    output.Append(“Cookie name = ” + Server.HtmlEncode(aCookie.Name)        + “<br />”);    output.Append(“Cookie value = ” + Server.HtmlEncode(aCookie.Value)        + “<br /><br />”);}Label1.Text = output.ToString();

 Note When you run this code, you might see a cookie named ASP.NET_SessionId. That is a cookie that ASP.NET uses to store a unique identifier for your session. The session cookie is not persisted on your hard disk. For more about session cookies, see the “Cookies and Session State” later in this topic.A limitation of the preceding example is that if the cookie has subkeys, the display shows the subkeys as a single name/value string. You can read a cookie’s HasKeys property to determine whether the cookie has subkeys. If so, you can read the subkey collection to get individual subkey names and values. You can read subkey values from the Values collection directly by index value. The corresponding subkey names are available in the AllKeys member of theValues collection, which returns an array of strings. You can also use the Keysmember of the Values collection. However, the AllKeys property is cached the first time it is accessed. In contrast, the Keys property builds an array each time it is accessed. For this reason, the AllKeys property is much faster on subsequent accesses within the context of the same page request.The following example shows a modification of the preceding example. It uses the HasKeys property to test for subkeys, and if subkeys are detected, the example gets subkeys from the Values collection:for(int i=0; i<Request.Cookies.Count; i++){    aCookie = Request.Cookies[i];    output.Append(“Name = ” + aCookie.Name + “<br />”);    if(aCookie.HasKeys)    {        for(int j=0; j<aCookie.Values.Count; j++)        {            subkeyName = Server.HtmlEncode(aCookie.Values.AllKeys[j]);            subkeyValue = Server.HtmlEncode(aCookie.Values[j]);            output.Append(“Subkey name = ” + subkeyName + “<br />”);            output.Append(“Subkey value = ” + subkeyValue +                “<br /><br />”);        }    }    else    {        output.Append(“Value = ” + Server.HtmlEncode(aCookie.Value) +            “<br /><br />”);    }}Label1.Text = output.ToString();Alternatively, you can extract the subkeys as a NameValueCollection object as shown in the following example:System.Text.StringBuilder output = new System.Text.StringBuilder();HttpCookie aCookie;string subkeyName;string subkeyValue;for (int i = 0; i < Request.Cookies.Count; i++){

    aCookie = Request.Cookies[i];    output.Append(“Name = ” + aCookie.Name + “<br />”);    if (aCookie.HasKeys)    {        System.Collections.Specialized.NameValueCollection CookieValues =            aCookie.Values;        string[] CookieValueNames = CookieValues.AllKeys;        for (int j = 0; j < CookieValues.Count; j++)        {            subkeyName = Server.HtmlEncode(CookieValueNames[j]);            subkeyValue = Server.HtmlEncode(CookieValues[j]);            output.Append(“Subkey name = ” + subkeyName + “<br />”);            output.Append(“Subkey value = ” + subkeyValue +                “<br /><br />”);        }    }    else    {        output.Append(“Value = ” + Server.HtmlEncode(aCookie.Value) +            “<br /><br />”);    }}Label1.Text = output.ToString();

Modifying and Deleting CookiesYou cannot directly modify a cookie. Instead, changing a cookie consists of creating a new cookie with new values and then sending the cookie to the browser to overwrite the old version on the client. The following code example shows how you can change the value of a cookie that stores a count of the user’s visits to the site:int counter;if (Request.Cookies["counter"] == null)    counter = 0;else{    counter = int.Parse(Request.Cookies["counter"].Value);}counter++;Response.Cookies["counter"].Value = counter.ToString();Response.Cookies["counter"].Expires = DateTime.Now.AddDays(1);

Deleting CookiesDeleting a cookie—physically removing it from the user’s hard disk—is a variation on modifying it. You cannot directly remove a cookie because the cookie is on the user’s computer. However, you can have the browser delete the cookie for you. The technique is to create a new cookie with the same name as the cookie to be deleted, but to set the cookie’s expiration to a date earlier than today. When the browser checks the cookie’s expiration, the browser will discard the now-outdated cookie. The following code example shows one way to delete all the cookies available to the application:HttpCookie aCookie;string cookieName;int limit = Request.Cookies.Count;for (int i=0; i<limit; i++){    cookieName = Request.Cookies[i].Name;    aCookie = new HttpCookie(cookieName);    aCookie.Expires = DateTime.Now.AddDays(-1);    Response.Cookies.Add(aCookie);}

Modifying or Deleting SubkeysModifying an individual subkey is the same as creating it, as shown in the following example:Response.Cookies["userInfo"]["lastVisit"] = DateTime.Now.ToString();Response.Cookies["userInfo"].Expires = DateTime.Now.AddDays(1);To delete an individual subkey, you manipulate the cookie’s Valuescollection, which holds the subkeys. You first recreate the cookie by getting it from the Cookies object. You can then call the Remove method of theValues collection, passing to the Remove method the name of the subkey to delete. You then add the cookie to the Cookies collection so it will be sent

in its modified form back to the browser. The following code example shows how to delete a subkey. In the sample, the name of the subkey to remove is specified in a variable.string subkeyName;subkeyName = “userName”;HttpCookie aCookie = Request.Cookies["userInfo"];aCookie.Values.Remove(subkeyName);aCookie.Expires = DateTime.Now.AddDays(1);Response.Cookies.Add(aCookie);

Cookies and SecurityThe security issues with cookies are similar to those of getting data from the client. In your application, cookies are another form of user input and are therefore subject to examining and spoofing. A user can as a minimum see the data that you store in a cookie, since the cookie is available on the user’s own computer. The user can also change the cookie before the browser sends it to you.You should never store sensitive data in a cookie, such as user names, passwords, credit card numbers, and so on. Do not put anything in a cookie that should not be in the hands of a user or of someone who might somehow steal the cookie.Similarly, be suspicious of information you get out of a cookie. Do not assume that the data is the same as when you wrote it out; use the same safeguards in working with cookie values that you would with data that a user has typed into a Web page. The examples earlier in this topic showed HTML-encoding the contents of a cookie before displaying the value in a page, as you would before displaying any information you get from users.Cookies are sent between browser and server as plain text, and anyone who can intercept your Web traffic can read the cookie. You can set a cookie property that causes the cookie to be transmitted only if the connection uses the Secure Sockets Layer (SSL). SSL does not protect the cookie from being read or manipulated while it is on the user’s computer, but it does prevent the cookie from being read while in transit because the cookie is encrypted. For more information, see Basic Security Practices for Web Applications.

Determining Whether a Browser Accepts CookiesUsers can set their browser to refuse cookies. No error is raised if a cookie cannot be written. The browser likewise does not send any information to the server about its current cookie settings.

 Note The Cookies property does not indicate whether cookies are enabled. It indicates only whether the current browser inherently supports cookies.One way to determine whether cookies are accepted is by trying to write a cookie and then trying to read it back again. If you cannot read the cookie you wrote, you assume that cookies are turned off in the browser.The following code example shows how you might test whether cookies are accepted. The sample consists of two pages. The first page writes out a cookie, and then redirects the browser to the second page. The second page tries to read the cookie. It in turn redirects the browser back to the first page, adding to the URL a query string variable with the results of the test.The code for the first page (AcceptsCookies.aspx) looks like the following example:protected void Page_Load(object sender, EventArgs e){    if (!Page.IsPostBack)    {        if (Request.QueryString["AcceptsCookies"] == null)        {            Response.Cookies["TestCookie"].Value = “ok”;            Response.Cookies["TestCookie"].Expires =                DateTime.Now.AddMinutes(1);            Response.Redirect(“TestForCookies.aspx?redirect=” +                Server.UrlEncode(Request.Url.ToString()));        }        else        {            Label1.Text = “Accept cookies = ” +                Server.UrlEncode(                Request.QueryString["AcceptsCookies"]);        }    }}The page first tests to see if this is a postback, and if not, the page looks for the query string variable name AcceptsCookies that contains the test results. If there is no query string variable, the test has not been completed, so the code writes out a cookie named TestCookie. After writing out the cookie, the sample calls Redirect to transfer to the test page

TestForCookies.aspx. Appended to the URL of the test page is a query string variable named redirect containing the URL of the current page; this will allow you to redirect back to this page after performing the test.The test page can consist entirely of code; it does not need to contain controls. The following example illustrates the test page (TestForCookies.aspx).protected void Page_Load(object sender, EventArgs e){    string redirect = Request.QueryString["redirect"];    string acceptsCookies;    if(Request.Cookies["TestCookie"] ==null)        acceptsCookies = “no”;    else    {        acceptsCookies = “yes”;        // Delete test cookie.        Response.Cookies["TestCookie"].Expires =            DateTime.Now.AddDays(-1);    }    Response.Redirect(redirect + “?AcceptsCookies=” + acceptsCookies,    true);}After reading the redirect query string variable, the code tries to read the cookie. For housekeeping purposes, if the cookie exists, it is immediately deleted. When the test is finished, the code constructs a new URL from the URL passed to it in the redirect query string variable. The new URL also includes a query string variable containing test results. The final step is to use the new URL to redirect the browser to the original page.An improvement in the example would be to keep the cookie test results in a persistent store such as a database so that the test does not have to be repeated each time the user views the original page. (Storing the test results in session state by default requires cookies.)

Cookies and Session StateWhen a user navigates to your site, the server establishes a unique session for that user that lasts for the duration of the user’s visit. For each session, ASP.NET maintains session state information where applications can store user-specific information. For more information, see ASP.NET Session State Overview topic.ASP.NET must track a session ID for each user so that it can map the user to session state information on the server. By default, ASP.NET uses a non-persistent cookie to store the session state. However, if a user has disabled cookies on the browser, session state information cannot be stored in a cookie.ASP.NET offers an alternative in the form of cookieless sessions. You can configure your application to store session IDs not in a cookie, but in the URLs of pages in your site. If your application relies on session state, you might consider configuring it to use cookieless sessions. However, under some limited circumstances, if the user shares the URL with someone else—perhaps to send the URL to a colleague while the user’s session is still active—then both users can end up sharing the same session, with unpredictable results. For more information on configuring your application to use cookieless sessions, see the ASP.NET State Management Overviewtopic.ASP.NET View State OverviewView state is the method that the ASP.NET page framework uses to preserve page and control values between round trips. When the HTML markup for the page is rendered, the current state of the page and values that must be retained during postback are serialized into base64-encoded strings. This information is then put into the view state hidden field or fields.This topic contains the following sections:

Scenarios Features Background Class Reference

ScenariosView state is used automatically by the ASP.NET page framework to persist information that must be preserved between postbacks. This information includes any non-default values of controls.You can also use view state to store application data that is specific to a page.Back to topFeaturesView state is a repository in an ASP.NET page that can store values that have to be retained during postback. The page framework uses view state to persist control settings between postbacks.You can use view state in your own applications to do the following:

Keep values between postbacks without storing them in session state or in a user profile. Store the values of page or control properties that you define. Create a custom view state provider that lets you store view state information in a SQL Server database or in another data

store.For example, you can store information in view state that your code can access during the page load event the next time that the page is sent to the server. For usage recommendations, see ASP.NET State Management Recommendations.Back to top

BackgroundA Web application is stateless. A new instance of the Web page class is created every time that the page is requested from the server. This would ordinarily mean that all information in the page and in its controls would be lost with each round trip. For example, by default if a user enters information into a text box on an HTML Web page, that information is sent to the server. However, it is not returned to the browser in the response.To overcome this intrinsic limitation of Web programming, the ASP.NET page framework includes several state-management features to preserve page and control values between round trips to the Web server. One of these features is view state. For information about other state management features, see ASP.NET State Management Overview.By default, the ASP.NET page framework uses view state to preserve page and control values between round trips. When the HTML for the page is rendered, the current state of the page and values that must be retained during postback are serialized into base64-encoded strings. They are then put into a hidden field or fields in the page.You can access view state in your code by using the page’s ViewState property. The ViewState property is a dictionary that contains key/value pairs that contain the view state data.    

 Security Note It is easy for a malicious user to see and modify the contents of a hidden field. For more information about how to secure view state data, seeSecuring View State later in this topic.For recommendations about when you should store information in view state, see ASP.NET State Management Recommendations.You can change the default behavior and store view state in another location such as a SQL Server database by implementing a custom PageStatePersisterclass to store page data. For an example of how to store page state in a stream instead of in a hidden field, see the example for the PageStatePersister class.   

Considerations for Using View StateView state provides state information for a specific ASP.NET page. If you need to use information on more than one page, or if you need the information to persist across visits to the Web site, you must use another method for maintaining state. You can use application state, session state, or profile properties. For more information, see How to: Pass Values Between ASP.NET Web Pages.View state information is serialized into XML and then encoded by using base-64 encoding, which can generate large amounts of data. When the page is posted to the server, the contents of view state are sent as part of the page postback information. If view state contains a large amount of information, it can affect performance of the page. Test the performance of your pages by using typical data for your application to determine whether the size of view state is causing performance problems.Another consideration is that if the amount of data in a hidden field becomes large, some proxies and firewalls will prevent access to the page that contains them. Because the maximum allowed amount can vary with different firewall and proxy implementations, large hidden fields can cause intermittent problems. If the amount of data that is stored in the ViewStateproperty exceeds the value specified in the page’sMaxPageStateFieldLength property, the page splits view state into multiple hidden fields. This reduces the size of individual hidden fields below the size that firewalls reject.View state is enabled by default, but some controls on a page might not need view state. For example, if a control is refreshed from the data store on each postback, you can turn view state off for that control in order to reduce the size of view state.You can configure controls so that view state is disabled by default for all controls within a page or a container control, and you can then enable view state for specific controls. You can also configure controls so that view state is disabled and cannot be enabled for child controls.To disable view state for a control by default so that it can be enabled for child controls, set the ViewStateMode property of the control to Disabled. To disable view state by default for an entire page, set the ViewStateMode attribute of the @   Page  directive to Disabled.To disable view state for a control and its children so that it cannot be enabled for child controls, set the EnableViewState property of the control to false. To disable view state for an entire page and all of its child controls, set the EnableViewState attribute of the @   Page  directive to false.

 Note Even when you explicitly turn view state off, a hidden field is still sent to the browser to indicate that postback is occurring for the page.For alternatives to using view state, see ASP.NET State Management Recommendations.Some mobile devices do not allow hidden fields at all. Therefore, view state will not work for those devices. For more information and alternatives, see ASP.NET Web Sites for Mobile Devices.   

Control State

In addition to view state, ASP.NET supports control state. The page uses control state to persist control information that must be retained between postbacks, even if view state is disabled for the page or for a control. Like view state, control state is stored in one or more hidden fields.

Saving Values in View StateYou can access view state information by using the page’s ViewStateproperty, which exposes a dictionary object. You can use this dictionary to store custom values. A typical use is to store the value of custom properties that you define in the page.Because view state is sent as a hidden field, you can make changes to view state until the page’s PreRenderComplete event. After the page is rendered to the browser, changes to view state will not be saved.The information in the hidden view state field can be seen by users if they view the source of the Web page and can decode base-64 encoded strings. This creates a potential security issue. For more information about security issues with view state, see Securing View State later in this topic.

 Note To use the ViewState property, the ASP.NET Web page must have a form element that has the attribute runat=”server”.To save a value to view state, create a new item that contains the value to save and add the item to the view state dictionary. The following example shows an ASP.NET Web page with code that saves a string and an integer value in view state.<%@ Page Language=”C#” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”><script runat=”server”>  // Sample ArrayList for the page.  ArrayList PageArrayList;  ArrayList CreateArray()  {    // Create a sample ArrayList.    ArrayList result = new ArrayList(4);    result.Add(“item 1″);    result.Add(“item 2″);    result.Add(“item 3″);    result.Add(“item 4″);    return result;  }  void Page_Load(object sender, EventArgs e)  {    if (ViewState["arrayListInViewState"] != null)    {      PageArrayList = (ArrayList)ViewState["arrayListInViewState"];    }    else    {      // ArrayList isn’t in view state, so it must be created and populated.      PageArrayList = CreateArray();    }    // Code that uses PageArrayList.  }  void Page_PreRender(object sender, EventArgs e)  {    // Save PageArrayList before the page is rendered.    ViewState.Add(“arrayListInViewState”, PageArrayList);  }</script><html xmlns=”http://www.w3.org/1999/xhtml” ><head runat=”server”>    <title>View state sample</title></head><body>    <form id=”form1″ runat=”server”>    <div>    </div>    </form>

</body></html>

Data Types You Can Store in View StateYou can store objects of the following types in view state:

Strings Integers Boolean values Array objects ArrayList objects Hash tables Custom type converters (see the TypeConverter class for more information)

You can store other types of data also, but the class must be compiled with the Serializable attribute so that its values can be serialized for view state.

Reading Values from View StateTo read a value from view state, you get the ViewState property of page and then read the value from the view state dictionary.The following example shows how you can get an ArrayList object named arrayListInViewState from view state and then bind a GridView control to the object as a data source.arrayList = new ArrayList();arrayList = (ArrayList)ViewState["arrayListInViewState"];this.GridView1.DataSource = arrayList;this.GridView1.DataBind();Values in view state are typed as String. In Visual Basic, if you set Option Strict On, you must cast view state values to the appropriate type before you use them, as shown in the previous example. In C#, you must always cast to the appropriate type when you read view state values.If you try to get a value out of view state that does not exist, no exception is thrown. To make sure that a value is in view state, check first whether the object exists. The following example shows how to check for a view state entry.if (ViewState["color"] == null)    // No such value in view state, take appropriate action.If you try to use a nonexistent view state entry in some other way (for example, to examine its type), a NullReferenceException exception is thrown.Back to top

Securing View StateBy default, view state data is stored in the page in a hidden field and is encoded using base64 encoding. In addition, a hash of the view state data is created from the data by using a machine authentication code (MAC) key. The hash value is added to the encoded view state data and the resulting string is stored in the page. When the page is posted back to the server, the ASP.NET page framework re-computes the hash value and compares it with the value stored in view state. If the hash values do not match, an exception is raised that indicates that view state data might be invalid.By creating a hash value, the ASP.NET page framework can test whether the view state data has been corrupted or tampered with. However, even if it is not tampered with, view state data can still be intercepted and read by malicious users.

Usign the MAC for Computing the View State Hash ValueThe MAC key that is used to compute the view state hash value is either auto-generated or specified in the Machine.config file. If the key is auto-generated, it is created based on the MAC address of the computer, which is the unique GUID value of the network adapter in that computer.It can be difficult for malicious users to reverse-engineer the MAC key based on the hash value in view state. Thus, MAC encoding is a reasonably reliable way to determine whether view state data has been changed.In general, the larger the MAC key that is used to generate the hash, the less likely it is that the hash value for different strings will be the same. When the key is auto-generated, ASP.NET uses SHA-1 encoding to create a large key. However, in a Web-farm environment, the key must be the same across all the servers. If the key is not the same, and the page is posted back to a different server than the one that created the page, the ASP.NET page framework will raise an exception. Therefore, in a Web farm environment, you should specify a key in the Machine.config file instead of letting ASP.NET auto-generate one. In that case, make sure that you create a key that is long enough to offer sufficient security for the hashed value. However, the longer the key is, the more time it takes to create a hash. Therefore, you must weigh security needs versus performance needs.

Encrypting View StateAlthough MAC encoding helps prevent tampering with view state data, it does not prevent users from viewing the data. You can prevent people from viewing this data in two ways: by transmitting the page over SSL, and by encrypting the view state data. Requiring the page to be sent over SSL can help prevent data-packet sniffing and unauthorized data access by people who are not the intended recipients of the page.

However, the user who requested the page can still view the view state data because SSL decrypts the page to display it in the browser. This is fine if you are not concerned about authorized users having access to view state data. However, in some cases, controls might use view state to store information that no users should have access to. For example, the page might contain a data-bound control that stores item identifiers (data keys) in view state. If those identifiers contain sensitive data, such as customer IDs, you should encrypt the view state data in addition to or instead of sending the page over SSL.To encrypt the data, set the page’s ViewStateEncryptionMode property to true. If you store information in view state, you can use regular read and write techniques; the page handles all encryption and decryption for you. Encrypting view state data can affect the performance of your application. Therefore, do not use encryption unless you need it.

Control State EncryptionControls that use control state can require that view state be encrypted by calling the RegisterRequiresViewStateEncryption method. If any control in the page requires that view state be encrypted, all view state in the page will be encrypted.

Per-user View State EncodingIf a Web site authenticates users, you can set the ViewStateUserKeyproperty in the Page_Init event handler to associate the page’s view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid, pre-filled Web page with view state from a previously created page. The attacker then lures a victim into clicking a link that sends the page to the server by using the victim’s identity.When the ViewStateUserKey property is set, the attacker’s identity is used to create the hash of the view state of the original page. When the victim is lured into resending the page, the hash values will be different because the user keys are different. The page will fail verification and an exception will be thrown.You must associate the ViewStateUserKey property with a unique value for each user, such as the user name or identifier.

Securing Configuration in Shared Hosting EnvironmentIn a shared hosting environment, malicious users can potentially modify state-management properties that might affect other applications on the computer. This can be done through direct modification of the Machine.config file, modification by way of the configuration classes, and other administration and configuration tools. You can help prevent modification to your application configuration by encrypting sections of configuration files. For more information, see Encrypting Configuration Information Using Protected ConfigurationClass Reference

ViewState Provides a dictionary object for retaining values between requests for the same page.

PageStatePersister

Provides a means to define a custom mechanism for storing view state information, such as in a SQL Server database.

 ASP.NET Session State OverviewUse ASP.NET session state to store and retrieve values for a user.This topic contains: 

Background Code Examples Class Reference

A Visual Studio project with source code is available to accompany this topic: Download.BackgroundASP.NET session state enables you to store and retrieve values for a user as the user navigates ASP.NET pages in a Web application. HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides a way to persist variable values for the duration of that session. By default, ASP.NET session state is enabled for all ASP.NET applications.Alternatives to session state include the following:

Application state, which stores variables that can be accessed by all users of an ASP.NET application. Profile properties, which persists user values in a data store without expiring them. ASP.NET caching, which stores values in memory that is available to all ASP.NET applications. View state, which persists values in a page. Cookies. The query string and fields on an HTML form that are available from an HTTP request.

For a comparison of different state-management options, see ASP.NET State Management Recommendations.

Session VariablesSession variables are stored in a SessionStateItemCollection object that is exposed through the HttpContext.Session property. In an ASP.NET page, the current session variables are exposed through the Session property of the Page object.

The collection of session variables is indexed by the name of the variable or by an integer index. Session variables are created by referring to the session variable by name. You do not have to declare a session variable or explicitly add it to the collection. The following example shows how to create session variables in an ASP.NET page for the first and last name of a user, and set them to values retrieved from TextBox controls.Session["FirstName"] = FirstNameTextBox.Text;Session["LastName"] = LastNameTextBox.Text;Session variables can be any valid .NET Framework type. The following example stores an ArrayList object in a session variable named StockPicks. The value returned by the StockPicks session variable must be cast to the appropriate type when you retrieve it from the SessionStateItemCollection.// When retrieving an object from session state, cast it to// the appropriate type.ArrayList stockPicks = (ArrayList)Session["StockPicks"];// Write the modified stock picks list back to session state.Session["StockPicks"] = stockPicks;

 Note When you use a session-state mode other than InProc, the session-variable type must be either a primitive .NET type or serializable. This is because the session-variable value is stored in an external data store. For more information, see Session-State Modes.     

Session IdentifiersSessions are identified by a unique identifier that can be read by using theSessionID property. When session state is enabled for an ASP.NET application, each request for a page in the application is examined for aSessionID value sent from the browser. If no SessionID value is supplied, ASP.NET starts a new session and the SessionID value for that session is sent to the browser with the response.By default, SessionID values are stored in a cookie. However, you can also configure the application to store SessionID values in the URL for a “cookieless” session.A session is considered active as long as requests continue to be made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, the session is considered expired. Requests made with an expired SessionIDvalue result in a new session.

 Security Note SessionID values are sent in clear text, whether as a cookie or as part of the URL. A malicious user could get access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID value.     

Cookieless SessionIDsBy default, the SessionID value is stored in a non-expiring session cookie in the browser. However, you can specify that session identifiers should not be stored in a cookie by setting the cookieless attribute to true in thesessionState section of the Web.config file.The following example shows a Web.config file that configures an ASP.NET application to use cookieless session identifiers.Copy<configuration>  <system.web>    <sessionState cookieless=”true”      regenerateExpiredSessionId=”true” />  </system.web></configuration>ASP.NET maintains cookieless session state by automatically inserting a unique session ID into the page’s URL. For example, the following URL has been modified by ASP.NET to include the unique session ID lit3py55t21z5v55vlm25s55:Copy

http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspxWhen ASP.NET sends a page to the browser, it modifies any links in the page that use an application-relative path by embedding a session ID value in the links. (Links with absolute paths are not modified.) Session state is maintained as long as the user clicks links that have been modified in this manner. However, if the client rewrites a URL that is supplied by the application, ASP.NET may not be able to resolve the session ID and associate the request with an existing session. In that case, a new session is started for the request.The session ID is embedded in the URL after the slash that follows the application name and before any remaining file or virtual directory identifier. This enables ASP.NET to resolve the application name before involving theSessionStateModule in the request.

 Note To improve the security of your application, you should allow users to log out of your application, at which point the application should call theAbandon method. This reduces the potential for a malicious user to get the unique identifier in the URL and use it to retrieve private user data stored in the session.     

Regenerating Expired Session IdentifiersBy default, the session ID values that are used in cookieless sessions are recycled. That is, if a request is made with a session ID that has expired, a new session is started by using the SessionID value that is supplied with the request. This can result in a session unintentionally being shared when a link that contains a cookieless SessionID value is used by multiple browsers. (This can occur if the link is passed through a search engine, through an e-mail message, or through another program.) You can reduce the chance of session data being shared by configuring the application not to recycle session identifiers. To do this, set the regenerateExpiredSessionId attribute of the sessionState configuration element to true. This generates a new session ID when a cookieless session request is made with an expired session ID.

 Note If the request that is made with the expired session ID is made by using the HTTP POST method, any posted data will be lost when regenerateExpiredSessionId is true. This is because ASP.NET performs a redirect to make sure that the browser has the new session identifier in the URL.     

Custom Session IdentifiersYou can implement a custom class to supply and validate SessionID values. To do so, create a class that inherits the SessionIDManager class and override the CreateSessionID and Validate methods with your own implementations. For an example, see the example provided for theCreateSessionID method.You can replace the SessionIDManager class by creating a class that implements the ISessionIDManager interface. For example, you might have a Web application that associates a unique identifier with non-ASP.NET pages (such as HTML pages or images) by using an ISAPI filter. You can implement a custom SessionIDManager class to use this unique identifier with ASP.NET session state. If your custom class supports cookieless session identifiers, you must implement a solution for sending and retrieving session identifiers in the URL.

Session ModesASP.NET session state supports several storage options for session variables. Each option is identified as a session-state Mode type. The default behavior is to store session variables in the memory space of the ASP.NET worker process. However, you can also specify that session state should be stored in a separate process, in a SQL Server database, or in a custom data source. If you do not want session state enabled for your application, you can set the session mode to Off.For more information, see Session-State Modes.

Session EventsASP.NET provides two events that help you manage user sessions. TheSession_OnStart event is raised when a new session starts, and theSession_OnEnd event is raised when a session is abandoned or expires. Session events are specified in the Global.asax file for an ASP.NET application.The Session_OnEnd event is not supported if the session Mode property is set to a value other than InProc, which is the default mode.

 Note If the Global.asax file or Web.config file for an ASP.NET application is modified, the application will be restarted and any values stored in application state or session state will be lost. Be aware that some anti-virus software can update the last-modified date and time of the Global.asax or Web.config file for an application.For more information, see Session-State Events.    

Configuring Session StateSession state is configured by using the sessionState element of the system.web configuration section. You can also configure session state by using the EnableSessionState value in the @ Page directive.The sessionState element enables you to specify the following options:

The mode in which the session will store data. The way in which session identifier values are sent between the client and the server. The session Timeout value. Supporting values that are based on the session Mode setting.

The following example shows a sessionState element that configures an application for SQLServer session mode. It sets the Timeout value to 30 minutes, and specifies that session identifiers are stored in the URL.<sessionState mode=”SQLServer”  cookieless=”true “  regenerateExpiredSessionId=”true “  timeout=”30″  sqlConnectionString=”Data Source=MySqlServer;Integrated Security=SSPI;”  stateNetworkTimeout=”30″/>You can disable session state for an application by setting the session-state mode to Off. If you want to disable session state for only a particular page of an application, you can set the EnableSessionState value in the @ Page directive to false. The EnableSessionState value can also be set to ReadOnly to provide read-only access to session variables.

Concurrent Requests and Session StateAccess to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If theEnableSessionState value in the @ Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.Back to topCode ExamplesHow to: Save Values in Session State How to: Read Values from Session State Implementing a Session-State Store Provider Back to top Class ReferenceThe following table lists key classes that relate to session state are in theSystem.Web.SessionState namespace.

Member DescriptionSessionIDManager Manages unique identifiers for ASP.NET session state.SessionStateItemCollection Used to store session state variables. ASP.NET Application State OverviewApplication state is a data repository available to all classes in an ASP.NET application. Application state is stored in memory on the server and is faster than storing and retrieving information in a database. Unlike session state, which is specific to a single user session, application state applies to all users and sessions. Therefore, application state is a useful place to store small amounts of often-used data that does not change from one user to another. For information on saving data on a per-user basis see ASP.NET Session State Overview and ASP.NET Profile Properties Overview.Using Application StateYou can access members of objects stored in application state without having to reference the Application collection. The following code example shows how to reference a member of an object defined in the StaticObjects collection of application state. Notice that the label identifier defined in Global.asax is used as the variable name.protected void Page_Load(Object sender, EventArgs e){    Label1.Text = MyInfo.Title;

}Application State ConsiderationsWhen using application state, you must be aware of the following important considerations:

Resources   Because it is stored in memory, application state is very fast compared to saving data to disk or a database. However, storing large blocks of data in application state can fill up server memory, causing the server to page memory to disk. As an alternative to using application state, you can use the ASP.NET cache mechanism for storing large amounts of application data. The ASP.NET cache also stores data in memory and is therefore very fast; however, ASP.NET actively manages the cache and will remove items when memory becomes scarce. For more information see ASP.NET Caching Overview.

Volatility   Because application state is stored in server memory, it is lost whenever the application is stopped or restarted. For example, if the Web.config file is changed, the application is restarted and all application state is lost unless application state values have been written to a non-volatile storage medium such as a database.

Scalability   Application state is not shared among multiple servers serving the same application, as in a Web farm, or among multiple worker processes serving the same application on the same server, as in a Web garden. Your application therefore cannot rely on application state containing the same data for application state across different servers or processes. If your application will run in multi-processor or multi-server environments, consider using a more scalable option, such as a database, for data that must preserve fidelity across the application.

Concurrency   Application state is free-threaded, which means that application state data can be accessed simultaneously by many threads. Therefore, it is important to ensure that when you update application state data, you do so in a thread-safe manner by including built-in synchronization support. You can use the Lock and UnLock methods to ensure data integrity by locking the data for writing by only one source at a time. You can also reduce the likelihood of concurrency problems by initializing application state values in the Application_Start method in the Global.asax file. ASP.NET Profile Properties OverviewIn many applications, you want to store and use information that is unique to a user. When a user visits your site, you can use the information you have stored to present the user with a personalized version of your Web application. Personalizing an application requires a number of elements: you must store the information using a unique user identifier, be able to recognize users when they visit again, and then fetch the user information as needed. To simplify your applications, you can use the ASP.NET profile feature, which can perform all of these tasks for you.The ASP.NET profile feature associates information with an individual user and stores the information in a persistent format. Profiles allow you to manage user information without requiring you to create and maintain your own database. In addition, the ASP.NET profile feature makes the user information available using a strongly typed API that you can access from anywhere in your application.You can store objects of any type using profiles. The profile feature provides a generic storage feature that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner.How ASP.NET Profiles WorkTo use profiles, you first enable profiles by modifying the configuration file for your ASP.NET Web application. As part of the configuration, you specify a profile provider, which is the underlying class that performs the low-level tasks of storing and retrieving profile data. You can use the profile provider included with the .NET Framework, which stores profile data in SQL Server, or you can create and use your own profile provider as described in the topic Implementing a Profile Provider. You can specify an instance of the SqlProfileProvider that connects to a database of your choosing, or you can use the default instance of the SqlProfileProvider that stores profile data on the local Web server.You configure the profile feature by defining a list of properties whose values you want to maintain. For example, you might want to store the user’s postal code so that your application can offer region-specific information, such as weather reports. In the configuration file, you would define a profile property named PostalCode. The profile section of the configuration file might look like the following:Copy<profile>  <properties>    <add />  </properties></profile>When your application runs, ASP.NET creates a ProfileCommon class, which is a dynamically generated class that inherits the ProfileBase class. The dynamic ProfileCommon class includes properties created from the profile property definitions you specify in your application configuration. An instance of this dynamic ProfileCommon class is then set as the value of theProfile property of the current HttpContext and is available to pages in your application.In your application, you collect the value or values you want to store and assign them to the profile properties you have defined. For example, your application’s home page might contain a text box that prompts the user to enter a postal code. When the user enters a postal code, you set a Profileproperty to store the value for the current user, as in the following example:Profile.PostalCode = txtPostalCode.Text;When you set a value for Profile.PostalCode, the value is automatically stored for the current user. You do not need to write any code to determine who the current user is or explicitly store the value in a database���the profile feature performs these tasks for you.When you want to use the value, you can get it in much the same way that you set it. For example, the following code example shows how to call an imaginary function named GetWeatherInfo, passing it the current user’s postal code as stored in a profile:weatherInfo = GetWeatherInfo( Profile.PostalCode );You do not need to explicitly determine who the user is or perform any database lookups. Simply getting the property value out of a profile causes ASP.NET to perform the necessary actions to identify the current user and look up the value in the persistent profile store.

State Management in ASP.NetIn general, Webapplications are stateless i.e. the objects wont persist its state accross request to the web application. In other words, the State or Cache Management is nothing but the way to storing the data in Client-Side and in Server-Side using pretty small memory to maintain its state.There are two major categories of the above :1.      Server-Side State Management2.      Client-Side State ManagementMoving forward, we will see how State Management is done in ASP.Net application.

Server-Side State ManagementSession State: Its nothing but defined as a period of time shared between the web application and user. Every user has individual session. Items/Objects can be placed into the Session which would only define these objects for that user. Session contains key variables which help to identify the related values. This can be thought of as a hash table. Each user would represent a different key node in the hash identifying unique values. The Session variables will be clear by the application which can clear it, as well as through the timeout property in the web config file. Usually the timeout is 20 minutes by default.Session Variables are stored on the server, can hold any type of data including references, they are similar to global variables in a windows application and use HTTP cookies to store a key with which to locate user’s session variables.The collection of session variables is indexed by the name of the variable or by an integer index. Session variables are created by referring to the session variable by name. You do not have to declare a session variable or explicitly add it to the collection.Lets get it cleared from following example:Session[“firstName”] = “Gaurav”   //User’s first nameSession[“lastName”] = “Arora”     //User’s last name// Clear the session variableSession[“FirstName”] = null;//Clear all Session variablesSession.Abandon(); InProc—Stores Session state in the same process as the ASP.NET process [aspnet_wp.exe].StateServer—Stores Session state in a Windows NT process, which is distinct from the ASP.NET process[aspnet_state.exe].SQLServer—Stores Session state in a SQL Server database.Both in StateServer and SQLServer options, we need to ensure that the objects we cache are serializable as data storages are out-of-process systems. Both these options have impact on the application performance as data retrieval and saving operations take more time when compared to the InProc option. So based on our application requirement we should choose the option that best suits our requirement.Note:By default, ASP.NET session state is enabled for all ASP.NET applications.ASP.NET application objectASP.NET provides an object called Application object to store data that is accessible to all user requests. The life span of this object is tied to the application and it is re-created every time the application starts. Unlike ASP.NETSession object this object is accessible to all user requests. Since this storage is created and maintained in an application domain space, this should not be used for data storage in a web farm scenario. This option is very useful to store data like the application metadata (CONFIG files data) that can be loaded to the Application object during application start up and can be used during the life of the application without reloading it every time for each user request. But if there is a requirement to invalidate the cached data whenever there is any change to the CONFIG files while the application is running, this option should not be used as it doesn’t provide any feature to expire the cached data. So in this case other options like the ASP.NET Cache object should be used, which is explained below.Types of Cache –DependenciesWhen anyone add an item to cache, he/she can define the dependency relationships that can force that item to be removed from the cache under specific activities of dependencies.For example: If the cache is dependent on file and when the file data changes you want the cache object to be updated.Following are the difference dependencies:File Dependency :Allows invalidating a specific cache item when a disk based file or files change.object errorData; //Load errorData from errors.xml CacheDependency fileDependency =

  

Recent ArticlesDisable Public holidays in ASP.Net Calendar Control Posted on 7/30/2010 @ 7:37 AM By Bala MuruganHow to Pass Values from One Page to Another in ASP.Net? Posted on 7/24/2010 @ 1:31 AM By Bala MuruganUsing ADRotator Control in ASP.Net-Part 2 Posted on 7/17/2010 @ 1:21 AM BySatheesh Babu BPass Values from CodeBehind to JavaScript and From JavaScript to CodeBehind in ASP.Net Posted on

 Insert Image &  Retrive Image From DatabaseDefault.aspx<form id=”form1″ runat=”server”>    <div>        emp name        <asp:TextBox ID=”TextBox1″ runat=”server”></asp:TextBox>        <br />        <br />        emp image&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;        <asp:FileUpload ID=”FileUpload1″ runat=”server” />        <br />        <br />        <asp:Button ID=”Button1″ runat=”server” onclick=”Button1_Click” Text=”Add”            Width=”100px” />        <asp:Button ID=”Button2″ runat=”server” onclick=”Button2_Click”            Text=”Display” />        <asp:Image ID=”Image1″ runat=”server” Width=”677px” />        <br />     </div></form>Default.aspx.cspublic partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlCommand cmd;    SqlDataReader rd;    public _Default()    {        con = new SqlConnection(“initial catalog=employee;integrated security=yes”);        con.Open();    }    protected void Page_Load(object sender, EventArgs e)    {    }    protected void Button1_Click(object sender, EventArgs e)    {        string fn =FileUpload1.FileName;        FileUpload1.SaveAs(Server.MapPath(@”image/”) + FileUpload1.FileName);        string path=”~/image/”+fn;        cmd = new SqlCommand(“insert into emp values(‘”+TextBox1.Text+”‘,’”+path+”‘)”,con);        int t = cmd.ExecuteNonQuery();        if (t>0)        {            Response.Write(“record inserted”);                   }    }    protected void Button2_Click(object sender, EventArgs e)    {        cmd = new SqlCommand(“select empimage from emp”, con);        rd = cmd.ExecuteReader();        while (rd.Read())        {            Image1.ImageUrl = rd[0].ToString();        }    }}insert record throgh gridview.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title></title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView ID=”GridView1″ ShowFooter=”True”  AutoGenerateColumns=”false”            runat=”server” BackColor=”#DEBA84″ BorderColor=”#DEBA84″ BorderStyle=”None”

            BorderWidth=”1px” CellPadding=”3″ CellSpacing=”2″>            <RowStyle BackColor=”#FFF7E7″ ForeColor=”#8C4510″ />        <Columns>        <asp:TemplateField>        <HeaderTemplate>Emp Id</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblEmpId” runat=”server” Text=’<%# bind(“EmpId”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>        <asp:TextBox ID=”txtEmpId” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>         <asp:TemplateField>        <HeaderTemplate>Emp Name</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblEmpName” runat=”server” Text=’<%# bind(“EmpName”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>        <asp:TextBox ID=”txtEmpName” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField> <asp:TemplateField>        <HeaderTemplate>Emp Salary</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblEmpSalary” runat=”server” Text=’<%# bind(“EmpSalary”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>        <asp:TextBox ID=”txtEmpSalary” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>         <asp:TemplateField>        <HeaderTemplate>Operation</HeaderTemplate>               <FooterTemplate>            <asp:Button ID=”btnAdd” runat=”server” OnClick=”AddRecord” Text=”Add” />        </FooterTemplate>        </asp:TemplateField>        </Columns>            <FooterStyle BackColor=”#F7DFB5″ ForeColor=”#8C4510″ />            <PagerStyle ForeColor=”#8C4510″ HorizontalAlign=”Center” />            <SelectedRowStyle BackColor=”#738A9C” Font-Bold=”True” ForeColor=”White” />            <HeaderStyle BackColor=”#A55129″ Font-Bold=”True” ForeColor=”White” />        </asp:GridView>    </div>    </form></body></html>.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Data.SqlClient;using System.Data;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlCommand  cmd;    SqlDataReader rd;    public _Default()

    {        con = new SqlConnection(“initial catalog=abhi;integrated security=yes”);        con.Open();    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fill();         }    }    void fill()    {        con.Close();        con.Open();        cmd=new SqlCommand (“select * from Employee”,con);        rd = cmd.ExecuteReader();        GridView1.DataSource = rd;        GridView1.DataBind();               rd.Close();                 }    protected void AddRecord(object sender, EventArgs e)    {        TextBox txtEmpId =GridView1.FooterRow.FindControl(“txtEmpId”) as TextBox;        TextBox txtEmpName = GridView1.FooterRow.FindControl(“txtEmpName”) as TextBox;        TextBox txtEmpSalary = GridView1.FooterRow.FindControl(“txtEmpSalary”) as TextBox;        con.Close();        con.Open();        cmd = new SqlCommand(“insert into Employee values(” + Convert.ToInt32(txtEmpId.Text) + “,’” + txtEmpName.Text + “‘,” + Convert.ToDecimal(txtEmpSalary.Text) + “)”, con);        int t=cmd.ExecuteNonQuery();        if (t>0)        {            fill();         }       }}Manipulation(Insert, Update, Delete) in asp.net.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title></title>    <style type=”text/css”>        .style1        {            width: 100%;        }    </style></head><body>    <form id=”form1″ runat=”server”>    <table class=”style1″>        <tr>            <td>                Emp Id</td>

            <td>                <asp:TextBox ID=”txtEmpId” runat=”server”></asp:TextBox>            </td>        </tr>        <tr>            <td>                Emp Name</td>            <td>                <asp:TextBox ID=”txtEmpName” runat=”server”></asp:TextBox>            </td>        </tr>        <tr>            <td>                Emp Salary</td>            <td>                <asp:TextBox ID=”txtEmpSalary” runat=”server”></asp:TextBox>            </td>        </tr>        <tr>            <td colspan=”2″>                <br />                <br />                <asp:Button ID=”btnDisplay” runat=”server” onclick=”btnDisplay_Click”                    Text=”Display” />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;                <asp:Button ID=”btnNext” runat=”server” onclick=”btnNext_Click” Text=”Next” />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;                <asp:Button ID=”btnPrev” runat=”server” onclick=”btnPrev_Click” Text=”Prev” />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;                <asp:Button ID=”btnInsert” runat=”server” onclick=”btnInsert_Click”                    Text=”Insert” />&nbsp;&nbsp;&nbsp;&nbsp;                <asp:Button ID=”btnUpdate” runat=”server” onclick=”btnUpdate_Click”                    Text=”Update” />&nbsp;&nbsp;&nbsp;                <asp:Button ID=”btnDelete” runat=”server” onclick=”btnDelete_Click”                    Text=”Delete” />            </td>        </tr>    </table>    <div>       </div>    </form></body></html>.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Data;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    static int counter;    SqlCommandBuilder bui;

    public _Default()    {        con = new SqlConnection(“initial catalog=abhi;integrated security=yes”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from employee”, con);        adap.Fill(ds, “employee”);        bui = new SqlCommandBuilder(adap);         }    protected void Page_Load(object sender, EventArgs e)    {           }       protected void btnDisplay_Click(object sender, EventArgs e)    {        txtEmpId.Text = ds.Tables["Employee"].Rows[0][0].ToString();        txtEmpName.Text = ds.Tables["Employee"].Rows[0][1].ToString();        txtEmpSalary.Text = ds.Tables["Employee"].Rows[0][2].ToString();    }    protected void btnNext_Click(object sender, EventArgs e)    {        int count = ds.Tables["Employee"].Rows.Count;        counter++;        if (counter<count)        {            txtEmpId.Text = ds.Tables["Employee"].Rows[counter][0].ToString();            txtEmpName.Text = ds.Tables["Employee"].Rows[counter][1].ToString();            txtEmpSalary.Text = ds.Tables["Employee"].Rows[counter][2].ToString();                   }        else        {                       Response.Write(“Record Not Found”);        }    }    protected void btnPrev_Click(object sender, EventArgs e)    {        int count = ds.Tables["Employee"].Rows.Count;        counter–;        if (counter < count)        {            txtEmpId.Text = ds.Tables["Employee"].Rows[counter][0].ToString();            txtEmpName.Text = ds.Tables["Employee"].Rows[counter][1].ToString();            txtEmpSalary.Text = ds.Tables["Employee"].Rows[counter][2].ToString();        }        else        {            Response.Write(“Record Not Found”);        }    }    protected void btnInsert_Click(object sender, EventArgs e)    {        adap.InsertCommand = bui.GetInsertCommand();        DataRow dr=ds.Tables["Employee"].NewRow();        dr[0] = Convert.ToInt32(txtEmpId.Text);        dr[1] = txtEmpName.Text;        dr[2] = Convert.ToDecimal(txtEmpSalary.Text);        ds.Tables["Employee"].Rows.Add(dr);        adap.Update(ds.Tables["Employee"]);    }

    protected void btnUpdate_Click(object sender, EventArgs e)    {     adap.UpdateCommand = bui.GetUpdateCommand();     DataRow[] dr =  ds.Tables["Employee"].Select(“EmpId=”+Convert.ToInt32(txtEmpId.Text)+”");     dr[0][1] = txtEmpName.Text;     dr[0][2] = Convert.ToDecimal(txtEmpSalary.Text);     adap.Update(ds.Tables["Employee"]);    }    protected void btnDelete_Click(object sender, EventArgs e)    {         adap.DeleteCommand = bui.GetDeleteCommand();DataColumn[] dc = new DataColumn[1];dc[0]=ds.Tables["Emp"].Columns["EmpId"];ds.Tables["Emp"].PrimaryKey = dc;DataRow dr=  ds.Tables["Emp"].Rows.Find(Convert.ToInt32(txtEmpId.Text));dr.Delete();adap.Update(ds.Tables["Emp"]);           }}

 display Record in Repeater.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title></title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:Repeater ID=”Repeater1″ runat=”server”>        <HeaderTemplate>        <table>        <tr>        <td style=”width:100px;background-color:Gray;”>Emp Id</td>        <td style=”width:100px;background-color:Gray;”>Emp Name</td>        <td style=”width:100px;background-color:Gray;”>Emp Salary</td>        </tr>        </table>        </HeaderTemplate>        <ItemTemplate>        <table>        <tr>        <td style=”width:100px;background-color:Gray;”>        <asp:Label ID=”lblEmpId” runat=”server” Text=’<%# bind(“EmpId”) %>’>        </asp:Label>        </td>        <td style=”width:100px;background-color:Gray;”>        <asp:Label ID=”lblEmpName” runat=”server” Text=’<%# bind(“EmpName”) %>’>        </asp:Label>        </td>        <td style=”width:100px;background-color:Gray;”>        <asp:Label ID=”lblEmpSalary” runat=”server” Text=’<%# bind(“EmpSalary”) %>’>        </asp:Label>        </td>        </tr>        </table>        </ItemTemplate>        </asp:Repeater>    </div>

    </form></body></html>.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Data;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    public _Default()    {        con = new SqlConnection(“initial catalog=abhi;integrated security=yes”);        ds = new DataSet();    }    protected void Page_Load(object sender, EventArgs e)    {        fill();    }    void fill()    {        adap = new SqlDataAdapter(“select * from employee”,con);        adap.Fill(ds,”Employee”);        Repeater1.DataSource = ds;        Repeater1.DataBind();    }}Deletion in Gridview.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title></title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView ID=”GridView1″ OnRowDeleting=”deleterecord”  AutoGenerateColumns=”False” runat=”server”>        <Columns>        <asp:TemplateField HeaderText=”Emp Id”>        <ItemTemplate>        <asp:Label ID=”lblEmpId” runat=”server” Text=’<%# bind(“EmpId”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>          <asp:TemplateField HeaderText=”Emp Name”>        <ItemTemplate>        <asp:Label ID=”lblEmpName” runat=”server” Text=’<%# bind(“EmpName”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>          <asp:TemplateField HeaderText=”Emp Salary”>        <ItemTemplate>        <asp:Label ID=”lblEmpSalary” runat=”server” Text=’<%# bind(“EmpSalary”) %>’></asp:Label>        </ItemTemplate>

        </asp:TemplateField>          <asp:TemplateField HeaderText=”Operation”>        <ItemTemplate>        <asp:Button ID=”btnDelete” runat=”server” CommandName=”Delete” Text=”Delete” />        </ItemTemplate>        </asp:TemplateField>        </Columns>        </asp:GridView>    </div>    </form></body></html>.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Data.SqlClient;using System.Data;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    SqlCommandBuilder bui;    public _Default()    {        con = new SqlConnection(“initial catalog=abhi;integrated security=yes”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from Employee”, con);        adap.Fill(ds, “Employee”);        bui = new SqlCommandBuilder(adap);    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fill();        }    }    void fill()    {             GridView1.DataSource = ds;        GridView1.DataBind();                 }    protected void deleterecord(object sender, GridViewDeleteEventArgs e)    {        adap.DeleteCommand = bui.GetDeleteCommand();       //DataColumn[] dc = new DataColumn[1];              //  Label lblEmpId   =GridView1.Rows[e.RowIndex].FindControl(“lblEmpId”) as Label;       // DataRow dr= ds.Tables["Employee"].Rows.Find(Convert.ToInt32(lblEmpId.Text));       // dr.Delete();        ds.Tables["Employee"].Rows[e.RowIndex].Delete();        adap.Update(ds.Tables["Employee"]);        fill();

    }}updation in gridview.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title></title></head><body>    <form id=”form1″ runat=”server”>    <div>    <asp:GridView ID=”g1″ OnRowUpdating=”updateRecord” AutoGenerateColumns=”false” OnRowCancelingEdit=”cancelRecord” OnRowEditing=”editRecord” runat=”server”>    <Columns>    <asp:TemplateField HeaderText=”Emp Id”>    <ItemTemplate>    <asp:Label ID=”lblEmpId” runat=”server” Text=’<%# Bind(“EmpId”) %>’></asp:Label>    </ItemTemplate>    </asp:TemplateField>    <asp:TemplateField HeaderText=”Emp Name”>    <ItemTemplate>    <asp:Label ID=”lblEmpName” runat=”server” Text=’<%# Bind(“EmpName”) %>’></asp:Label>    </ItemTemplate>    <EditItemTemplate>    <asp:TextBox ID=”txtEmpName” runat=”server” Text=’<%# Bind(“EmpName”) %>’></asp:TextBox>    </EditItemTemplate>    </asp:TemplateField>    <asp:TemplateField HeaderText=”Emp Salary”>    <ItemTemplate>    <asp:Label ID=”lblEmpSalary” runat=”server” Text=’<%# Bind(“EmpSalary”) %>’></asp:Label>    </ItemTemplate>    <EditItemTemplate>    <asp:TextBox ID=”txtEmpSalary” runat=”server” Text=’<%# Bind(“EmpSalary”) %>’></asp:TextBox>    </EditItemTemplate>    </asp:TemplateField>    <asp:TemplateField HeaderText=”Operation”>    <ItemTemplate>    <asp:Button ID=”btnEdit” runat=”server” CommandName=”Edit” Text=”Edit” />    </ItemTemplate>    <EditItemTemplate>    <asp:Button ID=”btnUpdate” CommandName=”Update” runat=”server”  Text=”Update” />    <asp:Button ID=”btnCancel” runat=”server” CommandName=”Cancel” Text=”Cancel” />    </EditItemTemplate>    </asp:TemplateField>    </Columns>    </asp:GridView>    </div>    </form></body></html>.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Data;using System.Data.SqlClient;

public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    SqlCommandBuilder bui;    public _Default()    {        con = new SqlConnection(“initial catalog=abhi;integrated security=yes”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from Employee”, con);        adap.Fill(ds, “Employee”);        bui = new SqlCommandBuilder(adap);    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fill();        }    }    void fill()    {               g1.DataSource = ds;        g1.DataBind();    }    protected void editRecord(object sender, GridViewEditEventArgs e)    {        g1.EditIndex = e.NewEditIndex;        fill();    }    protected void cancelRecord(object sender, GridViewCancelEditEventArgs e)    {        g1.EditIndex = -1;        fill();    }    protected void updateRecord(object sender, GridViewUpdateEventArgs e)    {        adap.UpdateCommand = bui.GetUpdateCommand();        Label lblEmpId =g1.Rows[e.RowIndex].FindControl(“lblEmpId”) as Label;       TextBox txtEmpName  =g1.Rows[e.RowIndex].FindControl(“txtEmpName”) as TextBox;       TextBox txtEmpSalary = g1.Rows[e.RowIndex].FindControl(“txtEmpSalary”) as TextBox;      DataRow[] dr=  ds.Tables["Employee"].Select(“EmpId=”+Convert.ToInt32(lblEmpId.Text)+”");      dr[0]["EmpName"] = txtEmpName.Text;      dr[0]["EmpSalary"] = Convert.ToDecimal(txtEmpSalary.Text);    int temp=  adap.Update(ds.Tables["Employee"]);    if (temp>0)    {        g1.EditIndex = -1;        fill();           }       }}record show in Datalist.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>

<html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title></title></head><body>    <form id=”form1″ runat=”server”>    <div>    <asp:DataList ID=”d1″ runat=”server”   RepeatColumns=”3″ >     <ItemTemplate>    <table>    <tr>    <td style=”width:100px;”>    <asp:Label ID=”lblEmpId” runat=”server” Text=’<%# bind(“EmpId”) %>’></asp:Label>    </td></tr>    <tr>    <td style=”width:100px;”><asp:Label ID=”Label1″ runat=”server” Text=’<%# bind(“EmpName”) %>’></asp:Label></td></tr>  <tr>  <td style=”width:100px;”><asp:Label ID=”Label2″ runat=”server” Text=’<%# bind(“EmpSalary”) %>’></asp:Label></td>    </tr>    </table>    </ItemTemplate>    </asp:DataList>       </div>    </form></body></html>.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Data;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    public _Default()    {        con = new SqlConnection(“initial catalog=abhi;integrated security=yes”);        ds = new DataSet();    }    protected void Page_Load(object sender, EventArgs e)    {        fill();    }    void fill()    {        DataList d;        Repeater r1;        adap = new SqlDataAdapter(“select * from Employee”,con);        adap.Fill(ds,”Employee”);        d1.DataSource = ds;        d1.DataBind();         

    }}Difference b/w Repeater,Data List & Grid View :-Concept Repeater Data List Grid ViewBase Class Control Web Control Web ControlDefault Output No No YesManipulation No No YesPaging No no YesAuto Formatting No Yes YesRepeat Column No Yes NoSorting No No Yesajax.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title></title>    <script language=”javascript” type=”text/javascript” >        function chk() {            var r = document.getElementById(“TextBox1″).value;            if (r < 60) {                alert(“enter above 60″);                return false;            }            else {                return true;            }        }    </script></head><body>    <form id=”form1″ runat=”server”>    <asp:ScriptManager ID=”ScriptManager1″ runat=”server”>    </asp:ScriptManager>    <asp:UpdatePanel ID=”up1″ runat=”server”>    <ContentTemplate>       <div>        <asp:TextBox ID=”TextBox1″ runat=”server”></asp:TextBox>       <asp:Button ID=”btnfirst” runat=”server”  Text=”first” onclick=”btnfirst_Click” />        <br />        <br />        <br />    </div>    </ContentTemplate>    <Triggers>    <asp:AsyncPostBackTrigger ControlID=”btnfirst” EventName=”Click” />    </Triggers>    </asp:UpdatePanel>     <div>     <asp:TextBox ID=”TextBox2″ runat=”server”></asp:TextBox>       <asp:Button ID=”btnsecond” runat=”server”  Text=”second”            onclick=”btnsecond_Click” />    </div>       </form></body>

</html>.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;public partial class _Default : System.Web.UI.Page{    protected void Page_Load(object sender, EventArgs e)    {        TextBox1.Text = System.DateTime.Now.Second.ToString();        TextBox2.Text = System.DateTime.Now.Second.ToString();         }    protected void Button1_Click(object sender, EventArgs e)    {        Response.Write(“cac”);    }    protected void btnfirst_Click(object sender, EventArgs e)    {        TextBox1.Text = System.DateTime.Now.Second.ToString();           }    protected void btnsecond_Click(object sender, EventArgs e)    {               TextBox2.Text = System.DateTime.Now.Second.ToString();    }}check all in gridview.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title>Untitled Page</title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView ID=”GridView1″ AutoGenerateColumns=”false” runat=”server”>        <Columns>        <asp:TemplateField >        <HeaderTemplate>        <asp:Button ID=”btnDelete” OnClick=”deleterecord” Text=”Delete” runat=”server” />        <asp:CheckBox ID=”chkAll” OnCheckedChanged=”checkallrows” AutoPostBack=”true” runat=”server” />        </HeaderTemplate>        <ItemTemplate>        <asp:CheckBox ID=”chkRow” runat=”server” />        </ItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Emp Id”>        <ItemTemplate>        <asp:Label ID=”lblEmpId” runat=”server” Text=’<%# bind(“Emp_Id”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Emp Name”>        <ItemTemplate>        <asp:Label ID=”lblEmpName” runat=”server” Text=’<%# bind(“Emp_Name”) %>’></asp:Label>

        </ItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Emp Salary”>        <ItemTemplate>        <asp:Label ID=”lblEmpSalary” runat=”server” Text=’<%# bind(“Emp_Salary”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>        </Columns>        </asp:GridView>    </div>    </form></body></html>.aspx.csusing System;using System.Configuration;using System.Data;using System.Linq;using System.Web;using System.Web.Security;using System.Web.UI;using System.Web.UI.HtmlControls;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Xml.Linq;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    SqlCommandBuilder bui;    public _Default()    {        con = new SqlConnection(“initial catalog=abhi;integrated security=yes”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from abhinavsir”,con);        adap.Fill(ds,”Emp”);        bui = new SqlCommandBuilder(adap);    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fill();        }    }    void fill()    {        GridView1.DataSource = ds;        GridView1.DataBind();    }    protected void checkallrows(object sender, EventArgs e)    {      CheckBox chkall  =GridView1.HeaderRow.FindControl(“chkall”) as CheckBox;           for (int i = 0; i < GridView1.Rows.Count; i++)      {          CheckBox chkrow = GridView1.Rows[i].FindControl(“chkrow”) as CheckBox;          if (chkall.Checked==true)          {              chkrow.Checked = true;

          }          else          {              chkrow.Checked = false;          }               }       }    protected void deleterecord(object sender, EventArgs e)    {               for (int i = 0; i < GridView1.Rows.Count; i++)        {          CheckBox chkrow = GridView1.Rows[i].FindControl(“chkrow”) as CheckBox;          if (chkrow.Checked==true)          {              adap.DeleteCommand = bui.GetDeleteCommand();              ds.Tables["Emp"].Rows[i].Delete();                                  }        }        int t = adap.Update(ds.Tables["Emp"]);        fill();    }}Record insert & Delete in gridview though  disconnected mode.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title>Untitled Page</title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView OnRowDeleting=”DeleteRecord” AutoGenerateColumns=”False” ShowFooter=”True” ID=”GridView1″            runat=”server”>        <Columns>        <asp:TemplateField>        <HeaderTemplate>Product No</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblProductNo” runat=”server” Text=’<%# bind(“Product_No”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>            <asp:TextBox ID=”txtProductNo” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>        <asp:TemplateField>        <HeaderTemplate>Product Name</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblProductName” runat=”server” Text=’<%# bind(“Product_Name”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>            <asp:TextBox ID=”txtProductName” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>        <asp:TemplateField>        <HeaderTemplate>Product Price</HeaderTemplate>

        <ItemTemplate>        <asp:Label ID=”lblProductPrice” runat=”server” Text=’<%# bind(“Product_Price”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>            <asp:TextBox ID=”txtProductPrice” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>        <asp:TemplateField>        <HeaderTemplate>Operation</HeaderTemplate>        <ItemTemplate>        <asp:Button ID=”btnDelete” runat=”server” CommandName=”Delete” Text=”Delete” />        </ItemTemplate>         <FooterTemplate>             <asp:Button ID=”btnSave” runat=”server” OnClick=”saverecord” Text=”Save” />        </FooterTemplate>        </asp:TemplateField>        </Columns>        </asp:GridView>    </div>    </form></body></html>.csusing System;using System.Configuration;using System.Data;using System.Linq;using System.Web;using System.Web.Security;using System.Web.UI;using System.Web.UI.HtmlControls;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    SqlCommandBuilder bui;    public _Default()    {        con = new SqlConnection(“initial catalog=ritu;uid=sa;pwd=sa”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from Product”,con);        adap.Fill(ds,”Prod”);        bui = new SqlCommandBuilder(adap);    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fillrecord();        }    }    void fillrecord()    {        GridView1.DataSource = ds;        GridView1.DataBind();    }    protected void saverecord(object sender, EventArgs e)    {

        adap.InsertCommand = bui.GetInsertCommand();       TextBox txtProductNo =GridView1.FooterRow.FindControl(“txtProductNo”) as TextBox;       TextBox txtProductName = GridView1.FooterRow.FindControl(“txtProductName”) as TextBox;       TextBox txtProductPrice = GridView1.FooterRow.FindControl(“txtProductPrice”) as TextBox;      DataRow dr =ds.Tables["Prod"].NewRow();      dr[0] = Convert.ToInt32(txtProductNo.Text);      dr[1] = txtProductName.Text;      dr[2] =Convert.ToDecimal(txtProductPrice.Text);      ds.Tables["Prod"].Rows.Add(dr);      int t=adap.Update(ds.Tables["Prod"]);      if (t>0)      {          fillrecord();      }    }    protected void DeleteRecord(object sender, GridViewDeleteEventArgs e)    {        adap.DeleteCommand = bui.GetDeleteCommand();       ds.Tables["Prod"].Rows[e.RowIndex].Delete();       adap.Update(ds.Tables["Prod"]);           fillrecord();          }}Record insert & Delete in gridview though  disconnected mode.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title>Untitled Page</title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView OnRowDeleting=”DeleteRecord” AutoGenerateColumns=”False” ShowFooter=”True” ID=”GridView1″            runat=”server”>        <Columns>        <asp:TemplateField>        <HeaderTemplate>Product No</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblProductNo” runat=”server” Text=’<%# bind(“Product_No”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>            <asp:TextBox ID=”txtProductNo” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>        <asp:TemplateField>        <HeaderTemplate>Product Name</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblProductName” runat=”server” Text=’<%# bind(“Product_Name”) %>’></asp:Label>        </ItemTemplate>        <FooterTemplate>            <asp:TextBox ID=”txtProductName” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>        <asp:TemplateField>        <HeaderTemplate>Product Price</HeaderTemplate>        <ItemTemplate>        <asp:Label ID=”lblProductPrice” runat=”server” Text=’<%# bind(“Product_Price”) %>’></asp:Label>        </ItemTemplate>

        <FooterTemplate>            <asp:TextBox ID=”txtProductPrice” runat=”server”></asp:TextBox>        </FooterTemplate>        </asp:TemplateField>        <asp:TemplateField>        <HeaderTemplate>Operation</HeaderTemplate>        <ItemTemplate>        <asp:Button ID=”btnDelete” runat=”server” CommandName=”Delete” Text=”Delete” />        </ItemTemplate>         <FooterTemplate>             <asp:Button ID=”btnSave” runat=”server” OnClick=”saverecord” Text=”Save” />        </FooterTemplate>        </asp:TemplateField>        </Columns>        </asp:GridView>    </div>    </form></body></html>.csusing System;using System.Configuration;using System.Data;using System.Linq;using System.Web;using System.Web.Security;using System.Web.UI;using System.Web.UI.HtmlControls;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    SqlCommandBuilder bui;    public _Default()    {        con = new SqlConnection(“initial catalog=ritu;uid=sa;pwd=sa”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from Product”,con);        adap.Fill(ds,”Prod”);        bui = new SqlCommandBuilder(adap);    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fillrecord();        }    }    void fillrecord()    {        GridView1.DataSource = ds;        GridView1.DataBind();    }    protected void saverecord(object sender, EventArgs e)    {        adap.InsertCommand = bui.GetInsertCommand();       TextBox txtProductNo =GridView1.FooterRow.FindControl(“txtProductNo”) as TextBox;       TextBox txtProductName = GridView1.FooterRow.FindControl(“txtProductName”) as TextBox;

       TextBox txtProductPrice = GridView1.FooterRow.FindControl(“txtProductPrice”) as TextBox;      DataRow dr =ds.Tables["Prod"].NewRow();      dr[0] = Convert.ToInt32(txtProductNo.Text);      dr[1] = txtProductName.Text;      dr[2] =Convert.ToDecimal(txtProductPrice.Text);      ds.Tables["Prod"].Rows.Add(dr);      int t=adap.Update(ds.Tables["Prod"]);      if (t>0)      {          fillrecord();      }    }    protected void DeleteRecord(object sender, GridViewDeleteEventArgs e)    {        adap.DeleteCommand = bui.GetDeleteCommand();       ds.Tables["Prod"].Rows[e.RowIndex].Delete();       adap.Update(ds.Tables["Prod"]);           fillrecord();          }}  .updation through Gridview.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title>Untitled Page</title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView ID=”GridView1″ OnRowUpdating=”updaterecord” OnRowCancelingEdit=”cancelrecord” OnRowEditing=”editrecord” AutoGenerateColumns=”false”  runat=”server”>        <Columns>        <asp:TemplateField HeaderText=”Product No”>        <ItemTemplate>        <asp:Label ID=”lblProductNo” runat=”server” Text=’<%# bind(“Product_no”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Product Name”>        <ItemTemplate>        <asp:Label ID=”lblProductName” runat=”server” Text=’<%# bind(“Product_name”) %>’></asp:Label>        </ItemTemplate>        <EditItemTemplate>        <asp:TextBox ID=”txtProductName” runat=”server” Text=’<%# bind(“Product_name”) %>’></asp:TextBox>        </EditItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Product Price”>        <ItemTemplate>        <asp:Label ID=”lblProductPrice” runat=”server” Text=’<%# bind(“Product_Price”) %>’></asp:Label>        </ItemTemplate>        <EditItemTemplate>        <asp:TextBox ID=”txtProductPrice” runat=”server” Text=’<%# bind(“Product_Price”) %>’></asp:TextBox>        </EditItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Operation”>        <ItemTemplate>            <asp:Button ID=”btnEdit” CommandName=”Edit” runat=”server” Text=”Edit” />        </ItemTemplate>

        <EditItemTemplate>            <asp:Button ID=”btnUpdate” runat=”server” Text=”Update” CommandName=”update” />            <asp:Button ID=”btnCancel” runat=”server” Text=”Cancel” CommandName=”cancel” />        </EditItemTemplate>        </asp:TemplateField>        </Columns>        </asp:GridView>    </div>    </form></body></html>.csusing System;using System.Configuration;using System.Data;using System.Linq;using System.Web;using System.Web.Security;using System.Web.UI;using System.Web.UI.HtmlControls;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Xml.Linq;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    SqlCommandBuilder bui;    public _Default()    {        con = new SqlConnection(“initial catalog=ritu;uid=sa;pwd=sa”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from product”,con);        adap.Fill(ds,”product”);        bui = new SqlCommandBuilder(adap);    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fillrecord();        }    }    void fillrecord()    {        GridView1.DataSource = ds;        GridView1.DataBind();      }    protected void editrecord(object sender, GridViewEditEventArgs e)    {        GridView1.EditIndex = e.NewEditIndex;        fillrecord();    }    protected void cancelrecord(object sender, GridViewCancelEditEventArgs e)    {        GridView1.EditIndex = -1;        fillrecord();    }    protected void updaterecord(object sender, GridViewUpdateEventArgs e)

    {        adap.UpdateCommand = bui.GetUpdateCommand();        Label lblProductNo = GridView1.Rows[e.RowIndex].FindControl(“lblProductNo”) as Label;        TextBox txtProductName = GridView1.Rows[e.RowIndex].FindControl(“txtProductName”) as TextBox;        TextBox txtProductPrice = GridView1.Rows[e.RowIndex].FindControl(“txtProductPrice”) as TextBox;      DataRow[] dr  =ds.Tables["Product"].Select(“Product_No=”+Convert.ToInt32(lblProductNo.Text)+”");      dr[0][1] = txtProductName.Text;      dr[0][2] =Convert.ToDecimal(txtProductPrice.Text);     int t =adap.Update(ds,”Product”);     if (t>0)     {         GridView1.EditIndex = -1;         fillrecord();      }    }}Check All Through Gridview.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title>Untitled Page</title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView ID=”GridView1″ AutoGenerateColumns=”false”  runat=”server”>        <Columns>        <asp:TemplateField >        <HeaderTemplate>        <asp:Button ID=”btnDelete” OnClick=”deleterecord” Text=”Delete” runat=”server” />        <asp:CheckBox Text=”Check All” OnCheckedChanged=”checkRows” AutoPostBack=”true” ID=”chkAll” runat=”server” />        </HeaderTemplate>        <ItemTemplate>        <asp:CheckBox  ID=”chkRow” runat=”server” />        </ItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Product No”>        <ItemTemplate>        <asp:Label ID=”lblProductNo” runat=”server” Text=’<%# bind(“Product_no”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Product Name”>        <ItemTemplate>        <asp:Label ID=”lblProductName” runat=”server” Text=’<%# bind(“Product_name”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>        <asp:TemplateField HeaderText=”Product Price”>        <ItemTemplate>        <asp:Label ID=”lblProductPrice” runat=”server” Text=’<%# bind(“Product_Price”) %>’></asp:Label>        </ItemTemplate>        </asp:TemplateField>               </Columns>                      </asp:GridView>    </div>    </form>

</body></html>.csusing System;using System.Configuration;using System.Data;using System.Linq;using System.Web;using System.Web.Security;using System.Web.UI;using System.Web.UI.HtmlControls;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Xml.Linq;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlDataAdapter adap;    DataSet ds;    SqlCommandBuilder bui;    public _Default()    {        con = new SqlConnection(“initial catalog=ritu;uid=sa;pwd=sa”);        ds = new DataSet();        adap = new SqlDataAdapter(“select * from product”, con);        adap.Fill(ds, “product”);        bui = new SqlCommandBuilder(adap);    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fillrecord();        }    }    void fillrecord()    {        GridView1.DataSource = ds;        GridView1.DataBind();    }    protected void checkRows(object sender, EventArgs e)    {        CheckBox chkall = GridView1.HeaderRow.FindControl(“chkAll”) as CheckBox;        for (int i = 0; i < GridView1.Rows.Count; i++)        {            CheckBox chkrow = GridView1.Rows[i].FindControl(“chkrow”) as CheckBox;            if (chkall.Checked==true)            {                chkrow.Checked = true;            }            else            {                chkrow.Checked = false;            }        }    }    protected void deleterecord(object sender, EventArgs e)    {        adap.DeleteCommand = bui.GetDeleteCommand();        for (int i = 0; i < GridView1.Rows.Count; i++)        {

            CheckBox chkrow = GridView1.Rows[i].FindControl(“chkrow”) as CheckBox;            if (chkrow.Checked == true)            {                ds.Tables["Product"].Rows[i].Delete();               }                   }       int t =adap.Update(ds.Tables["Product"]);       if (t>0)       {           fillrecord();       }    }}    usingSystem;usingSystem.Collections.Generic;usingSystem.Linq;usingSystem.Web;usingSystem.Web.UI;usingSystem.Web.UI.WebControls;usingSystem.Net.Mail;usingSystem.Net; publicpartial class _Default : System.Web.UI.Page {protected void Page_Load(object sender, EventArgs e){MailMessage m = newSystem.Net.Mail.MailMessage(“abhinavdotnet@gmail.com”,“abhsax1@gmail.com”,“aaa”,“asasasas”);try{NetworkCredential n = new NetworkCredential(“username”, “password”);SmtpClient s = new SmtpClient(“smtp.gmail.com”, 587);s.EnableSsl = true;s.UseDefaultCredentials = false;s.Credentials = n;s.Send(m);Response.Write(“m s”);}catch (Exception){throw;}}}Hyperlink in Asp.netDefault.aspx<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title>Untitled Page</title>

</head><body>    <form id=”form1″ runat=”server”>    <div>    <asp:GridView ID=”g1″ AutoGenerateColumns=”false” runat=”server”>    <Columns>    <asp:HyperLinkField HeaderText=”Emp Id” DataTextField=”EmpId” DataNavigateUrlFields=”EmpId”  DataNavigateUrlFormatString=”detail.aspx?temp={0}” />    <asp:TemplateField HeaderText=”Emp Name”>    <ItemTemplate>    <asp:Label ID=”lblEmpName” runat=”server” Text=’<%# bind(“EmpName”) %>’ ></asp:Label>    </ItemTemplate>    </asp:TemplateField>    <asp:TemplateField HeaderText=”Emp Salary”>    <ItemTemplate>    <asp:Label ID=”lblEmpSalary” runat=”server” Text=’<%# bind(“EmpSalary”) %>’ ></asp:Label>    </ItemTemplate>    </asp:TemplateField>       </Columns>    </asp:GridView>    </div>    </form></body></html>Default.aspx.csusing System;using System.Configuration;using System.Data;using System.Linq;using System.Web;using System.Web.Security;using System.Web.UI;using System.Web.UI.HtmlControls;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Xml.Linq;using System.Data.SqlClient;public partial class _Default : System.Web.UI.Page{    SqlConnection con;    SqlCommand cmd;    SqlDataReader rd;    public _Default()    {        con = new SqlConnection(“initial catalog=Employee;integrated security=yes”);        con.Open();    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fillrecord();        }    }    void fillrecord()    {        cmd = new SqlCommand(“select * from Emp”,con);        rd = cmd.ExecuteReader();        g1.DataSource = rd;        g1.DataBind();

    }}Detail.aspx<%@ Page Language=”C#” AutoEventWireup=”true” CodeFile=”detail.aspx.cs” Inherits=”detail” %><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“><html xmlns=”http://www.w3.org/1999/xhtml“><head runat=”server”>    <title>Untitled Page</title></head><body>    <form id=”form1″ runat=”server”>    <div>        <asp:GridView ID=”GridView1″ runat=”server”>        </asp:GridView>    </div>    </form></body></html>detail.aspx.csusing System;using System.Collections;using System.Configuration;using System.Data;using System.Linq;using System.Web;using System.Web.Security;using System.Web.UI;using System.Web.UI.HtmlControls;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Xml.Linq;using System.Data.SqlClient;public partial class detail : System.Web.UI.Page{    SqlConnection con;    SqlCommand cmd;    SqlDataReader rd;    public detail()    {        con = new SqlConnection(“initial catalog=Employee;integrated security=yes”);        con.Open();    }    protected void Page_Load(object sender, EventArgs e)    {        if (!IsPostBack)        {            fillrecord();        }    }    void fillrecord()    {        cmd = new SqlCommand(“select * from Empdetail where empid=”+Convert.ToInt32(Request.QueryString["temp"].ToString())+”", con);        rd = cmd.ExecuteReader();        GridView1.DataSource = rd;        GridView1.DataBind();    }}Server-side options for storing page information typically have higher security than client-side options, but they can use more Web server resources, which can lead to scalability issues when the size of the information store is large. ASP.NET

provides several options to implement server-side state management. For more information, see ASP.NET State Management Overview.The following are the server-side state management options that ASP.NET supports:ASP.NET offers you a variety of ways to maintain state information on the server, rather than persisting information on the client. With server-based state management, you can decrease the amount of information sent to the client in order to preserve state, however it can use costly resources on the server. The following sections describe three server-based state management features: application state, session state, and profile properties.Application StateASP.NET allows you to save values using application state — which is an instance of the HttpApplicationState class — for each active Web application. Application state is a global storage mechanism that is accessible from all pages in the Web application. Thus, application state is useful for storing information that needs to be maintained between server round trips and between requests for pages. For more information, see ASP.NET Application State Overview.Application state is stored in a key/value dictionary that is created during each request to a specific URL. You can add your application-specific information to this structure to store it between page requests.Application state is stored in an instance of the HttpApplicationState class. This class exposes a key-value dictionary of objects.TheHttpApplicationState instance is created the first time a user accesses any URL resource in an application. The HttpApplicationState class is most often accessed through the Application property of the HttpContext class.You can use application state in two ways. You can add, access, or remove values from the Contents collection directly through code. The HttpApplicationStateclass can be accessed at any time during the life of an application. However, it is often useful to load application state data when the application starts. To do so, you can put code to load application state into the Application_Start method in the Global.asax file.Alternatively, you can add objects to the StaticObjects collection via an <object runat=”server”> declaration in your Web application’s Global.asax file. Application state defined in this way can then be accessed from code anywhere in your application. The following example shows an object declaration for an application state value:CopyYou can add objects to the StaticObjectscollection only in the Global.asax file. The collection throws aNotSupportedException if you attempt to add objects directly through code.

1 Response to "Asp.Net"

abhinavdotnetnotesFebruary 14, 2011 at 5:16 am

I sended fully discription of webservice in c# .net

Reply

Leave a ReplyYour email address will not be published. Required fields are marked *

Name *

Email *

Website

 Notify me of follow-up comments via email.

 Subscribe to this site by email

Search

Top Posts

Latest Comments

Post Comment

Tags

Project 2011

Asp.Net

Have a nice day

Ado.Net

C# .net

Java Script

C# Notes

.Net Framework

Categories Uncategorized  (1)

Archives August 2010

Blog at WordPress.com.

Theme: Albeo by Design Disease.