Scribd
Upload
17 views35 pages

Unit V

The document discusses master pages in ASP.NET which allow creating a consistent layout across pages. Master pages define common elements like headers and navigation that can be applied to multiple content pages. Content pages combine the master page layout with unique content.

Uploaded by

Adinath
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
17 views35 pages

Unit V

The document discusses master pages in ASP.NET which allow creating a consistent layout across pages. Master pages define common elements like headers and navigation that can be applied to multiple content pages. Content pages combine the master page layout with unique content.

Uploaded by

Adinath
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 35

Unit-V

ASP.NET Master Page


Assistant professor: Bhise G.G
ASP.NET Master Pages Overview
ASP.NET master pages allow you to create a consistent layout for the pages in
your application. A single master page defines the look and feel and standard
behavior that you want for all of the pages (or a group of pages) in your
application. You can then create individual content pages that contain the content
you want to display. When users request the content pages, they merge with the
master page to produce output that combines the layout of the master page with
the content from the content page.

Master pages in ASP.NET work as a template page. All aspx pages can refer
master pages. With the help of Master pages we can define the look and feel of
all the pages in our web site in a single location. If we have done changes in master
page, then the changes will reflect in all the web pages that refer to master
pages.

ASP.NET web page that uses master page for common UI, is called as content
page. Content pages merge with the master pages at compile time to produce final
output. The final page combines the layout of the master page with the content
from the content page.

Before Master pages feature in ASP.NET, developers created consistent web


pages by using custom controls, CSS and JavaScript. Now developing consistent
web pages are very easy with the help of Master pages. You can dynamically
change the common UI part on master page from content pages.
A master page has the extension .master that can comprise static text, HTML
elements, and server controls. A master page is similar to an ASP.NET page but it
contains @Master directive at the top and one or more ContentPlaceHolder server
controls.
Master page inherits from the MasterPage class.
ContentPlaceHolder is an important control that is related with master page.
ContentPlaceHolder control is available only on master page. You can use more
than one ContentPlaceHolder control in master page. ContentPlaceHolder control
is used on master page to customize or add some controls on the content page as
follows : <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">

</asp:ContentPlaceHolder>

The page-specific content is then put inside a Content control that points to the
relevant ContentPlaceHolder:

<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1"


Runat="Server">
<asp:Button ID="Button1" runat="server" Text="Button" />
</asp:Content>
In the above example a Button control is placed inside Content control.
Note that the ContentPlaceHolderID attribute of the Content control points to
the ContentPlaceHolder1 that is defined in the master page.
Open your visual studio, create a new website and add the master page. You will
see the code as given below.

<%@ Master Language="C#" AutoEventWireup="true"


CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
<asp:ContentPlaceHolder id="head" runat="server">
</asp:ContentPlaceHolder>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:ContentPlaceHolder id="ContentPlaceHolder1"
runat="server">
</asp:ContentPlaceHolder>
</div>
</form>
</body>
</html>

The Need for Master Pages

In this lesson, you will learn about the need for and evolution of master pages in
ASP.NET in Visual Studio IDE. Master pages are created in a website to enhance
modularity and user-friendliness. They help standardize the designing elements
like header, footer, navigation menus, and other parts, which are common to the
entire web site and present on every single page of the web application.

Introduction#

Websites always use some elements repeatedly, like menu logos, headers, footers,
and sidebars. Some developers simply copy and paste the code for the common
elements to every page. This works, but the process is very cumbersome. Every
change to any of the elements needs to be done to each page manually. Formerly,
this was the only way to duplicate the change.

Another more sophisticated way was to include all the common elements into a so-
called ‘include file’. Then a link to this page would be included whereever needed.
Like at the top, the ‘header.aspx’ would be included, and at the bottom,
‘footer.aspx’ would be included. But, closing of the HTML tags was difficult. Web
pages sometimes displayed strange results because of inappropriate, non-existent
tag openings or closings. This made web developers unable to see the whole web
page.

Then, web developers tried using user controls to encapsulate common sections of
their web pages. The Drag-and-Drop technique was used, but the common areas
were displayed only as gray boxes, and visualizing the webpage was not possible.
The issue of matching tags remained the same.

Master pages#

Then, the ASP.NET team developed the idea of master pages: a unique way to
apply templates to web applications. User controls are embedded within the page
and are doomed to duplication. But master pages live outside the aspx page. The
master pages draw distinct lines between the common areas and unique content
areas of each page.

Master pages provide an easy template that is used by any number


of ASP.NET pages in the web application. A master file with a .master extension is
created, which is referenced by the subpage or the content page.

While deploying a master page, you can see the template in the IDE and the
design of the content page in the Design part of the IDE.
Benefits of master pages#

Many people and enterprises find using master pages ideal, as the technology
models their typical business requirements. Since most companies want to apply a
common look and feel across the intranet, they can provide the divisions of the
company with a .master file to use while creating a department’s section of the
intranet.

Once a master page has been defined, it can be bound to new ASP.NET pages
through the tick of a checkbox. These content pages include content placeholder
controls. When the web page is opened in a browser, ASP.NET’s engine creates
the master page’s control hierarchy and injects the control pages hierarchy at the
proper places. This combined control hierarchy is rendered and the resulting
HTML is rendered to the end user’s browser.

MasterPage

1. The extension of MasterPage is '.master'.


2. MasterPage cannot be directly accessed from the client because it just acts
as a template for the other Content Pages.
3. In a MasterPage we can have content either inside ContentPlaceHolder or
outside it. Only content inside the ContentPlaceHolder can be customized in
the Content Page.
4. We can have multiple masters in one web application.
5. A MasterPage can have another MasterPage as Master to it.
6. The content page content can be placed only inside the content tag.
7. Controls of MasterPage can be programmed in the MasterPage and content
page but a content page control will never be programmed in MasterPage.
8. A master page of one web application cannot be used in another web
application.
9. The MasterPageFile property of a webform can be set dynamically and it
should be done either in or before the Page_PreInit event of the
WebForm. Page.MasterPageFile = "MasterPage.master". The dynamically set
Master Page must have the ContentPlaceHolder whose content has been
customized in the WebForm.
10. The order in which events are raised: Load (Page) a Load (Master)
a LoadComplete (Page) i.e. if we want to overwrite something already done in
Load event handler of Master then it should be coded in the LoadComplete
event of the page.
11. Page_Load is the name of method for event handler for Load event of
Master. (it's not Master_Load).

Master page Layout with CSS

A Master Page enables us to share the same content among multiple content pages
in a website. We can use a Master Page to create a common page layout. For
example, if we want all the pages in our website to share a three-column layout,
we can create the layout once in a Master Page and apply the layout to multiple
content pages. We also can use Master Pages to display common content in
multiple pages. For example, if we want to display a standard header and footer in
each page in our website, then we can create the standard header and footer in a
Master Page. By taking advantage of Master Pages, we can make our website
easier to maintain, extend, and modify. If we need to add a new page to our
website that looks just like the other pages in our website, then we simply need to
apply the same Master Page to the new content page. If we decide to completely
modify the design of our website, we do not need to change every content page.
We can modify just a single Master Page to dramatically change the appearance of
all the pages in our application by using CSS. Take a look at the following example
for a better understanding.

Using CSS in Master Page

A Master Page has the .master extension and we create a Master Page by creating
a file that ends with the .master extension. We can locate a Master Page file
anywhere within an application. We also can add multiple Master Pages to the same
application.

<%@ Master Language="VB" CodeFile="MasterPage.master.vb" Inherits="MasterPa


ge" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1
transitional.dtd">
<html>
<head id="Head1" runat="server">
<style type="text/css">
html
{
background-color:silver;
font:14px Arial,Sans-Serif;
}
.content
{
margin:auto;
width:700px;
background-color:white;
border:Solid 3px blue;
}
.leftColumn
{
float:left;
padding:5px;
width:200px;
}
.rightColumn
{
float:left;
padding:5px;
height:auto;
border-left:dotted 3px blue;
}
.clear
{
clear:both;
}
</style>
<title>Using CSS in Master Page</title>
</head>
<body>
<form id="form1" runat="server">
<div class="content">
<div class="leftColumn">
<asp:contentplaceholder
id="ContentPlaceHolder1"
runat="server"/>
</div>
<div class="rightColumn">
<asp:contentplaceholder
id="ContentPlaceHolder2"
runat="server"/>
</div>
<br class="clear" />
</div>
</form>
</body>
</html>

In the above example, the Master Page looks very much like a normal ASP.NET
page. In fact, we can place almost all the same elements in a Master Page that
we can place in an ASP.NET page, including HTML, server-side scripts, and
ASP.NET controls. There are two special things about the Master Page. First, the
file contains a <%@ Master %> directive instead of the normal <%@ Page %>
directive. Second, the Master Page includes a ContentPlaceHolder control which is
for referral by child pages/content pages. When the Master Page is merged with
a particular content page, the content from the content page appears in the areas
marked by the ContentPlaceHolder controls. We can add as many
ContentPlaceHolders to a Master Page as we need.

The Master Page given below has a two-column page layout. Each
ContentPlaceHolder control is contained in a separate <div> tag. Cascading Style
Sheet (CSS) rules are used to position the two <div> tags into a two-column page
layout.
The content page, which uses a Master Page is given below:

<%@ Page Title="" Language="VB" MasterPageFile="~/MasterPage.master" AutoEv


entWireup="false"CodeFile="Default.aspx.vb" Inherits="_Default" %>
<asp:Content
ID="LeftOne"
ContentPlaceHolderID="ContentPlaceHolder1"
Runat="Server">
<b>This is heading like text for right column.</b>
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
</asp:Content>
<asp:Content
ID="RightOne"
ContentPlaceHolderID="ContentPlaceHolder2"
Runat="Server">
<b>This is menu like text for left column.</b>
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
<br />This is my data area.
</asp:Content>

When we open the preceding page in a web browser, the contents of the page are
merged with the Master Page. The Master Page is associated with the content
page through the MasterPageFile attribute included in the <%@ Page %> directive.
This attribute contains the virtual path to a Master Page. The content page does
not contain any of the standard opening and closing XHTML tags. All these tags
are contained in the Master Page. All the content contained in the content page
must be added with Content controls. We must place all the content contained in a
content page within the Content controls. If we attempt to place any content
outside these controls, we get an exception. The Content control includes a
ContentPlaceHolderID property. This property points to the ID of a
ContentPlaceHolder control contained in the Master Page. Within a Content
control, we can place anything that we would normally add to an ASP.NET page,
including XHTML tags and ASP.NET controls.

https://www.completecsharptutorial.com/mvc-articles/mvc-design-master-page-
layout-with-css-html-template.php

https://www.tutorialspoint.com/adobe_robohelp/adobe_robohelp_creating_worki
ng_on_master_pages.htm

Every ASP.NET developer needs to be familiar with Page Directives. If you are a
beginner and you want to learn about the Page Directives then you can read this
article.
So the first question is about Page Directives.

What is a Page Directive?

Basically, Page Directives are commands. These commands are used by the
compiler when the page is compiled.

How to use the directives in an ASP.NET page

It is not difficult to add a directive to an ASP.NET page. It is simple to add


directives to an ASP.NET page. You can write directives in the following format:

<%@[Directive][Attributes]%>

See the directive format, it starts with "<%@" and ends with "%>". The best way
is to put the directive at the top of your page. But you can put a directive
anywhere in a page. One more thing, you can put more than one attribute in a
single directive.

Here is the full list of directives:

• @Page
• @Master
• @Control
• @Import
• @Implements
• @Register
• @Assembly
• @MasterType
• @Output Cache
• @PreviousPageType
• @Reference

Let's discuss something about each directive.

@Page
When you want to specify the attributes for an ASP.NET page then you need to
use @Page Directive. As you know, an ASP.NET page is a very important part of
ASP.NET, so this directive is commonly used in ASP.NET.

Example:

1. <%@Page Language="C#" AutoEventWIreup="false" CodeFile="Default.aspx.


cs" Inherits="_Default"%>

@Master

Now you have some information about @Page Directives. The @Master Directive
is quite similar to the @Page Directive. The only difference is that the @master
directive is for Master pages. You need to note that, while using the @Master
Directive you define the template page's property. Then any content page can
inherit all the properties defined in the Master Page. But there are some
properties that are only available in a Master Page.

Example

1. <%@Master Language="C#" AutoEventWIreup="false" CodeFile="MasterPag


e1.master.cs" Inherits="MasterPage"%>

@Control

@Control builds ASP.NET user controls. When you use the directive you define
the properties to be inherited by the user controls and theses values are assigned
to the user controls

Example:

1. <%@Control Language="C#" Explicit="True" CodeFile="WebUserControl.ascx.


cs" Inherits="WebUserControl" %>

@Import
As you know you need to define namespaces in your .cs class before using a C# or
VB class. So the @Import Directive imports namespaces. This directive supports
just a single attribute "namespace" and this attribute takes a string value that
specifies the namespace to be imported. One thing you need to note is that the
@Import Directive cannot contain more than one attribute/value pair. But you
can use multiple lines.

Example:

1. <%@Import Namespace="System.Data"%>

@Implements

The @Implements Directive gets the ASP.NET pages to implement .Net


framework interfaces. This directive only supports a single attribute interface.

Example:

1. <%@Implements Interface="System.Web.UI.IValidator"%>

@Register

When you create a user control and you drag that user control onto your page
then you will see the @Register directive. This directive registers your user
control on the page so that the control can be accessed by the page.

Example:

1. <%@ Register TagPrefix="MayTag Namespace="MyName.MyNameSpace" Ass


embly="MyAssembly"%>

@Assembly

The @Assembly Directive attaches assemblies to the page or an ASP.NET user


control thereby all the assembly classes and interfaces are available to the class.
This directive supports the two attributes Name and src. The Name attribute
defines the assembly name and the src attribute defines the source of the
assembly.

Example:

1. <%@Assembly Name="MyAssembly"%>
2. <%@Assembly src="MYAssembly.cs">

@MasterType

The @MasterType Directive connects a class name to the ASP.NET page for
getting strongly typed references or members contained in the specified Master
Page. This directive supports the two attributes Typename and virtualpath.
Typename sets the name of the derived class from which to get the strongly
typed or reference members and virtualpath sets the location of the page from
which these are retrieved.

Example:

1. <%@MasterType VirtualPath="/MasterPage1.master"%>

@output cache

It controls the output caching policies of an ASP.NET page.

Example:

1. <%@ OutputCache Duration ="180" VaryByParam="None"%>

@Previouspagetype

This directive specifies the page from which any cross-page posting originates.

@Reference

This directive declares that another page or user control shout be complied along
with the active page or control. This directive supports the single attribute
virtualpath. It sets the location of the page or user control from which the active
page will be referenced.

Example:

1. <%@Reference VirtualPayh="~/MyControl.ascx"%>

Final Words

I hope you get some knowledge from here. Please comment about how you like this
article. Your comments are very valuable for me, because only you will tell me
where I am going wrong and what improvements I need to make to write a better
article. Please comment and provide your feedback.

Content Place holder

https://docs.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-
getting-started/master-pages/multiple-contentplaceholders-and-default-content-
cs

creating and apply theme

Introduction

Themes are also a new feature of ASP.NET that helps maintain a consistent look
and feel across all or several pages of our web site. Themes are needed when we
want to keep the style and layout information files separate from other web site
files. A theme is a collection of settings that define the look of controls and web
pages. These themes are applied across all the pages in a web application to
maintain a consistent appearance. Themes are included images and skin files; the
skin files set the visual properties of ASP.NET controls. Themes are of two types:

Page Theme

A Page theme contains the control skins, style sheets, graphic files, and other
resources inside the subfolder of the App_Theme folder in the Solution Explorer
window. A page theme is applied to a single page of the web site.
Global Theme

A Global theme is a theme that is applied to all the web sites on a web server and
includes property settings, and graphics. This theme allows us to maintain all the
websites on the same web server and define the same style for all the web pages
of the web sites.

Let's create a theme application with the help of the following steps:

Step 1 : Open Microsoft Visual Studio 2010.

Step 2 : Select File->New->Web Site.

Step 3 : Select ASP.NET Web Site and then click Ok.

Step 4 : Now right-click in the application name in the Solution Explorer window
and select Add
ASP.NET Folder->Theme from the context menu.

A sub folder named Theme1 is automatically created inside


the APP_Themes folder in the Solution Explorer.
Step 5 : Right-click on the Theme1 folder and select the Add New Item option.

Step 6 : Select the Skin file and click the Add button.

Now write the following code in the skin file.


Step 7 : Write the following code for Default.aspx page.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs"


Inherits="_Default" Theme="Theme1" %>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<asp:Label ID="Label2" runat="server" Font-Bold="False"
Font-Names="Comic Sans MS" Font-Underline="True"
Text="THEME EXAMPLE"></asp:Label>
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<asp:Label ID="Label1" runat="server" Text="enter the data in the text
box">
</asp:Label>
&nbsp;&nbsp;<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<asp:TextBox ID="TextBox1" runat="server" Height="42px" Width="237px">
</asp:TextBox>
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<asp:Button ID="Button1" runat="server" Text="Click Button"
BorderColor="#996633" BorderStyle="Solid" BorderWidth="5px" He
ight="60px" />
<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;
<asp:Label ID="Label3" runat="server" Text="Select the
Theme"></asp:Label>
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;
<br />
<br />
<br />
</div>
</form>
</body>
</html>

The design window will look like:


Step 8 : Now Press F5 key to run the application.

Output :

Now we will create an application for applying the theme at run time.

Step 9 : To do this add another skin file to the application and write the
following code for both skin files.

Code for simple theme is as follows:


Step 10 : Add the following code to the Default.aspx file:

The design window looks like:


Step 11 : Now write the following code for the default.aspx.cs file:

using 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
{
void Page_PreInit(object sender, EventArgs e)
{
// Get the theme name from a QueryString variable
string ThemeName;
ThemeName = Request.QueryString["Theme"];
if (ThemeName != null)
{
Page.Theme = ThemeName;
}
}
}

Step 12 : Press F5 keys to run the application:

Output :

After selecting the Simple theme the output is as follows:


After selecting the Coloured theme the output as follows:
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.

Scenarios

Cookies 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 top

Background

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

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 Cookies

The 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 the Response 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.

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:

VBCopy

Response.Cookies("userName").Value = "patrick"
Response.Cookies("userName").Expires = DateTime.Now.AddDays(1)

DimaCookieAsNewHttpCookie("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
type NameObjectCollectionBase.

For the second cookie, the code creates an instance of an object of


type HttpCookie, 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 Value

You 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
subkeysuserName 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:

VBCopy

Response.Cookies("userInfo")("userName") = "patrick"
Response.Cookies("userInfo")("lastVisit") = DateTime.Now.ToString()
Response.Cookies("userInfo").Expires = DateTime.Now.AddDays(1)

DimaCookieAsNewHttpCookie("userInfo")
aCookie.Values("userName") = "patrick"
aCookie.Values("lastVisit") = DateTime.Now.ToString()
aCookie.Expires = DateTime.Now.AddDays(1)
Response.Cookies.Add(aCookie)
Controlling Cookie Scope

By 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 Application

To limit cookies to a folder on the server, set the cookie's Path property, as in
the following example:
VBCopy

DimappCookieAsNewHttpCookie("AppCookie")
appCookie.Value = "written "&DateTime.Now.ToString()
appCookie.Expires = DateTime.Now.AddDays(1)
appCookie.Path = "/Application1"
Response.Cookies.Add(appCookie)

ASP.NET Application State

Application 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 State

Application state is stored in an instance of the HttpApplicationState class. This


class exposes a key-value dictionary of objects.

The HttpApplicationState 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 HttpApplicationState class 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. For more information
see ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0.
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:

Copy

<object runat="server" scope="application" ID="MyInfo"


PROGID="MSWC.MYINFO">
</object>

You can add objects to the StaticObjects collection only in the Global.asax file.
The collection throws a NotSupportedException if you attempt to add objects
directly through code.

You 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 that is defined in the
Global.asax file is used as the variable name.

VBCopy

ProtectedSubPage_Load(ByVal sender AsObject, ByVal e AsEventArgs)


Label1.Text = MyInfo.Title
EndSub
Application State Considerations

When 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. For more
information see ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0.

ASP.NET Session State

ASP.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 Variables

Session 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.

VBCopy

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.

VBCopy

' When retrieving an object from session state, cast it to


' the appropriate type.
DimstockPicksAsArrayList = CType(Session("StockPicks"), ArrayList)

' Write the modified stock picks list back to session state.
Session("StockPicks") = stockPicks

Session Identifiers

Sessions are identified by a unique identifier that can be read by using


the SessionID property. When session state is enabled for an ASP.NET
application, each request for a page in the application is examined for
a SessionID 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 SessionID value result in a new session.

Regenerating Expired Session Identifiers

By 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.

You might also like