GAC
GAC stands for Global Assembly Cache. It is used to save Assemblies that should be used by all applications. The GAC permits you to share assemblies across
various applications.
4.25. What is two-tier architecture?
The two-tier architecture is refers to client/ server architectures as well, the term client/ server was first used in the 1980s in reference to personal
computers (PCs) on a network. The actual client/ server model started gaining acceptance in the late 1980s, and later it was adapted to World Wide Web
programming.
4.26. What is three-tier architecture?
The three tier software architecture (also known as three layer architectures) emerged in the 1990s to overcome the limitations of the two tier
architecture. This architecture has aggressively customized and adopted by modern day system designer to web systems.
Three-tier is a client-server architecture in which the user interface, functional process logic, data storage and data access are developed and maintained
as independent modules, some time on separate platforms. The term "three-tier" or "three-layer", as well as the concept of multi-tier architectures (often
refers to as three-tier architecture), seems to have originated within Rational Software.
The 3-Tier architecture has the following three tiers.
Presentation Tier or Web Server: User Interface, displaying/ accepting data/ input to/ from the user
Application Logic/ Business Logic/ Transaction Tier or Application Server: Data validation, acceptability check before being added to the database and all
other business/ application specific operations
Data Tier or Database server: Simple reading and writing method to database or any other storage, connection, command, stored procedures etc
4.27. What is MVC architecture?
The Model-View-Controller (MVC) architecture separates the modeling of the domain, the presentation, and the actions based on user input into three
separate classes.
Unfortunately, the popularity of this pattern has resulted in a number of faulty usages; each technology (Java, ASP.NET etc) has defined it in their own
way making it difficult to understand. In particular, the term "controller" has been used to mean different things in different contexts. The definitions
given bellow are the closes possible ones I found for ASP.NET version of MVC.
Model: DataSet and typed DataSet (some times business object, object collection, XML etc) are the most common use of the model.
View: The ASPX and ASCX files generally handle the responsibilities of the view.
Controllers: The handling of events or the controlling is usually done in the code-behind class.
In a complex n-tier distributed system the MVC architecture place the vital role of organizing the presentation tier of the system.
4.28. What is SOA?
A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either
simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
The .Net technology introduces the SOA by mean of web services.
The SOA can be used as the concept to connect multiple systems to provide services. It has it's great share in the future of the IT world.
4.31. What is Gang of Four (GoF) Design Patterns?
The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational,
Structural, and Behavioral. Here you will find information on these important patterns.
Introducing Viewstate Outside the ASP.NET Context
In its very basic form, Viewstate is nothing more than a property which has a key/value pair indexer:
Collapse | Copy Code
Viewstate[“mystringvariable”] = “myvalue”;
Viewstate[“myintegervariable”] = 1;
As you can see, the indexer accepts a string as a key and an object as the value. The ViewState property is defined in the “ System.Web.UI.Control” class. Since all ASP.NET pages and controls derive from this class, they all have access to the ViewState
property. The type of the ViewState property is “System.Web.UI.StateBag”.
The very special thing about the StateBag class is the ability to “track changes”. Tracking is, by nature, off; it can be turned on by calling
the “TrackViewState()” method. Once tracking is on, it cannot be turned off. Only when tracking is on, any change to the StateBag
value will cause that item to be marked as “Dirty”.
Info
|
Introducing Viewstate Inside the ASP.NET Context
When dealt within the context of ASP.NET, the Viewstate can be defined as the technique used by an ASP.NET web page to remember the change of state
spanning multiple requests. As you know, ASP.NET is a stateless technology; meaning that two different requests (two postbacks) to the same web page are
considered completely unrelated. This raises the need of a mechanism to track the change of state for this web page between the first and the second
request.
The Viewstate of an ASP.NET page is created during the page life cycle, and saved into the rendered HTML using in the “__VIEWSTATE” hidden
HTML field. The value stored in the “__VIEWSTATE” hidden field is the result of serialization of two types of data:
Any programmatic change of state of the ASP.NET page and its controls. (Tracking and “Dirty” items come into play here. This will be
detailed later.)
Any data stored by the developer using the Viewstate property described previously.
This value is loaded during postbacks, and is used to preserve the state of the web page.
Info |
One final thing to be explained here is the fact that ASP.NET server controls use Viewstate to store the values of their properties. What does this mean?
Well, if you take a look at the source code of the TextBox server control, for example, you will find that the “Text” property is
defined like this:
Collapse | Copy Code
public string Text
{get { return (string)ViewState["Text"]; }set { ViewState["Text"] = value; }}
You should apply this rule when developing your own server controls. Now, this does not mean that the value of the “Text” property set at
design time is saved in the rendered serialized ViewState field. For example, if you add the following TextBox to your ASP.NET
page:
Collapse | Copy Code
<asp:TextBox runat="server" ID="txt" Text="sometext" />
According to the fact that the “Text” property uses Viewstate to store its value, you might think that the value is actually serialized in the __VIEWSTATE hidden field. This is wrong because the data serialized in the hidden __VIEWSTATE consists only of state changes done
programmatically. Design time data is not serialized into the __VIEWSTATE (more on this later). For now, just know that the above declaration
of the “Text” property means that it is utilizing Viewstate in its basic form: an indexed property to store values much like the Hashtable collection does.
ASP.NET Page Life Cycle
Generating the compiled class
The first step (actually, step 0 as explained in the info block below) of the life cycle is to generate the compiled class that represents the requested
page. As you know, the ASPX page consists of a combination of HTML and Server controls. A dynamic compiled class is generated that represents this ASPX
page. This compiled class is then stored in the “Temporary ASP.NET Files” folder. As long as the ASPX page is not modified (or the application
itself is restarted, in which case the request will actually be the first request and then the generation of the class will occur again), then future
requests to the ASPX page will be served by the same compiled class.
This compiled class will actually contain the programmatic definition of the controls defined in the aspx page. In order to fully understand the process of
dynamic generation, let us consider the following example of a simple ASPX page for collecting the username and the password:
Now, upon the first request for the above page, the generated class is created and stored in the following location:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\
<application name>\< folder identifier1>\< file identifier1>.cs
The compiled class “DLL” is also created in the same location with the same file identifier, as follows:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\
<application name>\< folder identifier1>\< file identifier1>.dll
As you can see, the generated class and its corresponding DLL are created, and will serve any new request for the ASPX page until one of the following
conditions occur:
The ASPX file is modified
The application is restarted, for example, as a result of IIS reset or app domain restart
The following code is extracted from the compiled class. Note that the code is reformatted and “cleaned up” for presentation purposes.
PreInit (New to ASP.NET 2.0)
The entry point of the page life cycle is the pre-initialization phase called “PreInit”. This is the only event where programmatic access to
master pages and themes is allowed. Note that this event is not recursive, meaning that it is accessible only for the page itself and not for any of its
child controls.
Init
Next is the initialization phase called “Init”. The “Init” event is fired reclusively for the page itself and for all the child
controls in the hierarchy (which is created during the creation of the compiled class, as explained earlier). Note that against many developers’ beliefs,
the event is fired in a bottom to up manner and not an up to bottom within the hierarchy. This means that following up with our previous example, the “ Init” event is fired first for the most bottom control in the hierarchy, and then fired up the hierarchy until it is fired for the page
itself. You can test this behavior yourself by adding a custom or user control to the page. Override the “OnInit” event handler in both the
page and the custom (or user) control, and add break points to both event handlers. Issue a request against the page, and you will notice that the event
handler for the control will be fired up before that of the page.
InitComplete (New to ASP.NET 2.0)
The initialization complete event called “InitComplete” signals the end of the initialization phase. It is at the start of this event that
tracking of the ASP.NET Viewstate is turned on. Recall that the StateBag class (the Type of Viewstate) has a tracking ability which is off by
default, and is turned on by calling the “TrackViewState()” method. Also recall that, only when tracking is enabled will any change to a
Viewstate key mark the item as “Dirty”. Well, it is at the start of “InitComplete” where “Page.TrackViewState()” is
called, enabling tracking for the page Viewstate.
LoadViewState
This event happens only at postbacks. This is a recursive event, much like the “Init” event. In this event, the Viewstate which has been saved
in the __VIEWSTATE during the previous page visit (via the SaveViewState event) is loaded and then populated into the control
hierarchy.
LoadPostbackdata
This event happens only at postbacks. This is a recursive event much like the “Init” event. During this event, the posted form data is loaded
into the appropriate controls. For example, assume that, on your form, you had a TextBox server control, and you entered some text inside theTextBox and posted the form. The text you have entered is what is called postback data. This text is loaded during the LoadPostbackdata event and handed to the TextBox. This is why when you post a form, you find that the posted data is loaded again
into the appropriate controls. This behavior applies to most controls like the selected item of a drop down list or the “checked” state of a check box,
etc…
A very common conceptual error is the thought that Viewstate is responsible for preserving posted data. This is absolutely false; Viewstate has nothing to
do with it. If you want a proof, disable the Viewstate on your TextBox control or even on the entire page, and you will find that the posted
data is still preserved. This is the virtue of the LoadPostbackdata event.
PreLaod (New to ASP.NET 2.0)
This event indicates the end of system level initialization.
Load
This event is recursive much like the “Init” event. The important thing to note about this event is the fact that by now, the page has been
restored to its previous state in case of postbacks. That is because the LoadViewState and the LoadPostbackdata events are fired,
which means that the page Viewstate and postback data are now handed to the page controls.
RaisePostbackEvent
This event is fired only at postbacks. What this event does is inspect all child controls of the page and determine if they need to fire any postback
events. If it finds such controls, then these controls fire their events. For example, if you have a page with a Button server control and you
click this button causing a postback, then the RaisePostbackEvent inspects the page and finds that the Button control has
actually raised a postback event – in this case, the Button's Click event. The Button's Click event is
fired at this stage.
LoadComplete (New to ASP.NET 2.0)
This event signals the end of Load.
Prerender (New to ASP.NET 2.0)
This event allows for last updates before the page is rendered.
PrerenderComplete (New to ASP.NET 2.0)
This event signals the end of “Prerender”.
SaveViewstate
This event is recursive, much like the “Init” event. During this event, the Viewstate of the page is constructed and serialized into the __VIEWSTATE hidden field.
Info
|
SaveStateControl (New to ASP.NET 2.0)
State Control is a new feature of ASP.NET 2.0. In ASP.NET 1.1, Viewstate was used to store two kinds of state information for a control:
Functionality state
UI state
This resulted in a fairly large __VIEWSTATE field. A very good example is the DataGrid server control. In ASP.NET 1.1,DataGrid uses the Viewstate to store its UI state such as sorting and paging. So, even if you wanted to disable Viewstate on the DataGrid and rebind the data source on each postback, you simply cannot do that if your DataGrid was using sorting or paging. The
result was that the DataGrid ended up using Viewstate to store both its bounded data and its UI state such as sorting and paging.
ASP.NET 2.0 solved this problem by partitioning the Viewstate into two:
The Viewstate we are discussing here
The Control State
The Control State is used to store the UI state of a control such as the sorting and paging of a DataGrid. In this case, you can safely
disable the DataGrid Viewstate (provided, of course, that you rebind the data source at each postback), and the sorting and paging will still
work simply because they are saved in the Control State.
The Control State is also serialized and stored in the same __VIEWSTATE hidden field. The Control State cannot be set off.
Render
This is a recursive event much like the “Init” event. During this event, the HTML that is returned to the client requesting the page is
generated.
Unload
This is a recursive event much like the “Init” event. This event unloads the page from memory, and releases any used resources.
Role of Viewstate in the Page Life Cycle
Viewstate in the “Init” event
The important thing to note in the “Init” event is that Viewstate tracking is not yet enabled. In order to demonstrate this, let us take the
following example:
Collapse | Copy Code
protected override void OnInit(EventArgs e)
(
bool ret;
ret = ViewState.IsItemDirty("item");//returns falseViewSTate["item"] = "1";
ret = ViewState.IsItemDirty("item");returns falsebase.OnInit(e);
}
Introduction
In this article, we will try to understand what the different events are which take place right from the time the user sends a request, until the time the
request is rendered on the browser. So we will first try to understand the two broader steps of an ASP.NET request and then we will move into different
events emitted from ‘HttpHandler’, ‘HttpModule’ and ASP.NET page object. As we move in this event journey, we will try to
understand what kind of logic should go in each and every one of these events.
This is a small Ebook for all my .NET friends which covers topics like WCF, WPF, WWF, Ajax, Core .NET, SQL, etc. You can download the same fromhere or else you can catch me on my daily free training here.
The Two Step Process
From 30,000 feet level, ASP.NET request processing is a 2 step process as shown below. User sends a request to the IIS:
ASP.NET creates an environment which can process the request. In other words, it creates the application object, request, response and context objects
to process the request.
Once the environment is created, the request is processed through a series of events which is processed by using modules, handlers and page objects. To
keep it short, let's name this step as MHPM (Module, handler, page and Module event), we will come to details later.
In the coming sections, we will understand both these main steps in more detail.
Creation of ASP.NET Environment
Step 1:
The user sends a request to IIS. IIS first checks which ISAPI extension can serve this request. Depending on file extension the request is processed. For
instance, if the page is an ‘.ASPX page’, then it will be passed to ‘aspnet_isapi.dll’ for processing.
Step 2:
If this is the first request to the website, then a class called as ‘ApplicationManager’ creates an application domain where the website can
run. As we all know, the application domain creates isolation between two web applications hosted on the same IIS. So in case there is an issue in one app
domain, it does not affect the other app domain.
Step 3:
The newly created application domain creates hosting environment, i.e. the ‘HttpRuntime’ object. Once the hosting environment is created, the
necessary core ASP.NET objects like ‘HttpContext’ , ‘HttpRequest’ and ‘HttpResponse’ objects are created.
Step 4:
Once all the core ASP.NET objects are created, ‘HttpApplication’ object is created to serve the request. In case you have a ‘ global.asax’ file in your system, then the object of the ‘global.asax’ file will be created. Please note global.asax file
inherits from ‘HttpApplication’ class.
Note
: The first time an ASP.NET page is attached to an application, a new instance of ‘HttpApplication’ is created. Said and done to maximize
performance, HttpApplication instances might be reused for multiple requests.
Step 5:
The HttpApplication object is then assigned to the core ASP.NET objects to process the page.
Step 6:
HttpApplication
then starts processing the request by HTTP module events, handlers and page events. It fires the MHPM event for request processing.
Note
: For more details, read this.
The below image explains how the internal object model looks like for an ASP.NET request. At the top level is the ASP.NET runtime which creates an ‘ Appdomain’ which in turn has ‘HttpRuntime’ with ‘request’, ‘response’ and ‘context’ objects.
You can read more about the differences from here.
Below is the logical flow of how the request is processed. There are 4 important steps MHPM as explained below:
Step 1(M: HttpModule):
Client request processing starts. Before the ASP.NET engine goes and creates the ASP.NET HttpModule emits events which can be used to inject
customized logic. There are 6 important events which you can utilize before your page object is created BeginRequest,AuthenticateRequest, AuthorizeRequest, ResolveRequestCache, AcquireRequestState and PreRequestHandlerExecute.
Step 2 (H: ‘HttpHandler’):
Once the above 6 events are fired, ASP.NET engine will invoke ProcessRequest event if you have implemented HttpHandler in your
project.
Step 3 (P: ASP.NET page):
Once the HttpHandler logic executes, the ASP.NET page object is created. While the ASP.NET page object is created, many events are fired which
can help us to write our custom logic inside those page events. There are 6 important events which provides us placeholder to write logic inside ASP.NET
pages Init, Load, validate, event, render and unload. You can remember the word SILVER to remember the events S – Start (does not signify anything as such just forms the word) , I – (Init) , L (Load) , V (Validate), E
(Event) and R (Render).
Step4 (M: HttpModule):
Once the page object is executed and unloaded from memory, HttpModule provides post page execution events which can be used to inject custom
post-processing logic. There are 4 important post-processing events PostRequestHandlerExecute, ReleaserequestState, UpdateRequestCache and EndRequest.
The below figure shows the same in a pictorial format.
What is Caching ?
Web applications are accessed by multiple users. A web site can have an extremely low load for minimum number of client access which provide faster access
of the sites or may be heavy load on the site can increase exponentially which can slow down the server as well as access of Sites . Slow access is the
most common problem for any web site when it is accessed by a large number of client simultaneously. For resolve this problem we can have used high level
of hardware configuration, Load Balancer , High bandwidth but load is not the only reason that make a web site is slow , so we need to provide such kind of
mechanism which also provide fast data access and provide performance improvement of web site. Caching provide the solution.
Caching
is a technique where we can store frequently used data and Web pages are stored temporarily on local hard disks for later retrieval. This technique
improves the access time when multiple users access a Web site simultaneously or a single user accesses a Web site multiple times. Caching for Web
applications can occur on the client (browser caching), on a server between the client and the Web server (proxy caching / Reverse Proxy Caching), and on
the Web server itself (page caching or data caching).
Maximum time we chose web server to store cached data though it improved the performance but it does not solve our purpose every time. If we consider about
load on Web Server we have to consider about the location that when the cached data should store. Following section will describe on different location of
storing cached data.
Different Caching Location
Caching in a web application can be done either on client side (Client Browser), In between Client and Server (Proxy & Reverse Proxy Caching ) and on
Server Side( Data Caching/ Page Output Caching) . So we can classified caching location in 4 way
Client Caching
Proxy Caching
Reverse Proxy Caching
Web Server Caching
1. Client Caching :
In Client Caching Client Browser perform caching by storing cached data on local disk as temporary file or browser internal memory. This provide quick
access of some information by client which reduce the network load and server load also. This information can't be shared by other clients so it is client
specific.
Fig 1.0 : Client Caching
Advantages
Data that are cached on local client can be easily accessed
2. Reduce Network Traffic
Disadvantages
1. Cached data are totally browser dependent, so it is not shareable
2. Proxy Caching :
Main disadvantage of Client caching was data that are store on client browser are client specific. Proxy Caching technique used a dedicated server that
store caching information in between client and web server in a shared location, that all client can used same shared data. The proxy server (e.g.
Microsoft Proxy Server ) fulfills all the requests for the Web page without sending out the request to the actual Web server over the Internet, resulting
in faster access.
Fig 1.0 : Proxy Caching
Proxy caches are often located near network gateways to reduce the bandwidth
. Some times Multiple Proxy Cache server is used for larger number of client. This is called Cache Array.
Fig 1.1 : Cache Array
Advantages
Data that are cached on proxy server can a accessed easily
Reduce Network Traffic
Disadvantages
1. It a Deployment and Infrastructure overhead to maintain a Proxy Cache Server
3. Reverse Proxy Caching :
Some Proxy Cache server can placed in front of web server to reduce the number of requests that they receive. This allows the proxy server to respond to
the frequently received requests and pass the other requests to the Web server. This is called a reverse proxy.
Fig 1.2 : Reverse Proxy Caching
Advantages
Data that are cached on reverse proxy server can a accessed easily
Web server reduce the number of request
Disadvantages
1. As the Server configured in front of Web sever some what it increases the network traffic.
4. Web Server Caching :
In Web server caching cached data stored inside the web server, Data caching and page caching used web sever caching mechanism.
Fig 1.3 : Web Server Caching
Advantages
1. Improve the performance of sites by decreasing the round trip of data retrieving from database or some other server
Disadvantages
1. Increase the Network Load
Advantages and Disadvantages Of Caching
Advantages
Reduced server load
Reduced bandwidth consumption
Example
Collapse | Copy Code
<%@ Page Language="C#" %>
<%@ OutputCache Duration='300' VaryByParam='none' %>
<html>
<script runat="server">
protected void Page_Load(Object sender, EventArgs e) {lbl_msg.Text = DateTime.Now.ToString();
}
</script>
<body>
<h3>Output Cache example</h3>
<p>Page generated on:
<asp:label id="lbl_msg" runat="server"/></p>
</body>
</html>
We also set Caching property from Codebehind also
Collapse | Copy Code
void Page_Load(Object sender, EventArgs e) {Response.Cache.SetExpires(DateTime.Now.AddSeconds(360));
Response.Cache.SetCacheability(
HttpCacheability.Public);
Response.Cache.SetSlidingExpiration(true);
_msg.Text = DateTime.Now.ToString();
}
Web is Stateless, which means a new instance of the web page class is re-created each time the page is posted to the server. As we all know HTTP is a
stateless protocol, it can't hold the client information on page. If user inserts some information, and move to the next page, that data will be lost and
user would not able to retrieve the information. So what we need? we need to store information. Session provides that facility to store information on
server memory. It can support any type of object to store along with our custom object. For every client Session data store separately, means session data
is stored as per client basis. Have a look at the following diagram.
Fig : For every client session data store separately
State Management using session is one of the asp.net best features, because it is secure, transparent from users and we can store any kind of object with
in it. Along with advantages, some times session can causes performance issue for heavy traffic sites because its stored on server memory and clients read
data from the server itself. Now lets have a look at the advantages and disadvantages of using session in our web application.
Advantages and Disadvantages of Session ?
Following are the basic advantages and disadvantages of using session. I have describe in details with each type of session at later point of time.
Advantages :
It helps to maintain user states and data to all over the application.
It can easily be implemented and we can store any kind of object.
Stores every client data separately.
Session is secure and transparent from user.
Disadvantages :
Performance overhead in case of large volume of user, because of session data stored in server memory.
Overhead involved in serializing and De-Serializing session Data. because In case of StateServer and SQLServer session mode we need to serialize the object
before store.
Besides these, there are many advantages and disadvantages of session that are based of session Types. I have Discussed all of them.
Storing and Retrieving values from Session
Storing and Retrieving values in session are quite similar with ViewState. We can interact with Session State with System.Web.SessionState.HttpSessionState
class, because this provides built in Session Object with Asp.Net Pages.
Asp.Net use 120 bit identifier to track each session. This is secure enough and can't be reverse engineered. When client communicate with server, only
session id is transmitted, between them. When client request for data, ASP.NET looks on to session ID and retrieves corresponding data. This is done in
following steps,
Client hits web site and some information is stored in session.
Server creates a unique session ID for that clients and stored in Session State Provider .
Again client request For some information with that unique session ID from Server.
Server,looks on Session Providers, and retrieve the serialized data from state server and type cast the object .
Fig : Communication of Client, web server, and State Provider
Ref. & for more Information: SessionID in MSDN
Session Mode and State Provider
In ASP.NET there are following session mode available,
InProc
StateServer
SQLServer
Custom
For every session State, there is Session Provider. Following diagram will show you how they are related.
Fig : Session State Architecture
we can choose the session State Provider based on which session state we are selecting. When ASP.NET request for any information based on session ID,
session state and its corresponding provider are responsible for sending the proper information based on user. Following tables show, the session mode
along with there provider Name.
Session State Mode | State Provider |
InProc | In-Memory Object |
StateServer | Aspnet_state.exe |
SQLServer | DataBase |
Custom | CustomProvider |
apart from that, there is another mode, "Off". If we select this option the session will be disabled for the application. But our objective is to use
session, so we will look into that four session State Mode.
Clients use cookies to work with session. because the client needs to present the appropriate session ID with each request. we can do it in following ways
Using cookies: ASP.NET creates a special cookies named ASP.NET_SessionId automatically when the session collection is used. This is the default. Session ID
is transmitted through that cookies .
Cookie Munging : Some older browser doest not support cookies or user may disable cookies in there browser, in that case ASP.Net transmitted session ID in
a specially modified (or “munged”) URL.
What is state management?
Web is Stateless. It means a new instance of the web page class is re-created each time the page is posted to the server. As we all know HTTP is a stateless protocol, its can't holds the client information on page. As for example , if we enter a text and client on submit button,
text does not appear after post back , only because of page is recreated on its round trip.
As given in above pages, page is recreated before its comes to clients and happened for each and every request. So it is a big issue to maintain the state
of the page and information for a web application. That is the reason to start concept of State Management. To overcome this problem ASP.NET
2.0 Provides some features like View State, Cookies, Session, Application objects etc. to manage the state of page.
There are some few selection criteria to selected proper way to maintain the state, as there are many way to do that. Those criteria are:
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?
So, when ever you start to think about state management, you should think about above criteria. based on that you can choose the best approaches for
manages state for your web application.
Different types of state management?
There are two different types of state management:
Client Side State Management
View State
Hidden Field
Cookies
Control State
Server Side State Management
Session
Application
Object
Caching
Database
Client Side state management does not use any server resource , it store information using client side option. Server Side state management use server side
resource for store data. Selection of client side and server side state management should be based on your requirements and the selection criteria that are
already given.
What is view state?
View State
is one of the most important and useful client side state management mechanism. It can store the page value at the time of post back (Sending and Receiving information from Server) of your page. ASP.NET pages provide the ViewState property as a
built-in structure for automatically storing values between multiple requests for the same page.
Example:
If you want to add one variable in View State,
Collapse | Copy Code
ViewState["Var"]=Count;
For Retrieving information from View State
Collapse | Copy Code
string Test=ViewState["TestVal"];
Sometimes you may need to typecast ViewState Value to retreive. As I give an Example to strore and retreive object in view state in the last of this
article.
Advantages of view state?
This are the main advantage of using View State:
Easy to implement
No server resources are required
Enhanced security features ,like it can be encoded and compressed.
Disadvantages of view state?
This are the main disadvantages of using View State:
It can be performance overhead if we are going to store larger amount of data , because it is associated with page only.
Its stored in a hidden filed in hashed format (which I have discussed later) still it can be easily trapped.
It does not have any support on mobile devices.
Now we will try to store object of "Student" Class in a view state.
Collapse | Copy Code
//Store Student Class in View State
student _objStudent = new student();
_objStudent.AddStudent(2, "Abhijit");
ViewState["StudentObject"] = _objStudent;
//Retrieve Student information view state
student _objStudent;
_objStudent = (student)ViewState["StudentObject"];
How to trace your view state information?
If you want to trace your view state information, by just enable "Trace" option of Page Directive
Now Run your web application, You can view the details of View State Size along with control ID in Control Tree Section. Don't worry about " Render Size Byte" , this only the size of rendered control.
Enabling and Disabling View State
You can enable and disable View state for a single control as well as at page level also. To turnoff view state for a single control , set EnableViewState Property of that control to false. e.g.:
Collapse | Copy Code
TextBox1.EnableViewState =false;
To turnoff the view state of entire page, we need to set EnableViewState to false of Page Directive as shown bellow.
Even you disable view state for the entire page , you will see the hidden view state tag with a small amount of information, ASP.NET always store the
controls hierarchy for the page at minimum , even if view state is disabled.
For enabling the same, you have to use the same property just set them as True
as for example, for a single control we can enabled view state in following way,
Collapse | Copy Code
TextBox1.EnableViewState =true;
and for a page level,
Cookies
This article describes Cookies, Persistent and Non-Persistent cookies, their uses, cookie Munging etc.
Introduction
First of all I would like to thanks to all of readers who read my previous articles and voted me. Wow.. What a great support I have got from you people.
Again thanks to Sean Ewington to start up with a very fantastic idea
with Beginner's Walk for Web Development article. I have written few articles
for Beginners. I really feel great when my "Beginner's Guide to View State" article
displayed in Home Page "Editor's Choice" section. Following are articles that I have written so far for the Beginner's
Exploring Caching in ASP.NET
Beginner's Guide To View State
Beginner's Guide To ASP.NET Application Folder
Cookies, Session, and Application Object are in Queue. Now, It's time for reading about cookies. I have spend a lots of times to prepared this article. And
you will be very surprised to know that Introduction part is the last topic which I am writing before posting article. I have read many articles, books
before writing this article. Done some hands on also. Hope I have explained this well , and hope you people also like it. Please give your suggestion and
feedback.
What are Cookies ?
Cookies
are the small files that are created on the client's system or client browser memory (if temporary). Its use for State management
that I have already discuss on my view state article. So we can store small piece of information in a client system and we can use it when we needed. Most
interesting thing is that Its works transparently with the user. It can be easily used any where of you web application. Cookies store information in a
plain text format. If any web application using cookies, Server send cookies and client browser will store it. The browser then returns the cookie to the
server at the next time the page is requested. The most common example of using a cookie is to store User information, User preferences , Password Remember
Option etc. Cookies has many advantages and disadvantages. I will comes to this points , but first have a look how cookies are started.
How Cookies are started ?
When client request to the server, server send the cookies into client . The same cookies can be referred for subsequent request. As for example, if codeproject.com stores session id as a cookies, when any client hits first times on the server, server generates the session id and send it as
a cookies to client. [As given in Fig 1.0]
Fig 1.0 : Initial state of cookie creation
Now for all other subsequent from the same client it uses the session-id from cookies, just like the picture below:
Fig 1.1 : Subsequent request for other pages
Browser and web server are responsible for exchange cookies information. For different sites, browser keeps cookies differently. If any pages need
information from cookies, when that URL is being hit, first its search for local system for cookies information then its moved to server with that
information.
Advantages of Cookies
Following are main advantages of using cookies in web application:
It's very simple to use and implement.
Browser's taking care send data.
· For multiple sites cookies, Browser automatically arranges them.
Disadvantages of Cookies
Main disadvantages of cookies are:
· Its store data in a simple text format. so it's not secure at all.
· There is a size limit of cookies data ( 4096 bytes / 4KB).
· Number if cookies also limited. Most Browser provides limits of storing cookies is 20. If new cookies came, it will discard the old one. Some of browser
support up to 300.
· We need to configure browser. It will not work on a high security configuration of browser. [I have explained about this in details.]
How to create cookies ?
For working with cookies we need to use namespace System.web
Now , have a look, on the code , that how can we create a cookies and add it with web response .3
The cookies which has been created will persist , until browser has been closed. we can persist the cookies. But how? Just after few point I have discussed
it.
How to Read data from cookies ?
Now , its times to retrieve data from cookies. Ok, before reading cookies, first of all we need to check whether a cookies was found or not. "Its always
good practice to check cookie before read it, because is browser is disable cookies.
What is Persistent and Non Persistent Cookies ?
We can classified cookies in two way,
Persistent Cookies
Non Persistent Cookies
Persistent Cookies :
This can be called as permanent cookies, which is stored in client hard-drive until it expires . persistent cookies should have set with expiration dates . Sometimes its stays until the user deletes the cookie. Persistent cookies are used to collect identifying information about the user from
that system. I have discuss about the creation of persistent cookies on "How to make Persist Cookies ?" section.
Non Persistent Cookies :
This can be called as Temporary Cookies. If there is no expires time defined then the cookie is stored in browser memory . The Example which I have given already its a Non-Persistent Cookies.
Therefore there is no difference between modifying persistent or non-persistent cookies. Only difference between them are Persistent cookies should have an Expatriation time defined within it.
How to make Persistent Cookies ?
I have already given an example of non-persistent cookies, For Persistent cookies we need only add to expiry times of cookies. In that given code I have
added Expire time to 5 days. Just check the example.
Collapse | Copy Code
//Creting a Cookie Object
HttpCookie _userInfoCookies = new HttpCookie("UserInfo");//Setting values inside it
_userInfoCookies["UserName"] = "Abhijit";
_userInfoCookies["UserColor"] = "Red";
_userInfoCookies["Expire"] = "5 Days";
//Adding Expire Time of cookies
_userInfoCookies.Expires = DateTime.Now.AddDays(5);
//Adding cookies to current web response
Response.Cookies.Add(_userInfoCookies);
Now , Looks the most interesting things that where they are store in hard drive.
Where does cookies are stored in local Hard drive ?
This is one of the interesting things to find out the cookies in your local drive. First of all, From "Explorer Folder Option ", Select, show hidden files
and folder.
Now Browse into document & settings of the current user and open the cookies folder. Now looks the picture.
Server Side Validation
So let's look at the server side sequence validation. Let's first look at the sequence of events that get fired during any postback. As we know, when you
load the sequence for the first time and the list of events that gets fired are different and there is no scope/use of validation. Validation gets fired on
any postback. So let's see the sequence of events on any postback.
Client Side Validation
If client side validation is enabled, a whole different sequence occurs in-between the round trips. Client side validation works with the help of Client
JavaScript library. That is added to the solution whenever we use any validator on our page, and looks like:
Collapse | Copy Code
<script language="javascript"
src="http://www.codeproject.com/
aspnet_client/system_web/1_0_3617_0/WebUIValidation.js">
</script>
From the server point of view, Clientside validation just means that the validators just emit different stuff into HTML. Except this, all the sequence of
events are the same. The server side events are still carried out. This has the following reasons.
Some validation may not support client script, say for custom validator with a server validation function and having no client validation function.
Server is always mandatory because a malicious user can very easily take a page and disable or change the script. So we cannot rely on it. It is just
used for giving the quick response to user. That's why it is always recommended that you should provide client side validation function as well as
server side validation functions.
Every validation control script makes sure that some client script is added to the page. But it doesn't mean all the controls get added to the page. Most
of the code resides in a script file named as WebUIValidation.js and this reference is added into the page. You can go through this file to see
the complete code for these validators. By default, the script file will be installed into the default root in the aspnet_client directory.
Table of Content
Introduction
Overview ASP.NET Application Folder
Advantages of ASP.NET Application Folder
Different Types of Folders
Details of Application Folder
Summary
Introduction
First of all I would like to thanks Sean Ewington for his
article Beginner's Walk for Web Development , which gives me a great opportunity
to write some article for Beginner's on ASP.Net Web Development at CodeProject . After writing articles on
caching
and View State for beginners , I have decided to
write a article on Asp.Net Application folder for Beginner's. But I will be back on rest of State management part . Like my others articles I believe this
will also give you very good idea on Application Folder . Please give your valuable suggestion and improvement area that I can incorporate with this
article and also on my next articles.
Overview ASP.NET Application Folder
ASP.Net 2.0 uses file-based approach. It's means all class files, resource files, Data , Folder are maintain in a hierarchical way. If we are
working with ASP.Net 2.0 , we can add files and folder from "Add Items" Options. If we look at a sample application hierarchy , It will looks
following figure.
we can add as many as files and folder (as per our requirements ) with our solutions. And it's doesn't need to recompile them each and every time when they
are added. Its Asp.Net's overhead to dynamically compiled them when required. So, what ASP.Net 2.0 does, it contain a defined folder structure, contains
files (Classes, Images, Resources etc.. ), compile them dynamically and even we can access those files through out the application. ASP.Net Provides some
special folder also to maintain files and resources. Let's see the advantages of using those folder .
Advantages of ASP.NET Application Folder
Following are the main advantages of use of ASP.Net Application Folder
We can maintains resources (Classes,Images,Code,Databases,Themes) in a
organized way, which give us to developed and maintain sites easily.
All files and folder are accessible by through the application.
We can add as many files as possible as per our requirements.
Files are compiles dynamically when required.
Different Types of Application Folders
Asp.Net treats following Folder in a special way , those are
App_Code
Bin
App_Data
App_Theme
App_Browser
App_WebReference
App_LocalResource
App_GlobalResource
Details of Application Folder
Now , look at the use of those folder , I am starting from App_Code.
App_Code Folder :
As name suggest, App_Code Folder store classes, typed data set etc. All the items that are
store in App_code , are automatically accessible by through out the application. If we store any class files (like .cs or .vb )
its compile them automatically . Its automatically create type data set from .Xsd file and create XML Web services proxy class
from WSDL. Let's have a look how we can use App_Code Folder.
We can add App_Code Folder , by Solution File -> Right Click -> Add Asp.Net Folder
-> App_Code. Now App_Code Folder is now added with your application.
Note :-
Try to Add one more App_Code Folder by using following steps. Opppps... No , App_Code folder is not available there. So , Asp.Net allows to add App_Code
folder for once.
Now we can add new items like Class, text, xml files inside the App_Code folder or we can also add existing files.
Let's have a look one example , that how its works . In the App_Code folder , I have added a class "MyCSharpClass.cs" .
In that class I have written small spice of code for adding two number.
Now, Try to access this class, from any where of you application. "MyCsharpClass" will be accessible through out the application.
If we want to store different class like .cs, .vb then what will happened. If we kept both .cs and .vb class it will
give following compilation error.
Because, All the classes contained in App_Code Folder are built into a single Assembly , It can't have different language in root level or
even a child level folder in following way.
We have a solution to overcome this problems. We have to create separate folder for C# and VB or other classes.
Store class files separately on those folder and an configure the folder hierarchy on web.config file .
Now , I am moving to our next Part that is Bin Folder .
Bin Folder:
Bin folder is used for keeping the assemblies inside it. we can access those as a reference from any where of our web application. Use of Bin folder comes
to the picture if we use any class library with our web application. Suppose, we are creating a Class Library "TestLib" , After build the
library , we will get "TestLib.dll", Now Right Click on Solution file -> Add References -> Project , Select TestLib Project, Click on
OK. Check the bin folder, its contain TestLib.Dll and TestLib.Pdb files.
Assemblies in Bin folder do not need to registered . Asp.net recognize the presence of dll inside the Bin Folder . Keeping .pdb files inside bin folder
helps us for debugging. Main limitation of storing assemblies in bin folder that , they are in scoped of Current Application . Therefore they cannot access
any code outside of current web application. [Source]
Let's have a look on App_Data Folder
App_Data Folder :
App_Data
Folder used as a "data storage" for the web application. It can store, .mdf, .mdb, XML, etc files. Its manage all of your application data in
a centrally manner. It can be accessible from any where of your web application. The real advantage is that any file you place in App_Data won't be
downloadable.
We can add .mdf file into App_Data Folder , directly by "Add New Item" . From there we can create table, procedure, function without opening
SQL Server. Now if we want to add that data in our application we can easily use.
Now, look at the connection string that we need to write for accessing App_Data folder databases.
So we can connect with "MyDB.mdf" file using this ConnectionString . Check the bellow example which I have used to read the Table
data from "MyDB.Mdf" file.
App_Theme Folder :
If you want to give your web sites a consistent looks then you need to design Themes for your web application. App_Themes folder contains your
Themes . A Theme folder can contain two Folder, one for Css files and another for Skin files. When we will add " App_Theme" automatically a sub folder with name "Theme1" will be created. we can change the name of Theme folder as per our requirement.
I will not cover how to create skin file or Css file in this article, my main concern is how to apply them. You can find the details of Skin and Css over here .
Now we have to apply the theme to the page, there are several way to do that, we can set the theme from "aspx" page at page directive in following way,
While we are going to set theme from aspx page list of Theme available to us as shown in picture. We can set the theme from code behind file also and even
we can change theme runtime (using HttpHandler).
App_Browser Folder :
App_Browser
Folder contain browser information files (.browser files). These files are xml based files which are used to identify the browser and browser
capabilities . you will find the browser files in following location,
If you want to change .browse file, just copy the file to App_Browser Directory and change it. You can create new Browser files by just click
on "Add New Item " on App_Browser Folder
As I already mention, Browser file is an configuration file, generally its look like this
App_WebReference :
AS name suggest, App_WebReference folder contain reference of any web services. If we added any web servies with our web application it will
come automatically inside App_WebReference folder as in windows application if we added any ".dll" its comes under "Reference"
Folder .
ASP.Net Resources :
Before start about App_GlobalResource and App_LocalResoce, I would like to give small introduction of Asp.net Resource. If you
are creating a sites for multinational company or a public web sites that can be accessible by all over the world, you need to consider the best ways to
address users in different cultures with different languages with different country.ASP.NET provides the infrastructure to create Web applications that
automatically adjust formatting and languages according to user preferences using Resource files. Main purpose of Resource files is " Localization" of web application.
ASP.NET uses resource files to make supporting multiple languages in a simpler way. Visual Studio 2005 can automatically generate XML resource files that
contain text for your controls in different languages. When user visit the sites they can change the languages of the sites based on there preference.
There are two type of resource
Local Resource
Global Resource
ASP.NET
Now take a take a look at ASP.NET in the context of Web application just discussed above. With Microsoft ASP.NET technology, ASP.NET files are just text
files and placed in the Web server (Microsoft IIS) and request URL (resource link entered or keyed on browser) points to those files. They are like any
other Resource file as has been depicted in REST. When a request comes for an ASP.NET page, the server will locate the requested file and ask the ASP.NET
engine to serve the request. The ASP.NET engine will process the server tags and generate HTML for it and return back to the client.
AJAX
Now take a look at what AJAX has brought in terms of changes on the architectural model. The following diagram shows the difference between a classic Web
application and AJAX application. Please note that XML data shown in the diagram could be any text based data like Microsoft JSON.
AJAX application uses a lot of small requests for data, rather than re-requesting the whole page. This allows AJAX applications to be more responsive, as
only the new additional delta data need to be transferred between client and server. People who criticize AJAX say it requires more bandwidth, but it is
not. Let me explain, remember Just In Time design principle, i.e. when a page is opened, the user may not be interested in the whole page data but rather
his interest is localized and the user interface has been designed keeping this in mind (a specific tree node, a panel within a window, etc.) – so in this
case we can populate page initially with optimum information and then let user demand for more.
HTTP
Hyper Text Transfer Protocol (HTTP) is an application level protocol which is used in the "World Wide Web (WWW)". It is a request/response style protocol.
Clients (Browsers) will request to a Server (Web Server) and the Server responds to these requests. HTTP uses TCP/IP protocol for communication. It
connects to a specific port (default is 80) to the Server and communicates via that port. Once the response is received completely, client programs will be
disconnected from the server. For each request, client programs have to acquire a connection with servers and do all the request cycles again.
In the response message HTTP contains status codes 100-199 indicating that the message contains a provisional information response, 200-299 indicating that
the request succeeded, 300-399 indicating that the request needs to be redirected to another resource, 400-499 indicating that the client made an error
that should not be repeated, and 500-599 indicating that the server encountered an error, but that the client may get a better response later (or via some
other server), etc.
In HTTP, requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries in WWW as well as
by the machines that originate services. The result is an infrastructure that allows for layers of transformation and indirection that are independent of
the information origin and this helps an Internet-scale, multi-vendor, scalable information system. To understand HTTP, let us try to translate into HTTP a
real life scenario. Consider the following (taken from ‘An Overview of REST’ by Alan Trick):
Proxy
As shown in the REST diagram, proxy lies between client and server. A client connects to the proxy, requesting some service, such as a file, connection,
web page, or other resource, available from a different server. The proxy evaluates the request according to its filtering rules. If the request is
validated by the filter, the proxy provides the resource by connecting to the relevant server and requesting the service on behalf of the client. Caching
proxies keep local copies of frequently requested resources, allowing large organizations to significantly reduce their upstream bandwidth usage and cost,
while significantly increasing performance.
Gateway
A gateway is a network point that acts as an entrance to another network. On the Internet, a node or stopping point can be either a gateway node or a host
(end-point) node. Both the computers of Internet users and the computers that serve pages to users are host nodes, while the nodes that connect the
networks in between are gateways. For example, the computers that control traffic between company networks or the computers used by internet service
providers (ISPs) to connect users to the internet are gateway nodes.
On an IP network, clients should automatically send IP packets with a destination outside a given subnet mask to a network gateway. A subnet mask defines
the IP range of a network. For example, if a network has a base IP address of 192.168.0.0 and has a subnet mask of 255.255.255.0, then any data going to an
IP address outside of 192.168.0.X will be sent to that network's gateway. On a Windows computer, this gateway feature is achieved by sharing the internet
connection on that desktop.
DNS
The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource participating in the Internet. It associates various
information with the domain names assigned to each of the participants. Most importantly, it translates domain names meaningful to humans into the
numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices world-wide. An often used
analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP
addresses. For example, www.example.com translates to 208.77.188.166.
AJAX
Ajax is shorthand for Asynchronous JavaScript and XML. AJAX as has been discussed in this article has more emphasis on user experience, i.e. responsiveness
of application with user actions and it consists of HTML, JavaScript technology, DHTML, and DOM.
JSON
JavaScript Object Notation (JSON) in its simplest form allows us to transform a set of data represented in a JavaScript object into a string. It is more
compact in notation than XML.
Postback
Postback is a mechanism of communication between client-side (browser) and server-side (IIS) of a Web application. Through postback, all contents of
page/form(s) sent to the server from client for processing and after following page life cycle all server side contents get rendered and
Introduction
Here in this article, I will be exploring the configuration files of a website. ASP.NET website configuration is normally a combination of two files:
machine.config
web.config
Here, I'll concentrate on web.config and give an overview of machine.config.
Every time we install the .NET framework, there is a machine.config file that is created in " C:\WINDOWS\Microsoft.NET\Framework\[Version]\CONFIG", which mainly defines:
Supported configuration file sections,
the ASP.NET worker process configuration, and
registers different providers that are used for advanced features such as profiles, membership, and role based security.
To explore the web.config might take a book, but here, I'll try to explore all the important sections that play a pivotal role for an ASP.NET
website and its deployment.
Every web application inherits settings from the machine.config file, and application level setting is done in the web.config file. We
can also override configurations in the machine.config file in the web.config file. But, a few settings can not be overridden because
certain settings are process model settings and can't be changed on a per application basis.
The entire contents of a configuration file, whether it is machine.config or web.config, is nested in a <configuration
> element.
ASP.NET Multilayered Configuration system
ASP.NET uses a multilayered configuration system that allows for using different settings for different parts of an application. For this, we must have an
additional subdirectory inside the virtual directory, and these subdirectories will contain their own config files with additional settings. ASP.NET uses configuration inheritance so that each subdirectory acquires the settings from the parent directory.
Let's take an example. We have a web request http://localhost/X/Y/Z/page.aspx, where X is the root directory of the application. In this
case, multiple levels of settings come into the picture.
The default machine.config settings are applied first.
Next, the web.config of the root level is applied. This web.config resides in the same config directory as the machine.config file.
Now, if there is any config file in the application root X, these settings are applied.
If there is any config file in the subdirectory Y, these settings are now applied.
If there is any config file in the application root Z, those settings are then applied.
But here, there is a limitation: we can have unlimited number of subdirectories having different settings, but the configuration at step 1 and 2 are more
significant because some of the settings can not be overridden, like the Windows account that is to be used to execute the code, and other settings can be
only overridden at the application root level, like the type of authentication to be used etc.
Different config files are useful when we apply different security settings to different folders. The files that need to be secured would then be placed in
a separate folder with a separate web.config file that defines the more stringent security settings to these files and vice versa.
In the web.config, under the <configuration> element, there is another element <system.web>, which is used
for ASP.NET settings and contains separate elements for each aspect of the configuration.
Important Configuration Tags
There are a lot of configuration tags that are provided by the web.config file, like authentication, authorization, browserCaps, clientTarget etc., but all of these don't have that much importance (and also can't be covered in a single article
), so here, I have only concentrated on the main tags of the config file.
<authentication>
This element is used to verify the client's identity when the client requests a page from the server. This is set at the application level. We have four
types of authentication modes: “None”, “Windows”, “Forms”, and “Passport”.
If we don't need any authentication, this is the setting we use:
Collapse | Copy Code
<authentication mode="None"/>
Normally, Windows authentication is used, for which, we need to check the checkbox: Integrated Windows Authentication.
Collapse | Copy Code
<authentication mode="Windows"/>
This authentication is handled by IIS. When the user sends a request to the server, IIS authenticates it and sends the authentication identity to the code.
IIS gives us four choices for the authentication modes: Anonymous, Basic, Digest, and Windows Integrated. If the user selects Anonymous, then IIS doesn't
perform any authentication. For Basic authentication, the user has to provide a username and password. This authentication is very unsecure, because the
user credentials are sent in clear text format over the network. Digest authentication is same as Basic, except it hashes the user's password and transmits
the hashed version over the wire. So, it is more secure than Basic. For Windows Integrated authentication, passwords never cross the network. The user must
still have a username and password, but the application uses either the Kerberos or a challenge/response protocol to authenticate the user.
Forms authentication
uses web application forms to collect user credentials, and on the basis of the credential, it takes action on a web application.
Collapse | Copy Code
<authentication mode="Forms">
<forms name="Form" loginUrl="index.asp" />
</authentication>
Passport authentication
is provided by Microsoft. A redirect URL should be specified, and is used when the requested page is not authenticated, and then it redirects to this URL.
Collapse | Copy Code
<authentication mode="Passport">
<passport redirectUrl="internal" />
</authentication>
Here, users are authenticated using the information in Microsoft's Passport database. The advantage is, we can use existing user credentials (such as an
email address and password) without forcing users to go through a separate registration process. The disadvantage is we need to go through the licensing
agreement with Microsoft and pay a yearly fee based on the use.
For using Passport authentication, you first install the Passport Software Development Kit (SDK) on your server. The SDK can be downloaded from here. It includes full
details of implementing passport authentication in your own applications.
<authorization>
The <authorization> tag controls client access to web page resources. This element can be declared at any level (machine, site,
application, subdirectory, or page).
Collapse | Copy Code
<authorization>
<allow users="comma-separated list of users"
roles="comma-separated list of roles"
verbs="comma-separated list of verbs"/>
<deny users="comma-separated list of users"
roles="comma-separated list of roles"
verbs="comma-separated list of verbs"/>
</authorization>
<
allow
>
: Using this tag, we can control access to resources on the basis of the following verbs. In these attributes, we use symbols: ? and *.? means for
anonymous users/resources, and * means for all users.
users
: This contains the list of user names (comma separated) that are allowed to access the resources.
roles
: This contains the list of roles (comma separated) that are allowed to access the resources.
verbs
: This contains the list of HTTP verbs to which the action applies (comma separated). It is used to create a rule that applies to a specific type of
HTTP request (GET, POST, HEAD, OR DEBUG).
<
deny
>
: Using this tag, we can control access to resources on the basis of the following verbs:
users
: This contains the list of users names (comma separated) that are denied access to the resources.
roles
: This contains the list of roles (comma separated) that are denied access to the resources.
verbs
: This contains the list of HTTP verbs to which the action applies (comma separated). It is used to create a rule that applies to a specific type of
HTTP request (GET, POST, HEAD, OR DEBUG).
<compilation>
In this section, we can configure the settings of the compiler. Here, we can have lots of attributes, but the most common ones are debug and defaultLanguage. Setting debug to true means we want the debugging information in the browser, but it has a
performance tradeoff, so normally, it is set as false. And, defaultLanguage tells ASP.NET which language compiler to use: VB or
C#.
<customErrors>
This tags includes the error settings for the application, and is used to give custom error pages (user-friendly error pages) to end users. In the case
that an error occurs, the website is redirected to the default URL. For enabling and disabling custom errors, we need to specify the mode
attribute.
Collapse | Copy Code
<customErrors defaultRedirect="url" mode="Off">
<error statusCode="403" redirect="/accesdenied.html" />
<error statusCode="404" redirect="/pagenotfound.html" />
</customErrors>
"On"
means this settings is on, and if there is any error, the website is redirected to the default URL.
"Off"
means the custom errors are disabled.
"RemoteOnly"
shows that custom errors will be shown to remote clients only.
Collapse | Copy Code
<error statusCode="403" redirect="/accesdenied.html" />
<error statusCode="404" redirect="/pagenotfound.html" />
This means if there is an error of 403, then the website will redirected to the custom page accessdenied.html. Similarly for 404 as defined above.
Note
: If an error occurs in the custom error page itself, ASP.NET won't able to handle it. It won't try to reforward the user to the same page. Instead,
it'll show the normal default client error page with a generic message
.
<globalization>
This section is used when we want to use encoding or specify a culture for the application. This is a very vast topic, and can take an article itself for
explaining it. Here, we define the character set for the server to send the response to the client, which is by default is UTF-8, and the settings of which
the server should use to interpret and display culturally specific strings, such as numbers and dates.
Collapse | Copy Code
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<httpRuntime>
This section can be used to configure the general runtime settings of the application. The main two are:
Collapse | Copy Code
<httpRuntime appRequestQueueLimit="50" executionTimeout="300" />
As the name suggests, the attribute appRequestQueueLimit defines the number of requests that can be queued up on the server for processing. If
there are 51 or more requests, then server would return the 503 error ("Server too busy").
The attribute executionTimeout defines the number of minutes ASP.NET will process a request before it gets timeout.
<trace>
As the name suggestz, it is used for tracing the execution of an application. We have here two levels of tracing: page level and application level.
Application level enables the trace log of the execution of every page available in the application. If pageOutput="true", trace information
will be displayed at the bottom of each page. Else, we can view the trace log in the application root folder, under the name trace.axd.
Collapse | Copy Code
<trace enabled="false" requestLimit="10" pageOutput="false"
traceMode="SortByTime" locaOnly="true" />
Set the attribute localOnly to false for not viewing the trace information from the client.
For enabling trace at page level, set Trace="True" in the Page tag (on the top of the page).
<identity>
Using this tag, we can control the identity of the application. By default, Impersonation is disabled. Using Impersonation, an
ASP.NET application can execute optionally with the identity of a client on whose behalf they are operating.
Collapse | Copy Code
<identity impersonate="false" userName="domain\username" password="password" />
<sessionState>
In this section, we tell ASP.NET where to store the session. By default, it's inproc which means storing the session values on the server. But
we have four options:
"Off" means session is not enabled for the application.
"inproc" means storing the session values on the server.
"StateServer" means session states are stored in a remote server.
"SQLServer" means session states are stored in a SQL Server database. For this, we need to install the InstallSQLState.sql script
in the SQL Server database. It is mainly used when the we use web farms (an application deployed on multiple servers), but it makes the performance
slow as compared to "inproc".
Here are the other settings:
"cookieless": when it istrue, it means the session used is without cookies.
“timeout” specifies after how much time the session would expire if the application is not accessed during that period.
"stateConnectionString" needs to be specified when the session mode isStateServer.
"sqlConnectionString" is the connection string of the SQL Server database if the session mode issqlserver.
"stateNetworkTimeout" attribute, when using theStateServermode to store session state, specifies the number of seconds the
TCP/IP network connection between the web server and the state server can be idle before the session is abandoned. The default is 10.
Collapse | Copy Code
<sessionState mode="Off"
cookieless="true"
timeout="100"
stateConnectionString="tcpip=server:port"
sqlConnectionString="sql connection string"
stateNetworkTimeout="number of seconds"/>
<appSettings>
This section is used to store custom application configuration like database connection strings, file paths etc. This also can be used for custom
application-wide constants to store information over multiple pages. It is based on the requirements of the application.
Collapse | Copy Code
<appSettings>
<add key="Emailto" value="me@microsoft.com" />
<add key="cssFile" value="CSS/text.css" />
</appSettings>
It can be accessed from code like:
Collapse | Copy Code
ConfigurationSettings.AppSettings("Emailto");All the values returned from it are strings.
Custom Configuration Sections
We might need some custom configuration sections based on the requirements. One of the simplest ways we can do this is to create our own named sections,
and we can use existing NameValueSectionHandler components to parse them, and they can be used as key/value pairs to be accessed at run-time.
This can be read very easily accessed from the code-behind as:
Collapse | Copy Code
private string ReadCustomSection()
{string strKey = "mySectionKey1";
NameValueCollection nvcmySection = (NameValueCollection)
ConfigurationSettings.GetConfig("mySection");string strValueofKey = nvcmySection[strKey];
return strValueofKey;
}
There are more ways for using custom configuration sections. Check this article: CustomConfigurationSection.
The Silverlight Framework
In this lesson of the Silverlight tutorial, you will learn...
How Microsoft Silverlight compares to Windows Presentation Foundation (WPF).
To use various tools to create Silverlight applications.
To write code in Silverlight applications using JavaScript and .NET Framework programming languages.
About Windows Live Services that compliment Silverlight.
About the controls that Microsoft provided for integrating Silverlight with ASP.NET.
To use Silverlight from an ASP.NET AJAX page.
To create a Silverlight application.
This lesson will introduce you to the inner workings of a Silverlight application.
Overview
Microsoft Silverlight is the latest development offering from Microsoft and a logical progression of Microsoft technologies.
Silverlight vs. WPF
Silverlight is a subset of Windows Presentation Foundation that also extends and uses many of the features and aspects of ASP.NET AJAX. Silverlight's
strengths lie in its portability over the Web. However, because it must work across platforms and browsers, it cannot take advantage of or be reliant
upon any particular environment or platform. This limits its ability to provide the advanced 3D graphic features, speech and voice recognition,
recording, and other features that WPF provides.
Furthermore, for security reasons, Silverlight has limited access to the host machine, which further limits its capabilities.
Silverlight Performance
Silverlight has a speedy rendering engine. There are a couple experiments out there on the Web that illustrate the performance advantages of
Silverlight. The bouncing balls experiment, located at http://bubblemark.com, is a great example and can be used
to compare rendering speeds of the most popular competitive development environments. Be sure to pick the Silverlight 2.0 option.
Introducing Silverlight
What's New in the .NET Framework
As of the writing of this course, version 3.5 of the .NET Framework has been released. Version 3.5 includes features that encompass all facets of Windows,
Web, and network development:
Includes just under 10,000 classes, methods, and properties.
Complies with the latest Web development standards.
Introduces revolutionary technologies used in Windows Vista development, rich media and user experiences, workflow management, security and
authorization, and complete distributed communication protocols.
The .NET Framework can also be fully extended by developers to create custom classes and types. The functionality of the .NET Framework spans the server,
the workstation, and the Web. The four primary additions to the .NET Framework as of version 3.0 are:
Windows Presentation Foundation (WPF)
Windows Communication Foundation (WCF)
Windows Workflow Foundation (WF)
CardSpace
Windows Presentation Foundation (WPF)
WPF is used to develop elaborate user interfaces like those that adorn Windows Vista and managed advanced media streaming and integration. WPF is the a
complete revamp of Windows Forms so that user interface, graphic, and media development is now designed around the .NET Framework.
Windows Communication Foundation (WCF)
WCF encompasses the ASP.NET Web Services and .NET remoting functionality that was contained in the .NET Framework 2.0 as well as new communication
technologies.
Windows Workflow Foundation (WF)
WF is used to model complex workflow processes.
CardSpace
CardSpace is the embodiment of new security and user authorization functionality.
Silverlight Architecture
Unlike ASP.NET, the bulk of Silverlight processing occurs on the client machine thus decreasing server resource utilization and improving the Web
experience on the client. The figure below shows the difference between ASP.NET processing and Silverlight processing:
When a client initially attempts to run a Silverlight application, if the Silverlight plug-in has not been installed on the client machine, it will be
downloaded and installed. Upon subsequent requests to run the application, the application will instantiate on the client machine and make requests for
resources from the server only when necessary. The Silverlight plug-in can be thought of as a scaled-down version of the full .NET Framework. It only
contains those classes and functionality that are applicable to a Silverlight Web client and those were streamlined and optimized for use on the Web client
machine.
Silverlight was designed using the same design paradigm as ASP.NET. Each page of a Silverlight application includes an associated code behind file that
includes the code that handles events fired by the page. Silverlight resembles WPF in that it uses Extensible Application Markup Language (XAML) to
construct the user interface (presentation layer). As Silverlight applications are composed of text-based files that include markup and code, they can be
created using any text editor; however, more advanced tools and development environments such as Visual Studio or Expression Blend simplify the task
significantly.
Silverlight Technologies
Version 1.0 of Silverlight used JavaScript and supported the industry-leading Windows Media Services enabling delivery of audio and video that includes 2D
and vector graphics.
Version 2 includes all features of version 1.0 and:
support for the .NET Framework.
support for .NET-compliant programming languages such as C#, Visual Basic, Python, and Ruby.
support for database operations and language-integrated query (LINQ).
The figure below illustrates the major differences between version 1.0 and version 2:
The diagram located at ClassFiles/WhatIsSilverlight/Demos/SilverlightTechnologyMap.gif gives a broad picture of the technologies to be supported by
Silverlight version 2.
Silverlight Hosting
Microsoft Silverlight functionality is completely encapsulated within the Silverlight plug-in. Web applications typically require the server hosting the
Web application to meet minimum requirements. Silverlight applications simply require a Web server to be equipped as they would be for hosting HTML
documents. Silverlight applications can be hosted on any Web server accessible to the target audience. The two most commonly used Web servers are Microsoft
Internet Information Server (IIS) and Apache.
Executing a Silverlight application on a Web client machine is a two step process. First, the application will detect if the Silverlight plug-in is
installed on the Web client machine. If the plug-in is not installed, the user will be prompted with an option to download the plug-in. If the user opts to
do so, a request will be made of the Web server to download and install the plug-in. The Silverlight plug-in is embodied in a .dll executable file that is
loaded into the Web client browser memory once installed. The only interaction required by the Web client when installing the Silverlight plug-in is to
grant permission for the plug-in to be installed. Various Web servers, including Microsoft Internet Information Server (IIS), may require slight
configuration modifications so that the Silverlight executable file will be downloaded to the Web client when requested.
Second, once the Silverlight plug-in is installed on the Web client machine, the Silverlight application itself must be downloaded. A Silverlight
application may consist of many types of files. Slight configuration modifications may be necessary on the Web server, such as MIME types, so that XAML and
XAP files are associated with Silverlight and downloaded correctly to the Web client machine when requested.
Once the Silverlight plug-in is installed on a Web client machine and a Silverlight application is downloaded, the Silverlight application is then hosted
on the Web client machine. There are some requirements necessary for the Web client machine as discussed in the sections below, however all media players,
audio and video codecs, compilers and the runtime are encapsulated in the Silverlight plug-in.
What is Silverlight? Conclusion
In this lesson of the Silverlight tutorial, you
Explored Microsoft Silverlight at a high level.
Studied some of the history leading up to the release of Silverlight.
Investigated the architecture of Silverlight.
Learned which operating systems and browsers support Silverlight 2.
C# Web Service
Introduction
Creating your first web service is incredibly easy. In fact, by using the wizards in Visual Studio. NET you can have your first service up and running in
minutes with no coding.
For this example I have created a service called MyService in the /WebServices directory on my local machine. The files will
be created in the /WebServices/MyService directory.
A new namespace will be defined called MyService, and within this namespace will be a set of classes that define your Web Service. By default
the following classes will be created:
Global (in global.asax) | Derived from HttpApplication. This file is the ASP.NET equivalent of a standard ASP global.asa file. |
WebService1 (in WebService1.cs) | Derived from |
There are also a number of files created:
AssemblyInfo.cs | Contains version and configuration information for your assembly. |
web.config | Defines how your application will run (debug options, the use of cookies etc). |
MyService.disco | Discovery information for your service. |
WebService1.asmx | Your WebService URL. Navigate to this file in a browser and you will get back a user-friendly page showing the methods available, the |
bin\MyService.dll | The actual WebService component. This is created when you build the service. |
The class for your service that is created by default is called (in this case) WebService1, and is within theMyService namespace.
The code is partially shown below.
Collapse
namespace MyService
{...
/// <summary>
/// Summary description for WebService1.
/// </summary>
[WebService(Namespace="http://codeproject.com/webservices/",
Description="This is a demonstration WebService.")]
public class WebService1 : System.Web.Services.WebService
{public WebService1()
{//CODEGEN: This call is required by the ASP+ Web Services Designer
InitializeComponent();
}
...
[WebMethod]
public string HelloWorld()
{return "Hello World";
}
}
}
A default method HelloWorld is generated and commented out. Simply uncomment and build the project. Hey Presto, you have a walking talking
WebService.
A WebService should be associated with a namespace. Your Wizard-generated service will have the name space http://tempuri.org. If you compile and run the
service as-is you'll get a long involved message indicating you should choose a new namespace, so we add the namespace, and the WebService description as
follows:
Collapse
[WebService(Namespace="http://codeproject.com/webservices/",
Description="This is a demonstration WebService.")]
public class WebService1 : System.Web.Services.WebService
{...
To test the service you can right click on WebService1.asmx in the Solution Explorer in Visual Studio and choose "View in Browser". The test page
is shown below,
When invoked this returns the following:
Getting the demo application to run
If you downloaded the source code with this article then you will need to create a directory 'WebServices' in your web site's root directory and extract
the downloaded zip into there. You should then have:
Collapse
\WebServices
\WebServices\bin
\WebServices\WebService1.asmx
...
Navigating to http://localhost/WebServices/WebService1.asmx won't show you the WebService because you need to ensure that the webservice's
assembly is in the application's /bin directory. You will also find that you can't load up the solution file MyService.sln. To kill two birds with
one stone you will need to fire up the IIS management console, open your website's entry, right click on the WebServices folder and click Properties. Click the 'Create' button to create a new application the press OK. The /WebServices directory is now an application
and so the .NET framework will load the WebService assembly from the /WebServices/bin directory, and you will be able to load and build the MyService.sln solution.
Extending the example
So we have a WebService. Not particularly exciting, but then again we haven't exactly taxed ourselves getting here. To make things slightly more
interesting we'll define a method that returns an array of custom structures.
Within the MyService namespace we'll define a structure called ClientData:
Collapse
public struct ClientData
{public String Name;
public int ID;
}
and then define a new method GetClientData. Note the use of the WebMethod attribute in front of the method. This specifies that
the method is accessible as a WebService method.
Collapse
[WebMethod]
public ClientData[] GetClientData(int Number)
{ClientData [] Clients = null;
if (Number > 0 && Number <= 10)
{Clients = new ClientData[Number];
for (int i = 0; i < Number; i++)
{Clients[i].Name = "Client " + i.ToString();
Clients[i].ID = i;
}
}
return Clients;
}
If we compile, then navigate to the the .asmx page then we are presented with a form that allows us to enter a value for the parameter. Entering a
non-integer value will cause a type-error, and entering a value not in the range 1-10 will return a null array. If, however, we manage to get the input
parameter correct, we'll be presented with the following XML file:
It's that easy.
Caching WebServices
Often a WebService will return the same results over multiple calls, so it makes sense to cache the information to speed things up a little. Doing so in
ASP.NET is as simple as adding a CacheDuration attribute to your WebMethod:
Collapse
[WebMethod(CacheDuration = 30)]
public ClientData[] GetClientData(int Number)
{The CacheDuration attribute specifies the length of time in seconds that the method should cache the results. Within that time all responses from the
WebMethod will be the same.
You can also specify the CacheDuration using a constant member variable in your class:
Collapse
private const int CacheTime = 30; // seconds
[WebMethod(CacheDuration = CacheTime)]
public ClientData[] GetClientData(int Number)
{Adding Descriptions to your WebMethods
In the default list of WebMethods created when you browse to the .asmx file it's nice to have a description of each method posted. The Description attribute accomplishes this.
Collapse
[WebMethod(CacheDuration = 30,
Description="Returns an array of Clients.")]
public ClientData[] GetClientData(int Number)
{Your default .asmx page will then look like the following:
There are other WebMethod attributes to control buffering, session state and transaction support.
Deploying the WebService
Now that we have a WebService it would be kind of nice to allow others to use it (call me crazy, but...). Publishing your WebService on your server
requires that your solution be deployed correctly. On the Build menu of Visual Studio is a "Deploy" option that, when first selected, starts a Wizard that
allows you to add a Deployment project to your solution. This creates an installation package that you can run on your server which will create the
necessary directories, set the correct parameters and copy over the necessary files.
This doesn't really give you an idea of what, exactly, is happening, so we'll deploy our MyService manually.
Deploying the application is done using the steps in Getting the demo application to run. We need to create a directory for our
service (or use an existing directory) for our .asmx file, and we need to have the service's assembly in the application's bin/ directory. Either
place the .asmx file in a subdirectory on your website and place the assembly in the /bin folder in your website's root, or place the /bin in the
subdirectory containing the .asmx file and mark that directory as an application (see above).
If you choose to create a separate directory and mark it as an application then Within this directory you need to add the following files and directories:
MyService.asmx | This file acts as the URL for your service |
MyService.disco | The discovery document for your service |
web.config | Configuration file for your service that overrides default web settings (optional). |
/bin | This directory holds the assembly for your service |
/bin/MyService.dll | The actual service asembly. |
Conclusion
Writing WebServices is extremely easy. Using the Visual Studio. NET wizards makes writing and deploying these services a point and click affair, but even
if you wish to do it by hand then the steps involved are extremely simple.
Web Services with ASP.NET
Rob Howard
Microsoft Corporation
February 22, 2001
Web Services are the underpinning of Microsoft's .NET strategy. The concepts and the innovations behind this initiative have struck a chord with
developer's building the next generation of Internet applications.
In this month's column, we're going to take a look at the features within ASP.NET to enable Web Services. Before we dig into the technical details let's
start with an overview of Web Services.
Web Services Overview
A Web Service is programmable application logic accessible via standard Web protocols. One of these Web protocols is the Simple Object Access Protocol
(SOAP). SOAP is a W3C submitted note (as of May 2000) that uses standards based technologies (XML for data description and HTTP for transport) to encode
and transmit application data.
Consumers of a Web Service do not need to know anything about the platform, object model, or programming language used to implement the service; they only
need to understand how to send and receive SOAP messages (HTTP and XML).
Soap Message
A SOAP message consists of several elements, most notably an envelope. The envelope encapsulates the data transmitted within the SOAP message. Below is a
simple SOAP message complete with HTTP headers:
POST /demo/MSDN/PerfCounter.asmx HTTP/1.1
Connection: Keep-Alive
Content-Length: 150
Content-Type: text/xml
Host: localhost
User-Agent: MS Web Services Client Protocol 1.0.2204.19
SOAPAction: "http://tempuri.org/PerfCounters"
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<soap:Body>
<PerfCounters xmlns="http://tempuri.org/"/>
</soap:Body>
</soap:Envelope>
In the example above, we see the HTTP headers for the request, including the HTTP SOAPAction header, which is optionally used by the server for routing the
SOAP message. Following the HTTP headers we find the body of the HTTP message. The body of the HTTP message is the SOAP request for a PerfCounters Web
Service, which we are going to build.
Unfortunately we don't have nearly enough room in this column to discuss SOAP in depth. To learn more about SOAP, please see the SOAP Developer Resources page. Here you can find the public
specification for SOAP 1.1 as well as articles and other relevant resources.
No comments:
Post a Comment