DOT NET FrameWork Concepts

.Net Framework Concepts


[Source: Dot Net Framework Essentials, O'Reilly]


· Since Web Services are highly reusable across the Web, Microsoft plans to provide a number of building block services, that applications developers can use, for a fee. An example of building –block service is Microsoft Passport, which allows you to use a single username and password at all web sites that support Passport authentication.

· The .NET Framework is a new development and runtime infrastructure that will change the development of business applications on the Windows platform. It includes the Common Language Runtime (CLR) and a common framework of classes that can be used by all .NET languages.

· Language Integration

COM supports language independence, which means that you can develop a COM component in any language you want. As long as your component meets all the rules spelled out in the COM specification, it can be instantiated and used by your applications. While this supports binary reuse, it doesn't support language integration. In other words, you can't reuse the code in the COM components written by someone else; you can't extend a class hosted in the COM component; you can't catch exceptions thrown by code in the COM component; and so forth.

Microsoft .NET supports not only language independence, but also language integration. This means that you can inherit from classes, catch exceptions, and take advantage of polymorphism across different languages. The .NET Framework makes this possible with a specification called the Common Type System (CTS), which all .NET components must support. For example, everything in .NET is an object of a specific class that derives from the root class called System.Object. The CTS supports the general concepts of classes, interfaces, delegates (which support callbacks), reference types, and value types. The .NET base classes provide most of the base system types, such as ones that support integer, string, and file manipulation. Because every language compiler must meet a minimum set of rules stipulated by the Common Language Specification (CLS) and generate code to conform to the CTS, different .NET languages can intermingle with one another.

· In the .NET environment, your executable will use the shared DLL with which it was built. This is guaranteed, because a shared DLL must be registered against something similar to the Windows 2000 cache, called the Global Assembly Cache (GAC). In addition to this requirement, a shared DLL must have a unique hash value, public key, locale, and version number. Once you've met these requirements and registered your shared DLL in the GAC, its physical filename is no longer important. In other words, if you have two versions of a DLL that are both called MyDll.dll, both of them can live and execute on the same system without causing DLL Hell. Again, this is possible because the executable that uses one of these DLLs is tightly bound to the DLL during compilation.

In addition to eradicating DLL Hell, .NET also removes the need for component-related registry settings. Microsoft .NET stores all references and dependencies of .NET assemblies within a special section called a manifest. In addition, assemblies can be either private or shared. Private assemblies are found using logical paths or XML-based application configuration files, and public assemblies are registered in the GAC; in both cases the system will find your dependencies at runtime. If they are missing, you get an exception telling you exactly what happened.

Finally, .NET brings back the concept of zero-impact installation and removal. Unlike COM, but like DOS, to set up an application in .NET, you simply xcopy your files from one directory on a CD to another directory on your machine, and the application will run automatically. Similarly, you can just delete the directory to uninstall the application from your machine.

· Unlike traditional security support whereby only access to the executable is protected, .NET goes further to protect access to specific parts of the executable code. For example, to take advantage of declarative security checks, you can prefix your method implementations with security attributes without having to write any code. To take advantage of imperative security checks, you write the code in your method to explicitly cause a security check. There are many other security facilities that .NET provides in an attempt to make it harder to penetrate your applications and system.

· .NET Framework Hierarchy

As you can see in Figure, the .NET Framework sits on top of the operating system, which can be a few different flavors of Windows and consists of a number of components. .NET is essentially a system application that runs on Windows.





The most important component of the Framework is something called the CLR. If you are a Java programmer, think of the CLR as the .NET equivalent of the Java Virtual Machine (JVM). If you don't know Java, think of the CLR as the heart and soul of the .NET architecture. At a high level, the CLR activates objects, performs security checks on them, lays them out in memory, executes them, and garbage-collects them. Conceptually, the CLR and the JVM are similar in that they are both runtime infrastructures that abstract the underlying platform differences. However, while the JVM currently supports just the Java language, the CLR supports all languages that can be represented in the Common Intermediate Language (CIL). The JVM executes bytecode, so it could technically support many different languages, too. Unlike Java's bytecode, though, IL is never interpreted. Another conceptual difference between the two infrastructures is that Java code runs on multiple platforms with a JVM, whereas .NET code runs only on the Windows platforms with the CLR (at the time of this writing). Microsoft has submitted the Common Language Infrastructure (CLI), which is functional a subset of the CLR, to ECMA, so a third-party vendor could theoretically implement a CLR for a platform other than Windows.

· An assembly is the basic unit of deployment and versioning, consisting of a manifest, a set of one or more modules, and an optional set of resources.

· .NET Portable Executable File

A Windows executable, EXE or DLL, must conform to a file format called the PE file format, which is a derivative of the Microsoft Common Object File Format (COFF). Both of these formats are fully specified and publicly available. The Windows OS knows how to load and execute DLLs and EXEs because it understands the format of a PE file. Given this, any compiler that wants to generate Windows executables must obey the PE/COFF specification.

Standard Windows PE files are divided into two major sections. The first section includes the PE/COFF headers that reference the contents within the PE file. In addition to the header section, the PE file holds a number of native image sections, including the .data, .rdata, .rsrc , and .text sections. These are the standard sections of a typical Windows executable, but Microsoft's C/C++ compiler allows you to add your own custom sections into the PE file using a compiler pragma statement. For example, you can create your own data section to hold encrypted data that only you can read. Taking advantage of this ability, Microsoft has added a few new sections to the normal PE file specifically to support the CLR's functionality. The CLR understands and manages the new sections. For example, the CLR will read these sections and determine how to load classes and execute your code at runtime.

The sections that Microsoft has added to the normal PE format are the CLR header and the CLR data sections. While the CLR header stores information to indicate that the PE file is a .NET executable, the CLR data section contains metadata and IL code, both of which determine how the program will be executed.

· Metadata

Metadata is machine -readable information about a resource, or "data about data." Such information might include details on content, format, size, or other characteristics of a data source. In .NET, metadata includes type definitions, version information, external assembly references, and other standardized information.

In order for two components, systems, or objects to interoperate with one another, at least one must know something about the other. In COM, this "something" is an interface specification, which is implemented by a component provider and used by its consumers.

In .NET, metadata is a common mechanism or dialect that the .NET runtime, compilers, and tools can all use. Microsoft .NET uses metadata to describe all types that are used and exposed by a particular .NET assembly. Metadata includes descriptions of an assembly and modules, classes, interfaces, methods, properties, fields, events, global methods, and so forth.

· .NET assemblies are deployable units and manifests are the metadata that describes the assemblies.

· IL Code

An assembly contains the IL code that the CLR executes at runtime. The IL code typically uses types defined within the same assembly, but it also may use or refer to types in other assemblies. There is one caveat: each assembly can have at most one entry point, such as DllMain( ), WinMain( ), or Main( ). You must follow this rule because when the CLR loads an assembly, it searches for one of these entry points to start assembly execution.

· There are four types of assemblies in .NET:

Static assemblies

These are the .NET PE files that you create at compile time. You can create static assemblies using your favorite compiler: csc, cl, or vbc.

Dynamic assemblies

These are PE-formatted, in-memory assemblies that you dynamically create at runtime using the classes in the System.Reflection.Emit namespace.



Private assemblies

These are static assemblies used by a specific application.

Public or shared assemblies

These are static assemblies that must have a unique shared name and can be used by any application.

· Side-by-Side Execution

The CLR allows any versions of the same-shared DLL (shared assembly) to execute at the same time, on the same system, and even in the same process. This concept is known as side-by-side execution.

· Manifests: Assembly Metadata

An assembly manifest is metadata that describes everything about the assembly, including its identity, a list of files belonging to the assembly, references to external assemblies, exported types, exported resources, and permission requests. In short, it describes all the details that are required for component plug-and-play. Since an assembly contains all these details, there's no need for storing this type of information in the registry, as in the COM world.

· An assembly can be a single-module assembly or a multi-module assembly. In a single-module assembly, everything in a build is clumped into one EXE or DLL, an example of which is the hello.exe application that we developed earlier. This is easy to create because a compiler takes care of creating the single -module assembly for you.

A multi-module assembly is one that contains many modules and resource files. To create it you have to use the Assembly Linker (al.exe) that is provided by the .NET SDK. This tool takes one or more IL or resource files and spits out a file with an assembly manifest.

· Any .NET language may be converted into IL, so .NET supports multiple languages and perhaps multiple platforms in the future (as long as the target platforms have a CLR).




· The Common Type System (CTS)

Because .NET treats all languages as equal, a class written in C# should be equivalent to a class written in VB.NET, and an interface defined in Managed C++ should be exactly the same as one that is specified in managed COBOL. Languages must agree on the meanings of these concepts before they can integrate with one another. In order to make language integration a reality, Microsoft has specified a common type system to which every .NET language must abide.

· Interfaces

Interfaces support exactly the same concept as a C++ abstract base class (ABC) with only pure virtual functions. An ABC is a class that declares one or more pure virtual functions and thus cannot be instantiated. If you know COM or Java, interfaces in .NET are conceptually equivalent to a COM or Java interface. You specify them, but you don't implement them. A class that derives from your interface must implement your interface. An interface may contain methods, properties, indexers, and events. In .NET, a class can derive from multiple interfaces.

· The Common Language Specification (CLS)

Microsoft has published the Common Language Specification (CLS). The CLS specifies a series of basic rules that are required for language integration. Since Microsoft provides the CLS that spells out the minimum requirements for being a .NET language, compiler vendors can build their compilers to the specification and provide languages that target .NET. Besides compiler writers, application developers should read the CLS and use its rules to guarantee language interoperation.

· CLR Execution

.Net PE Files(Metadata And IL) >> Class Loader >> Verifier >> JIT >> Managed Native Code

Once the class loader has found and loaded the target class, it caches the type information for the class so that it doesn't have to load the class again for the duration of this process.



The verifier is responsible for verifying that:

· The metadata is well formed, meaning the metadata must be valid.
· The IL code is type safe, meaning type signatures are used correctly.

The JIT compilers convert IL to native code so that it can execute on the target operating system. For optimization reasons, JIT compilation occurs only the first time a method is invoked. Recall that the class loader adds a stub to each method during class loading. At the first method invocation, the VEE reads the information in this stub, which tells it that the code for the method has not been JIT compiled. At this indication, the JIT compiler compiles the method and injects the address of the managed native method into this stub. During subsequent invocations to the same method, no JIT compilation is needed because each time the VEE goes to read information in the stub, it sees the address of the native method. Because the JIT compiler only performs its magic the first time a method is invoked, the methods you don't need at runtime will never be JIT compiled. The compiled, native code lies in memory until the process shuts down and until the garbage collector clears off all references and memory associated with the process. This means that the next time you execute the process or component, the JIT compiler will again perform its magic.

If you want to avoid the cost of JIT compilation at runtime, you can use a special tool called ngen, which compiles your IL during installation and setup time. Using ngen, you can JIT-compile the code once and cache it on the machine so that you can avoid JIT compilation at runtime (this process is referred to as Pre-JITting). In the event that the PE file has been updated, you must PreJIT the PE file again. Otherwise, the CLR can detect the update and dynamically command the appropriate JIT compiler to compile the assembly.

· All .NET assemblies are essentially binary components. You can treat each .NET assembly as a component that you can plug into another component or application, without the need for source code, since all the metadata for the component is stored inside the .NET assembly. While you have to perform a ton of plumbing to build a component in COM, you need to perform zero extra work to get a component in .NET, as all .NET assemblies are components by nature. Remember, we're using the term "component" as a binary, deployable unit, not as a COM class.

· Shared Components

Unlike application-private assemblies, shared assemblies - ones that can be used by any client application - must be published or registered in the system Global Assembly Cache (GAC). When you register your assemblies against the GAC, they act as system components, such as a system DLL that every process in the system can use. A prerequisite for GAC registration is that the component must possess originator and version information. In addition to other metadata, these two items allow multiple versions of the same component to be registered and executed on the same machine. Again, unlike COM, we don't have to store any information in the system registry for clients to use these shared assemblies.

· Object Pooling

A pool is technical term that refers to a group of resources, such as connections, threads, and objects. Putting a few objects into a pool allows hundreds of clients to share these few objects (you can make the same assertion for threads, connections, and other objects). Pooling is therefore a technique that minimizes the use of system resources, improves performance, and helps system scalability.

· ADO.NET Architecture

Microsoft ADO.NET's object model encompasses two distinct groups of classes: content components and managed-provider components. The content components include the DataSet class and other supporting classes such as DataTable, DataRow, DataColumn, and DataRelation. These classes contain the actual content of a data exchange. The managed-provider components assist in data retrievals and updates. Microsoft provides two managed providers in its current release of ADO.NET: OLE DB and SQL. The OLE DB managed provider comes with OleDbConnection, OleDbCommand, OleDbParameter, and OleDbDataReader. The SQL Server managed provider comes with a similar set of objects, whose names start with SqlClient instead of OleDb. Developers can use the connection, command, and data reader objects to directly manipulate data.

· We might think that setting up and tearing down connections is not a good idea since the cost of establishing a connection is usually high. This is a concern only in the absence of connection pooling. ADO.NET automatically keeps connections to a data source in a pool, so when an application thinks it is tearing down a connection, it's actually returning it to the resource pool. This allows connections to be reused, avoiding the cost of reconstructing new connections from scratch.

· Because ADO.NET framework classes are managed code, developers can inherit and extend these classes to their custom needs.

· A data reader is a new object providing fast, forward-only, and read-only access to data. This is similar to an ADO Recordset with server-side, forward - only, and read-only cursor types. Since this is a server –side cursor, the connection to the server is open throughout the reading of data.

· Even though each DataAdapter maps only one DataTable in the DataSet, you can have multiple adapters to fill the DataSet object with multiple DataTables.

· Adding Multiple Tables In A Dataset [C#]

public DataSet GenerateDS( ) {

/* Create the DataSet object. */
DataSet ds = new DataSet("DBDataSet");

String sConn = "provider=SQLOLEDB;server=(local);database=pubs;uid=sa;pwd=;";

/* Create the DataSet adapters. */

OleDbDataAdapter dsAdapter1 = new OleDbDataAdapter("select * from authors", sConn);
OleDbDataAdapter dsAdapter2 = new OleDbDataAdapter("select * from titles", sConn);
OleDbDataAdapter dsAdapter3 = new OleDbDataAdapter("select * from titleauthor", sConn);

/* Fill the data set with three tables. */

dsAdapter1.Fill(ds, "authors");
dsAdapter2.Fill(ds, "titles");
dsAdapter3.Fill(ds, "titleauthor");

return ds;

· We can have many different DataAdapters populating the DataSet. Each of these DataAdapters can be going against a completely different data source or data server. In other words, you can construct a DataSet object filled with data that is distributed across multiple servers.

· ADO.NET breaks away from the COM-based recordset and employs XML as its transport data format. Because XML is platform independent, ADO.NET extends the reach to include anyone who is able to encode/decode XML. This is a big advantage over ADO because a COM-based recordset is not platform independent.

· Web Services allow access to software components through standard web protocols such as HTTP and SMTP. Using the Internet and XML, we can now create software components that communicate with others, regardless of language, platform, or culture. Web Services are distributed software components that are accessible through standard web protocols. Microsoft .NET Web Services currently supports three protocols: HTTP GET, HTTP POST, and SOAP (Simple Object Access Protocol).

· HTTP GET and HTTP POST

As their names imply, both HTTP GET and HTTP POST use HTTP as their underlying protocol. Both of these methods encode request parameters as name/value pairs in the HTTP request. The GET method creates a query string and appends it to the script's URL on the server that handles the request. For the POST method, the name/value pairs are passed in the body of the HTTP request message.

· SOAP

Similar to HTTP GET and HTTP POST, SOAP serves as a mechanism for passing messages between the clients and servers. In this context, the clients are web services consumers, and the servers are the web services. The clients simply send an XML-formatted request message to the server to get the service. The server responds by sending back yet another XML-formatted message. SOAP is different than HTTP GET and HTTP POST because it uses XML to format its payload. The messages being sent back and forth have a better structure and can convey more complex information compared to simple name/value pairs in HTTP GET/POST protocols. Another difference is that SOAP can be used on top of other transport protocols, such as SMTP in addition to HTTP.

· Web Services Discovery

Even though advertising of a web service is important, it is optional. Web services can be private as well as public. Depending on the business model, some business-to -business (B2B) services would not normally be advertised publicly. Instead, the web service owners would provide specific instructions on accessing and using their service only to the business partner. To advertise web services publicly, authors post discovery files on the Internet. Potential web services clients can browse to these files for information about how to use the web services—the WSDL (Web Service Description Language). Think of it as the yellow pages for the web service. All it does is point you to where the actual web services reside and to the description of those web services. The process of looking up a service and checking out the service description is called Web Service discovery. There are two ways of advertising the service: static and dynamic. In both of these, XML conveys the locations of web services.

Static discovery is easier to understand because it is explicit in nature. If you want to advertise your web service, you must explicitly create the .disco discovery file and point it to the WSDL.

As opposed to explicitly specifying the URL for all web services your site supports, you can enable dynamic discovery, which enables all web services underneath a specific URL on your web site to be listed automatically. For your web site, you might want to group related web services under many different directories and then provide a single dynamic discovery file in each of the directory.

· Web Services and Security

We incorporate security into web service in two ways: system security and application security. System -level security allows for restricting access to the web services from unauthorized clients. It is done in a declarative fashion, whereas application - level security is more flexible. With system-level security, you will most likely have the list of authorized clients' IP addresses that you will let access your web service through the use of some configuration - management tools. With application-level security, you will incorporate the authentication into your web service, thus providing a more flexible configuration.

In system – level security client send a user name and password to web server. This pair can be in plain text format or in some encrypted format. Once server authenticates the user it can access the services available to server.

In application – level security mode your web services involves taking security into your own hands. You can program your web services so that all of their methods require an access token, which can be obtained from the web service after sending in the client's username and password. The client credentials can be sent to the server through SSL (Secure Sockets Layer), which eliminates the risk of sending clear-text passwords across the wire. Through this SSL channel, the server returns an access token to the caller, who can use it to invoke all other web service methods.

· Web Form Events

The first event that happens in the life of a Web Form is the Init event. This is raised so that we can have initialization code for the page. The controls on the page are not yet created at this point. This event is raised once for each user of the page.

The Load event follows the Init event. Subsequently, it is raised each time the page is requested. When this event is raised, all child controls of the Web Form are loaded and accessible. You should be able to retrieve data and populate the controls so that they can render themselves on the page when sent back to the client.

The PreRender event happens just before the page is rendered and sent back to the client. We don't often handle this event; however, it depends on the situation.

The last event in the life of a Web Form is the Unload event. This happens when the page is unloaded from memory. Final cleanup should be done here.



· Lifecycle Of A Web Form

In ASP .NET, the web page starts its life when a client requests a particular page. IIS parses and runs the scripts on the ASP page to render HTML content. As soon as the page rendering is complete, the page's life ceases; only the view states of the page persist between requests to the page. These view states allow the controls on the server to appear as if they are still present to handle server events.

· Using Web Services

In Visual Studio.NET IDE, you can choose Project >> Add Web Reference and then type in the URL where the web service resides. For example, we'll point to the web service we created on local server, than is PubsWS (suppose). The URL to this web service on our server is http://localhost/PubsWS/PubsWS.asmx. After adding the web reference, you can access the proxy object to the web service you are calling via the type servername.proxyObjectName. For your case, it is localhost.PubsWS.

The following code excerpt demonstrates how to use the web service through the proxy. We create an instance of the proxy object and then ask it to relay the message to the real web service to get the list of authors. The result will be streamed back in XML format, which is reconstructed into a DataSet object.

[C#]

localhost.PubsWS ws = new localhost.PubsWS( );
DataSet ds = ws.GetAuthors( );

· ASP.NET Session-State Management

ASP.NET improves upon ASP session-state management by moving to an out-of-process model. By having all web servers in the farm pointing to a common server that hosts the out-of-process state manager, the web client can be redirected around the farm without losing the session states. By using an out-of-process model, we no longer have the problem of losing session states when the IIS process is cycled. This means that if the web server application crashed for whatever reason and restarted within the session time-out duration, the web clients could still have all their session states intact. Of course, if the out-of-process state manager crashed, that is a whole different issue. This leads to the next improvement of ASP.NET—the ability to persist session state to a database.

· There are two levels of configuration: machine and application. Machine-level configuration associates with the machine.config file stored in WinNT\Microsoft.NET\
Framework\\CONFIG\machine.config, while the application-level configuration uses the web.config file in the application root directory. The application-level configuration overrides the machine -level configuration.