Interview Tips Interview Tips, Interview Questions and Answers

25Oct/100

asp.net session configuration

Below is a sample config.web file used to configure the session state settings for an ASP.NET application:

mode="inproc"
cookieless="false"
timeout="20"
sqlconnectionstring="data source=127.0.0.1;user id=;password= "
server="127.0.0.1"
port="42424"
/>

The settings above are used to configure ASP.NET session state. Let's look at each in more detail and cover the various uses afterward.

* Mode. The mode setting supports three options: inproc, sqlserver, and stateserver. As stated earlier, ASP.NET supports two modes: in process and out of process. There are also two options for out-of-process state management: memory based (stateserver), and SQL Server based (sqlserver). We'll discuss implementing these options shortly.
* Cookieless. The cookieless option for ASP.NET is configured with this simple Boolean setting.
* Timeout. This option controls the length of time a session is considered valid. The session timeout is a sliding value; on each request the timeout period is set to the current time plus the timeout value
* Sqlconnectionstring. The sqlconnectionstring identifies the database connection string that names the database used for mode sqlserver.
* Server. In the out-of-process mode stateserver, it names the server that is running the required Windows NT service: ASPState.
* Port. The port setting, which accompanies the server setting, identifies the port number that corresponds to the server setting for mode stateserver.

22Oct/100

ASP.NET Session State

ASP.NET session state solves all of the above problems associated with classic ASP session state:

* Process independent. ASP.NET session state is able to run in a separate process from the ASP.NET host process. If session state is in a separate process, the ASP.NET process can come and go while the session state process remains available. Of course, you can still use session state in process similar to classic ASP, too.
* Support for server farm configurations. By moving to an out-of-process model, ASP.NET also solves the server farm problem. The new out-of-process model allows all servers in the farm to share a session state process. You can implement this by changing the ASP.NET configuration to point to a common server.
* Cookie independent. Although solutions to the problem of cookieless state management do exist for classic ASP, they're not trivial to implement. ASP.NET, on the other hand, reduces the complexities of cookieless session state to a simple configuration setting.

16Jun/100

ASP.NET Cookies Overview

A 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 Limitations

Most 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."

17Feb/100

asp.net interview questions: state management

  1. What is the lifespan for items stored in ViewState?
    Item stored in ViewState exist for the life of the current page.  This includes postbacks (to the same page).
  2. What is ViewState?
    ViewState allows the state of objects (serializable) to be stored in a hidden field on the page.  ViewState is transported to the client and back to the server, and is not stored on the server or any other external source.  ViewState is used the retain the state of server-side objects between postabacks.
  3. What are the different types of Session state management options available with ASP.NET?
    ASP.NET provides In-Process and Out-of-Process state management.  In-Process stores the session in memory on the web server.  This requires the a "sticky-server" (or no load-balancing) so that the user is always reconnected to the same web server.  Out-of-Process Session state management stores data in an external data source.  The external data source may be either a SQL Server or a State Server service.  Out-of-Process state management requires that all objects stored in session are serializable.
  4. What does the "EnableViewState" property do?  Why would I want it on or off?
    It allows the page to save the users input on a form across postbacks.  It saves the server-side values for a given control into ViewState, which is stored as a hidden value on the page before sending the page to the clients browser.  When the page is posted back to the server the server control is recreated with the state stored in viewstate.