User:Prernasancheti

Its General Idea About .NET........

Common Language Runtime (CLR)

As part of Microsoft's .NET Framework, the Common Language Runtime (CLR) is programming that manages the execution of programs written in any of several supported languages, allowing them to share common object-orientedclass es written in any of the languages. The Common Language Runtime is somewhat comparable to the Java Virtual Machine that Sun Microsystems furnishes for running programs compiled from the Java language. Microsoft refers to its Common Language Runtime as a "managed execution environment." A program compiled for the CLR does not need a language-specific execution environment and can easily be moved to and run on any system with Windows 2000 or Windows XP . Programmers writing in any of Visual Basic , Visual C++ , or C# compile their programs into an intermediate form of code called Common Intermediate Language ( CIL ) in a portable execution ( PE ) file that can then be managed and executed by the Common Language Runtime. The programmer and the environment specify descriptive information about the program when it is compiled and the information is stored with the compiled program as metadata . Metadata, stored in the compiled program, tells the CLR what language was used, its version, and what class libraries will be needed by the program. The Common Language Runtime allows an instance of a class written in one language to call a method of a class written in another language. It also provides garbage collecting (returning unneeded memory to the computer), exception handling, and debugging services.

Component Component Object Model is a method to facilitate communication between different applications and languages. There are many other ways to structure software components. What makes COM interesting is that it is a widely accepted interoperability standard. In addition, the standard explains the way the memory should be organized for all the objects. Interfaces are the contract between the client and the server, i.e. an interface is the way in which an object exposes its functionality to the outside world. In COM, an interface is a table of pointers to functions implemented by the object. The table represents the interface, and the functions to which it points are the methods of that interface.

Interface In the field of computer science, an interface is a tool and concept that refers to a point of interaction between components, and is applicable at the level of both hardware and software. This allows a component, whether a piece of hardware such as a graphics card or a piece of software such as an internet browser, to function independently while using interfaces to communicate with other components via an input/output system and an associated protocol.

What is COM? Component Object Model (COM) is a binary-interface standard for software componentry introduced by Microsoft in 1993. It is used to enable interprocess communication and dynamic object creation in a large range of programming languages. The term COM is often used in the Microsoft software development industry as an umbrella term that encompasses the OLE, OLE Automation, ActiveX, COM+ and DCOMtechnologies. Microsoft COM (Component Object Model) technology in the Microsoft Windows-family of Operating Systems enables software components to communicate. COM is used by developers to create re-usable software components, link components together to build applications, and take advantage of Windows services. COM objects can be created with a variety of programming languages. Object-oriented languages, such as C++, provide programming mechanisms that simplify the implementation of COM objects. The family of COM technologies includes COM+, Distributed COM (DCOM) and ActiveX® Controls. Microsoft provides COM interfaces for many Windows application programming interfaces such as Direct Show, Media Foundation, Packaging API, Windows Animation Manager, Windows Portable Devices, and Microsoft Active Directory (AD). COM is used in applications such as the Microsoft Office Family of products. For example COM OLE technology allows Word documents to dynamically link to data in Excel spreadsheets and COM Automation allows users to build scripts in their applications to perform repetitive tasks or control one application from another.

Advantages of COM 1. Object Oriented All the COM objects are Object Oriented as its name implies. There are three basic Object Oriented concepts: a. Encapsulation: This is implemented by the interfaces provided by the COM Objects. Those interfaces hide the implementation details from the end user and provides the functionality to the user. By that, the user just needs to know what interface methods to call, to do a specific operation provided by that COM object. b. Polymorphism: This is often called “One Method Multiple Interfaces”. A COM object could define a single method to perform a specific operation; but that operation could be implemented through various interfaces/ways. c. Inheritance: When we want to incorporate some additional functionalities to an existing COM object, we can enhance the existing COM object by inheriting a new COM object from it. COM incorporates all those three concepts in it.

2. Loose Coupling In a software, that uses COM objects, we can easily replace an existing COM object with another COM object written in entirely another language as long as the signatures of the methods in both the COM objects remain same. In that case, there will not be any change in the existing software code that uses the COM object.

3. Easy Transition Let us suppose that a software uses a specific COM object provided by a third party. At some point of time, that third party might upgrade that COM object to incorporate some additional functionalities. At this time, if we would like to use the latest version of that COM object in our software, we can just remove the existing (old) version of that COM object and place this new version of COM into our software as long as the signatures of the methods in the old version of the COM object do not change in the new version. But this is a standard for any COM objects provided by third parties and for anybody who develops COM objects. If they upgrade the existing version of COM object, they will not alter the existing signatures but might add some optional parameters to those methods; But that will not affect the existing system to function properly. So even if we develop a COM object and would like to upgrade, then we should keep in mind the existing method signatures. At any point of time the existing system should not get affected by upgrading to a newer version of COM. This is rather a defined norm in developing COM objects. So transition is easy.

4. Binary Language Since most of the COM libraries are in binary language, it could be used by any application written in any language. So COM is language neutral. This is one of the main advantages of COM; it's language independent.

5. Resource utilization: Every COM object will be destroyed automatically as long as no client is using that object actively. This is implemented by COM using a technique called reference counting. Every COM object will maintain a reference count(the number of clients using that COM object); Once that count reaches zero(that means no clients actively using that COM object), then that COM object will be destroyed automatically. With this approach, we can increase resource utilization in an application. Resources such as memory will be best utilized by releasing the inactive/unused COM objects.

IUknown Interface Enables clients to get pointers to other interfaces on a given object through the QueryInterface method, and manage the existence of the object through the AddRefand Release methods. All other COM interfaces are inherited, directly or indirectly, from IUnknown. Therefore, the three methods in IUnknown are the first entries in the VTable for every interface. Use IUnknown methods to switch between interfaces on an object, add references, and release objects. The IUnknown interface has the following methods. Method Description AddRef Increments the reference count for an interface on an object. QueryInterface Retrieves pointers to the supported interfaces on an object. Release Decrements the reference count for an interface on an object.

Dynamic Link library Dynamic-link library , is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems. These libraries usually have the file extension DLL, OCX(for libraries containing ActiveXcontrols), or DRV (for legacysystem drivers). The file formats for DLLs are the same as for Windows EXE files — that is,Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for 16-bitWindows. As with EXEs, DLLs can contain code, data, and resources, in any combination. In the broader sense of the term, any data file with the same file format can be called a resource DLL. Examples of such DLLs include icon libraries, sometimes having the extension ICL, and font files, having the extensionsFON and FOT.[citation needed]

DLL Server COM makes it possible to create DLL servers that can be loaded into a surrogate EXE process. This combines the ease of writing DLL servers with the benefits of executable implementation. Development tools like Microsoft Visual Studio facilitate the writing of DLL servers, but a DLL server in itself has limits. Running the DLL server in a surrogate process offers several possible benefits: • Fault isolation and the ability to service multiple clients simultaneously. • In a distributed environment, a DLL server implementation could be used to service remote clients. • It could permit clients to help protect themselves from untrusted server code while allowing them access to the services the DLL server provides. • Running a DLL server in a surrogate provides the DLL with the surrogate's security. • COM provides a default surrogate process, or you can write a custom surrogate if you have special needs. Although DLL servers are normally run in-process with the client application, it is possible to "wrap" a DLL server inside another EXE application that will serve as its "host" (or surrogate). By doing this, any DLL server can be used as if it was an EXE server simply because the host executes out-of-process. Microsoft Transaction Server (MTS) is an example of a DLL host application.

.Net architecture

.NET Framework Architecture .NET is tiered, modular, and hierarchal. Each tier of the .NET Framework is a layer of abstraction. .NET languages are the top tier and the most abstracted level. The common language runtime is the bottom tier, the least abstracted, and closest to the native environment. This is important since the common language runtime works closely with the operating environment to manage .NET applications. The .NET Framework is partitioned into modules, each with its own distinct responsibility. Finally, since higher tiers request services only from the lower tiers, .NET is hierarchal. The architectural layout of the .NET Framework is illustrated in Figure

Figure An overview of the .NET architecture. .NET Framework is a managed environment. The common language runtime monitors the execution of .NET applications and provides essential services. It manages memory, handles exceptions, ensures that applications are well-behaved, and much more. Language interoperability is one goal of .NET. .NET languages share a common runtime (the common language runtime, a common class library), the Framework Class Library (FCL), a common component model, and common types. In .NET, the programming language is a lifestyle choice. Except for subtle differences, C#, VB.NET, or JScript.NET offer a similar experience. .NET abstracts lower-level services, while retaining most of their flexibility. This is important to C-based programmers, who shudder at the limitations presented in Visual Basic 6 and earlier. Let us examine each tier of the .NET Framework as it relates to a managed environment, language interoperability, and abstraction of lower-level services. Managed Languages and Common Language Specification .NET supports managed and unmanaged programming languages. Applications created from managed languages, such as C# and VB.NET, execute under the management of a common runtime, called the common language runtime. There are several differences between a compiled managed application and an unmanaged program. • Managed applications compile to Microsoft Intermediate Language (MSIL) and metadata. MSIL is a low-level language that all managed languages compile to instead of native binary. Using just-in-time compilation, at code execution, MSIL is converted into binary optimized both to the environment and the hardware. Since all managed languages ultimately become MSIL, there is a high degree of language interoperability in .NET. • Metadata is data that describes data. In a managed application, also called an assembly, metadata formally defines the types employed by the program. • Wave a fond goodbye to the Registry. Managed applications are sweeping away the Registry, Interface Definition Language (IDL) files, and type libraries with a single concept called metadata. Metadata and the related manifest describe the overall assembly and the specific types of an assembly. • Managed applications have limited exposure to the unmanaged environment. This might be frustrating to many programmers, particularly experienced C gurus. However, .NET has considerable flexibility. For those determined to use unmanaged code, there are interoperability services.

.NET Assemblies In .NET, a managed application is called an assembly. An assembly adheres to the traditional Portable Executable (PE) format but contains additional headers and sections specific to .NET. MSIL and metadata are the most important new additions to the .NET PE. When the .NET Framework is installed, a new program loader recognizes and interprets the .NET PE format. In future Windows operating systems, the first being .NET Server, the .NET loader is automatically provided. What is a managed language? If someone wants to create Forth.NET, are there established guidelines? Common Language Specification (CLS) is a set of specifications or guidelines defining a .NET language. Shared specifications promote language interoperability. For example, CLS defines the common types of managed languages, which is a subset of the Common Type System (CTS). This removes the issue of marshaling, a major impediment when working between two languages.

XML Web Services Web services are the basis of the programmable Web and distributed applications that transcend hardware and operating environments. Web services are not unique to Microsoft. Microsoft, IBM, Sun, and other vendors are promoting Web services as integral components of their recent initiatives. Web services promote remote function calls over the Internet. The promotion and hype surrounding Web services has been deafening. A Web service exposes functionality to the entire world—any device at any time. Not coincidentally, this is the very definition of .NET and explains the importance of a Web server to .NET. Anyone with Web-enabled software, such as a browser, that understands HTML and HTTP can access a Web service. Any device, large or small, that is Web enabled can access a Web service. This revolutionizes embedded devices, bringing an array of services to these devices that were not previously practical. The Internet never closes, which means that Web services are available 24/7. The explosion of computers and PDAs that are continuously wired to the Internet creates a burgeoning audience for Web services.XML Web services are part of ASP.NET and leverage open standards, such as HTTP and XML, to publish public functions to the Internet. In addition, creating Web services in .NET is remarkably easy. Web pages publish presentation data with limited functionality over the Internet. Open standards, namely HTML and HTTP, are the backbone of Web pages and deliver them to almost anyone with a browser. Web services expose functionality over the Internet using open standards—the combination of HTTP, XML, SOAP, and the Web Service Description Language (WSDL), which are the underpinning of this exciting technology. SOAP is the preferred protocol for XML Web services. Visual Studio .NET removes the challenge of creating a Web service. Developers can create Web services with limited or no knowledge of SOAP, XML, or WSDL. The first step is to create an ASP.NET Web service project. The new project is a starter kit for a Web service application. A Web service class, sample Web method, web.config file, global.asx file, and the remaining plumbing of a Web service are provided. See Figure 1.4. The developer is left with only one task—writing the functions to be exposed as Web methods. Consuming a Web service is equally easy. Start by creating a proxy from the WSDL of the Web service. Create the proxy in Visual Studio .NET by adding a Web reference or externally using the WSDL.exe tool. After creating the proxy, compile it into the Web service client or into a separate assembly, and then bind it to the client. In the client code, create an instance of the proxy and call the Web service methods as local functions. The proxy connects to the Web service, uses SOAP to invoke a remote method, and then return any values. The parameters, return value, and other Web service data are transported in XML envelopes.

Figure 1.4 The Web service class and method are generated for the ASP.NET Web service project.

.NET Remoting .NET Remoting is a second option for remoting objects in the .NET Framework. The first mentioned was XML Web services. .NET Remoting is similar to Web services conceptually. However, with .NET Remoting the developer chooses the transmission protocol, data protocol, data port, and other aspects of the remoting architecture necessary to open a channel for client-server communication. In essence, a developer is setting the specifications of the remoting infrastructure. In this way, .NET Remoting offers unlimited possibilities. Like Web services, .NET Remoting can leverage open standards, such as XML, HTTP, and SMTP. .NET Remoting is fully extensible. Custom or and proprietary standards can also be plugged in. The namespace for .NET Remoting is System.Runtime.Remoting. Remoted objects can be copied or used as a reference (marshal-by-reference). If copied, the object is duplicated in the address area of the client and is then accessible as a local object. Alternately, remoted objects can be accessed by reference via a proxy that connects to the object on the server machine. The indirection of a proxy affects performance. However, not all remoted objects are good candidates for copying. Some are either too large, have software dependencies on the server side, or require the server machine. For server-side or referenced objects, .NET controls the activation of remoted objects as either Singleton or SingleCall objects. Singleton objects are created once, then shared among multiple clients. With SingleCall objects, each client receives a unique instance of the remoted object. RemotingConfiguration.Reg-isterWellKnownServiceType is the method that establishes the activation mode. Like MSRPC (Microsoft RPC), the server application must be running for clients to connect. There is no Service Control Manager (SCM), as exists in COM, to bootstrap .NET Remoting server applications.Example of .NET Remoting can be found in Chapter 5, "Role-Based Security." Common Language Runtime The common language runtime is the engine of .NET and the common runtime of all managed languages. In addition, as the final layer resting atop of the operating environment, the CLR provides the first level of abstraction. Since assemblies run within the context of the common language runtime, they are independent of the underlying operating environment and hardware. Assemblies or managed code are portable to any environment offering a .NET-compliant common language runtime, as defined by the Common Language Infrastructure (CLI). Managed code is managed by the common language runtime. common language runtime manages security, code verification, type verification, exception handling, garbage collection, a common runtime, and other important elements of program execution. When an assembly is executed, mscoree.dll is loaded into the memory of the running process, and the imported entry point _CorExeMain is called. Mscoree contains the common language runtime, which then manages the executing application. Of the many services offered by the common language runtime, we will focus on the two most important: code execution and memory management. Just-in-Time Compilation Assemblies contain MSIL, which is converted into native binary and executed at runtime, using a process aptly named Just-in-Time compilation, or jitting. An assembly is subjected to two compilations. First, managed code is compiled to create the actual assembly. Managed compilers, such as csc and vbc, compile C# and VB.NET source code into an assembly that contains MSIL and metadata. Second, the assembly is compiled at load time, converting the MSIL into native binary that is optimized for the current platform and hardware. When an assembly is jitted, an in-memory cache of the binary is created and executed. Just-in-Time compilers are called Jitters. There is a Jitter for each supported hardware architecture. Converting an entire program to native binary may be inefficient and compromise the performance of the application. The Jitter converts to binary only methods that are called; there's no need to convert methods that are never used to native code. Only the parts of the program used during the current execution are loaded into memory, which conserves resources. When the assembly is loaded, the class loader stubs the methods of each class. At this time, the stubs point to a Jitter routine that converts MSIL to native binary. Upon invocation of a stubbed method, the conversion routine is called that compiles MSIL into native binary, which is then cached in memory. The stub is then updated to point to the in-memory location of the native binary and the code is executed. Future calls to the same function skip the conversion routine and execute the native binary directly. If you chart the runtime performance of a jitted assembly, you will see a series of small peaks and valleys. Based on usage patterns, the type of application, and the size of the application, this may not be the most efficient model for executing the assembly. Consider a large application in which the user touches 80 percent of the functionality and where performance is a concern. A few peaks and valleys may not be noticeable, but a few hundred might be problematic. In this scenario, a different model will work better. In the alternate model, you compile and cache the native binary of the entire assembly. Running the assembly from the cache should improve performance. Instead of a blizzard of peaks and valleys, the new chart would show an acute spike at the beginning and then flat line for the remainder of the program. To adopt the later model, use the Ngen tool to generate the cached native image of the .NET assembly.

--Prernasancheti (talk) 10:07, 17 May 2011 (UTC)