NET Remoting
Microsoft's .NET framework provides a way for a client in one application domain to access objects in another application domain; this is made possible through .NET Remoting.
.NET Remoting is a very flexible technology that allows clients and servers to communicate with each other, no matter where they are located. The client and server can be on the same machine, on different machines on the same network, or in different countries across the world. .NET Remoting makes life easy by providing services and infrastructure components that hide all the complexities from application developers.
.NET Remoting allows us to use different protocols, different serialization formats, configuration settings, etc. .NET Remoting even allows programmers to create and install their own "hooks" in the .NET Remoting pipeline in order to customize the default behavior of the remoting framework (Tracking Services is an example of such a hook)
So how does .NET Remoting work? Well, some of the concepts behind .NET Remoting are borrowed from the old distributed technologies, such as DCOM, CORBA, etc. First of all, always remember that in .NET Remoting, objects are exposed to the outside world through some "Listener" process; that listener process could be a console application, a WinForm application, a Windows service, or even IIS. The listener process specifies the objects that are exposed programmatically or by using the .config file. Once that part is done, client applications connect to the listener process for object creation requests and the listener process then creates and returns the objects back to the client. All communication between client and server application domains is performed by sending and receiving encoded streams of data over some channel.
Channels
The basic purpose of channels is to transport data from one end point to another; .NET comes with two built-in channels, HTTP channel (System.Runtime.Remoting.Channels.Http) and TCP channel (System.Runtime.Remoting.Channels.Tcp).
TCP channel is faster than HTTP channel, and it is good for binary data; whereas HTTP channel is very good when it comes to firewalls and the Internet. You are not limited to these channels; you can create your own custom channels and plug them into .NET Remoting.
Formatters
Formatters, as the name implies, format data or messages for delivery. Once data/message has been formatted, it is transported to other application domains by using the appropriate channel. .NET comes with two built-in formatters, Soap formatter (System.Runtime.Serialization.Formatters.Soap) and Binary formatter (System.Runtime.Serialization.Formatters.Binary).
Soap formatter formats message in Soap 1.1 specification, whereas Binary formatter formats message in pure binary form.
Types of Remoting Objects
There are two types of objects supported by .NET Remoting: server-activated objects (also known as well-known objects) and client-activated objects.
Server-activated objects
Server-activated objects, as the name implies, are created by the server and their lifetime is also managed by the server. The point to catch here is that these objects are not created when a client calls New or Activator.GetObject; rather, the actual instance of the object is created when the client actually invokes a method on proxy.
There is one implication to the above mentioned behavior. Since the object is not created at the time the client calls the New or Activator.GetObject method, we cannot use non-default constructors with server-activated objects. Only default constructors (constructors with no parameters) are supported for such objects.
There are two modes in which server-activated objects can be activated:
- Singleton
Only one object will be created on the server to fulfill the requests of all the clients; that means the object is shared, and the state will be shared by all the clients. - SingleCall
Such objects are created on each method call and objects are not shared among clients. State should not be maintained in such objects because such objects are destroyed after each method call.
Client-activated objects
Client-activated objects are created by the server and their lifetime is managed by the client. In contrast to server-activated objects, client-activated objects are created as soon as the client calls New or any other object creation method; therefore, we can use both the default and non-default constructors with client-activated objects. Client-activated objects are specific to the client, and objects are not shared among different clients; object instance exists until the lease expires or the client destroys the object.
Configuration
Like other .NET technologies, .NET Remoting also needs some configuration information in order to work. We can configure our remoting application either programmatically or by using a .config file. For this article, we will discuss .config files.
.NET Remoting configuration settings are packed in the <application> tag in the following XML format:
In order to expose server-activated objects, we use the <service> tag, as shown in the example below:
objectUri="Customer"/> The above configuration specifies that we are exposing a SingleCall object whose complete type name is MyObjects.Customer. The class is contained in the MyObjects.DLL assembly; the object's URI is Customer, and the object is accessible through TCP channel on port 1234.
Each server-activated object will have its own <wellknown> tag.
The corresponding client-side .config file would be as follows:
url="tcp://localhost:1234/Customer"/> The client-side configuration file is slightly different from the server configuration file. We are using the <client> tag instead of the <service> tag; similarly we are using the url attribute in the <wellknown> tag on the client-side to specify the exact location of the server object.
For client-activated objects, we use the <activated> tag (both on sever and the client), instead of the <wellknown> tag. Following example shows how to expose a client-activated object.
The corresponding client-side configuration file would look as follows:
· What’s a Windows process?
It’s an application that’s running and had been allocated memory.
· What’s typical about a Windows process in regards to memory allocation?
Each process is allocated its own block of available RAM space, no process can access another process’ code or data. If the process crashes, it dies alone without taking the entire OS or a bunch of other applications down.
· Explain what relationship is between a Process, Application Domain, and Application?
A process is an instance of a running application. An application is an executable on the hard drive or network. There can be numerous processes launched of the same application (5 copies of Word running), but 1 process can run just 1 application.
· What are possible implementations of distributed applications in .NET?
.NET Remoting and ASP.NET Web Services. If we talk about the Framework Class Library, noteworthy classes are in System.Runtime.Remoting and System.Web.Services.
· What are the consideration in deciding to use .NET Remoting or ASP.NET Web Services?
Remoting is a more efficient communication exchange when you can control both ends of the application involved in the communication process. Web Services provide an open-protocol-based exchange of informaion. Web Services are best when you need to communicate with an external organization or another (non-.NET) technology.
· What’s a proxy of the server object in .NET Remoting?
It’s a fake copy of the server object that resides on the client side and behaves as if it was the server. It handles the communication between real server object and the client object. This process is also known as marshaling.
· What are remotable objects in .NET Remoting?
Remotable objects are the objects that can be marshaled across the application domains. You can marshal by value, where a deep copy of the object is created and then passed to the receiver. You can also marshal by reference, where just a reference to an existing object is passed.
· What are channels in .NET Remoting?
Channels represent the objects that transfer the other serialized objects from one application domain to another and from one computer to another, as well as one process to another on the same box. A channel must exist before an object can be transferred.
· What security measures exist for .NET Remoting in System.Runtime.Remoting?
None. Security should be taken care of at the application level. Cryptography and other security techniques can be applied at application or server level.
· What is a formatter?
A formatter is an object that is responsible for encoding and serializing data into messages on one end, and deserializing and decoding messages into data on the other end.
· Choosing between HTTP and TCP for protocols and Binary and SOAP for formatters, what are the trade-offs?
Binary over TCP is the most effiecient, SOAP over HTTP is the most interoperable.
· What’s SingleCall activation mode used for?
If the server object is instantiated for responding to just one single request, the request should be made in SingleCall mode.
· What’s Singleton activation mode?
A single object is instantiated regardless of the number of clients accessing it. Lifetime of this object is determined by lifetime lease.
· How do you define the lease of the object?
By implementing ILease interface when writing the class code.
· Can you configure a .NET Remoting object via XML file?
Yes, via machine.config and application level .config file (or web.config in ASP.NET). Application-level XML settings take precedence over machine.config.
· How can you automatically generate interface for the remotable object in .NET with Microsoft tools?
Use the Soapsuds tool.
State Management in ASP.Net
Web Pages developed in ASP.Net are HTTP based and HTTP protocol is a stateless protocol. It means that web server does not have any idea about the requests from where they coming i.e from same client or new clients. On each request web pages are created and destroyed.
So, how do we make web pages in ASP.Net which will remember about the user, would be able to distinguish b/w old clients(requests) and new clients(requests) and users previous filled information while navigating to other web pages in web site?
Solution of the above problem lies in State Management.
ASP.Net technology offers following state management techniques.
Client side State Management
o Cookies
o Hidden Fields
o View State
o Query String
Server side State Management
o Session State
o Application State
These state management techniques can be understood and by following simple examples and illustrations of the each techniques.
Client Side State Management
Cookies
A cookie is a small amount of data which is either stored at client side in text file or in memory of the client browser session. Cookies are always sent with the request to the web server and information can be retrieved from the cookies at the web server. In ASP.Net, HttpRequest object contains cookies collection which is nothing but list of HttpCookie objects. Cookies are generally used for tracking the user/request in ASP.Net for example, ASP.Net internally uses cookie to store session identifier to know whether request is coming from same client or not. We can also store some information like user identifier (UserName/Nick Name etc) in the cookies and retrieve them when any request is made to the web server as described in following example. It should be noted that cookies are generally used for storing only small amount of data(i.e 1-10 KB).
Code Sample
//Storing value in cookie
HttpCookie cookie = new HttpCookie("NickName");
cookie.Value = "David";
Request.Cookies.Add(cookie);
//Retrieving value in cookie
if (Request.Cookies.Count > 0 && Request.Cookies["NickName"] != null)
lblNickName.Text = "Welcome" + Request.Cookies["NickName"].ToString();
else
lblNickName.Text = "Welcome Guest";
Cookies can be permanent in nature or temporary. ASP.Net internally stores temporary cookie at the client side for storing session identifier. By default cookies are temporary and permanent cookie can be placed by setting "Expires" property of the cookie object.
Hidden Fields
A Hidden control is the control which does not render anything on the web page at client browser but can be used to store some information on the web page which can be used on the page.
HTML input control offers hidden type of control by specifying type as "hidden". Hidden control behaves like a normal control except that it is not rendered on the page. Its properties can be specified in a similar manner as you specify properties for other controls. This control will be posted to server in HttpControl collection whenever web form/page is posted to server. Any page specific information can be stored in the hidden field by specifying value property of the control.
ASP.Net provides HtmlInputControl that offers hidden field functionality.
Code Sample
//Declaring a hidden variable
protected HtmlInputHidden hidNickName;
//Populating hidden variable
hidNickName.Value = "Page No 1";
//Retrieving value stored in hidden field.
string str = hidNickName.Value;
Note:Critical information should not be stored in hidden fields.
View State/Control State
ASP.Net technology provides View State/Control State feature to the web forms. View State is used to remember controls state when page is posted back to server. ASP.Net stores view state on client site in hidden field __ViewState in encrypted form. When page is created on web sever this hidden control is populate with state of the controls and when page is posted back to server this information is retrieved and assigned to controls. You can look at this field by looking at the source of the page (i.e by right clicking on page and selecting view source option.)
You do not need to worry about this as this is automatically handled by ASP.Net. You can enable and disable view state behaviour of page and its control by specifying 'enableViewState' property to true and false. You can also store custom information in the view state as described in following code sample. This information can be used in round trips to the web server.
Code Sample
//To Save Information in View State
ViewState.Add ("NickName", "David");
//Retrieving View state
String strNickName = ViewState ["NickName"];
Query String
Query string is the limited way to pass information to the web server while navigating from one page to another page. This information is passed in url of the request. Following is an example of retrieving information from the query strings.
Code Sample
//Retrieving values from query string
String nickname;
//Retrieving from query string
nickName = Request.Param["NickName"].ToString();
But remember that many browsers impose a limit of 255 characters in query strings. You need to use HTTP-Get method to post a page to server otherwise query string values will not be available.
Server Side State Management
Session State
Session state is used to store and retrieve information about the user as user navigates from one page to another page in ASP.Net web application. Session state is maintained per user basis in ASPNet runtime. It can be of two types in-memory and out of memory. In most of the cases small web applications in-memory session state is used. Out of process session state management technique is used for the high traffic web applications or large applications. It can be configured with some configuration settings in web.conig file to store state information in ASPNetState.exe (windows service exposed in .Net or on SQL server.
In-memory Session state can be used in following manner
Code Sample
//Storing informaton in session state
Session["NickName"] = "Ambuj";
//Retrieving information from session state
string str = Session["NickName"];
Session state is being maintained automatically by ASP.Net. A new session is started when a new user sents first request to the server. At that time session state is created and user can use it to store information and retrieve it while navigating to different web pages in ASP.Net web application.
ASP.Net maintains session information using the session identifier which is being transacted b/w user machine and web server on each and every request either using cookies or querystring (if cookieless session is used in web application).
Application State
Application State is used to store information which is shared among users of the ASP.Net web application. Application state is stored in the memory of the windows process which is processing user requests on the web server. Application state is useful in storing small amount of often-used data. If application state is used for such data instead of frequent trips to database, then it increases the response time/performance of the web application.
In ASP.Net, application state is an instance of HttpApplicationState class and it exposes key-value pairs to store information. Its instance is automatically created when a first request is made to web application by any user and same state object is being shared across all subsequent users.
Application state can be used in similar manner as session state but it should be noted that many user might be accessing application state simultaneously so any call to application state object needs to be thread safe. This can be easily achieved in ASP.Net by using lock keyword on the statements which are accessing application state object. This lock keyword places a mutually exclusive lock on the statements and only allows a single thread to access the application state at a time. Following is an example of using application state in an application.
Code Sample
//Stroing information in application state
lock (this)
{
Application["NickName"] = "David";
}
//Retrieving value from application state
lock (this)
{
string str = Application["NickName"].ToString();
}
Using ASP.NET Session State
Session state settings in ASP.NET are configured through the ASP.NET XML configuration file config.web. We'll look at config.web in more detail in a later column, but for this discussion of session state let's look at it briefly.
Config.web
There are two types of configuration files: a machine configuration file and an application configuration file, both named config.web. The two are identical, except that the machine configuration file applies settings to all applications but the application configuration files are either restrictive or expansive on an application-by-application basis.
In Beta 1, the machine config.web file is in the WinNT\Microsoft.NET\Framework\v1.0.2204 directory, while the optional application configuration files exist in the application's directory. Application config.web files are optional in the sense that if an application config.web file doesn't exist, the machine config.web settings are used instead. ASP.NET session state settings can be made in the machine config.web file and overridden in a particular application's config.web file.
Note: Changes made to config.web are applied immediately, unlike classic ASP, where the server has to be stopped and started for settings to take affect.
Session configuration
Below is a sample config.web file used to configure the session state settings for an ASP.NET application:
|
The settings above are used to configure ASP.NET session state. Let's look at each in more detail and cover the various uses afterward.
- Mode. The mode setting supports three options: inproc, sqlserver, and stateserver. As stated earlier, ASP.NET supports two modes: in process and out of process. There are also two options for out-of-process state management: memory based (stateserver), and SQL Server based (sqlserver). We'll discuss implementing these options shortly.
- Cookieless. The cookieless option for ASP.NET is configured with this simple Boolean setting.
- Timeout. This option controls the length of time a session is considered valid. The session timeout is a sliding value; on each request the timeout period is set to the current time plus the timeout value
- Sqlconnectionstring. The sqlconnectionstring identifies the database connection string that names the database used for mode sqlserver.
- Server. In the out-of-process mode stateserver, it names the server that is running the required Windows NT service: ASPState.
- Port. The port setting, which accompanies the server setting, identifies the port number that corresponds to the server setting for mode stateserver.
Sample session state application
Before we use session state, we need an application to test it with. Below is the code for a simple Visual Basic® application that writes to and reads from session state, SessionState.aspx:
|
This simple page wires up two server-side events for the Add and View buttons, and simply sets the session state to the value in the text box.
There are four general configuration settings we can look at in more detail: in-process mode, out-of-process mode, SQL Server mode, and Cookieless.
In-process Mode
In-process mode simply means using ASP.NET session state in a similar manner to classic ASP session state. That is, session state is managed in process and if the process is re-cycled, state is lost. Given the new settings that ASP.NET provides, you might wonder why you would ever use this mode. The reasoning is quite simple: performance. The performance of session state, e.g. the time it takes to read from and write to the session state dictionary, will be much faster when the memory read to and from is in process, as cross-process calls add overhead when data is marshaled back and forth or possibly read from SQL Server.
In-process mode is the default setting for ASP.NET. When this setting is used, the only other session config.web settings used are cookieless and timeout.
If we call SessionState.aspx, set a session state value, and stop and start the ASP.NET process (iisreset), the value set before the process was cycled will be lost.
Out-of-process Mode
Included with the .NET SDK is a Windows® NT service: ASPState. This Windows service is what ASP.NET uses for out-of-process session state management. To use this state manager, you first need to start the service. To start the service, open a command prompt and type:
net start aspstate |
What you'll see is:
Figure 1. Starting the Windows NT service ASPState at the command prompt
At this point, the Windows NT Service ASPState has started and is available to ASP.NET. Next, we need to configure ASP.NET to take advantage of this service. To do this we need to configure config.web:
|
We changed only from inproc mode to stateserver mode. This setting tells ASP.NET to look for the ASP state service on the server specified in the server and port settings—in this case, the local server.
We can now call SessionState.aspx, set a session state value, stop and start the IIS process (iisreset), and continue to have access to the values for our current state.
SQL Server Mode
The SQL Server mode option is similar to that of the Windows NT Service, except that the information persists to SQL Server rather than being stored in memory.
To use SQL Server as our session state store, we first must create the necessary tables and stored procedures that ASP.NET will look for on the identified SQL Server. The .NET SDK provides us with a SQL script (state.sql) to do just that.
state.sql
The state.sql file contains the SQL commands used to create the ASPState database. This script creates two tables and several stored procedures. ASP.NET uses both the tables and the procedures to store data in SQL Server. I would recommend reading through state.sql to learn more about what it is doing.
The state.sql file can be found in [system drive]\winnt\Microsoft.NET\Framework\[version]\
Applying the state.sql script
To apply the state.sql script, use the command line tool SQL Server provides: osql.exe. Using an sa equivalent SQL user, the syntax below is used:
osql –S [server name] –U [user] –P [password] |
Note: A lightweight version of SQL Server is installed when the .NET SDK is installed.
Here's what you should see:
Figure 2. Using the SQL Server command line tool to apply state.sql script
After running osql, start and stop SQL Server; part of what state.sql added were some start-up stored procedures that need to be run. Next, modify the configuration settings to set the mode to sqlserver and modify the sqlconnectionstring to identify the appropriate SQL Server serving the ASPState database. For example:
|
Again, similar to the Windows NT service state manager, we can now call SessionState.aspx, set a session state value, stop and start the IIS process (iisreset), and continue to have access to the values for our current state. In fact, we could cluster the SQL Servers such that if one SQL Server happened to be unavailable, another server that was replicating its data could take its place. This provides a level of reliability that was not available in ASP.
Cookieless State
The last new feature that we can configure for ASP.NET session state is cookieless session state. Essentially this feature allows sites whose clients choose not to use cookies to take advantage of ASP.NET session state.
This is done by modifying the URL with an ID that uniquely identifies the session:
http://localhost/(lit3py55t21z5v55vlm25s55)/Application/SessionState.aspx |
ASP.NET will modify relative links found within the page and embed this ID. Thus, as long as the user follows the path of links the site provides, session state can be maintained. However, if the end user re-writes the URL, the session state instance will most likely be lost.
The IIS 4.0 Resource Kit provided a similar feature. It was implemented as an ISAPI filter that could modify the incoming and outgoing byte stream to write and read the necessary information. The difference between this and the ASP.NET feature is the effort required to use the feature. In ASP.NET, it's simply a matter of flipping a Boolean value in the config.web file:
|
Once cookieless is set to true, ASP.NET will do the work necessary to enable cookieless session state. Also note that all modes are supported for cookieless sessions.
Performance and Reliability Considerations
It's worth mentioning, briefly, some of the performance and reliability issues you should consider when using ASP.NET session state modes.
- In process. In process will perform best because the session state memory is kept within the ASP.NET process. For Web applications hosted on a single server, applications in which the user is guaranteed to be re-directed to the correct server, or when session state data is not critical (in the sense that it can be re-constructed or re-populated), this is the mode to choose.
- Out of process. This mode is best used when performance is important but you can't guarantee which server a user will request an application from. With out-of-process mode, you get the performance of reading from memory and the reliability of a separate process that manages the state for all servers.
- SQL Server. This mode is best used when the reliability of the data is fundamental to the stability of the application, as the database can be clustered for failure scenarios. The performance isn't as fast as out of process, but the tradeoff is the higher level of reliability.
Improvements in ASP.NET 2.0
ASP.NET 2.0 was designed to make web development easier and quicker.
Design goals for ASP.NET 2.0:
- Increase productivity by removing 70% of the code
- Use the same controls for all types of devices
- Provide a faster and better web server platform
- Simplify compilation and installation
- Simplify the administration of web applications
What's New in ASP.NET 2.0?
Some of the new features in ASP.NET 2.0 are:
- Master Pages, Themes, and Web Parts
- Standard controls for navigation
- Standard controls for security
- Roles, personalization, and internationalization services
- Improved and simplified data access controls
- Full support for XML standards like, XHTML, XML, and WSDL
- Improved compilation and deployment (installation)
- Improved site management
- New and improved development tools
The new features are described below.
Master Pages
ASP.NET didn't have a method for applying a consistent look and feel for a whole web site.
Master pages in ASP.NET 2.0 solves this problem.
A master page is a template for other pages, with shared layout and functionality. The master page defines placeholders for content pages. The result page is a combination (merge) of the master page and the content page.
Themes
Themes is another feature of ASP.NET 2.0. Themes, or skins, allow developers to create a customized look for web applications.
Design goals for ASP.NET 2.0 themes:
- Make it simple to customize the appearance of a site
- Allow themes to be applied to controls, pages, and entire sites
- Allow all visual elements to be customized
Web Parts
ASP.NET 2.0 Web Parts can provide a consistent look for a site, while still allowing user customization of style and content.
New controls:
- Zone controls - areas on a page where the content is consistent
- Web part controls - content areas for each zone
Navigation
ASP.NET 2.0 has built-in navigation controls like
- Site Maps
- Dynamic HTML menus
- Tree Views
Security
Security is very important for protecting confidential and personal information.
In ASP.NET 2.0 the following controls has been added:
- A Login control, which provides login functionality
- A LoginStatus control, to control the login status
- A LoginName control to display the current user name
- A LoginView control, to provide different views depending on login status
- A CreateUser wizard, to allow creation of user accounts
- A PasswordRecovery control, to provide the "I forgot my password" functionality
Roles and Personalization
Internet communities are growing very popular.
ASP.NET 2.0 has personalization features for storing user details. This provides an easy way to customize user (and user group) properties.
Internationalization
Reaching people with different languages is important if you want to reach a larger audience.
ASP.NET 2.0 has improved support for multiple languages.
Data Access
Many web sites are data driven, using databases or XML files as data sources.
With ASP.NET this involved code, and often the same code had to be used over and over in different web pages.
A key goal of ASP.NET 2.0 was to ease the use of data sources.
ASP.NET 2.0 has new data controls, removing much of the need for programming and in-depth knowledge of data connections.
Mobility Support
The problem with Mobile devices is screen size and display capabilities.
In ASP.NET, the Microsoft Mobile Internet Toolkit (MMIT) provided this support.
In ASP.NET 2.0, MMIT is no longer needed because mobile support is built into all controls.
Images
ASP.NET 2.0 has new controls for handling images:
- The ImageMap control - image map support
- The DynamicImage control - image support for different browsers
These controls are important for better image display on mobile devices, like hand-held computers and cell phones.
Automatic Compilation
ASP.NET 2.0 provides automatic compilation. All files within a directory will be compiled on the first run, including support for WSDL, and XSD files.
Compiled Deployment (Installation) and Source Protection
ASP.NET 2.0 also provides pre-compilation. An entire web site can be pre-compiled. This provides an easy way to deploy (upload to a server) compiled applications, and because only compiled files are deployed, the source code is protected.
Site Management
ASP.NET 2.0 has three new features for web site configuration and management:
- New local management console
- New programmable management functions (API)
- New web-based management tool
Development Tools
With ASP.NET Visual Studio.NET was released with project and design features targeted at corporate developers.
With ASP.NET 2.0, Visual Studio 2005 was released.
Key design features for Visual Studio 2005 include:
- Support for the features described above
- Upload files from anywhere (FTP, File System, Front Page....)
- No project files, allowing code to be manipulated outside Visual Studio
- Integrated Web Site Administration Tool
- No "build" step - ability to compile on first run
All non-static pages and applications (static: "HTML only" pages, images, etc.) are
interpreted and executed by the server. Application pools (AppPools) were
introduced in IIS 6 as a way of keeping the effects from the code executed by
different virtual servers as encapsulated as possible.
Each application pool gets it own worker process on the system. By doing this, each
application in a pool will never have an effect on applications in other pools. If
an application causes a process to crash, for example, this only affects the pool
in which it is in. The Web server and other pools continue to run normally.
Resources such as memory (RAM), CPU load and required CPU time can be limited
separately for each application pool. Pools that generate too many errors within a
specific time frame can be disabled automatically.
Application pools can be restarted automatically (recycling), e.g. every night or
if certain resources are exceeded. Note however, that all information on the
current sessions (session variables) will be lost.
You can create as many application pools as you want. The number is limited only by
the resources on the server. Note however, that each running pool consumes system
resources for process management (overhead). Your system easily supports around 25
application pools without noticeable performance loss. The exact number depends on:
1. Your server's memory and CPU load
2. The number and type of applications in the pools
3. The number of requests for these applications
4. The resource needs of other applications/programmes running on the server
Applications can be assigned to a specific pool in their properties. You can assign
an application pool at the bottom of the "Home Directory" tab (or a "directory" if
it is a lower-level application). New pools can be created by right-clicking
on "Application Pools".
Because each pool is assigned an identity (user), all applications in the pool run
using these permissions. Applications running in a pool as Administrator (not
recommended!) would then have administrative rights, can read related files, power
down the server, etc. Use the "Network Service" identity or a custom user to
restrict access.
In this part, we will take a look at one of the new features in IIS 6.0, named Application Pool, and demonstrate the use of application pools in isolating ASP.NET Web applications, thereby increasing the reliability of your ASP.NET Web applications. Then, we also will explore how these application pools affect ASP.NET applications in terms of the identity that is used to run your ASP.NET applications. Along the way, we will also look at the steps to be followed for creating application pools and assigning ASP.NET applications to run under a specific application pool. Finally, we will illustrate how to configure an application pool to run using the credentials of a specific user account.
What is an Application Pool?
An Application Pool can contain one or more applications and allows us to configure a level of isolation between different Web applications. For example, if you want to isolate all the Web applications running in the same computer, you can do this by creating a separate application pool for every Web application and placing them in their corresponding application pool. Because each application pool runs in its own worker process, errors in one application pool will not affect the applications running in other application pools. Deploying applications in application pools is a primary advantage of running IIS 6.0 in worker process isolation mode because you can customize the application pools to achieve the degree of application isolation that you need.
When you configure application pools for optimum availability, you also should consider how to configure application pools for application security. For example, you might need to create separate application pools for applications that require a high level of security, while allowing applications that require a lower level of security to share the same application pool. In the later part of this article, we will see how to configure identities at the application pool level.
Creating a new Application Pool
Creating a new application pool is a very simple process that is carried out by using the IIS manager. When you create a new application pool, you have the following two options:
- You can either create a new application pool from scratch or
- You can create a new application by importing the configuration settings from an external XML file
To create a new application pool from scratch, right-click on the Application Pools node from the tree view and select New->Application Pool from the context menu. You will be presented with the following screen, where you need to enter a name for the application pool.
When creating a new application, you also have the option of inheriting the settings from an existing application pool. For example, if you want your new application pool to inherit the settings from the DefaultAppPool, you can do that by selecting the option Use existing application pool as a template in the above screen. After you pick this option, the Application Pool name dropdown box will be enabled from where you can select an existing application pool.
After the pool is created, you can save the settings of the application pool to an external XML file any time by right-clicking the application pool and selecting the option All Tasks->Save Configuration to a File that is available from the context menu. This is an extremely useful feature that makes it possible for you to easily recreate the same application pool on the same server or on a different server with minimal effort.
Configuring Identity for ASP.NET Web Applications
In previous versions of IIS, worker processes ran as LocalSystem, a powerful account that has system administrator privileges on the server. Because LocalSystem has access to almost all resources on the operating system, this caused security implications. As mentioned previously, in IIS 6.0, you can set the identity of the worker process at the application pool level. The identity of an application pool is the account under which the application pool's worker process runs. By default, application pools operate under the NetworkService account, which has low-level user access rights. The NetworkService account has the following seven privileges:
- Adjust memory quotas for a process
- Generate security audits
- Log on as a service
- Replace process level token
- Impersonate a client after authentication
- Allow logon locally
- Access this computer from the network
By running the worker process using a very low-privileged account such as NetworkService, you can reduce the security vulnerability. However, by using IIS manager, you can configure the application pool to run as any of the following pre-defined accounts:
- NetworkService
- LocalSystem
- LocalService
To configure identity for an application pool, right-click the application pool and select Properties from the context menu. In the Properties dialog box, select the Identity tab and you will see the following screen.
In the above dialog box, when you select the Predefined option, you can select any of the pre-defined accounts from the dropdown box. Instead of using a pre-defined account, if you want your application pool to run under a different account, select the Configurable option and then set the User name and Password in the textboxes. This approach is particularly useful especially when you are running multiple applications or sites on one Web server. For example, if an ISP hosts two companies—who may even be competitors—on one Web server, it has to guarantee that these two applications run in isolation from each other. More importantly, the ISP has to make sure that a malicious administrator for one application can't access the data of the other application. You can accomplish this level of isolation by using the configurable worker process identity.
· Each computer on which the common language runtime is installed has a machine-wide code cache called the 'Global Assembly Cache'. The global assembly cache (or GAC as it is commonly known) stores assemblies specifically designated to be shared by several applications on the computer. The global assembly cache is located in 'Windows/WinNT' directory and inherits the directory's access control list that administrators have used to protect the folder.
Assemblies installed in GAC should adhere to a specific versioning scheme that will allow them for side-by-side execution (multiple versions of the same assembly can be maintained in the GAC) of different code versions.
Shared Assemblies including all the important .NET System assemblies implementing the Framework Class Library reside within GAC. The GAC was originally called Fusion Cache and is implemented using Fusion.dll in .NET Framework.
Assemblies placed in the GAC must have the same assembly name and file name (not including the file name extension). For example, an assembly with the assembly name of 'myAssembly' must have a file name of either 'myAssembly.exe' or 'myAssembly.dll'.
· Scenarios for installing Assemblies in GAC
There are multiple reasons why an assembly should be installed in GAC:
- File Security:
Administrators usually protect the 'Windows/WinNT' directory using an access control list (ACL) to control access. Because the GAC is located in 'Windows/WinNT' folder, this means that the GAC folder inherits the access rights from the 'Windows/WinNT' folder, and only administrators can modify the contents of the GAC. This will ensure that assemblies that are installed in GAC are not being accidentally removed/modified by in-experienced users.
- Shared Location:
GAC acts as a common place for installing assemblies that are shared by multiple applications on the same machine. A common misconception is that in order to make the .NET assemblies available to COM InterOp or to the unmanaged code, the assemblies should be installed in GAC. However, this does not mandate installing assemblies in the GAC. Only those assemblies that are shared with other applications on the same machine should be installed in GAC.
- Side-by-Side versioning:
Side-by-side execution means having the ability to install and use multiple versions of the same assembly. In simple words side-by-side versioning means having the same assembly present with multiple versions but with the same name. GAC can contain multiple copies of the same assembly with different versions, which allows a robust support for versioning in the Common Language Runtime.
- As an additional search location:
When an assembly needs to be loaded by the Common Language Runtime, the CLR first checks the GAC for the assembly.
· Pre-Requisites for installing an assembly in GAC
To install an assembly in GAC, the assembly must be signed with a strong name.
Quote:
| Originally Posted by .NET Framework Documentation
|
In order to help assemblies to sign with a string name, one can use the Strong Name Tool. Further information can also be found in the following article.
· Installing/uninstalling an assembly in GAC
There are multiple ways of installing an assembly in GAC:
- Using Windows Installer:
This is a preferred way for installing shared assemblies and should be the only way to install the shared assemblies on production systems (or non-development machines).
- Global Assembly Cache Tool:
The Global Assembly Cache Utility Tool can be used to install or uninstall assemblies in GAC. It also allows us to view or manipulate the contents of the GAC. The common syntax of 'GACUTIL.exe' is:
Code:
gacutil [options] [assemblyName | assemblyPath | assemblyListFile]
To install a strong named assembly from the command prompt in the GAC use:
Code:
gacutil /i myAssembly.dll
To uninstall a strong named assembly from the command prompt in the GAC use:
Code:
gacutil /u myAssembly.dll
To view the contents of the GAC we can use:
Code:
gacutil /l
To check if an assembly ('myAssembly.dll') is already present in the GAC:
Code:
gacutil /l myAssembly.dll
- Other ways:
There are other ways also to install/uninstall the assemblies to/from GAC and to view the contents. Following links will give some insight on these tools:
Advantages of using GAC are:
Strong name signature verification: All shared assemblies must have strong name signatures. These signature are verified when the assembly is installed into the gac. Once verified the signatures are not verified each time the assembly is referenced. In contrast, shared assemblies deployed outside the assembly have their signatures verified each time the assembly is loaded.
- Performance:CLR to look into the GAC first when resolving an Assembly reference. If it doesn't find the requested assembly in the GAC then it looks in the application directory and follows the rest of the probing logic algorithm. Clearly there is a performance gain by putting the assembly in the first place to be searched.
- Deploying bug fixes:Administrators can use the gac to deploy bug fixes intended to be picked up by all applications. By deploying the fix to the gac and stating the appropriate version policy in the machine configuration file, an admin can ensure that all applications on the machine will begin to use the fix.
