Tuesday, February 24, 2009

.NET Technology

An Overview of .NET Technology

The Microsoft .NET Framework is a software technology that is available with several Microsoft Windows operating systems. It includes a large library of pre-coded solutions to common programming problems and a virtual machine that manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering and is intended to be used by most new applications created for the Windows platform.

The pre-coded solutions that form the framework's Base Class Library cover a large range of programming needs in a number of areas, including user interface, data access, database connectivity, cryptography, web application development, numeric algorithms, and network communications. The class library is used by programmers, who combine it with their own code to produce applications.

Programs written for the .NET Framework execute in a software environment that manages the program's runtime requirements. Also part of the .NET Framework, this runtime environment is known as the Common Language Runtime (CLR). The CLR provides the appearance of an application virtual machine so that programmers need not consider the capabilities of the specific CPU that will execute the program. The CLR also provides other important services such as security, memory management, and exception handling. The class library and the CLR together compose the .NET Framework.

Version 3.0 of the .NET Framework is included with Windows Server 2008 and Windows Vista. The current version of the framework can also be installed on Windows XP and the Windows Server 2003 family of operating systems A reduced "Compact" version of the .NET Framework is also available on Windows Mobile platforms, including smartphones.

 

Interoperability 

Because interaction between new and older applications is commonly required, the .NET Framework provides means to access functionality that is implemented in programs that execute outside the .NET environment. Access to COM components is provided in the System.Runtime.InteropServices and System.EnterpriseServices namespaces of the framework; access to other functionality is provided using the P/Invoke feature.

Common Runtime Engine 

The Common Language Runtime (CLR) is the virtual machine component of the .NET framework. All .NET programs execute under the supervision of the CLR, guaranteeing certain properties and behaviors in the areas of memory management, security, and exception handling. 

Base Class Library 

The Base Class Library (BCL), part of the Framework Class Library (FCL), is a library of functionality available to all languages using the .NET Framework. The BCL provides classes which encapsulate a number of common functions, including file reading and writing, graphic rendering, database interaction and XML document manipulation. 

Simplified Deployment 

Installation of computer software must be carefully managed to ensure that it does not interfere with previously installed software, and that it conforms to security requirements. The .NET framework includes design features and tools that help address these requirements.

Security 

The design is meant to address some of the vulnerabilities, such as buffer overflows, that have been exploited by malicious software. Additionally, .NET provides a common security model for all applications.

Portability 

The design of the .NET Framework allows it to theoretically be platform agnostic, and thus cross-platform compatible. That is, a program written to use the framework should run without change on any type of system for which the framework is implemented. Microsoft's commercial implementations of the framework cover Windows, Windows CE, and the Xbox 360. In addition, Microsoft submits the specifications for the Common Language Infrastructure (which includes the core class libraries, Common Type System, and the Common Intermediate Language), the C# language, and the C++/CLI language to both ECMA and the ISO, making them available as open standards. This makes it possible for third parties to create compatible implementations of the framework and its languages on other platforms.

Architecture

Visual overview of the Common Language Infrastructure (CLI)

Common Language Infrastructure

The core aspects of the .NET framework lie within the Common Language Infrastructure, or CLI. The purpose of the CLI is to provide a language-neutral platform for application development and execution, including functions for exception handling, garbage collection, security, and interoperability. Microsoft's implementation of the CLI is called the Common Language Runtime or CLR.

Assemblies

The intermediate CIL code is housed in .NET assemblies. As mandated by specification, assemblies are stored in the Portable Executable (PE) format, common on the Windows platform for all DLL and EXE files. The assembly consists of one or more files, one of which must contain the manifest, which has the metadata for the assembly. The complete name of an assembly (not to be confused with the filename on disk) contains its simple text name, version number, culture, and public key token. The public key token is a unique hash generated when the assembly is compiled, thus two assemblies with the same public key token are guaranteed to be identical from the point of view of the framework. A private key can also be specified known only to the creator of the assembly and can be used for strong naming and to guarantee that the assembly is from the same author when a new version of the assembly is compiled

Metadata


All CLI is self-describing through .NET metadata. The CLR checks the metadata to ensure that the correct method is called. Metadata is usually generated by language compilers but developers can create their own metadata through custom attributes. Metadata contains information about the assembly, and is also used to implement the reflective programming capabilities of .NET Framework.

Security


.NET has its own security mechanism with two general features: Code Access Security (CAS), and validation and verification. Code Access Security is based on evidence that is associated with a specific assembly. Typically the evidence is the source of the assembly (whether it is installed on the local machine or has been downloaded from the intranet or Internet). Code Access Security uses evidence to determine the permissions granted to the code. Other code can demand that calling code is granted a specified permission. The demand causes the CLR to perform a call stack walk: every assembly of each method in the call stack is checked for the required permission; if any assembly is not granted the permission a security exception is thrown.

When an assembly is loaded the CLR performs various tests. Two such tests are validation and verification. During validation the CLR checks that the assembly contains valid metadata and CIL, and whether the internal tables are correct. Verification is not so exact. The verification mechanism checks to see if the code does anything that is 'unsafe'. The algorithm used is quite conservative; hence occasionally code that is 'safe' does not pass. Unsafe code will only be executed if the assembly has the 'skip verification' permission, which generally means code that is installed on the local machine.

.NET Framework uses appdomains as a mechanism for isolating code running in a process. Appdomains can be created and code loaded into or unloaded from them independent of other appdomains. This helps increase the fault tolerance of the application, as faults or crashes in one appdomain do not affect rest of the application. Appdomains can also be configured independently with different security privileges. This can help increase the security of the application by isolating potentially unsafe code. The developer, however, has to split the application into subdomains; it is not done by the CLR.


Class library


Namespaces in the BCL

System

System. CodeDom

System. Collections

System. Diagnostics

System. Globalization

System. IO

System. Resources

System. Text

System. Text.RegularExpressions


Microsoft .NET Framework includes a set of standard class libraries. The class library is organized in a hierarchy of namespaces. Most of the built in APIs are part of either System.* or Microsoft.* namespaces. It encapsulates a large number of common functions, such as file reading and writing, graphic rendering, database interaction, and XML document manipulation, among others. The .NET class libraries are available to all .NET languages. The .NET Framework class library is divided into two parts: the Base Class Library and the Framework Class Library.


The Base Class Library (BCL) includes a small subset of the entire class library and is the core set of classes that serve as the basic API of the Common Language Runtime The classes in mscorlib.dll and some of the classes in System.dll and System.core.dll are considered to be a part of the BCL. The BCL classes are available in both .NET Framework as well as its alternative implementations including .NET Compact Framework, Microsoft Silverlight and Mono.


The Framework Class Library (FCL) is a superset of the BCL classes and refers to the entire class library that ships with .NET Framework. It includes an expanded set of libraries, including WinForms, ADO.NET, ASP.NET, Language Integrated Query, Windows Presentation Foundation, Windows Communication Foundation among others. The FCL is much larger in scope than standard libraries for languages like C++, and comparable in scope to the standard libraries of Java.


Memory management


The .NET Framework CLR frees the developer from the burden of managing memory (allocating and freeing up when done); instead it does the memory management itself. To this end, the memory allocated to instantiations of .NET types (objects) is done contiguously[ from the managed heap, a pool of memory managed by the CLR. As long as there exists a reference to an object, which might be either a direct reference to an object or via a graph of objects, the object is considered to be in use by the CLR. When there is no reference to an object, and it cannot be reached or used, it becomes garbage. However, it still holds on to the memory allocated to it. .NET Framework includes a garbage collector which runs periodically, on a separate thread from the application's thread, that enumerates all the unusable objects and reclaims the memory allocated to them.

The .NET Garbage Collector (GC) is a non-deterministic, compacting, mark-and-sweep garbage collector. The GC runs only when a certain amount of memory has been used or there is enough pressure for memory on the system. Since it is not guaranteed when the conditions to reclaim memory are reached, the GC runs are non-deterministic. Each .NET application has a set of roots, which are pointers to objects on the managed heap (managed objects). These include references to static objects and objects defined as local variables or method parameters currently in scope, as well as objects referred to by CPU registers. When the GC runs, it pauses the application, and for each object referred to in the root, it recursively enumerates all the objects reachable from the root objects and marks them as reachable. It uses .NET metadata and reflection to discover the objects encapsulated by an object, and then recursively walk them. It then enumerates all the objects on the heap (which were initially allocated contiguously) using reflection. All objects not marked as reachable are garbage. This is the mark phase. Since the memory held by garbage is not of any consequence, it is considered free space. However, this leaves chunks of free space between objects which were initially contiguous. The objects are then compacted together, by using memcpy to copy them over to the free space to make them contiguous again. Any reference to an object invalidated by moving the object is updated to reflect the new location by the GC. The application is resumed after the garbage collection is over.

The GC used by .NET Framework is actually generational. Objects are assigned a generation; newly created objects belong to Generation 0. The objects that survive a garbage collection are tagged as Generation 1, and the Generation 1 objects that survive another collection are Generation 2 objects. The .NET Framework uses up to Generation 2 objects Higher generation objects are garbage collected less frequently than lower generation objects. This helps increase the efficiency of garbage collection, as older objects tend to have a larger lifetime than newer objects. Thus, by removing older (and thus more likely to survive a collection) objects from the scope of a collection run, fewer objects need to be checked and compacted.

Standardization and licensing


While Microsoft and their partners hold patents for the CLI and C#, ECMA and ISO require that all patents essential to implementation be made available under "reasonable and non-discriminatory terms." In addition to meeting these terms, the companies have agreed to make the patents available royalty-free.

However, this does not apply for the part of the .NET Framework which is not covered by the ECMA/ISO standard, which includes Windows Forms, ADO.NET, and ASP.NET. Patents that Microsoft holds in these areas may deter non-Microsoft implementations of the full framework.

On 3 October 2007, Microsoft announced that much of the source code for the .NET Framework will be made available with the final release of Visual Studio 2008 towards the end of 2007 under the shared source Microsoft Reference License. The source code for other libraries including Windows Communication Foundation (WCF), Windows Workflow Foundation (WF) and Language Integrated Query (LINQ) will be added in future releases. Being released under the Microsoft Reference License means this source code is made available for debugging purpose only, primarily to support integrated debugging of the BCL in Visual Studio.

Versions

Microsoft started development on the .NET Framework in the late 1990s originally under the name of Next Generation Windows Services (NGWS). By late 2000 the first beta versions of .NET 1.0 were released.

The .NET Framework stack.

Version

Version Number

Release Date

1.0

1.0.3705.0

2002-01-05

1.1

1.1.4322.573

2003-04-01

2.0

2.0.50727.42

2005-11-07

3.0

3.0.4506.30

2006-11-06

3.5

3.5.21022.8

2007-11-09

 

Description of 1-Tier ,2-Tier and 3-Tier Web Applications


Description of 1-Tier and 2-Tier Web Applications

Client-Server environments. Perhaps the most influential Client-Server environment is the Internet and its global users. With the increasing use of web applications, an examination of the best architecture to support web applications is timely. The architectural component of this discussion will focus on the underlying structures and schematics that best build web applications. Specifically, we will be discussing tier architecture, which is the breaking down of an application into logical chunks that are called Tiers. Tiers can exist on the same computer and be connected virtually or logically or on different machines.

The simplest examples of tier architecture are enumerated as 1-Tier, 2-Tier, and 3-Tier. 1-Tier Architecture is the simplest, single tier on single user, and is the equivalent of running an application on a personal computer. All the required component to run the application are located within it. User interface, business logic, and data storage are all located on the same machine. They are the easiest to design, but the least scalable. Because they are not part of a network, they are useless for designing web applications. 2-Tier Architectures supply a basic network between a client and a server. For example, the basic web model is a 2-Tier Architecture. A web browser makes a request from a web server, which then processes the request and returns the desired response, in this case, web pages. This approach improves scalability and divides the user interface from the data layers. However, it does not divide application layers so they can be utilized separately. This makes them difficult to update and not specialized. The entire application must be updated because layers aren’t separated.

3-Tier Architecture is most commonly used to build web applications. In this model, the browser acts like a client, middleware or an application server contains the business logic, and database servers handle data functions. This approach separates business logic from display and data. But, it does not specialize functional layers. Its fine for prototypical or very simple web applications, but it doesn’t measure up to the complexity demanded of web applications. The application server is still too broad, with too many functions grouped together. This reduces flexibility and scalability. N-Tier Architectures provide finer granularity, which provides more modules to choose from as the application is separated into smaller functions.

"Tier" can be defined as "one of two or more rows, levels, or ranks arranged one above another". So from this, we get an adapted definition of the understanding of what N-tier means and how it relates to our application architecture: "Any number of levels arranged above another, each serving distinct and separate tasks." To gain a better understanding of what is meant, let's take a look at a typical N-tier model.

The Data Tier

Since this has been deemed the Age of Information, and since all information needs to be stored, the Data Tier described above is usually an essential part. Developing a system without a data tier is possible, but I think for most applications the data tier should exist. So what is this layer? Basically, it is your Database Management System (DBMS) -- SQL Server, Access, Oracle, MySql, plain text (or binary) files, whatever you like. This tier can be as complex and comprehensive as high-end products such as SQL Server and Oracle, which do include the things like query optimization, indexing, etc., all the way down to the simplistic plain text files (and the engine to read and search these files). Some more well-known formats of structured, plain text files include CSV, XML, etc.. Notice how this layer is only intended to deal with the storage and retrieval of information. It doesn't care about how you plan on manipulating or delivering this data. This also should include your stored procedures. Do not place business logic in here, no matter how tempting.

The Presentation Logic Tier

Let's jump to the Presentation Logic Layer in Figure 1.1. You probably are familiar with this layer; it consists of our standard ASP documents, Windows forms, etc. This is the layer that provides an interface for the end user into your application. That is, it works with the results/output of the Business Tier to handle the transformation into something usable and readable by the end user. It has come to my attention that most applications have been developed for the Web with this layer talking directly to the Data Access Layer and not even implementing the Business Tier. Sometimes the Business Layer is not kept separated from the other two layers. Some applications are not consistent with the separation of these layers, and it's important that they are kept separate. A lot of developers will simply throw some SQL in their ASP (using ADO), connect to their database, get the recordset, and loop in their ASP to output the result. This is usually a very bad idea. I will discuss why later.


The Proxy Tier and the Distributed Logic

There's also that little, obscure Proxy Tier. "Proxy" by definition is "a person [object] authorized to act for another". This "object," in our context, is referring to any sort of code that is performing the actions for something else (the client). The key part of this definition is "act for another." The Proxy Layer is "acting" on behalf of the Distributed Logic layer (or end-user's requests) to provide access to the next tier, the Business Tier. Why would anyone ever need this? This facilitates our need for distributed computing. Basically it comes down to you choosing some standard method of communication between these two entities. That is, "how can the client talk to the remote server?"

This is where we find the need for the Simple Object Access Protocol (SOAP). SOAP is a very simple method for doing this. Without too many details, SOAP could be considered a standard (protocol) for accessing remote objects. It provides a way in which to have two machines "talking" or "communicating" with each other


The Client Interface

In this section of Figure 1.1 we notice that the end-user presentation (Windows forms, etc.) is connected directly to the Business Tier. A good example of this would be your applications over the Local Area Network (LAN). This is your typical, nondistributed, client-server application. Also notice that it extends over and on top of the Distributed Logic layer. This is intended to demonstrate how you could use SOAP (or some other type of distributed-computing messaging protocol) on the client to communicate with the server and have those requests be transformed into something readable and usable for the end user.


The Business Tier

This is basically where the brains of your application reside; it contains things like the business rules, data manipulation, etc. For example, if you're creating a search engine and you want to rate/weight each matching item based on some custom criteria (say a quality rating and number of times a keyword was found in the result), place this logic at this layer. This layer does NOT know anything about HTML, nor does it output it. It does NOT care about ADO or SQL, and it shouldn't have any code to access the database or the like. Those tasks are assigned to each corresponding layer above or below it.

We must gain a very basic understanding of Object-Oriented Programming (OOP) at this time and make sure you understand the important benefits of OOP. To clarify, let's look at another example, such as a shopping cart application. Think in terms of basic objects. We create an object to represent each product for sale. This Product object has the standard property getters and setters: getSize, getColor, setSize, setColor, etc. It is a super simple implementation of any generic product. Internally, it ONLY knows how to return information (getters) and understands how it can validate the data you pump into it (ONLY for its limited use). It is self-contained (encapsulation). The key here is to encapsulate all the logic related to the generic product within this object. If you ask it to "getPrice," it will return the price of the single item it represents. Also if you instruct it to "validate" or "save," it has the brains to be able to handle this, return any errors, etc.

We can plug this Product object into another object, a "Cart" object. This cart can contain and handle many Product objects. It also has getters and setters, but obviously on a more global scale. You can do something like "for each product in myCart", and enumerate (loop through) each product within. (For more information on enumeration, Now, when you call "getPrice" for the Cart object, it knows that it must enumerate each product that it has, add up the price for each, and return that single total. When we fire the "saveCart" method, it will loop for each "product" and call its "saveProduct" method, which will then hit the Data Access Tier objects and methods to persist itself over to the Data Tier.

We could also take our simple Product object, and plug it into our "Sale" object. This Sale object contains all of the items that are available for a particular sale. And the Sale object can be used for things like representing all the items on sale at a given outlet or the like. I'm sure you are beginning to understand the advantage of using an OOP environment.

Data Access Tier

This layer is where you will write some generic methods to interface with your data. For example, we will write a method for creating and opening a Connection object (internal), and another for creating and using a Command object, along with a stored procedure (with or without a return value), etc. It will also have some specific methods, such as "saveProduct," so that when the Product object calls it with the appropriate data, it can persist it to the Data Tier. This Data Layer, obviously, contains no data business rules or data manipulation/transformation logic. It is merely a reusable interface to the database.

Applying N-Tier Architecture and Example

Let’s now apply N-Tier Architecture to our shopping cart example. In this example, we will demonstrate how sales tax is calculated and displayed. The presentation tier calls the business logic tier to perform computations on the data in the shopping cart to calculate total price. The business logic tier communicates with a database (data tier) to extract the sales tax amount based on the total price.

he business logic tier is able to communicate with the data tier through the integration tier. Through encapsulation, the integration tier is able to conceal the complexities of communication. It also retrieves the right tax rate and returns it to the business logic tier. The business logic tier completes its calculations. The presentation tier formats the response through HTML and forwards it to the client or web browser, where it is displayed to the user.

Benefits of N-Tier Architecture

There are many business benefits to N-Tier Architecture. For example, a small business can begin running all tiers on a single machine. As traffic and business increases, each tier can be expanded and moved to its own machine and then clustered. This is just one example of how N-Tier Architecture improves scalability and supports cost-efficient application building.

N-Tier model also make applications more readable and reusable. It reduces the amount of spaghetti code. Custom tag libraries and EJBs are easier to port to readable applications in well-maintained templates. Reusability multiplies developer productivity and improves application maintainability. It is an important feature in web applications.

N-Tier Architectures make application more robust because there is no single point of failure. Tiers function with relative independence. For example, if a business changes database vendors, they just have to replace the data tier and adjust the integration tier to any changes that affect it. The business logic tier and the presentation tier remain unchanged. Likewise, if the presentation layer changes, this will not affect the integration or data layer. In 3-Tier Architecture all the layers exist in one and affect each other. A developer would have to pick through the entire application code to implement any changes. Again, well-designed modules allow for applications or pieces of applications to be customized and used across modules or even projects. Reusability is particularly important in web applications.

As demonstrated N-Tier Architecture offers innovations in the standard Client-Server technology that spawned the Internet itself. It is but one of many web application frameworks. These are used to develop dynamic web sites, web applications or web services. They provide database access libraries, templates, and, as previously stated code re-use. Most web application frameworks follow the Model View Controller (MVC) which separate the user interface, the business rules and the data model. They provide authentication and authorization to provide security. This allows the web server to restrict user access based on pre-determined criteria. Web application frameworks also provide a unified API (Application programming Interface). This allows web application to work with various databases without requiring any code change. These frameworks also maintain a web template system.

Finally, N-Tier Architecture helps developers build web applications because it allows developers to apply their specific skill to that part of the program that best suits their skill set. Graphic artists can focus on the presentation tier, while administrators can focus on the database tier




asp.net

How ASP .NET different from ASP?
Difference between ASP.NET and ASP?

1. Scripting is separated from the HTML, Code is compiled as a DLL, these DLLs can be executed on the server.
2. ASP is interpreted. ASP.NET Compiled event base programming.Control events for text button can be handled at client java script only. Since we have server controls events can handle at server side.
3. More error handling.
4. ASP .NET has better language support, a large set of new controls and XML based components, and better user authentication.
5. ASP .NET provides increased performance by running compiled code.
6. ASP .NET code is not fully backward compatible with ASP.
7. ASP .NET also contains a new set of object oriented input controls, like programmable list boxes, validation controls. A new data grid control supports sorting, data paging, and everything you expect from a dataset control. The first request for an ASP.NET page on the server will compile the ASP .NET code and keep a cached copy in memory. The result of this is greatly increased performance.
8. ASP .NET is not fully compatible with earlier versions of ASP, so most of the old ASP code will need some changes to run under ASP .NET. To overcome this problem, ASP .NET uses a new file extension ".aspx". This will make ASP .NET applications able to run side by side with standard ASP applications on the same server.

Can we run both ASP and ASP.Net on same server?
Yes. They will run side by side without affecting each other’s working.

Can ASP pages and ASP.Net pages share session variables?
No. Both support session variables but the session variables are not shared across the two platforms.

Can ASP.NET still recognize the Global.asa file?
Asp.Net does not recognize the standard ASP global.asa file. Instead it uses a file named global.asax with the same name – plus additional functionality.


What methods are fired during the page load?
Various stages of page load lifecycle.
What is the order of events in a web form?
Init () - when the page is instantiated.
Load () - when the page is loaded into server memory.
PreRender () - the brief moment before the page is displayed to the user as HTML. Unload () - when page finishes loading.

What is the process-flow for ASP.NET?
1. User requests an ASPX page in the browser.
2. An HTTP request is sent to IIS.
3. The isapi filter (xspisapi.dll) intercepts the request and passes the request on to the XSP worker process (xspwp.exe).
4. The worker process takes care of handling the request to the appropriate HTTPModules and finally to HTTPHandler as defined in the configuration files.
5. The ASPX page is read from the HD or cache and the server code is loaded into memory and executed.
6. The server side code outputs normal HTML which is handled back through the chain of modules and eventually to IIS, which sends the response back to the client’s browser.
7. If the user clicks or otherwise acts on an HTML element (say, a textbox) that has a server side event handler, the form is posted back to the server with hidden form fields containing information as to what control and event occurred. Some controls do not automatically post by default, but wait for a button_click event to post. This is configurable by the developer.
8. The ASPX page is again loaded into memory using the same sequence of events as before, but this time ASP.Net reads in the hidden form field data and automatically triggers the appropriate _OnChange, OnClick and other appropriate event handlers.
9. Resulting HTML is sent to the browser.
10. The process continues in a continual “Post Back” cycle.

Describe the role of inetinfo.exe, aspnet_isapi.dll andaspnet_wp.exe in the page loading process?
inetinfo.exe is the Microsoft IIS server running, handling ASP.NET requests among other things. When an ASP.NET request is received (usually a file with .aspx extension),the ISAPI filter aspnet_isapi.dll takes care of it by passing the request to the actual worker process aspnet_wp.exe.

What is the difference between inline and code behind?
Inline code is written along side the HTML in a page. There is no separate distinction between design code and logic code.
Code-behind is code written in a separate file and referenced by the .aspx page.
Code Behind is relevant to Visual Studio.NET only.

What is the difference between Server.Transfer and Response.Redirect?
Server.Transfer: It transfers execution from the first page to the second page on the server.
All the state information that has been created for the first (i.e. calling) ASP page will be transferred to the second (i.e. called) page.
When second ASP page completes its tasks, you do not return to the first ASP page. All these happen on the server side, browser is not aware of this.
The benefit of this approach is one less round trip to the server from the client browser.
Response.Redirect: This tells the browser that the requested page can be found at a new location. The browser then initiates another request to the new page loading its contents in the browser.
Hence, there is roundtrip between client and server.
The redirect message issue HTTP 304 to the browser and causes browser to got the specific page.

Should validation (did the user enter a real date) occur server-side or client-side? Why?
Client-side. This reduces an additional request to the server to validate the users input.

What’s the difference between Response.Write () and Response.Output.Write ()?
The latter one allows you to write formatted output.

Suppose you want a certain ASP.NET function executed on MouseOver over a certain button. Where do you add an event handler?
It’s the Attributes property, the Add function inside that property. So
btnSubmit.Attributes.Add ("onClick","someClientCode () ;")

What does the "EnableViewState" property do? Why would I want it on or off?
It enables the viewstate on the page. It allows the page to save the users input on a form.

What is ViewState? ViewState represents the state of a page when it was last processed on the web server. It holds the values of a control that has been dynamically changed.

Briefly describe different techniques for ASP.NET State Management? State management is the art of retaining information between requests. State Management is of 2 types.
1. Client side state management
A) View State
B) Query String
C) Hidden Fields
D) Cookies
2. Server side state management
A) Session
B) Application
C) Cache

What is the lifespan for items stored in ViewState? Item stored in ViewState exist for the life of the current page. This includes postbacks (to the same page).

What is Postback?
When an action occurs (like button click), the page containing all the controls within the tag performs an HTTP POST, while having itself as the target URL. This is called Postback.

What is smart Navigation? The cursor position is maintained when the page get refreshed due to server side validation and the page get refreshed.

What are the different types of Session state management options available with ASP.NET? ASP.NET provides In-Process and Out-of-Process state management. In-Process stores the session in memory on the web server. This requires the a "sticky-server" (or no load-balancing) so that the user is always reconnected to the same web server. Out-of-Process Session state management stores data in an external data source. The external data source may be either a SQL Server or a State Server service. Out-of-Process state management requires that all objects stored in session are serializable.

How do you turn off SessionState in the web.config? By simply adding the httpmodule tag in web.cofig file

How can I kill a user Session? Call session.abandon

List the ASP.NET validation controls?
RequiredFieldValidator
RangeValidator
CompareValidator
RegularExpressionValidator
CustomValidator
ValidationSummary

What data type does the RangeValidator control support?
Integer, String and Date.

Name two properties common in every validation control?
ControlToValidate property and Text property.

Which control would you use if you needed to make sure the values in two different controls matched? CompareValidator Control

Can you give an example of what might be best suited to place in the Application_Start and Session_Start subroutines?
This is where you can set the specific variables for the Application and Session objects.

Can you edit data in the Repeater control?
No, it just reads the information from its data source

What is Data Binding? Data binding is a way used to connect values from a collection of data (e.g. DataSet) to the controls on a web form. The values from the dataset are automatically displayed in the controls without having to write separate code to display them.

Describe Paging in ASP.NET.
The DataGrid control in ASP.NET enables easy paging of the data. The AllowPaging property of the DataGrid can be set to True to perform paging. ASP.NET automatically performs paging and provides the hyperlinks to the other pages in different styles, based on the property that has been set for PagerStyle.Mode.

What is caching and the different techniques available for caching?
Caching is a concept of storing frequently used data into temporary memory. It provides data for immediate access to requesting program calls.
The types of caching are :-
Page / output caching
On per page basis or on a per user control basis, letting you store part or whole page in a cache, and customize their expiration.
Fragment / Partial page output caching
No need to cache entire page, only caches static i.e. html of page.
Programmatic / Data caching
Take advantage of .Net runtime cache engine to store any data or object between responses.
Cache[“foo”]=bar
Retrieve value- bar=cache[“foo”]
Ex.
i.e. page does not change for some period of time, for 15 seconds.
If page is refreshed or loaded within the next 15 seconds then the web server will serve the same contents without needing to dynamically regenerate the page.

What is authentication and authorization? Authentication is the process of identification and validation of a user's credentials. After the identity is authenticated, a process called authorization determines whether that identity has access to a particular resource.

Whenever a user logs on to an application, the user is first authenticated and then authorized. The application’s web.config file contains all of the configuration settings for an ASP.NET application. It is the job of the authentication provider to verify the credentials of the user and decide whether a particular request should be considered authenticated or not. An authentication provider is used to prove the identity of the users in a system. ASP.NET provides three ways to authenticate a user:
1 Forms authentication
2 Windows authentication
3 Passport authentication

Forms Authentication - This authentication mode is based on cookies where the user name and the password are stored either in a text file or the database. After a user is authenticated, the user’s credentials are stored in a cookie for use in that session. When the user has not logged in and requests for a page that is insecure, he or she is redirected to the login page of the application. Forms authentication supports both session and persistent cookies.

The following needs to be specified in the application’s web.config file for using Forms Based Authentication in ASP.NET:

Windows Authentication-This is the default authentication mode in ASP.NET. Using this mode, a user is authenticated based on his/her Windows account. Windows Authentication can be used only in an intranet environment where the administrator has full control over the users in the network. The following should be set in the web.config file to use Windows Authentication:

Windows authentication can be of the following types
1 Anonymous Authentication
2 Basic Authentication
3 Digest Authentication
4 Integrated Windows Authentication

Passport Authentication-Passport authentication is a centralized authentication service that uses Microsoft's Passport Service to authenticate the users of an application. It allows the users to create a single sign-in name and password to access any site that has implemented the Passport single sign-in (SSI) service. The following code shows how we can specify Passport Authentication in the web.config file:
ASP.NET also supports custom authentication. In such a case the authentication mode has to be specified as none in the web.config file as shown below:
Then we need to write our own custom authentication provider.

Authorization is the process of determining the accessibility to a resource for a previously authenticated user. Note that authorization can only work with authenticated users
The default authentication mode is anonymous authentication. There can be three types of authorization in ASP.NET. They are
1 URL Authorization
2 File Authorizations
3 Authorization based on ACLs

CONFIGURATION
The Web.config is an XML based configuration file for the entire application and resides in the application root. It provides the application wide settings for the entire application.

The Machine.config located at the "C:\WINDOWS\Microsoft.NET\Framework\vx.x.xxxx\CONFIG" directory, is used to apply configuration settings for any applications that are running in the entire system.


web.config
The XML based web.config file is used to specify the application wide settings for your entire application. The system wide settings are however stored in the machine.config file. There can be multiple config files in your application (one per each folder in your application) but only one machine.config file. Note that the settings specified in the Web.config file actually override the settings that are specified in the Machine.config file.
1) You can use the section of the section group to specify whether session and/or view state would be enabled or disabled for the web pages of the application.
2) The authentication and authorization sections in the web.config file allow you to specify the authentication mode applicable for your application and the authorization information for the authenticated users.
3) You can also specify the trace and globalization information using the respective sections in the web.config file.
4) You can specify the application wide error information using the section.
5) The section is the most widely used of all the sections in the web.config file and it typically stores the following.
· Database Connection Strings
· Server Name
· File Path
· Custom Key - Value Settings

To read the web.config file, use the code snippet given below.System.Configuration.Configuration wConfig =System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration ("/joydip");

You can read the machine.config file using the code snippet shown below.System.Configuration.Configuration mConfig =System.Web.Configuration.WebConfigurationManager.OpenMachineConfiguration ();


GLOBAL.ASAX
"The Global.asax file, also known as the ASP.NET application file, is an optional file that contains code for responding to application-level events raised by ASP.NET."
The Global.asax file is parsed and dynamically compiled by ASP.NET into a .NET Framework class the first time any resource or URL within its application namespace is activated or requested. Whenever the application is requested for the first time, the Global.asax file is parsed and compiled to a class that extends the HttpApplication class. When the Global.asax file changes, the framework reboots the application and the Application_OnStart event is fired once again when the next request comes in. Note that the Global.asax file does not need recompilation if no changes have been made to it. There can be only one Global.asax file per application and it should be located in the application's root directory only.
It is a collection of event handlers that you can use to change and set settings in your site. The events can come from one of two places - The HTTPApplication object and any HTTPModule object that is specified in web.confg or machine.config.

The following are some of the important events in the Global.asax file.
Application_Init
The Application_Init event is fired when an application initializes the first time.
Application_Start
The Application_Start event is fired the first time when an application starts.
Session_Start
The Session_Start event is fired the first time when a user’s session is started. This typically contains for session initialization logic code.
Application_BeginRequest
The Application_BeginRequest event is fired each time a new request comes in.
Application_EndRequest
The Application_EndRequest event is fired when the application terminates.
Application_AuthenticateRequest
The Application_AuthenticateRequest event indicates that a request is ready to be authenticated. If you are using Forms Authentication, this event can be used to check for the user's roles and rights.
Application_Error
The Application_Error event is fired when an unhandled error occurs within the application.
Session_End
The Session_End Event is fired whenever a single user Session ends or times out.
Application_End
The Application_End event is last event of its kind that is fired when the application ends or times out. It typically contains application cleanup logic.

HttpContext
Encapsulates all HTTP-specific information about an individual HTTP request.
Each time a Web server receives a request for an ASP.NET resource - be it an ASP.NET Web page, a Web service, or any other request that is mapped in IIS to the ASP.NET engine - an instance of the System.Web.HttpContext object is created. This class contains information about the request. For example, the HttpContext class has the "intrinsic" objects you're familiar with: Request, Response, Session, Application, Server, and Cache. HttpContext contains information about the current user making the request in its User property; it stores information about any errors that have occurred in its Errors property.
An HttpContext object will encapsulate specific details of a single HTTP request. Properties of this class include the Request object, the Response object, the Session object, and an AllErrors property which keeps an array of Exception objects accrued during the current request.

HTTP Handlers
Handlers are used to process individual endpoint requests. Handlers enable the ASP.NET framework to process individual HTTP URLs or groups of URL extensions within an application. Unlike modules, only one handler is used to process a request. All handlers implement the IHttpHandler interface, which is located in the System.Web namespace. Handlers are somewhat analogous to Internet Server Application Programming Interface (ISAPI) extensions.
HttpHandlers are the earliest possible point where we have access to the requests made to the web server (IIS). When a request is made to the web server for an ASP.NET resource (.aspx, .asmx, etc.), the worker process of the ASP.NET creates the right HttpHandler for the request which responds to the request. The default handlers for each request type that ASP.NET handles are set in the machine.config file. For example, all the requests made to ASP.NET (.aspx) pages are handled by System.Web.UI.PageHandlerFactory. So whenever an ASP.NET is requested at the web server, the PageHandlerFactory will fulfill the request.
Almost everything we do in an HttpHandler, we can simply do it in a normal .aspx page. Then why do we need HttpHandlers? First, the HttpHandlers are more reusable and portable than the normal .aspx pages. Since there are no visual elements in an HttpHandler, they can be easily placed into their own assembly and reused from project to project. Second, HttpHandlers are relatively less expensive than the PageHandler. For a page to be processed at the server, it goes through a set of events (onInit, onLoad, etc.), viewstate and postbacks or simply the complete Page Life Cycle. When you really have nothing to do with the complete page life cycle (like displaying images), HttpHandlers are useful, though the performance hit is negligible.

Creating an HttpHandler
To create an HttpHandler, we need to implement the IHttpHandler interface. The IHttpHandler contains one property and one method.

IHttpHandler interface
Public interface IHttpHandler
{
bool IsReusable { get; }
void ProcessRequest(HttpContext context);
}

The property IsReusable specifies whether the ASP.NET should reuse the same instance of the HttpHandler for multiple requests.
The ProcessRequest () method is where you actually implement the logic to handle the request.
After you create the HttpHandler, you have to map a path to the handler in the web.config.
A typical web.config configuration for the handler looks like the following.

The verb part is just what you want it to respond to (GET, POST, etc.). Path is the file or file extension you want it to respond to and Type is - ClassName, Assembly. For the above web.config setting, each request to the getAvatarImage.img will be sent to the handler and the ProcessRequest will be executed. When we use a new file extension like "getAvatarImage.img" or "getAvatarImage.do," we need to create IIS Extensions mapping for the new extensions.

We will be using the built-in extensions (.ashx) that are already mapped to ASP.NET so that we can avoid the necessity to modify the IIS extensions mapping. With .ashx extension, there is no requirement for registration in the web/machine.config.


HTTP Modules
Modules are called before and after the handler executes. Modules enable developers to intercept, participate in, or modify each individual request. Modules implement the IHttpModule interface, which is located in the System.Web namespace.
HTTP modules are .NET components that implement the System.Web.IHttpModule interface. These components plug themselves into the ASP.NET request processing pipeline by registering themselves for certain events. Whenever those events occur, ASP.NET invokes the interested HTTP modules so that the modules can play with the request.