Software Technologies

In general terms, the page goes through the stages outlined in the following table. In addition to the page life-cycle stages, there are application stages that occur before and after a request but are not specific to a page. For more information, see ASP.NET Application Life Cycle Overview for IIS 7.0.

Stage
Description

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 step, 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. Additionally, during the start step, the page's UICulture property is set.

Page initialization
During page initialization, controls on the page are available and each control's UniqueID property is set. Any themes are also applied to the page. 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.

Validation
During validation, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page.

Postback event handling
If the request is a postback, any event handlers are called.

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

Unload
Unload is called 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 any cleanup is performed.

http://msdn.microsoft.com/en-us/library/ms178473(VS.80).aspx

How Does It Work?
http://msdn.microsoft.com/en-us/library/aa302376.aspx#secnetap04_topic2

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation
Published: November 2002
Last Revised: January 2006

Applies to:
Microsoft® ASP.NET
Microsoft® Windows® 2000
See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.



See the Landing Page for the starting point and a complete overview of Building Secure ASP.NET Applications.



Summary: This appendix provides additional material to explain in more detail how certain key concepts and processes discussed within the main body of the guide actually work. (9 printed pages)



Contents
IIS and ASP.NET Processing
ASP.NET Pipeline Processing
IIS and ASP.NET Processing
Note The information in this section applies to Internet Information Services (IIS) 5, running on Windows® 2000.

ASP.NET Web applications and Web services are processed by code that executes in a single instance of the ASP.NET worker process (aspnet_wp.exe), although on multi-processor computers, you can configure multiple instances, one per processor.

IIS authenticates callers and creates a Windows access token for the caller. If anonymous access is enabled within IIS, then a Windows access token for the anonymous Internet user account (typically, IUSR_MACHINE) is created by IIS.

Requests for ASP.NET file types are handled by an ASP.NET ISAPI extension (aspnet_isapi.dll), which runs in the IIS (inetinfo.exe) process address space. This uses a named pipe to communicate with the ASP.NET worker process as shown in Figure 1. IIS passes the Windows access token that represents the caller to the ASP.NET worker process. The ASP.NET Windows authentication module uses this to construct a WindowsPrincipal object and the ASP.NET File authorization module uses it to perform Windows access checks to ensure the caller is authorized to access the requested file.

Figure 1. IIS and ASP.NET communication
Note Access tokens are process relative. As a result, the ASP.NET ISAPI DLL running in inetinfo.exe calls DuplicateHandle to duplicate the token handle into the aspnet_wp.exe process address space and then passes the handle value through the named pipe.

Application Isolation

Separate application domains within the worker process (one per IIS virtual directory, or in other words, one per ASP.NET Web application or Web service) are used to provide isolation.



This is in contrast to classic ASP, where the application protection level, configured within the IIS metabase determined whether the ASP application should execute in process with IIS (inetinfo.exe), out of process in a dedicated instance of Dllhost.exe, or in a shared (pooled) instance of Dllhost.exe.



Important The process isolation level setting within IIS has no affect on the way ASP.NET Web applications are processed.

The ASP.NET ISAPI Extension

The ASP.NET ISAPI extension (aspnet_isapi.dll) runs in the IIS process address space (inetinfo.exe) and forwards requests for ASP.NET file types to the ASP.NET worker process through a named pipe.



Specific ASP.NET file types are mapped to the ASP.NET ISAPI extension by mappings defined within the IIS metabase. Mappings for standard ASP.NET file types (including .aspx, .asmx, .rem, .soap) are established when the .NET Framework is installed.



To view application mappings



1.From the Administrative Tools programs group, start Internet Information Services.

2.Right-click the default Web site on your Web server computer, and then click Properties.

3.Click the Home Directory tab, and then click Configuration.

A list of mappings is displayed. You can see which file types are mapped to Aspnet_isapi.dll.



IIS 6.0 and Windows Server

IIS 6.0 on Windows Server will introduce some significant changes to the current process arrangement.



You will be able to configure multiple application pools, each served by one or more process instances (w3wp.exe). This will provide additional fault tolerance and manageability benefits and will allow you to isolate separate applications in separate processes.

ASP.NET is integrated with the IIS 6.0 Kernel mode HTTP listener, which will allow requests to be passed directly from the operating system to the ASP.NET worker process.

ASP.NET Pipeline Processing

ASP.NET authentication and authorization mechanisms are implemented using HTTP module objects, which are invoked as part of the standard ASP.NET pipeline processing. Individual Web requests and responses pass through a pipeline of objects as shown in Figure 2.







Figure 2. ASP.NET pipeline processing



The ASP.NET pipeline model consists of an HttpApplication object, various HTTP module objects, and an HTTP handler object, together with their associated factory objects, which have been omitted from Figure 2 for clarity. An HttpRuntime object is used at the start of the processing sequence and an HttpContext object is used throughout the lifecycle of a request to convey details about the request and response.



The following list explains the responsibilities and operations performed by the objects associated with the HTTP processing pipeline:



The HttpRuntime object examines the request received from IIS and dispatches it to an appropriate instance of the HttpApplication object to process the request. There is a pool of HttpApplication objects in each application domain in Aspnet_wp.exe. There is a one-to-one mapping between application domains, HttpApplication objects and IIS virtual directories. In other words, ASP.NET treats separate IIS virtual directories as separate applications.

Note There is one instance of HttpRuntime in every Web application domain.

The HttpApplication objects control the pipeline processing. An individual HttpApplication object is created to handle each simultaneous HTTP request. HttpApplication objects are pooled for performance reasons.

HTTP module objects are filters that process HTTP request and response messages as they flow through the pipeline. They can view or alter the content of the request and response messages. HTTP modules are classes that implement IHttpModule.

HTTP handler objects are the endpoints for HTTP requests and provide the request processing for specific file types. For example, one handler processes requests for *.aspx files while another processes requests for *.asmx files. The HTTP response message is generated and returned from the HTTP handler. HTTP handlers are classes that implement IHttpHandler.

An HttpContext object is used throughout the pipeline to represent the current Web request and response. It is available to all modules in the pipeline and the handler object at the end of the pipeline. The HttpContext object exposes various properties including the User property which contains an IPrincipal object that represents the caller.

The Anatomy of a Web Request

The ASP.NET ISAPI library (Aspnet_isapi.dll) runs inside the IIS process address space (Inetinfo.exe). It dispatches requests to the HttpRuntime object within the ASP.NET worker process (Aspnet_wp.exe). The following set of actions occurs in response to each Web request received by ASP.NET:



The HttpRuntime object examines the request and forwards it to an instance of an HttpApplication object.

There is at least one HttpApplication object instance per application domain (the objects are pooled) and one application domain per IIS virtual directory. The initial request for a file in a particular virtual directory results in a new application domain and a new HttpApplication object being created.



A list of HTTP modules is read from Machine.config (they are contained within the <httpModules> element). Additional custom HTTP modules can be added to Web.config for a specific application. The default <httpModules> element within Machine.config is shown in the following code snippet. Copy Code <httpModules>

<add name="OutputCache"

type="System.Web.Caching.OutputCacheModule"/>

<add name="Session"

type="System.Web.SessionState.SessionStateModule"/>

<add name="WindowsAuthentication"

type="System.Web.Security.WindowsAuthenticationModule"/>

<add name="FormsAuthentication"

type="System.Web.Security.FormsAuthenticationModule"/>

<add name="PassportAuthentication"

type="System.Web.Security.PassportAuthenticationModule"/>

<add name="UrlAuthorization"

type="System.Web.Security.UrlAuthorizationModule"/>

<add name="FileAuthorization"

type="System.Web.Security.FileAuthorizationModule"/>

</httpModules>

The authentication modules hook the AuthenticateRequest event, while the authorization modules hook the AuthorizeRequest event.



The request passes through every module in the pipeline, although only a single authentication module is loaded. This depends on the configuration of the <authentication> element in Web.config. For example, the <authentication> element that follows results in the WindowsAuthenticationModule being loaded.



Copy Code <authentication mode="Windows" />

The activated authentication module is responsible for creating an IPrincipal object and storing it in the HttpContext.User property. This is vital, because the downstream authorization modules use this IPrincipal object in order to make authorization decisions.

In the absence of authentication (for example, where anonymous access is enabled within IIS and ASP.NET is configured with <authentication mode="None" />), there's a special non configured module that puts a default anonymous principal into the HttpContext. User property. As a result, HttpContext.User is always non-null after authentication.



If you implement a custom authentication module, code within the custom module must create an IPrincipal object and store it in HttpContext.User,



Note ASP.NET also wires up Thread.CurrentPrincipal based on HttpContext.User after the AuthenticateRequest event.

The HttpApplication fires the AuthenticateRequest event, which can be hooked in global.asax. This allows you to inject custom processing code; for example, to load the set of roles associated with the current user. However, note that the WindowsAuthenticationModule does this automatically. The role list is obtained from the set of Windows groups in which the authenticated Windows user is a member.

After the appropriate authentication module has finished its processing, the authorization modules are called if the request hasn't been aborted.

When the UrlAuthorizationModule is called, it checks for an <authorization> tag in Machine.config and Web.config. If present, it retrieves the IPrincipal object from HttpContext.User and checks to see whether the user is authorized to access the requested resource using the specified verb (GET, POST, and so on).

If the user is not authorized, the UrlAuthorizationModule calls HttpApplication.CompleteRequest, which aborts normal message processing. The UrlAuthorizationModule returns an HTTP 401 status code.



Next, the FileAuthorizationModule is called. It checks whether the IIdentity object in HttpContext.User.Identity is an instance of the WindowsIdentity class.

If the IIdentity object is not a WindowsIdentity, the FileAuthorizationModule performs no further processing.



If a WindowsIdentity is present, the FileAuthorizationModule calls the AccessCheck API (through P/Invoke) to see if the authenticated caller (whose access token has been passed to ASP.NET by IIS and is exposed by the WindowsIdentity object) is authorized to access the requested file. If the file's security descriptor contains at least a Read ACE in its DACL, the request is allowed to proceed. Otherwise the FileAuthorizationModule calls HttpApplication.CompleteRequest and returns a 401 status code.



Forms authentication processing

The FormsAuthenticationModule is activated when the following element is in Web.config.



Copy Code <authentication mode="Forms" />

Remember that for Forms authentication, you implement the Application_Authenticate event in Global.asax. For Forms authentication, the following sequence occurs:



Within this code, you can construct an IPrincipal object and store it in HttpContext.User. This typically contains the role list retrieved from a custom data store (normally a SQL Server database or Active Directory). The IPrincipal object is typically an instance of the GenericPrincipal class but could also be a custom IPrincipal class.

The FormsAuthenticationModule checks to see if you have created an IPrincipal object. If you have, it is used by the downstream authorization modules. If you haven't, the FormsAuthenticationModule constructs a GenericPrincipal (with no roles) and stores it in the context.



If there is no role information, any authorization checks (such as PrincipalPermssion demands) that demand role membership, will fail.



The UrlAuthorizationModule handles the AuthorizeRequest event. Its authorization decisions are based on the IPrincipal object contained within HttpContext.User.

Windows authentication processing

The WindowsAuthenticationModule is activated when the following element is in Web.config.



Copy Code <authentication mode="Windows" />

For Windows authentication, the following sequence occurs:



1.The WindowsAuthenticationModule creates a WindowsPrincipal object using the Windows access token passed to ASP.NET by IIS.

2.It uses P/Invoke to call Win32 functions to obtain the list of Windows group that the user belongs to. These are used to populate the WindowsPrincipal role list.

3.It stores the WindowsPrincipal object in HttpContext.User, ready to be used by the downstream authorization modules.

Event Handling

The HttpApplication object fires the set of events shown in Table 1. Individual HTTP modules can hook these events (by providing their own event handlers).



Table 1. Events fired by HttpApplication objects



Event Notes

BeginRequest Fired before request processing starts

AuthenticateRequest To authenticate the caller

AuthorizeRequest To perform access checks

ResolveRequestCache To get a response from the cache

AcquireRequestState To load session state

PreRequestHandlerExecute Fired immediately before the request is sent to the handler object

PostRequestHandlerExecute Fired immediately after the request is sent to the handler object

ReleaseRequestState To store session state

UpdateRequestCache To update the response cache

EndRequest Fired after processing ends

PreSendRequestHeaders Fired before buffered response headers are sent

PreSendRequestContent Fired before buffered response body sent





Note The HTTP handler executes in between the PreRequestHandlerExecute and PostRequestHandlerExecute events.

The last two events are non-deterministic and could occur at any time (for example, as a result of a Response.Flush). All other events are sequential.

You do not need to implement an HTTP module simply in order to hook one of these events. You can also add event handlers to Global.asax. In addition to the events listed in Table 1 (which can all be hooked by individual HTTP module objects), the HttpApplication object fires Application_OnStart and Application_OnEnd handlers, which will be familiar to ASP developers. These can be handled only within Global.asax. Finally, you can also implement custom event handlers within Global.asax for events fired by individual HTTP module objects. For example, the session state module fires Session_OnStart and Session_OnEnd events.



Implementing a Custom HTTP Module

To create your own HTTP module and insert it into the ASP.NET processing pipeline



1.Create a class that implements IHttpModule.

2.Place the assembly that contains the module in your application's \bin subdirectory or you can install it into the Global Assembly Cache.

3.Add an <HttpModules> element to your application's web.config, as shown below. Copy Code <system.web>

<httpModules>

<add name="modulename"

type="namespace. classname, assemblyname" />

</httpModules>

</system.web>

Implementing a Custom HTTP Handler

You may need to implement a custom HTTP handler, for example to handle the processing of files with the .data file extension.



To implement a custom HTTP handler



1.Add a mapping to the IIS metabase to map the .data file extension to the ASP.NET ISAPI extension (Aspnet_isapi.dll).

Right-click your application's virtual directory in the IIS MMC snap-in, click the Configuration button, and then click Add to create a new mapping for .data files to C:\Winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll.



Note If you select the Check that file exists check box when adding the mapping, then the file must be physically present. This is usually what is wanted unless you have virtualized paths that don't map to a physical file. Virtualized paths ending with .rem or .soap are used by .NET Remoting.

2.Create a class that implements IHttpHandler (and optionally IHttpAsyncHandler if you want to handle requests asynchronously).

3.Place the assembly that contains the handler in your application's \bin subdirectory or you can install it into the Global Assembly Cache.

4.Add the handler to the processing pipeline by adding an <httpHandlers> section to your application's Web.config file. Copy Code <system.web>

<httpHandlers>

<add verb="*" path="*.data" type="namespace.classname, assemblyname" />

</httpHandlers>

</system.web>

Internet Information Server introduced the notion "Isolation Level", which is also present in IIS4 under a different name. IIS5 supports three isolation levels, that you can set from the Home Directory tab of the site's Properties dialog:

•Low (IIS Process): ASP pages run in INetInfo.Exe, the main IIS process, therefore they are executed in-process. This is the fastest setting, and is the default under IIS4. The problem is that if ASP crashes, IIS crashes as well and must be restarted (IIS5 has a reliable restart feature that automatically restarts a server when a fatal error occurs).

•Medium (Pooled): In this case ASP runs in a different process, which makes this setting more reliable: if ASP crashes IIS won't. All the ASP applications at the Medium isolation level share the same process, so you can have a web site running with just two processes (IIS and ASP process). IIS5 is the first Internet Information Server version that supports this setting, which is also the default setting when you create an IIS5 application. Note that an ASP application that runs at this level is run under COM+, so it's hosted in DLLHOST.EXE (and you can see this executable in the Task Manager).

•High (Isolated): Each ASP application runs out-process in its own process space, therefore if an ASP application crashes, neither IIS nor any other ASP application will be affected. The downside is that you consume more memory and resources if the server hosts many ASP applications. Both IIS4 and IIS5 supports this setting: under IIS4 this process runs inside MTS.EXE, while under IIS5 it runs inside DLLHOST.EXE.

When selecting an isolation level for your ASP application, keep in mind that out-process settings - that is, Medium and High - are less efficient then in-process (Low). However, out-process communication has been vastly improved under IIS5, and in fact IIS5's Medium isolation level often deliver better results than IIS4's Low isolation. In practice, you shouldn't set the Low isolation level for an IIS5 application unless you really need to serve hundreds pages per second.

Session State


ASP.NET provides the cross-request state information (shopping carts, data scrolling, and so on) infrastructure that Web applications require, with built-in session-state functionality that enables you to take the following actions:



Automatically identify and classify requests coming from a single browser client into a logical application session on the server.

Store session-scoped data on the server for use across multiple browser requests.

Raise appropriate session-lifetime management events (Session_OnStart, Session_OnEnd, and so on) that can be handled in application code.

Note The Session_OnEnd event is supported only the in-process session-state mode. This event is not raised if you use State Server or SQL Server modes.

Automatically release session data if the browser does not revisit an application within a specified time-out period.

This topic provides an overview of session state, describes how active ASP.NET sessions are identified and tracked, explains the session-state store and general structure, and concludes with a high-level code example.



Session State Overview

HTTP is a stateless protocol, which means that it does not automatically indicate whether a sequence of requests is all from the same client or even whether a single browser instance is still actively viewing a page or site. As a result, building Web applications that need to maintain some cross-request state information (shopping carts, data scrolling, and so on) can be extremely challenging without additional infrastructure help.



ASP.NET provides the following support for sessions:



A session-state facility that is easy to use, familiar to ASP developers, and consistent with other .NET Framework APIs.

A reliable session-state facility that can survive Internet Information Services (IIS) restarts and worker-process restarts without losing session data.

A scalable session-state facility that can be used in both Web farm (multicomputer) and Web garden (multiprocess) scenarios and that enables administrators to allocate more processors to a Web application to improve its scalability.

A session-state facility that works with browsers that do not support HTTP cookies.

A throughput equivalent to that of ASP (or better) for core session-state scenarios (50/50 read/write when putting items into shopping carts, modifying last page visited, validating credit card details, and so on).

Session state, however, does not persist across Web application boundaries. If a Web application switches to another application during execution, the session information is not available to the new application.



Identifying a Session

Each active ASP.NET session is identified and tracked using a 120-bit SessionID string containing only the ASCII characters that are allowed in URLs. SessionID values are generated using an algorithm that guarantees uniqueness so that sessions do not collide, and randomness so that a malicious user cannot use a new SessionID to calculate the SessionID of an existing session.



The SessionID strings are communicated across client-server requests either by means of an HTTP cookie or a modified URL with the SessionID string embedded, depending on how you configure the application settings.



Session-State Store

ASP.NET provides a simple and easy-to-use session-state model that you can use to store arbitrary data and objects across multiple Web requests. It accomplishes this using a dictionary-based, in-memory cache of object references that live within the IIS process. When using the in-process session-state mode consider the following limitations:



When using the in-process session-state mode, session-state data is lost if aspnet_wp.exe or the application domain restarts. These restarts commonly occur in the following circumstances:

Setting an attribute in the element of the application's Web.config file that causes a new process to start when a condition is met, such as memoryLimit.

The Global.asax or Web.config file is modified.

Changes to the \Bin directory of the Web application.

Antivirus software scans and modifies the Global.asax file, the Web.config file, or a file in the \Bin directory of the Web application.

If you enable Web garden mode in the element of the application's Web.config file, do not use in-process session-state mode. Otherwise, random data loss can occur.

Instead of keeping live objects, the .NET State Server simply stores session state in memory when in out-of-proc mode. In this mode the worker process talks directly to the State Server. In SQL mode, session states are stored in a SQL Server database and the worker process talks directly to SQL. The ASP.NET worker processes are then able to take advantage of this simple storage service by serializing and saving (using .NET serialization services) all objects within a client's Session collection at the end of each Web request. When the client revisits the server, the relevant ASP.NET worker process retrieves these objects from the State Server as binary streams, deserializes them into live instances, and places them back into a new Session collection object exposed to the request handler.



In SQL mode, session state can also be configured to work in a failover cluster. A failover cluster is two or more identical, redundant Web servers that store their session data on a separate computer in a SQL Server database. For information on how to set up this configuration, see Configuring SQL Server Mode.



By cleanly separating the storage of session data from the application's use of it, ASP.NET supports several powerful scenarios that were unavailable with earlier versions of ASP:



Recovery from application crashes, because the memory used for session state is not within the ASP.NET worker process.

Because all state is stored separately from an individual worker process, it is not lost if the process crashes due to an access violation or is forcibly restarted by the IIS Admin Service in the event of a deadlock or memory leak.



Partitioning an application across multiple worker processes.

Because all state is stored separately from worker processes, you can cleanly partition an application across multiple processes. Such partitioning can dramatically improve both the availability and the scalability of an application on multiple-process computers. Moreover, because it associates each worker process with a single computer, ASP.NET is able to eliminate cross-processor lock contention, one of the major scalability bottlenecks in earlier versions of ASP.



Partitioning an application across multiple Web farm computers.

Because all state is stored separately from worker processes, you can partition an application across multiple worker processes running on multiple computers. The model for communicating state between a worker process and a state service running on different computers is almost the same as that for processes and servers running on the same computer. In either case there can only be one State Server per Web farm.



Session State Structure

ASP.NET-based applications use an event-based execution organization to enable multiple .NET Framework class modules to participate in the processing of a single Web request.



The SessionState Module

The .NET Framework implements session state through the SessionStateModule class (derived from IHttpModule), which participates in the execution of each request received by a .NET-based application. The SessionStateModule is responsible for either generating or obtaining unique SessionID strings and for storing and retrieving state data from an external state provider.



Session State Collections

The SessionState class exposes two state collections: Contents and StaticObjects. The Contents collection exposes all variable items that have been added to the session-state collection directly through code. For example:



[Visual Basic] Copy Code ' Visual Basic code from within a page, a handler, or Global.asax.

Session("Message") = "MyMsg"

Session("AppStartTime") = Now

[C#]

// C# code from within a page, a handler, or Global.asax.

Session["Message"] = "MyMsg";

Session["AppStartTime"] = DateTime.Now;For compatibility with earlier versions of ASP, these values also can be accessed through a Contents property on the application object, as in the following example.



[Visual Basic] Copy Code ' Visual Basic code from within a page, a handler, or Global.asax.

Session.Contents("Message") = "MyMsg"

Session.Contents("AppStartTime") = Now

[C#]

// C# code from within a page, a handler, or Global.asax.

Session.Contents["Message"] = "MyMsg";

Session.Contents["AppStartTime"] = DateTime.Now;The StaticObjects collection exposes all variable items that have been added to the session-state collection through

ASP.NET runs within a process known as the ASP.NET worker process. All ASP.NET functionality runs within the scope of this process.

A regular Web server contains only a single ASP.NET worker process. This is different from both Web farms and Web gardens:

A Web farm contains multiple ASP.NET worker processes.
Each server in the group of servers handles a separate ASP.NET worker process.

A Web garden contains multiple ASP.NET worker processes.
Each CPU in the SMP server handles a separate ASP.NET worker process.

Choosing an ASP.NET worker process

When a Web client connects to a Web farm or Web garden, one of the multiple ASP.NET worker processes is selected to run the request.

In a Web farm, Network Load Balancing determines the ASP.NET worker process selected.
In a Web garden, the ASP.NET worker process selected is determined by ASP.NET.
State management with multiple ASP.NET worker processes

When moving from a scenario with a single ASP.NET worker process (a normal Web server) to a scenario with multiple ASP.NET worker processes (a Web farm or Web garden), complications with state management are introduced.

Web pages are stateless, so a Web server must persist state through other means. Typical means to manage state on the Web server include Session State and the ASP.NET Cache.

Note Issues of persistence and state (within a single Web server) are discussed in detail in the section Which Persistence Approach Should I Use with Crystal Reports?.
Both Session and Cache are contained within the memory space of a single ASP.NET worker process. But in a Web farm or Web garden, multiple ASP.NET worker processes work together simultaneously. The Session or Cache within any individual ASP.NET worker process cannot manage state across multiple processes.

Therefore, an additional layer is required for state management: an out-of-process Session State server that stores and retrieves state information for every ASP.NET worker process in the Web farm or Web garden.

A Web farm has multiple servers that are exposed to browser clients as a single virtual server, with one virtual Media Access Card and TCP/IP address.

Behind this virtual layer, each server in the Web farm receives every network packet, but only processes a subset of those packets. The ability to equally share the workload is what gives Web farms their superior processing power.

This distribution of packets is managed by Network Load Balancing. Network Load Balancing does the following:

It balances the client requests between servers.
It determines which server will process which request.
It ensures that server resource use and client wait times are optimized.
It provides a superior alternative to client affinity.
Note In a client affinity scenario, connecting clients are restricted to return to the same server each time.
Client affinity is usually turned off, because it can create a bottleneck of requests for a particular server.
Each server on a Web farm has a Network Load Balancing network device driver, which communicates with the other servers, and each server typically has two network cards. The second card allows internal communications for Network Load Balancing to be done over a separate, internal network.

The Network Load Balancing network device driver is provided in the following operating systems:

Windows 2000 Advanced Server.
Windows Advanced Server 2003.
Web garden architecture

A Web garden is like a Web farm, except that rather than use several server machines linked together, it uses single machine with multiple CPUs.

This single SMP (symmetric multiprocessing) server uses ASP.NET to run a separate ASP.NET worker process on each CPU. The server manages multiple client requests against the multiple CPUs on the server.

The answer is yes.

When creating a web project in Visual Studio .NET 2005, the bin folder gets exposed to TFS source control.

Normally, the bin folder is how the web project keeps track of the project references. When a project reference is added to the project, the .dll is copied to the bin directory.

In a source controlled environment, this copy is "noticed" by Visual Studio 2005 and exposed to the source control process. This means that you can check in all the .dlls added to the bin folder.



The Bin folder is not visible on the Source Control Window. So, when you checked in the .dll files, the files will be drop on the drop release folder.

I don't see why we need to put bin folder into our source control. It is not a wise idea bro. If you want to put your dll, let say external dll or third party library such as nhibernate.dll or P&P EntLib dlls, put it in another folder other than bin, obj, debug..etc..if you 're developing multitier apps or seperate your module into several projects, it is much easier because you can just Add Reference to you projects instead of refer to dll.
In our development team here, we organise all our tools, and libraries properly, put it into the right folder.Example: put all the externall dlls into a folder named 'Library'. When new developer join our team. they can just get latest the root folder, then he can compile the solution without any problem.

The functionality available through the use of abstract classes and of interfaces is quite similar. However, each has its pros and cons.

Contents [hide]
1 Inheritance
1.1 Single inheritance
1.2 Value type polymorphism
2 Separation of contract and implementation
3 Versioning
4 Design flexibility
5 Visual C# Best Practices
5.1 Use an abstract class
5.2 Use an interface
6 Summary
7 See also

Inheritance
A C# class may only subclass—inherit from—one other class. Therefore, by inheriting from (subclassing) an abstract class, the derived class has used up its ability to participate in a meaningful type hierarchy.

On the other hand, a class can implement—inherit from—any number of interfaces. And, it can still inherit from (subclass) a base class which makes sense.

Single inheritance
C# supports single inheritance: C# does not support multiple inheritance from multiple classes like C++ does. But, by using abstract classes and interfaces, C# programs can achieve most of the same functionality without the confusion and maintenance problems associated with multiple inheritance.

Value type polymorphism
.NET value types are objects descending from Object; but, they cannot inherit from other types. They can implement interfaces. Thus, primitives—such as Int32— can implement the IComparable interface, for example, making them comparable.

Separation of contract and implementation
Interfaces separate the syntax rather than the semantic contract from the implementation. Classes can be designed to decouple the semantic contract from the implementation. For example, abstract classes can be separated in a different assembly than their concrete implementations.

Versioning
An abstract class can contain an interface plus implementations. This simplifies versioning. An abstract class can be extended by adding new nonabstract methods with default implementations. Also, a convenience method is easily added to an abstract class.

An interface cannot be modified without breaking its contract with the classes which implement it. Once an interface has been shipped, its member set is permanently fixed. An API based on interfaces can only be extended by adding new interfaces.

Design flexibility
Interfaces offer more design flexibility; precisely because, they can be implemented by any class regardless of its type hierarchy.

Visual C# Best Practices
Use abstract classes and interfaces in combination to optimize your design trade-offs.
Use an abstract class
When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. (COM was designed around interfaces.)
Use an abstract class to define a common base class for a family of types.
Use an abstract class to provide default behavior.
Subclass only a base class in a hierarchy to which the class logically belongs.
Use an interface
When creating a standalone project which can be changed at will, use an interface in preference to an abstract class; because, it offers more design flexibility.
Use interfaces to introduce polymorphic behavior without subclassing and to model multiple inheritance—allowing a specific type to support numerous behaviors.
Use an interface to design a polymorphic hierarchy for value types.
Use an interface when an immutable contract is really intended.
A well-designed interface defines a very specific range of functionality. Split up interfaces that contain unrelated functionality.
Summary
The following table compares the features of abstract classes and interfaces.

Abstract class Interface
Derived classes exhaust their single base class inheritance option. Classes can implement multiple interfaces without using up their base class option. But, there are no default implementations.
Cannot be instantiated except as part of subclasses. Only derived classes can call an abstract class constructor. Cannot be instantiated.
Defines abstract member signatures which derived classes must implement. Otherwise, the derived class itself will be abstract. Defines abstract member signatures—all of which—implementing classes must implement. Otherwise, a compiler error results.
New non-abstract members may be added that derived classes will inherit without breaking version compatibility. Extending an interface with new members breaks version compatibility.
Optionally, provide default (virtual) member implementation. All members are virtual and cannot provide implementations.
Can include data fields. Cannot include data fields. However, abstract properties may be declared.