• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
 Inside .NET 
Introduction
The .NET architecture addresses an important need - language interoperability. As more than onelanguage can be converted to the same intermediate language (MSIL - Microsoft IntermediateLanguage), the code compiled through two different high-level languages can interact at anintermediate code level. This gives you the ability to work in different languages depending on your requirements, and still benefit from the unified platform to which the code for any .NET compliantlanguage is compiled. To understand the internals of .NET, it is essential to keep this core idea in mind.Also, understanding the internal details of .NET is essential to exploit the advanced features likeruntime code generation and reflection. Visual Studio .NET is shipped with many tools, such as anassembly linker, that are best understood and used only when the programmer has a goodunderstanding of the internals of .NET. When you understand how the runtime executes, the structureof the executable files that your compiler generates, the garbage collection process, etc, you arenaturally in a better position to program and make the best use of .NET. The objective of this case studyis to present you with the internal details of .NET so as to put you in a better position to make use of various tools (shipped with .NET) and techniques (for programming in .NET).
System Requirements
It is preferable that the reader has access to a compiler of one of the .NET languages, preferably C# as programming examples are provided in C#. The programmers with good understanding of a .NETlanguage are in a better position to understand the internals of .NET. (The full .NET SDK can bedownloaded by following this link:http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml&frame=true.
An Overview of .NET
What does the .NET Framework Provide?
The .NET Framework is aimed at providing various services to the applications and serves as a runtimeenvironment for execution of applications. The core philosophy of .NET is simple:
provide a valuable,common set of services for applications that can be used irrespective of the source language
. .NETsupports a variety of source languages - from object oriented languages to procedural/structuredlanguages. The language compilers compile the code as a mix of intermediate language code (MSIL)and metadata (data describing the type) targeting the .NET platform. The runtime of .NET takes care of converting the code to native code for that platform and executing it. Thus, the primary objective of .NET is to provide proper interoperability and communication between applications. Before .NET, itwas done using internal APIs, RPC (Remote Procedure Calls), OLE (Object Linking and Embedding),and ActiveX controls. .NET integrates many such technologies and services that existed separately and provides a unified platform.The .NET Framework enables a number of services to deploy different kind of applications with areliable installation in a simplified methodology (easy deployment in the form of assemblies) andsupports full backward compatibility when you install new versions of existing components and DLLswithout any compatibility problems (referred to as
versioning
). This environment facilitates securityand safety by means of automatic memory management, runtime support of components, and code
 
verification. The support of serialization helps a wide variety of pre-existing industry open standardslike HTTP, XML, and SOAP without introducing new ones.
Common Language Runtime (CLR)
The Common Language Runtime plays a very significant role in .NET - it manages the execution of thecode and also provides many services to the code (such as garbage collection and interoperability withCOM components). Logically, it can be considered to have the following parts:
Common Type System (CTS) and Microsoft Intermediate Language (MSIL)
Common Language Specification (CLS)
Virtual Execution System (VES) and the Just-In-Time (JIT) compiler CLR is the execution engine that loads, compiles, and executes the MSIL code by converting it intonative code. It interacts with the operating system to provide the execution services for the .NETFramework, which in turn provides services to the applications that are run on .NET. The runtime playsmany roles and provides several services: it ensures code reusability, provides automatic memorymanagement services to avoid memory leaks, verifies types and parameters to guarantee that the codewill not cause any security breaches, ensures consistent cross language inheritance and exceptionhandling, manages threads and processes, and supports developer services such as debugging (by usinga built-in stack walking facility in runtime) and profiling.
Common Type System (CTS)
The .NET platform makes it easy for code written in one language to be used in any other .NETlanguage (meaning that components written in one CLS compliant language could be used byapplications written in any other CLS compliant language). This interoperability could not be achievedif every language had its own set of data types associated with it. So, the .NET Framework supports aCommon Type System (CTS) which provides a rich set of data types so that various high-levellanguages can compile the source code to .NET making use of a common set of data types (so that thecomponents can be used easily from some other source language). In essence, CTS provides a set of common types to ensure that components are interoperable regardless of the source language in whichthe component was developed.CTS also strictly enforces type safety - it specifies rules for type visibility, object lifetime, and for access to the members in the assemblies (assemblies are discussed a bit later). Even an object in onelanguage can be passed as a parameter of a method in another language without any problem.Language interoperability enables code reusability and improves the productivity of applicationdevelopment.Let me give a few examples. Not all languages support unsigned types - for example, Visual Basicdoesn't support unsigned types, whereas C++ does. When a component is developed using C++ makinguse of unsigned types, it is difficult (and bug-prone) to make use of a component in Visual basic (as VBdoesn't support unsigned types). CTS is designed to overcome exactly these kinds of problems. CTSdoes not support unsigned types (except byte type, which is unsigned by default). Other issuesregarding the use of types are also resolved. For example, the sizes of value types are predefined andremain the same across languages. Consider the following example:
// in C#.NETpublic double dbl;// or in VB.NETPublic dbl As Double
 
Here, a double variable is declared in both C#.NET and VB.NET - the variable dbl resolves to theSystem.Double type which occupies 8 bytes. In other words, whatever the source language, if a datatype supported by CTS is used, then the component can be used without any problem in another sourcelanguage.
CLS Compliance
In order to achieve cross-language interoperability, the languages targeting .NET should follow a set of rules and guidelines for creating components that can be used by the code in some other sourcelanguage. Unless the code conforms to such a minimum set of rules and guidelines, the code may notmake use of the services that the .NET Framework provides. It is also not possible to ensure that thecode can be used properly in some other source language if the rules are not followed properly.For example, a few programming languages support operator overloading, but many languages do not.Language such as C# support operator overloading, whereas Visual J# doesn't. The component thatmakes use of operator overloading may not be used properly in a language where that feature is notsupported. However, this is not a problem if the same feature is used internally. This is a significant problem, as achieving 'language interoperability' is the main objective of .NET.To overcome such problems, there is a common set of rules and guidelines defined to facilitatelanguage interoperability. A component that conforms to such a set of rules and guidelines can be usedin any .NET language and it is referred to as a 'Common Language Subset - Compliant' (CLS-Compliant) component.
The Execution Model
To understand the internals of .NET, we need to have a very good idea of how program source codegets finally executed in .NET. Program code may be written in any source language, and to execute itwe need a compiler for that language targeting the .NET platform (such as VB.NET and Effiel.NETcompilers). The language compiler compiles the source code to the intermediate format as assemblies(that contain MSIL and metadata). Ultimately, the code gets executed in the .NET Framework - this isirrespective of the source language in which the code is written.When the code needs to be executed, the runtime takes over the control and verifies the content (for security reasons and to make sure that the code is typesafe). Finally, the intermediate code is convertedinto native code and gets executed. The code can make use of the rich class library and the servicesavailable in the .NET Framework.Thus the intermediate files (where the compiled code is stored) plays an important role in .NETtechnology and that is covered in the following section.
PE Files and Assemblies
In .NET, the unit of deployment is the PE (Portable Executable) file - a predefined binary standard(also referred to as Common Object File Format - COFF file format). It is made up of collection of modules, exported types and resources and is put together as an .exe file. It is very useful in versioning,deploying, sharing, etc. The modules in PE file are known as assemblies.
PE Files
A Portable Executable (PE) file contains MSIL code for .NET languages instead of storing assemblylanguage code (such as native x86 machine code). A PE file consists of a CLR header followed by
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...