You are on page 1of 26

Introduction to .

Net Framework 2011


Introduction The .NET Framework defines an environment that supports the development and execution of highly distributed, component-based applications. It enables differing computer languages to work together and provides for security, program portability, and a common programming model for the Windows platform. The .NET Framework, as the most important new technology for developers for many years, we would not be exaggerating. .NET is designed to provide a new environment within which you can develop almost any application to run on Windows, whereas C# is a new programming language that has been designed specifically to work with .NET. Using C# you can, for example, write a dynamic Web page, an XML Web service, a component of a distributed application, a database access component, a classic Windows desktop application, or even a new smart client application that allows for online/offline capabilities. The .NET Framework (pronounced dot net) is a software framework that runs primarily on Microsoft Windows. It includes a large library and supports several programming languages which allow language interoperability (each language can use code written in other languages). The .NET library is available to all the programming languages that .NET supports. Programs written for the .NET Framework execute in a software environment (as contrasted to hardware environment), known as the Common Language Runtime (CLR), an application virtual machine that provides important services such as security, memory management, and exception handling. The class library and the CLR together constitute the .NET Framework. The .NET Framework's Base Class Library provides user interface, data access, database connectivity, cryptography, web application development, numeric algorithms, and network communications. Programmers produce software by combining their own source code with the .NET Framework and other libraries. The .NET Framework is intended to be used by most new applications created for the Windows platform. Microsoft also produces a popular integrated development environment largely for .NET software called Visual Studio. The Significance of . NET and C# In order to understand the significance of .NET, it is useful to remind ourselves of the nature of many of the Windows technologies that have appeared in the past 10 years or so. Although they may look quite different on the surface, all of the Windows operating systems from Windows 3.1 (introduced in 1992) through Windows Server 2008 have the same familiar Windows API at their core. As we have progressed through new versions of Windows, huge numbers of new functions have been added to the API, but this has been a process of evolving and extending the API rather than replacing it.

Introduction to .Net Framework 2011


The same can be said for many of the technologies and frameworks that we have used to develop software for Windows. For example, COM (Component Object Model) originated as OLE ( Object Linking and Embedding ). At the time, it was, to a large extent, simply a means by which different types of Office documents could be linked, so that, for example, you could place a small Excel spreadsheet in your Word document. From that it evolved into COM, DCOM ( Distributed COM ), and eventually COM+ a sophisticated technology that formed the basis of the way almost all components communicated, as well as implementing transactions, messaging services, and object pooling. Microsoft chose this evolutionary approach to software for the obvious reason that it is concerned about backward compatibility. Over the years, a huge base of third - party software has been written for Windows, and Windows wouldnt have enjoyed the success it has had if every time Microsoft introduced a new technology it broke the existing code base! Although backward compatibility has been a crucial feature of Windows technologies and one of the strengths of the Windows platform, it does have a big disadvantage. Every time some technology evolves and adds new features, it ends up a bit more complicated than it was before. It was clear that something had to change. Microsoft couldnt go on forever extending the same development tools and languages, always making them more and more complex in order to satisfy the conflicting demands of keeping up with the newest hardware and maintaining backward compatibility with what was around when Windows first became popular in the early 1990s. There comes a point where you have to start with a clean slate if you want a simple yet sophisticated set of languages, environments, and developer tools, which makes it easy for developers to write state - of - the - art software. This fresh start is what C# and .NET are all about. Roughly speaking, .NET is a framework an API for programming on the Windows platform. Along with the .NET Framework, C# is a language that has been designed from scratch to work with .NET, as well as to take advantage of all the progress in developer environments and in our understanding of object oriented programming principles that have taken place over the past 20 years. Before we continue, we should make it clear that backward compatibility has not been lost in the process. Existing programs will continue to work, and .NET was designed with the ability to work with existing software. Presently, communication between software components on Windows almost entirely takes place using COM. Taking account of this, .NET does have the ability to provide wrappers around existing COM components so that .NET components can talk to them. It is true that you don t need to learn C# in order to write code for .NET. Microsoft has extended C++, provided another new language called J#, and made substantial changes to Visual Basic to turn it into the more powerful language Visual Basic .NET, in order to allow code written in either of these languages to target the .NET environment. These other languages, however, are hampered by the legacy of having evolved over the years rather than having been written from the start with todays technology in mind.
2

Introduction to .Net Framework 2011


.Net Framework Version History .NET Framework 1.0 This is the first release of the .NET Framework, released on 13 February 2002 and available for Windows 98, Me, NT 4.0, 2000, and XP. Mainstream support by Microsoft for this version ended 10 July 2007, and extended support ended 14 July 2009. NET Framework 1.1 This is the first major .NET Framework upgrade. It is available on its own as a redistributable package or in a software development kit, and was published on 3 April 2003. It is also part of the second release of Microsoft Visual Studio .NET (released as Visual Studio .NET 2003). This is the first version of the .NET Framework to be included as part of the Windows operating system, shipping with Windows Server 2003. Mainstream support for .NET Framework 1.1 ended on 14 October 2008, and extended support ends on 8 October 2013. Since .NET 1.1 is a component of Windows Server 2003, extended support for .NET 1.1 on Server 2003 will run out with that of the OS - currently 14 July 2015. Changes in 1.1 on comparison with 1.0 Built-in support for mobile ASP.NET controls. Previously available as an add-on for .NET Framework, now part of the framework. Security changes - enable Windows Forms assemblies to execute in a semi-trusted manner from the Internet, and enable Code Access Security in ASP.NET applications. Built-in support for ODBC and Oracle databases. Previously available as an add-on for .NET Framework 1.0, now part of the framework. .NET Compact Framework - a version of the .NET Framework for small devices. Internet Protocol version 6 (IPv6) support. Numerous API changes.

.NET Framework 2.0 Released with Visual Studio 2005, Microsoft SQL Server 2005, and BizTalk 2006. The 2.0 Redistributable Package can be downloaded for free from Microsoft, and was published on 22 January 2006. The 2.0 Software Development Kit (SDK) can be downloaded for free from Microsoft. It is included as part of Visual Studio 2005 and Microsoft SQL Server 2005. Version 2.0 without any Service Pack is the last version with support for Windows 98 and Windows Me. Version 2.0 with Service Pack 2 is the last version with official support for Windows 2000 although there have been some unofficial workarounds published online to use a subset of the functionality from Version 3.5 in Windows 2000. Version 2.0 with Service Pack 2 requires Windows 2000 with SP4 plus KB835732 or KB891861 update, Windows XP with SP2 or later and Windows Installer 3.1 (KB893803-v2) . It shipped with Windows Server 2003 R2 (not installed by default).

Introduction to .Net Framework 2011


Changes in 2.0 in comparison with 1.1 Numerous API changes. A new hosting API for native applications wishing to host an instance of the .NET runtime. The new API gives a fine grain control on the behavior of the runtime with regards to multithreading, memory allocation, assembly loading and more (detailed reference). It was initially developed to efficiently host the runtime in Microsoft SQL Server, which implements its own scheduler and memory manager. Full 64-bit support for both the x64 and the IA64 hardware platforms. Language support for generics built directly into the .NET CLR. Many additional and improved ASP.NET web controls. New data controls with declarative data binding. New personalization features for ASP.NET, such as support for themes, skins and web parts. .NET Micro Framework - a version of the .NET Framework related to the Smart Personal Objects Technology initiative. Partial classes Anonymous methods Data Tables Generics

.NET Framework 3.0 .NET Framework 3.0, formerly called WinFX was released on 21 November 2006. It includes a new set of managed code APIs that are an integral part of Windows Vista and Windows Server 2008 operating systems. It is also available for Windows XP SP2 and Windows Server 2003 as a download. There are no major architectural changes included with this release; .NET Framework 3.0 uses the Common Language Runtime of .NET Framework 2.0. Unlike the previous major .NET releases there was no .NET Compact Framework release made as a counterpart of this version. .NET Framework 3.0 consists of four major new components: Windows Presentation Foundation (WPF), formerly codenamed Avalon; a new user interface subsystem and API based on XML and vector graphics, which uses 3D computer graphics hardware and Direct3D technologies. Windows Communication Foundation (WCF), formerly codenamed Indigo; a service-oriented messaging system which allows programs to interoperate locally or remotely similar to web services. Windows Workflow Foundation (WF) allows for building of task automation and integrated transactions using workflows. Windows CardSpace, formerly code-named InfoCard; a software component which securely stores a person's digital identities and provides a unified interface for choosing the identity for a particular transaction, such as logging in to a website.

.NET Framework 3.5


4

Introduction to .Net Framework 2011


Version 3.5 of the .NET Framework was released on 19 November 2007, but it is not included with Windows Server 2008. As with .NET Framework 3.0, version 3.5 uses the CLR of version 2.0. In addition, it installs .NET Framework 2.0 SP1, (installs .NET Framework 2.0 SP2 with 3.5 SP1) and .NET Framework 3.0 SP1 (installs .NET Framework 3.0 SP2 with 3.5 SP1), which adds some methods and properties to the BCL classes in version 2.0 which are required for version 3.5 features such as Language Integrated Query (LINQ). These changes do not affect applications written for version 2.0. As with previous versions, a new .NET Compact Framework 3.5 was released in tandem with this update in order to provide support for additional features on Windows Mobile and Windows Embedded CE devices. Changes since version 3.0 New language features in C# 3.0 and VB.NET 9.0 compiler Adds support for expression trees and lambda methods Extension methods Expression trees to represent high-level source code at runtime. Anonymous types with static type inference Language Integrated Query (LINQ) along with its various providers o LINQ to Objects o LINQ to XML o LINQ to SQL Paging support for ADO.NET ADO.NET synchronization API to synchronize local caches and server side datastores Asynchronous network I/O API. Peer-to-peer networking stack, including a managed PNRP resolver. Managed wrappers for Windows Management Instrumentation and Active Directory Enhanced WCF and WF runtimes, which let WCF work with POX and JSON data, and also expose WF workflows as WCF services. WCF services can be made stateful using the WF persistence model. Support for HTTP pipelining and syndication feeds. ASP.NET AJAX is included

Service Pack 1 The .NET Framework 3.5 Service Pack 1 was released on 11 August 2008. This release adds new functionality and provides performance improvements under certain conditions, especially with WPF where 20-45% improvements are expected. Two new data service components have been added, the ADO.NET Entity Framework and ADO.NET Data Services. Two new assemblies for web development, System.Web.Abstraction and System.Web.Routing, have been added; these are used in the ASP.NET MVC Framework and, reportedly, will be utilized in the future release of ASP.NET Forms applications. Service Pack 1 is included with SQL Server 2008 and Visual Studio 2008 Service Pack 1.It also featured a new set of controls called "Visual Basic Power Packs" which brought back Visual Basic controls such as "Line" and "Shape". .NET Framework Client Profile
5

Introduction to .Net Framework 2011


There is also a new variant of the .NET Framework, called the ".NET Framework Client Profile", which at 28 MB is significantly smaller than the full framework and only installs components that are the most relevant to desktop applications. However, the Client Profile amounts to this size only if using the online installer. When using the off-line installer, the download size is still 250 MB. .NET Framework 4 Microsoft announced the .NET Framework 4 on 29 September 2008. The Public Beta was released on 20 May 2009 Some focuses of this release are: Parallel Extensions to improve support for parallel computing, which target multi-core or distributed systems. To this end, they plan to include technologies like PLINQ (Parallel LINQ), a parallel implementation of the LINQ engine, and Task Parallel Library, which exposes parallel constructs via method calls. New Visual Basic and C# language features, such as statement lambdas, implicit line continuations, dynamic dispatch, named parameters, and optional parameters. Full support for IronPython, IronRuby, and F#. Support for a subset of the .NET Framework and ASP.NET with the "Server Core" variant of Windows Server 2008 R2. Support for Code Contracts. Inclusion of the Oslo modelling platform, along with the M programming language.

On 28 July 2009, a second release of the .NET Framework 4 beta was made available with experimental software transactional memory support. Whether this functionality will be available in the final version of the framework has not been confirmed. On 19 October 2009, Microsoft released Beta 2 of the .NET Framework 4. At the same time, Microsoft announced the expected launch date of .NET Framework 4 as the 22 March 2010. The ship date should be close to, but is not identical to, this date. In conjunction with .NET Framework 4, Microsoft will offer a set of enhancements, codenamed Dublin, for Windows Server 2008 application server capabilities. Dublin will extend IIS to be a "standard host" for applications that use either WCF or WF. There are lot of new features in ASP.Net 4.0 like html, jscript snippets, new development profiles, generate form usage, enablePersistedSelection, web.config transformation, compression enabling for session values etc.

Introduction to .Net Framework 2011

.Net Framework Architecture The Microsoft .NET platform consists of five main components, as shown in Figure 1-1. At the lowest layer lies the operating system (OS), which can be one of a variety of Windows platforms, including Windows XP, Windows 2000, Windows Server 2003, Windows ME, and Windows CE. As part of the .NET strategy, Microsoft has promised to deliver more .NET device software to facilitate a new generation of smart devices. On top of the operating system is a collection of specialized server products that shortens the time required to develop large-scale business systems. These server products include Application Center, BizTalk Server, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, and SQL Server.

Since web services are highly reusable across the Web, Microsoft provides a number of building-block services (officially called .NET Services) that
7

Introduction to .Net Framework 2011


applications developers can use, for a fee. Two examples of .NET Services that Microsoft offers include .NET Passport and .NET Alerts. .NET Passport allows you to use a single username and password at all web sites that support Passport authentication. .NET Alerts allow .NET Alert providers, such as a business, to alert their consumers with important or up-to-the-minute information. Microsoft plans to add newer services, such as calendar, directory, and search services. Third-party vendors are also creating new web services of their own. The top layer of the .NET architecture is a development tool called Visual Studio .NET (VS.NET), which makes possible the rapid development of web services and other applications. A successor to Microsoft Visual Studio 6.0, VS.NET is an Integrated Development Environment (IDE) that supports four different languages and features such as cross-language debugging and the XML Schema Editor. The .NET Framework is a development and runtime infrastructure that changes the development of business applications on the Windows platform. The .NET Framework includes the CLR and a common framework of classes that can be used by all .NET languages. As you can see in Figure 1-2, 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.

Figure 1-2 The .Net Framework Architecture The most important component of the framework is 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,
8

Introduction to .Net Framework 2011


while the JVM officially supports only the Java language, the CLR supports any language that can be represented in its Common Intermediate Language (CIL). The JVM executes bytecode, so it can, in principle, support many languages, too. Unlike Java's bytecode, though, CIL is never interpreted. Another conceptual difference between the two infrastructures is that Java code runs on any platform with a JVM, whereas .NET code runs only on platforms that support the CLR. In April, 2003, the International Organization for Standardization and the International Electrotechnical Committee (ISO/IEC) recognized a functional subset of the CLR, known as the Common Language Interface (CLI), as an international standard. This development, initiated by Microsoft and developed by ECMA International, a European standards organization, opens the way for third parties to implement their own versions of the CLR on other platforms, such as Linux or Mac OS X. In Figure 1-2, the layer on top of the CLR is a set of framework base classes. This set of classes is similar to the set of classes found in STL, MFC, ATL, or Java. These classes support rudimentary input and output functionality, string manipulation, security management, network communications, thread management, text management, reflection functionality, collections functionality, as well as other functions. On top of the framework base classes is a set of classes that extend the base classes to support data management and XML manipulation. These classes, called ADO.NET, support persistent data managementdata that is stored on backend databases. Alongside the data classes, the .NET Framework supports a number of classes to let you manipulate XML data and perform XML searching and XML translations. Classes in three different technologies (including web services, Web Forms, and Windows Forms) extend the framework base classes and the data and XML classes. Web services include a number of classes that support the development of lightweight distributed components, which work even in the face of firewalls and NAT software. These components support plug-and-play across the Internet, because web services employ standard HTTP and SOAP. Web Forms, the key technology behind ASP.NET, include a number of classes that allow you to rapidly develop web Graphical User Interface (GUI) applications. If you're currently developing web applications with Visual Interdev, you can think of Web Forms as a facility that allows you to develop web GUIs using the same drag-and-drop approach as if you were developing the GUIs in Visual Basic. Simply drag-and-drop controls onto your Web Form, double-click on a control, and write the code to respond to the associated event. Windows Forms support a set of classes that allow you to develop native Windows GUI applications. You can think of these classes collectively as a much better version of the MFC in C++ because they support easier and more powerful GUI development and provide a common, consistent interface that can be used in all languages.
9

Introduction to .Net Framework 2011


Visual Studio.NET Framework Editions Visual Studio.NET comes in different editions. You can select edition appropriate for the kind of development you are doing. Following editions of VS.NET are available: - Professional - Enterprise Developer - Enterprise Architecture Visual Studio .NET Professional edition offers a development tool for creating various types of applications mentioned previously. Developers can use Professional edition to build Internet and Develop applications quickly and create solutions that span any device and integrate with any platform. Visual Studio .NET Enterprise Developer (VSED) edition contains all the features of Professional edition plus has additional capabilities for enterprise development. The features include things such as a collaborative team development, Third party tool integration for building XML Web services and built-in project templates with architectural guidelines and spanning comprehensive project life-cycle. Visual Studio .NET Enterprise Architect (VSEA) edition contains all the features of Visual Studio .NET Enterprise Developer edition and additionally includes capabilities for designing, specifying, and communicating application architecture and functionality. The additional features include Visual designer for XML Web services, Unified Modeling Language (UML) support and enterprise templates for development guidelines and policies. .Net Framework Feature Now that we know some basics of .NET, let us see what makes .NET a wonderful platform for developing modern applications. 1. Rich Functionality out of the box .NET framework provides a rich set of functionality out of the box. It contains hundreds of classes that provide variety of functionality ready to use in your applications. This means that as a developer you need not go into low level details of many operations such as file IO, network communication and so on. 2. Easy development of web applications ASP.NET is a technology available on .NET platform for developing dynamic and data driven web applications. ASP.NET provides an event driven programming model (similar to Visual Basic 6 that simplify development of web pages (now called as web forms) with complex user interface. ASP.NET server controls provide advanced user interface elements (like calendar and grids) that save lot of coding from programmers side. 3. OOPs Support
10

Introduction to .Net Framework 2011


The advantages of Object Oriented programming are well known. .NET provides a fully object oriented environment. The philosophy of .NET is Object is mother of all. Languages like Visual Basic.NET now support many of the OO features that were lacking traditionally. Even primitive types like integer and characters can be treated as objects something not available even in OO languages like C++. 4. Multi-Language Support Generally enterprises have varying skill sets. For example, a company might have people with skills in Visual Basic, C++, and Java etc. It is an experience that whenever a new language or environment is invented existing skills are outdated. This naturally increases cost of training and learning curve. .NET provides something attractive in this area. It supports multiple languages. This means that if you have skills in C++, you need not throw them but just mould them to suit .NET environment. Currently four languages are available right out of the box namely Visual Basic.NET, C# (pronounced as C-sharp), Jscript.NET and Managed C++ (a dialect of Visual C++). There are many vendors that are working on developing language compilers for other languages (20+ language compilers are already available). The beauty of multi language support lies in the fact that even though the syntax of each language is different, the basic capabilities of each language remain at par with one another. 5. Multi-Device Support Modern lift style is increasingly embracing mobile and wireless devices such as PDAs, mobiles and handheld PCs. . . .NET provides promising platform for programming such devices. .NET Compact Framework and Mobile Internet Toolkit are step ahead in this direction. 6. Automatic memory management While developing applications developers had to develop an eye on system resources like memory. Memory leaks were major reason in failure of applications. .NET takes this worry away from developer by handling memory on its own. The garbage collector takes care of freeing unused objects at appropriate intervals. 7. Compatibility with COM and COM+ Before the introduction of .NET, COM was the de-facto standard for componentized software development. Companies have invested lot of money and efforts in developing COM components and controls. The good news is you can still use COM components and ActiveX controls under .NET. This allows you to use your existing investment in .NET applications. .NET still relies on COM+ for features like transaction management and object pooling. In fact it provides enhanced declarative support for configuring COM+ application right from your source code. Your COM+ knowledge still remains as a valuable asset. 8. No more DLL Hell If you have worked with COM components, you probably are aware of DLL hell. DLL conflicts are a common fact in COM world. The main reason
11

Introduction to .Net Framework 2011


behind this was the philosophy of COM one version of component across machine. Also, COM components require registration in the system registry. .NET ends this DLL hell by allowing applications to use their own copy of dependent DLLs. Also, .NET components do not require any kind of registration in system registry. 9. Strong XML support Now days it is hard to find a programmer who is unaware of XML. XML has gained such a strong industry support that almost all the vendors have released some kind of upgrades or patches to their existing software to make it XML compatible. Currently, .NET is the only platform that has built with XML right into the core framework. .NET tries to harness power of XML in every possible way. In addition to providing support for manipulating and transforming XML documents, .NET provides XML web services that are based on standards like HTTP, XML and SOAP. 10. Ease of deployment and configuration Deploying windows applications especially that used COM components were always been a tedious task. Since .NET does not require any registration as such, much of the deployment is simplified. This makes XCOPY deployment viable. Configuration is another area where .NET especially ASP.NET shines over traditional languages. The configuration is done via special files having special XML vocabulary. Since, most of the configuration is done via configuration files, there is no need to sit in front of actual machine and configure the application manually. This is more important for web applications; simply FTPing new configuration file makes necessary changes. 11. Security Windows platform was always criticized for poor security mechanisms. Microsoft has taken great efforts to make .NET platform safe and secure for enterprise applications. Features such as type safety, code access security and role based authentication make overall application more robust and secure. .Net Framework Advantages we discuss some of the improved features of .NET in brief. Object - oriented programming Both the .NET Framework and C# are entirely based on object - oriented principles right from the start. Good design A base class library, which is designed from the ground up in a highly intuitive way. Language independence With .NET, all of the languages Visual Basic .NET, C#, J#, and managed C++ compile to a common Intermediate Language . This means that languages are interoperable in a way that has not been seen before.
12

Introduction to .Net Framework 2011


Better support for dynamic Web pages Though ASP offered a lot of flexibility, it was also inefficient because of its use of interpreted scripting languages, and the lack of object oriented design often resulted in messy ASP code. .NET offers an integrated support for Web pages, using a new technology ASP.NET. With ASP.NET, code in your pages is compiled, and may be written in a .NET - aware high - level language such as C# or Visual Basic 2008. Efficient data access A set of .NET components, collectively known as ADO.NET, provides efficient access to relational databases and a variety of data sources. Components are also available to allow access to the file system, and to directories. In particular, XML support is built into .NET, allowing you to manipulate ,which may be imported from or exported to non - Windows platforms. Code sharing .NET has completely revamped the way that code is shared between applications, introducing the concept of the assembly , which replaces the traditional DLL. Assemblies have formal facilities for versioning, and different versions of assemblies can exist side by side. Improved security Each assembly can also contain built - in security information that can indicate precisely who or what category of user or process is allowed to call which methods on which classes. This gives you a very fine degree of control over how the assemblies that you deploy can be used. Zero - impact installation There are two types of assemblies: shared and private. Shared assemblies are common libraries available to all software, whereas private assemblies are intended only for use with particular software. A private assembly is entirely self - contained, so the process of installing it is simple. There are no registry entries; the appropriate files are simply placed in the appropriate folder in the file system. Support for Web services .NET has fully integrated support for developing Web services as easily as you d develop any other type of application. Visual Studio 2008 .NET comes with a developer environment, Visual Studio 2008, which can cope equally well with C++, C#, and Visual Basic 2008, as well as with ASP.NET code. Visual Studio 2008 integrates all the best features of the respective language specific environments of Visual Studio .NET 2002/2003/2005 and Visual Studio 6. C# C# is a new object - oriented language intended for use with .NET.

13

Introduction to .Net Framework 2011

.Net Framework Component Common Language Runtime (CLR) The most important component of the .NET Framework is the Common Language Runtime (CLR). The CLR manages and executes code written in .NET languages and is the basis of the .NET architecture, similar to the Java Virtual Machine. The CLR activates objects, performs security checks on them, lays them out in memory, executes them, and garbage-collects them. The common language runtime facilitates the followings:

Run-time environment o CLR Compiles application into the runtime, compile the IL code into native code, execute the code. Run-time services. o Memory management, o Type safety, o Enforces Security, o Exception Management o Thread support o Debugging support

Understanding Architecture of .NET Framework CLR

14

Introduction to .Net Framework 2011


Class loader, which loads classes into CLR. MSIL to native code compiles, this converts MSIL code into native code. Code manager, this manages the code during execution. Memory allocation and Garbage collector, this performs automatic memory management. Security engine, this enforces security restrictions as code level security folder level and machine level security using tools provided by Microsoft .NET and using .NET Framework setting under control panel. Type checker, which enforces strict type checking. Thread support, which provides multithreading support to applications. Exception manager, which provides a mechanism to handle the runtime exceptions handling. Debug engine, which allows developer to debug different types of applications. COM marshaler, which allows .NET applications to exchange data with COM applications. Base class library support, which provides the classes (types) that the applications need at run time.

Understanding CLR To execute the program and gain all the benefits of managed execution environment we write code in a language which is supported by CLS that is .NET Framework. The language compiler compiles the source code into the MSIL code which consists of CPU- independent code and instructions which is platform independent. MSIL consists of the followings:

Instructions that enables to perform arithmetic and logical operations Access memory directly. Control the flow of execution, Handles exceptions,

MSIL code can be compiling into CPU specific instructions before executing, for which the CLR requires information about the code which is nothing but metadata. Metadata describes the code and defines the types that the code contains as well referenced to other types which the code uses at run time. An assembly consists of portable executable file. At the time of executing PE file the class loader loads the MSIL code and the metadata form the portable executable file into the run time memory. Before the execution of PE file it passes the code to the native code compiler for compilation, IL to native code compilation is done by JIT compiler. For different CPU architecture and compilers for the IL code in to the native instructions. Features of the Common Language Runtime The CLR has the following Fractures

Manages memory, o Allocation of Memory o De-Allocation of Memory (garbage collation)


15

Introduction to .Net Framework 2011


Thread execution support, Code execution, Code safety verification, Compilation. o MSIL to Native Code. Code Security based on Trust (granted permission to execute code. Code level, Folder level, Machine level) These features are intrinsic to the managed code that runs on the common language runtime. Managed multithreading support and monitor the threads. Application domain contains one or more threads to execute. Manages interoperability with unmanaged code, and COM marshaling A structured exception handling mechanism, The infrastructure and managed execution process, memory management and garbage collection.

Common Type System (CTS) Common Type System (CTS) describes how types are declared, used and managed in the runtime and facilitates cross-language integration, type safety, and high performance code execution. The common type system performs the following functions: Establishes a framework that enables cross-language integration, type safety, and high performance code execution. Provides an object-oriented model that supports the complete implementation of many programming languages. Defines rules that languages must follow, which helps ensure that objects written in different languages can interact with each other. The Common Type System can be divided into two general categories of types,

Reference type Value type

Common Type System Architecture

16

Introduction to .Net Framework 2011


Value types represent values allocated on the stack. They cannot be null and must always contain some data. When value types are passed into a function, they are passed by value, meaning that a copy of the value is made prior to function execution. This implies that the original value won't change, no matter what happens to the copy during the function call. Since intrinsic types are small in size and don't consume much memory, the resource cost of making a copy is negligible and outweighs the performance drawbacks of object management and garbage collection. Value types include primitives, structures, and enumerations; They include: Boolean Byte Char DateTime Decimal Double Guid Int16 Int32 Int64 SByte Single Timespan Reference type provides more benefits over a value type. Reference types are so called because they contain references to heap-based objects and can be null. These types are passed by reference, meaning that when you pass such an object into a function, an address of or pointer to the object is passednot a copy of the object, as in the case of a value type. Since you are passing a reference, the caller will see whatever the called function does to your object. The first benefit here is that a reference type can be used as an output parameter, but the second benefit is that you don't waste extra resources because a copy is not made. If your object is large (consuming lots of memory), than reference types are a better choice. In .NET, one drawback of a reference type is that it must be allocated on the managed heap, which means it requires more CPU cycles because it must be managed and garbage-collected by the CLR. In .NET, the closest concept to destruction is finalization, but unlike destructors in C++, finalization is nondeterministic. In other words, you don't know when finalization will happen because it occurs when the garbage collector executes (by default, when the system runs out of memory). Since finalization is nondeterministic, another drawback of reference types is that if reference-type objects hold on to expensive resources that will be released during finalization, system performance will degrade because the resources won't be released until these objects are garbage-collected. Reference types include classes, interfaces, arrays, and delegates Boxing and Unboxing

17

Introduction to .Net Framework 2011


Microsoft .NET supports value types for performance reasons, but everything in .NET is ultimately an object. In fact, all primitive types have corresponding classes in the .NET Framework. For example, int is, in fact, an alias of System.Int32, and System.Int32 happens to derive from System.ValueType, meaning that it is a value type. Value types are allocated on the stack by default, but they can always be converted into a heap-based, reference-type object; this is called boxing. The following code snippet shows that we can create a box and copy the value of i into it: int i = 1; // i - a value type object box = i; // box - a reference object When you box a value, you get an object upon which you can invoke methods, properties, and events. For example, once you have converted the integer into an object, as shown in this code snippet, you can call methods that are defined in System.Object, including ToString( ), Equals( ), and so forth. The reverse of boxing is of course unboxing, which means that you can convert a heap-based, reference-type object into its value-type equivalent, as the following shows: int j = (int)box; Common Language Specification (CLS) A goal of .NET is to support language integration in such a way that programs can be written in any language, yet can interoperate with one another, taking full advantage of inheritance, polymorphism, exceptions, and other features. However, languages are not made equal because one language may support a feature that is totally different from another language. For example, Managed C++ is case-sensitive, but VB.NET is not. In order to bring everyone to the same sheet of music, 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. MSIL (Microsoft Intermediate Language) The code that is output by the C# compiler is written in a language called Microsoft Intermediate Language, or MSIL. MSIL is made up of a specific set of instructions that specify how your code should be executed. It contains instructions for operations such as variable initialization, calling object methods, and error handling, just to name a few. C# is not the only language in which source code changes into MSIL during the compilation process. All .NET-compatible languages, including Visual Basic .NET and Managed C++, produce MSIL when their source code is compiled. Because all of the .NET languages compile to the same MSIL instruction set, and
18

Introduction to .Net Framework 2011


because all of the .NET languages use the same runtime, code from different languages and different compilers can work together easily. MSIL is not a specific instruction set for a physical CPU. It knows nothing about the CPU in your machine, and your machine knows nothing about MSIL. How, then, does your .NET code run at all, if your CPU can't read MSIL? The answer is that the MSIL code is turned into CPU-specific code when the code is run for the first time. This process is called "just-in-time" compilation, or JIT. The job of a JIT compiler is to translate your generic MSIL code into machine code that can be executed by your CPU. You may be wondering about what seems like an extra step in the process. Why generate MSIL when a compiler could generate CPU-specific code directly? After all, compilers have always done this in the past. There are a couple of reasons for this. First, MSIL enables your compiled code to be easily moved to different hardware. Suppose you've written some C# code and you'd like it to run on both your desktop and a handheld device. It's very likely that those two devices have different types of CPUs. If you only had a C# compiler that targeted a specific CPU, then you'd need two C# compilers: one that targeted your desktop CPU and another that targeted your handheld CPU. You'd have to compile your code twice, ensuring that you put the right code on the right device. With MSIL, you compile once. Installing the .NET Framework on your desktop machine includes a JIT compiler that translates your MSIL into CPU-specific code for your desktop. Installing the .NET Framework on your handheld includes a JIT compiler that translates that same MSIL into CPU-specific code for your handheld. You now have a single MSIL code base that can run on any device that has a .NET JIT compiler. The JIT compiler on that device takes care of making your code run on the device. Another reason for the compiler's use of MSIL is that the instruction set can be easily read by a verification process. Part of the job of the JIT compiler is to verify your code to ensure that another reason for the compiler's use of MSIL is that the instruction set can be easily read by a verification process. Part of the job of the JIT compiler is to verify your code to ensure that it is as clean as possible. The verification process ensures that your code is accessing memory properly and that it is using the correct variable types when calling methods that expect a specific type. These checks ensure that your code doesn't execute any instructions that could make the code crash. The MSIL instruction set was designed to make this verification process relatively straightforward. CPU-specific instruction sets are optimized for quick execution of the code, but they produce code that can be hard to read and, therefore, hard to verify. Having a C# compiler that directly outputs CPU-specific code can make code verification difficult or even impossible. Allowing the .NET Framework JIT compiler to verify your code ensures that your code accesses memory in a bug-free way and that variable types are properly used. JIT (Just in Time) JIT compilers play a major role in the .NET platform because all .NET PE files contain IL and metadata, not native code. The JIT compilers convert IL to
19

Introduction to .Net Framework 2011


native code so that it can execute on the target operating system. For each method that has been successfully verified for type safety, a JIT compiler in the CLR will compile the method and convert it into native code. One advantage of a JIT compiler is that it can dynamically compile code that is optimized for the target machine. If you take the same .NET PE file from a one-CPU machine to a two-CPU machine, the JIT compiler on the two-CPU machine knows about the second CPU and may be able to spit out the native code that takes advantage of the second CPU. Another obvious advantage is that you can take the same .NET PE file and run it on a totally different platform, whether it be Windows, Unix, or whatever, as long as that platform has a CLR. 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 VES reads the information in this stub, which tells it that the code for the method has not been JITcompiled. At this indication, the JIT compiler compiles the method and injects the address of the native method into this stub. During subsequent invocations to the same method, no JIT compilation is needed because each time the VES 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.exe, 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. Assemblies An assembly is the logical unit that contains compiled code targeted at the .NET Framework. An assembly is completely self - describing and is a logical rather than a physical unit, which means that it can be stored across more than one file (indeed, dynamic assemblies are stored in memory, not on file at all). If an assembly is stored in more than one file, there will be one main file that contains the entry point and describes the other files in the assembly. Note that the same assembly structure is used for both executable code and library code. The only real difference is that an executable assembly contains a main program entry point, whereas a library assembly does not.
20

Introduction to .Net Framework 2011


An important characteristic of assemblies is that they contain metadata that describes the types and methods defined in the corresponding code. An assembly, however, also contains assembly metadata that describes the assembly itself. This assembly metadata, contained in an area known as the manifest , allows checks to be made on the version of the assembly, and on its integrity. The fact that an assembly contains program metadata means that applications or other assemblies that call up code in a given assembly do not need to refer to the registry, or to any other data source, to find out how to use that assembly. This is a significant break from the old COM way of doing things, in which the GUIDs of the components and interfaces had to be obtained from the registry, and in some cases, the details of the methods and properties exposed would need to be read from a type library. Having data spread out in up to three different locations meant there was the obvious risk of something getting out of synchronization, which would prevent other software from being able to use the component successfully. With assemblies, there is no risk of this happening, because all the metadata is stored with the program executable instructions. Note that even though assemblies are stored across several files, there are still no problems with data going out of synchronization. This is because the file that contains the assembly entry point also stores details of, and a hash of, the contents of the other files, which means that if one of the files gets replaced, or in any way tampered with, this will almost certainly be detected and the assembly will refuse to load. Assemblies come in two types: private and shared assemblies. Private assemblies are the simplest type. They normally ship with software and are intended to be used only with that software. The usual scenario in which you will ship private assemblies is when you are supplying an application in the form of an executable and a number of libraries, where the libraries contain code that should be used only with that application. The system guarantees that private assemblies will not be used by other software because an application may load only private assemblies that are located in the same folder that the main executable is loaded in, or in a subfolder of it. Because you would normally expect that commercial software would always be installed in its own directory, there is no risk of one software package overwriting, modifying, or accidentally loading private assemblies intended for another package. And, because private assemblies can be used only by the software package that they are intended for, you have much more control over what software uses them. There is, therefore, less need to take security precautions because there is no risk, for example, of some other commercial software overwriting one of your assemblies with some new version of it (apart from software that is designed specifically to perform malicious damage). There are also no problems with name collisions. If classes in your private assembly happen to have the same name as classes in someone else s private assembly,
21

Introduction to .Net Framework 2011


that does not matter, because any given application will be able to see only the one set of private assemblies. Because a private assembly is entirely self - contained, the process of deploying it is simple. You simply place the appropriate file(s) in the appropriate folder in the file system (no registry entries need to be made). This process is known as zero impact (xcopy) installation . Shared assemblies are intended to be common libraries that any other application can use. Because any other software can access a shared assembly, more precautions need to be taken against the following risks: Name collisions, where another company s shared assembly implements types that have the same names as those in your shared assembly. Because client code can theoretically have access to both assemblies simultaneously, this could be a serious problem. The risk of an assembly being overwritten by a different version of the same assembly the new version being incompatible with some existing client code. The solution to these problems is placing shared assemblies in a special directory subtree in the file system, known as the global assembly cache (GAC). Unlike with private assemblies, this cannot be done by simply copying the assembly into the appropriate folder it needs to be specifically installed into the cache. This process can be performed by a number of .NET utilities and requires certain checks on the assembly, as well as the set up of a small folder hierarchy within the assembly cache that is used to ensure assembly integrity. To prevent name collisions, shared assemblies are given a name based on private key cryptography (private assemblies are simply given the same name as their main file name). This name is known as a strong name; it is guaranteed to be unique and must be quoted by applications that reference a shared assembly. Problems associated with the risk of overwriting an assembly are addressed by specifying version information in the assembly manifest and by allowing side - by - side installations. Managed vs. Unmanaged Code In general, when you write a C# program, you are creating what is called managed code. Managed code is executed under the control of the Common Language Runtime, as just described. Because it is running under the control of the CLR, managed code is subject to certain constraintsand derives several benefits. The constraints are easily described and met: the compiler must produce an MSIL file targeted for the CLR (which C# does) and use the .NET class library (which C# does). The benefits of managed code are many, including modern memory management, the ability to mix languages, better security, support for version control, and a clean way for software components to interact.

22

Introduction to .Net Framework 2011


The opposite of managed code is unmanaged code. Unmanaged code does not execute under the Common Language Runtime. Thus, Windows programs prior to the creation of the .NET Framework use unmanaged code. It is possible for managed code and unmanaged code to work together, so the fact that C# generates managed code does not restrict its ability to operate in conjunction with preexisting programs. Metadata The compilation process also outputs metadata, which is an important piece of the .NET code sharing story. Whether you use C# to build an end-user application or you use C# to build a class library to be used by someone else's application, you're going to want to make use of some alreadycompiled .NET code. That code may be supplied by Microsoft as a part of the .NET Framework, or it may be supplied by a user over the Internet. The key to using this external code is letting the C# compiler know what classes and variables are in the other code base so that it can match up the source code you write with the code found in the precompiled code base that you're working with. Think of metadata as a "table of contents" for your compiled code. The C# compiler places metadata in the compiled code along with the generated MSIL. This metadata accurately describes all the classes you wrote and how they are structured. All of the classes' methods and variable information is fully described in the metadata, ready to be read by other applications. Visual Basic .NET, for example, may read the metadata for a .NET library to provide the IntelliSense capability of listing all of the methods available for a particular class. If you've ever worked with COM (Component Object Model), you may be familiar with type libraries. Type libraries aimed to provide similar "table of contents" functionality for COM objects. However, type libraries suffered from some limitations, not the least of which was the fact that not all of the data relevant to the object was put into the type library. Metadata in .NET does not have this shortcoming. All of the information needed to describe a class in code is placed into the metadata. You can think of metadata as having all of the benefits of COM type libraries without the limitations. Garbage Collection The garbage collector is .NET s answer to memory management and in particular to the question of what to do about reclaiming memory that running applications ask for. Up until now, two techniques have been used on the Windows platform for de - allocating memory that processes have dynamically requested from the system: Make the application code do it all manually. Make objects maintain reference counts. Having the application code responsible for deallocating memory is the technique used by lower - level, high - performance languages such as C+ +. It is efficient, and it has the advantage that (in general) resources are
23

Introduction to .Net Framework 2011


never occupied for longer than necessary. The big disadvantage, however, is the frequency of bugs. Code that requests memory also should explicitly inform the system when it no longer requires that memory. However, it is easy to overlook this, resulting in memory leaks. Although modern developer environments do provide tools to assist in detecting memory leaks, they remain difficult bugs to track down. That s because they have no effect until so much memory has been leaked that Windows refuses to grant any more to the process. By this point, the entire computer may have appreciably slowed down due to the memory demands being made on it. Maintaining reference counts is favored in COM. The idea is that each COM component maintains a count of how many clients are currently maintaining references to it. When this count falls to zero, the component can destroy itself and free up associated memory and resources. The problem with this is that it still relies on the good behavior of clients to notify the component that they have finished with it. It takes only one client not to do so, and the object sits in memory. In some ways, this is a potentially more serious problem than a simple C++ - style memory leak because the COM object may exist in its own process, which means that it will never be removed by the system. (At least with C++ memory leaks, the system can reclaim all memory when the process terminates.) The .NET runtime relies on the garbage collector instead. The purpose of this program is to clean up memory. The idea is that all dynamically requested memory is allocated on the heap (that is true for all languages, although in the case of .NET, the CLR maintains its own managed heap for .NET applications to use). Every so often, when .NET detects that the managed heap for a given process is becoming full and therefore needs tidying up, it calls the garbage collector. The garbage collector runs through variables currently in scope in your code, examining references to objects stored on the heap to identify which ones are accessible from your code that is, which objects have references that refer to them. Any objects that are not referred to are deemed to be no longer accessible from your code and can therefore be removed. Java uses a system of garbage collection similar to this. Garbage collection works in .NET because IL has been designed to facilitate the process. The principle requires that you cannot get references to existing objects other than by copying existing references and that IL be type safe. In this context, what we mean is that if any reference to an object exists, then there is sufficient information in the reference to exactly determine the type of the object. It would not be possible to use the garbage collection mechanism with a language such as unmanaged C++, for example, because C++ allows pointers to be freely cast between types. One important aspect of garbage collection is that it is not deterministic. In other words, you cannot guarantee when the garbage collector will be
24

Introduction to .Net Framework 2011


called; it will be called when the CLR decides that it is needed, though it is also possible to override this process and call up the garbage collector in your code. Reflection Because assemblies store metadata, including details of all the types and members of these types that are defined in the assembly, it is possible to access this metadata programmatically. This technique, known as reflection , raises interesting possibilities, because it means that managed code can actually examine other managed code, and can even examine itself, to determine information about that code. This is most commonly used to obtain the details of attributes, although you can also use reflection, among other purposes, as an indirect way of instantiating classes or calling methods, given the names of those classes or methods as strings. In this way, you could select classes to instantiate methods to call at runtime, rather than at compile time, based on user input (dynamic binding).

Language Compilation in .Net

25

Introduction to .Net Framework 2011

26

You might also like