Convert An Image into Byte[]

using System.Drawing.Imaging;

string FileName = "\\NoImage.jpg";

string DocumentPath = Server.MapPath("~/Images");

System.Drawing.Bitmap myBitmap = new System.Drawing.Bitmap(DocumentPath + FileName);

imgByte = GetImageBytes(myBitmap); //Calling the function GetImageBytes()

fileExtn = "jpg";

//Definition for GetImageBytes()

private byte[] GetImageBytes(System.Drawing.Image image)

{

ImageCodecInfo codec = null;

foreach (ImageCodecInfo e in ImageCodecInfo.GetImageEncoders())

{

if (e.MimeType == "image/png")

{

codec = e;

break;

}

}

using (EncoderParameters ep = new EncoderParameters())

{

ep.Param[0] = new EncoderParameter(Encoder.Quality, 100L);

using (MemoryStream ms = new MemoryStream())

{

image.Save(ms, codec, ep);

return ms.ToArray();

}

}

}

Page Element Attributes in Asp.Net 2.0 and there uses

In asp.Net 2.0 there are many attributes in the page tag itself. Each attribute has a special meaning to it. These attributes are defined in the page so that we can specify them for specific pages. Most of them are also defined globally so that we do not have define them in the page.

Here is a list of attributes of the Page Tag.

asyncTimeout – This is an optional attribute to define the timeout for the asynchronous handler during asynchronous processing of the page. The default value is 45 sec.

autoeventWireup – This is also an optional attribute that defines if the events in the page are automatically enabled. The default value is true. This means

if we define a Page_load(with same signature) method in the page class, the event will be automatically be attached with page load method.

buffer – defines if there will be response buffereing based on URL resource. The default value is true

Compilationmode – This attribute is defined for the asp.net compiler. It defines the compilation model for the page. The values can be Always (meaning page should be compiled every time), Auto (meaning) compiler should not compile the page if possible and never (meaning that the page should never be compiled).

EnableEventValidation – defines if the page controls will be validated in the postback /callback or not.

EnableSessionState - defines the usages of session in the page. Default value is true. Other possible values are false (session will not be saved) and read only (session values can only be read but not written to).

EnableViewState – As the name suggest the tag specifies if the view state will be enabled for the page.

EnableViewStateMac – checks for the authentication of the viewstate. The check is made to check if the viewstate has been tampered on the client side. The default value is true.

MaintainscrollPositiononPostback - Maintains the position of the scroll during post back. The default value is false.

MasterPageFile – Is used to define the master Page for the page (if any).

MaxPageStateFieldLength – This is another optional attribute which takes and int32 type parameter. The attribute is used to define max length of character for the state field of the page. When set to a positive number, the viewstate of the page is broken into many numbers with a max character provided in the field. If the value is a negative number that the viewstate is kept in one variable only. The default value is -1.

PageBaseType – Takes a string value defining the base type that will be used for the bage. The default is System.Web.UI.Page. The value gets overridden by the value in the inherits attribute in the standalone file.

PageParserFilterType - Specifies the type name of a filter that is used by the ASP.NET parser to determine whether an item is allowed in the page at parse time. The filter must derive from the PageParserFilter class.

smartNavigation – determines if the page is going to use smart navigation for IE browser (5.5+). When set to true, in the browser, Navigational flash is eliminated, scroll position is persisted, Element focus is persisted and the history of the browser only stores the last state of the page. The default value is false.

styleSheetTheme – defines the Theme to be used by the page. The theme defined in the attribute is used before the creation of controls.

Theme - Specifies the theme to be used for the page. The theme is applied after the creation of the control.

userControlbaseType – specifies the base type for controls to be used when the page is standalone.

ValidateRequest – Defines if Asp.Net will validate the request for potential dangerous data. Te default value is true.

ViewStateEncryptionMode – Defines the mode of encryption of the viewstate. The attribute will override any default value provided in the configuration value. Possible values are Always, Auto (Viewstate is only encrypted if a controls request for it) and Never. The default value is Auto.

Advantages and disadvantages of ASP.NET Server Controls and HTML Server Controls

Difference between ASP.NET Server Controls and HTML Server Controls

ASP.NET Server Controls

Advantages:

1. ASP .NET Server Controls can detect the target browser's capabilities and render themselves accordingly. No issues for compatibility issues of Browsers i.e page that might be used by both HTML 3.2 and HTML 4.0 browsers code is written in the Server Controls.

2. Newer set of controls that can be used in the same manner as any HTML control like Calender controls. Without any need of Activex Control without bringing up issues of Browser compatibility).

3. Processing would be done at the server side. In built functionality to check for few values(with Validation controls) so no need to choose between scripting language which would be incompatible with few browsers.

4. ASP .NET Server Controls have an object model different from the traditional HTML and even provide a set of properties and methods that can change the outlook and behavior of the controls.

5. ASP .NET Server Controls have higher level of abstraction. An output of an ASP .NET server control can be the result of many HTML tags that combine together to produce that control and its events. Example Gridview or Form control.

Disadvantages:

1. The control of the code is inbuilt with the web server controls so you have no much of direct control on these controls

HTML Server Controls

Advantages:

1. The HTML Server Controls follow the HTML-centric object model. Model similar to HTML

2. Here the controls can be made to interact with Client side scripting. Processing would be done at client as well as server depending on your code.

5. A HTML Server Control has similar abstraction with its corresponding HTML tag and offers no abstraction.

Disadvantages:

1. You would need to code for the browser compatibility.

2. The HTML Server Controls have no mechanism of identifying the capabilities of the client browser accessing the current page.

Using the 'is' and 'as' keyword

Using 'is' and 'as' keyword in C# instead of reflection:

Now a days people are so much relayed on the casting reference types and reflection that they forget the use of the other keyword in the system to work out the same. I support the use of the inbuilt keywords like as and is because they are faster and many a times they also make us rely on hard coding the type of the object.

Reflection is a very powerful tool but it also has some performance degradation as against the inbuilt keywords. Also if we use the inbuilt keywords we don’t have to hard code the type in the code. With reflection to check the type of an object we would write the following code.

if(Variable.GetType() == Type.GetType("System.String"))

Here we are using reflection to get the type of the variable. It has 2 disadvantages. First of all it’s using which has its own performance hit and second that for checking purpose the type of the Variable has been hard coded. We can do the same task simply without using any reflection.

if(Variable is string)

In the above code we are not using any reflection, but still are able to compare the type of the Variable very easily and the code would be extremely fast.

Also while casting a variable to one type we use reflection even when we can do away with it.

myVariable = (string)Request["myVariable"];

can easily be written as

myVariable = Request["myVariable"] as string;

Here if the variable cannot be cast the IL will return a null value. This method would only work for reference type. For value types like int etc we can use System.convert.

Overview of user controls vs. custom controls

Web custom controls are compiled components that run on the server and encapsulate the user-interface and other related functionality into reusable packages. They can include all the design-time features of standard ASP.NET server controls, including full support for Visual Studio design features such as the Properties window, the visual designer, and the Toolbox. There are several ways to create Web custom controls:

You can compile a control that combines the functionality of two or more existing controls. For example, if you need a control that encapsulates a button and a text box. You can create it by compiling the existing controls together.

If an existing server control almost meets your requirements but lacks some required features, you can customize the control by deriving from it and overriding its properties, methods, and events. If none of the existing Web server controls (or their combination's) meet your requirements, you can create a custom control by deriving from one of the base control classes. These classes provide all the functionality like other Web server controls. You only need to write the logic for the programming features you require.

If none of the existing ASP.NET server controls meet the specific requirements of your applications, you can create either a Web user control or a Web custom control that encapsulates the functionality you need.

The main difference between the two controls lies in ease of creation vs. ease of use at design time. Web user controls are easy to make, but they can be less convenient to use in advanced scenarios. Web user controls can be developed almost exactly the same way that you develop Web Form pages.

Like Web Forms, user controls can be created in the visual designer or they can be written with code separate from the HTML. They can also support execution events. However, since Web user controls are compiled dynamically at run time they cannot be added to the Toolbox and they are represented by a simple placeholder when added to a page.

This makes Web user controls harder to use if you are accustomed to full Visual Studio .NET design-time support, including the Properties window and Design view previews. Also the only way to share the user control between applications is to put a separate copy in each application, which takes more maintenance if you make changes to the control.

Web custom controls are compiled code, which makes them easier to use but more difficult to create. Web custom controls must be authored in code. Once you have created the control you can add it to the Toolbox and display it in a visual designer with full Properties window support and all the other design-time features of ASP.NET server controls. In addition you can install a single copy of the Web custom control in the global assembly cache and share it between applications

, which make maintenance easier.

Difference:

Web User Controls:
1) Easy to Create.
2) Limited support for consumers who use visual design tool.
3) A separate copy of the control is required in each application.
4) Cannot be added to toolbox in Visual Studio.
5) Good for Static Layout.
6) If the control you are going to create is only for a particular website then User
  Control is the best option.
7) It's an .ascx

Web Custom Controls:
1) Harder to Create.
2) Full support for consumers.
3) Only a single copy of the control is required in the GAC.
4) Can be added to toolbox in Visual Studio.
5) Good for Dynamic Layout.
6) One Custom control can share diffrent application.
7) It's a .dll

Useful Links For Reference

1) Nine Options for Managing Persistent User State in Your ASP.NET Application

2) Passing Dataset From One Page TO Another In ASP.Net

ASP .NET Control Naming Conventions

Control Name Example

Label lblName lbl

TextBox txtName txt

GridView gvResult gv
Button btnSave btn
ImageButton ibtnSave ibtn
Hyperlink lnkHomePage lnk
DropDownList ddlCompany ddl
ListBox lstCompany lst
DataList dlstAddress dlst
Repeater repSection rep
Checkbox chkMailList chk
CheckBoxList chkAddress chk
RadioButton rdoSex rdo
RadioButtonList rdoAgeGroup rdo
Image imgLogo img
Panel panSection pan
PlaceHolder plhHeader plh
Calender calMyDate cal
Adrotator adrBanner adr
Table tblResults tbl
[All]Validators valCreditCardNumber val
ValidationSummary valsErrors vals

How to re-register ASP.NET

To re-register ASP.NET

From a command prompt window, run the following command: systemroot\Microsoft.NET\Framework\ versionNumber \aspnet_regiis -i

Note With Windows Server 2003, you can install ASP.NET using the Add or Remove Programs Control Panel.

ASP.NET Page Life Cycle Stages:

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

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

Initialization : During page initialization, controls on the page are available and each control's UniqueID property is set. A master page and themes are also applied to the page if applicable. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.

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

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

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

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

Life-Cycle Events
Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code.

The page life-cycle events that you will use most frequently are given below.
PreInit :Raised after the start stage is complete and before the initialization stage begins.

Use this event for the following:

• Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.

• Create or re-create dynamic controls.

• Set a master page dynamically.

• Set the Theme property dynamically.

• Read or set profile property values.

If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.

Init : Raised after all controls have been initialized and any skin settings have been applied. The Init event of individual controls occurs before the Init event of the page.

Use this event to read or initialize control properties.

InitComplete : Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event.

Use this event to make changes to view state that you want to make sure are persisted after the next postback.

PreLoad : Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request instance.

Load :The Page object calls the OnLoad method on the Page object, and then recursively does the same for each child control until the page and all controls are loaded. The Load event of individual controls occurs after the Load event of the page.

Use the OnLoad event method to set properties in controls and to establish database connections.

Control events : Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event.

In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.

LoadComplete : Raised at the end of the event-handling stage.

Use this event for tasks that require that all other controls on the page be loaded.

PreRender : Raised after the Page object has created all controls that are required in order to render the page, including child controls of composite controls. (To do this, the Page object calls EnsureChildControls for each control and for the page.)

The Page object raises the PreRender event on the Page object, and then recursively does the same for each child control. The PreRender event of individual controls occurs after the PreRender event of the page.

Use the event to make final changes to the contents of the page or its controls before the rendering stage begins.

PreRenderComplete :

Raised after each data bound control whose DataSourceID property is set calls its DataBind method. For more information, see Data Binding Events for Data-Bound Controls later in this topic.

SaveStateComplete :

Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.

Render : This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup to send to the browser.

If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. For more information, see Developing Custom ASP.NET Server Controls.

A user control (an .ascx file) automatically incorporates rendering, so you do not need to explicitly render the control in code.

Unload :

Raised for each control and then for the page.

In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections.

For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks.

During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.

---

The .NET Framework

The .NET Framework is a common environment for building, deploying, and running Web Services and Web Applications.

NET framework 2.0:

It brings a lot of evolution in class of the framework and refactor control including the support of:
Generics, Anonymous methods, Partial class, Nullable type..
The new API gives a fine grain control on the behavior of the runtime with regards to multithreading, memory allocation, assembly loading and more Full 64-bit support for both the x64 and the IA64 hardware platforms
New personalization features for ASP.NET, such as support for themes, skins and webparts.
.NET Micro Framework
New personalization features for ASP.NET, such as support for themes, skins and webparts.

.NET framework 3.0:

Also called WinFX,includes a new set of managed code APIs that are an integral part of Windows Vista and Windows Server 2008 operating systems and provides

Windows Presentation Foundation (WPF), formerly code-named Avalon; a new user interface subsystem and API based on XML and vector graphics, which will make use of 3D computer graphics hardware and Direct3D technologies.
• Windows Communication Foundation (WCF), formerly code-named Indigo; a service-oriented messaging system which allows programs to interoperate locally or remotely similar to web services.
• Windows Workflow Foundation (WWF) allows for building of task automation and integrated transactions using workflows.
• Windows CardSpace (WCS), formerly code-named InfoCard; a software component which securely stores a person's digital identities and provides a unified interface for choosing the identity for a particular transaction, such as logging in to a website.
Windows Communication Foundation (WCF), formerly called Indigo; a service-oriented messaging system which allows programs to interoperate locally or remotely similar to web services.
Windows Presentation Foundation (WPF), formerly called Avalon; a new user interface subsystem and API based on XML and vector graphics, which uses 3D computer graphics hardware and Direct3D technologies.
Windows Workflow Foundation (WF) allows for building of task automation and integrated transactions using workflows.
Windows CardSpace, formerly called InfoCard; a software component which securely stores a person's digital identities and provides a unified interface for choosing the identity for a particular transaction, such as logging in to a website

.NET framework 3.5:
It implement Linq evolution in language. So we have the folowing evolution in class:

Linq for SQL, XML, Dataset, Object Addin system, p2p base class, Active directory,
ASP.NET Ajax, Anonymous types with static type inference, Paging support for ADO.NET
ADO.NET synchronization API to synchronize local caches and server side datastores
Asynchronous network I/O API Support for HTTP pipelining and syndication feeds.
New System.CodeDom namespace.

---

Session and Cookie

If you set the variable to "cookies", then your users will not have to log in each time they enter your community.

The cookie will stay in place within the user’s browser until it is deleted by the user.

But Sessions are popularly used, as the there is a chance of your cookies getting blocked if the user browser security setting is set high.

If you set the variable to "sessions", then user activity will be tracked using browser sessions, and your users will have to log in each time they re-open their browser. Additionally, if you are using the "sessions" variable, you need to secure the "sessions" directory, either by placing it above the web root or by requesting that your web host make it a non-browsable directory.

The Key difference would be cookies are stored in your hard disk whereas a session aren't stored in your hard disk. Sessions are basically like tokens, which are generated at authentication. A session is available as long as the browser is opened.

The main difference between cookies and sessions is that cookies are stored in the user's browser, and sessions are not. This difference determines what each is best used for.

A cookie can keep information in the user's browser until deleted. If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. You can store almost anything in a browser cookie. The trouble is that a user can block cookies or delete them at any time. If, for example, your website's shopping cart utilized cookies, and a person had their browser set to block them, then they could not shop at your website.

Sessions are not reliant on the user allowing a cookie. They work instead like a token allowing access and passing information while the user has their browser open. The problem with sessions is that when you close your browser you also lose the session. So, if you had a site requiring a login, this couldn't be saved as a session like it could as a cookie, and the user would be forced to re-login every time they visit.

You can of course get the best of both worlds! Once you know what each does, you can use a combination of cookies and sessions to make your site work exactly the way you want it to.

A session is a store of data on the server containing state information on a user. A particular sessions is identified by its session id, ideally a large (i.e. unguessable) random number. For example, the session could hold a user's shopping cart.

A cookie is also a store. To create a cookie, the server sends a HTTP header to the client (i.e. the web browser). If the client supports and accepts the cookie, the cookie will be sent back to the server along with every request made to the server.

Cookies are often used to store a session id, binding the session to the user.

No doubt you found the term ,,cookie'' appear frequently when ,,sessions'' are being discussed.
A cookie is a bit of information which is sent to your browser and stored there. The browser will send this information back to the server every time you send a request. (to the server that set the cookie)
This behavior can be used to identify a session if sessions take more than one (server-(client)-server) transactions.

Hmmm, analogy?
Imagine the web application as a fairground (carnival?). You pay for a ticket when you enter (start a session). The ticket now is your cookie and every ride (transaction) you want to go on you wave your ticket (cookie) and get on it. Without a cookie you would have to buy a ticket for every single ride.

Remember, HTTP is a stateless protocol. Without adding any extra magic, if a user visits your site twice in a row, as far as the web server is concerned, those are two totally separate visits having nothing in common with eachother (save for coming from the same IP address).

If you want your web server to be able to remember users between pages they visit, you need some way to create a "session" -- some way to save information about the user so you can recognize them the next time they request a page.

The most common way to do this is by using cookies.

So, sessions are what you want, and cookies are most often how you get them.

Cookies persist on your local computer, they are small text files that are stored there by websites and web applications that contain some basic information about you as a user.

Sessions are application specific and persist only as long as you are actively engaged with a particular web site. For instance if you leave Amazon.com open do some shopping, then close the web browser before making any purchases, your session has ended, however the cookie that identifies your username still exists on your local computer.

1) session should work regardless of the settings on the client browser. even if users decide to forbid the cookie (through browser settings) session still works. there is no way to disable sessions from the client browser.
2) session and cookies differ in type and amount of information they are capable of storing.
Javax.servlet.http.Cookie class has a setValue() method that accepts Strings. javax.servlet.http.HttpSession has a setAttribute() method which takes a String to denote the name and java.lang.Object which means that HttpSession is capable of storing any java object. Cookie can only store String objects.

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.

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.

There are four general configuration settings we can look at in more detail: in-process mode, out-of-process mode, SQL Server mode, and Cookieless.

In-process Mode

In-process mode simply means using ASP.NET session state in a similar manner to classic ASP session state. That is, session state is managed in process and if the process is re-cycled, state is lost. Given the new settings that ASP.NET provides, you might wonder why you would ever use this mode. The reasoning is quite simple: performance. The performance of session state, e.g. the time it takes to read from and write to the session state dictionary, will be much faster when the memory read to and from is in process, as cross-process calls add overhead when data is marshaled back and forth or possibly read from SQL Server.

In-process mode is the default setting for ASP.NET. When this setting is used, the only other session config.web settings used are cookieless and timeout.

If we call SessionState.aspx, set a session state value, and stop and start the ASP.NET process (iisreset), the value set before the process was cycled will be lost.

Out-of-process Mode

Included with the .NET SDK is a Windows® NT service: ASPState. This Windows service is what ASP.NET uses for out-of-process session state management. To use this state manager, you first need to start the service. To start the service, open a command prompt and type:

To do this we need to configure config.web:

                   configuration

                       sessionstate 

                           mode="stateserver"

                           cookieless="false" 

                           timeout="20" 

                           sqlconnectionstring="data source=127.0.0.1;user id=;password="

                           server="127.0.0.1" 

                           port="42424" 

                       /

                     /configuration·            
We changed only from inproc mode to stateserver mode.
This setting tells ASP.NET to look for the ASP state service on the server specified
in the server and port settings—in this case, the local server.

We can now call SessionState.aspx, set a session state value, stop and start the IIS process (iisreset), and continue to have access to the values for our current state.

SQL Server Mode

The SQL Server mode option is similar to that of the Windows NT Service, except that the information persists to SQL Server rather than being stored in memory.

To use SQL Server as our session state store, we first must create the necessary tables and stored procedures that ASP.NET will look for on the identified SQL Server. The .NET SDK provides us with a SQL script (state.sql) to do just that.

state.sql

The state.sql file contains the SQL commands used to create the ASPState database. This script creates two tables and several stored procedures. ASP.NET uses both the tables and the procedures to store data in SQL Server. I would recommend reading through state.sql to learn more about what it is doing.

The state.sql file can be found in [system drive]\winnt\Microsoft.NET\Framework\[version]\

Applying the state.sql script

To apply the state.sql script, use the command line tool SQL Server provides: osql.exe. Using an sa equivalent SQL user, the syntax below is used:

Cookieless State

The last new feature that we can configure for ASP.NET session state is cookieless session state. Essentially this feature allows sites whose clients choose not to use cookies to take advantage of ASP.NET session state.

This is done by modifying the URL with an ID that uniquely identifies the session:

http://localhost/(lit3py55t21z5v55vlm25s55)/Application/SessionState.aspx

ASP.NET will modify relative links found within the page and embed this ID. Thus, as long as the user follows the path of links the site provides, session state can be maintained. However, if the end user re-writes the URL, the session state instance will most likely be lost.

The IIS 4.0 Resource Kit provided a similar feature. It was implemented as an ISAPI filter that could modify the incoming and outgoing byte stream to write and read the necessary information. The difference between this and the ASP.NET feature is the effort required to use the feature. In ASP.NET, it's simply a matter of flipping a Boolean value in the config.web file:

configuration

   sessionstate 

      mode="stateserver"

      cookieless="true" 

      timeout="20" 

      sqlconnectionstring="data source=127.0.0.1;user id=;password="

      server="127.0.0.1" 

      port="42424" 

  /

/configuration

Once cookieless is set to true, ASP.NET will do the work necessary to enable cookieless session state. Also note that all modes are supported for cookieless sessions.

Performance and Reliability Considerations

It's worth mentioning, briefly, some of the performance and reliability issues you should consider when using ASP.NET session state modes.

In process. In process will perform best because the session state memory is kept within the ASP.NET process. For Web applications hosted on a single server, applications in which the user is guaranteed to be re-directed to the correct server, or when session state data is not critical (in the sense that it can be re-constructed or re-populated), this is the mode to choose.

Out of process. This mode is best used when performance is important but you can't guarantee which server a user will request an application from. With out-of-process mode, you get the performance of reading from memory and the reliability of a separate process that manages the state for all servers.

SQL Server. This mode is best used when the reliability of the data is fundamental to the stability of the application, as the database can be clustered for failure scenarios. The performance isn't as fast as out of process, but the tradeoff is the higher level of reliability.

An overview of Asp.net Cookies

When working with a web application many a times we want to store the client specific data on the client side only. This helps in showing personalized data for the client. The session maintained by default is also done with the help of the session cookie only.

In a layman developer word a cookie is a small amount of data that is passed between the client and the server in the request and response. The data in the cookie can be read in interpreted by the server and is sent to the server whenever the user visits the same site.

But remember maintenance of cookie also depends on the user. Many user can turn there cookie off or the users can delete the cookies in there cookies. Moreover client can read the information kept in the cookie. That is why cookie cannot be used to store sensitive data.

Remember the cookie is set for a website and not individual pages of the site. Hence the cookie is sent to and from the browser on each and every request to the server. So we should also be very careful on how much data needs to be stored in a cookie. If the amount of data stored in a cookie is vary large than it can slow your site as the amount of data passed to and from is very high.

There are also some limitations in the cookies. Cookies of the maximum size 4096 bytes are supported by most of the browser. The limitation is not only on the bytes but also the number of cookies. One website can keep only up to a maximum of 20 cookies. If we try to store more number of cookies then the earlier cookies will be deleted by default. Many browsers have also kept a limitation on absolute number of the cookies. Most browser keeps only a maximum of 300 cookies from all the site combined.

One more very Important issue with cookie is the fact that it is entirely dependent on the browser. User may have turned off receiving any cookie from any site. No error is raised if the cookie is not written in the browser. Also the fact that the browser never sends information about its current cookie setting to the server and the server has no want to find if the cookie has been written properly or not

In Asp.net the cookie property does not indicate on weather the cookies are enabled in the browser or not (As discussed above there is no ways for the server to understand if the browser will accept cookies or not). It only indicates only the fact that the current browser support cookies or not.

A few interesting things about session in Asp.Net

If we have the session state enabled and we do not store anything in the session then the session Id will change every time a new request is made. This also means that a new session is created every time. But the sate is never saved as there is nothing to save. Note the session_Start event will not fire for every request. The session_start event will only fire once.

Another interesting stuff about session Id is that it does not changes after we have called the Session.Abondon() method or when the session times out. Even though Session State expires but the session ID remains same. The session Id will last as long as the browser session does.

Session Class has two methods. Session.Abondon() and Session.Clear(). Both the methods are used to clear the data in the session. But there is one difference between them. If we use Session.Abondon() then Session_end event will be fired and session_start event will be fired on the next request. The same is not true for session.Clear() method.

---