Introduction
Microsoft has secured certification for both C# and CLI from ECMA and ISO/IEC as Industry standards. This is a very important step for Microsoft and .NET platform because this enhances the credibility of the newer .NET platform and allures a larger portion of technology industry into adopting .NET as their development platform. Several companies and government organizations only utilize ISO certified technologies; for example, in Australia anything ISO certified is also considered Australian standard according to the rules of the Australian government. Several academic institutions will now be interested in teaching standard C#. Another major outcome of having an open industry standard specification is .NET platform could be getting ported to other platforms like Linux and UNIX; the best example is the Mono Project by Ximian- it is an open source implementation of .NET platform for UNIX and Linux based on ECMA approved Public Domain Specification of C# and CLI. Microsoft submitted the specifications to ECMA, which in turn fast-tracked them through ISO. In doing so, Microsoft released all intellectual property in the core C#/CLI platform to the public domain. No one needs a license to implement C#/CLI. This will also help everybody in better understanding the implementations of C# and CLI which are at the core of .NET platform.
Microsoft has implemented .NET Framework for all of its operating system suits (excluding Microsoft Windows 95 and earlier) on all supported hardware platforms. For handheld and small devices, Microsoft has released a compact framework of .NET. But, there are various other implementations being developed on platforms other than Microsoft Windows. The most popular implementation, after Microsoft .NET, is the open source ‘Mono’ Project on Linux. Microsoft has released almost all the source code of their .NET Framework for FreeBSD and Mac OS under the title of Shared Source Common Language Infrastructure (SSCLI).
Difference Between Traditional Development and .NET Development
In traditional programming languages, the source code of a program is compiled to a specific platform’s assembly language and then machine language code. Later the library code required by the program is linked to it. Finally the operating system executes the program when desired by the user. The complete process is depicted in the following figure:
In the presence of .NET Framework, a program is not compiled to the native machine executable code; rather it gets compiled to an intermediate language code called Microsoft Intermediate Language (MSIL) or Common Intermediate Language (CIL). The .NET Common Language Runtime (CLR) then converts this intermediate code at runtime to the machine executable code. The optimization is carried out at runtime. A program also does not call the operating system APIs directly; rather it delegates this task to the CLR which performs the desired operations on behalf of the program and returns the results of the operations back to the program. The CLR also performs the memory management, garbage collection, security and thread management on behalf of the program. .NET Framework is shipped with the supporting object oriented framework of common code libraries, called the .NET Framework Class Library (FCL), to facilitate the common operations. Hence .NET manages the overall execution of an application. This is the reason why the code running on .NET Framework is sometimes called the managed code. The complete process is depicted in the following Figure. Note that only the CLR (and thus the .NET framework and not the user application) is interacting and coupled with the platform and operating system.
The basic components of .NET platform (framework) are:
Common Language Runtime (CLR):
The most important part of the .NET Framework is the .NET Common Language Runtime (CLR) also called .NET Runtime in short. It is a framework layer that resides above the Operating System and handles/manages the execution of the .NET applications. Our .NET programs don't directly communicate with the Operating System but through CLR.
MSIL (Microsoft Intermediate Language) Code:
When we compile our .NET Program using any .NET compliant language like (C#, VB.NET, C++ .NET), it does not get converted into the executable binary code but to an intermediate code, called MSIL or IL in short, understandable by CLR. MSIL is an OS and H/w independent code. When the program needs to be executed, this MSIL or intermediate code is converted to binary executable code, called native code. The presence of IL makes it possible for the Cross Language Relationship as all the .NET compliant languages produce the similar standard IL code.
Just In Time Compilers (JITers)
When our IL compiled code needs to be executed, CLR invokes JIT compilers which compile the IL code to native executable code (.exe or .dll) for the specific machine and OS. JITers in many ways are different from traditional compilers as they, as their name suggests, compile the IL to native code only when desired, e.g., when a function is called, IL of function’s body is converted to native code; just in time of need. So, the part of code that is not used by particular run is not converted to native code. If some IL code is converted to native code, then the next time when its needed to be used, the CLR uses the same copy without re-compiling. So, if a program runs for sometime, then it won't have any just in time performance penalty. As JITers are aware of processor and OS exactly at runtime, they can optimize the code extremely efficiently resulting in very robust applications. Also, since JITer knows the exact current state of executable code, they can also optimize the code by in-lining small function calls (like replacing body of small function when its called in a loop, saving the function call time). Although, Microsoft stated that C# and .NET are not competing with languages like C++ in efficiency, speed of execution, JITers can make your code even faster than C++ code in some cases when program is run over extended period of time (like web-servers).
Framework Class Library (FCL)
.NET Framework provides a huge set of Framework (or Base) Class Library (FCL) for common, usual tasks. FCL contains thousands of classes to provide the access to Windows API and common functions like String Manipulation, Common Data Structures, IO, Streams, Threads, Security, Network Programming, Windows Programming, Web Programming, Data Access, etc. It is simply the largest standard library ever shipped with any development environment or programming language. The best part of this library is they follow extremely efficient OO design (design patterns) making their access and use very simple and predictable. You can use the classes in FCL in your program just as you use any other class and can even apply inheritance and polymorphism on these.
Common Language Specification (CLS)
Earlier we used the term ‘.NET Compliant Language’ and stated that all the .NET compliant languages can make use of CLR and FCL. But what makes a language ‘.NET compliant language’? The answer is Common Language Specification (CLS). Microsoft has released a small set of specification that each language should meet to qualify as a .NET Compliant Language. As IL is a very rich language, it is not necessary for a language to implement all the IL functionality, rather it meets the small subset of it, CLS, to qualify as a .NET compliant language, which is the reason why so many languages (procedural and OO) are now running under .NET umbrella. CLS basically addresses language design issues and lays certain standards like there should be no global function declaration, no pointers, no multiple inheritance and things like that. The important point to note here is that if you keep your code within CLS boundary, your code is guaranteed to be usable in any other .NET language.
Common Type System (CTS)
.NET also defines a Common Type System (CTS). Like CLS, CTS is also a set of standards. CTS defines the basic data types that IL understands. Each .NET compliant language should map its data types to these standard data types. This makes it possible for the 2 languages to communicate with each other by passing/receiving parameters to/from each other. For example, CTS defines a type Int32, an integral data type of 32 bits (4 bytes) which is mapped by C# through int and VB.Net through its Integer data type.
Garbage Collector (GC)
CLR also contains Garbage Collector (GC) which runs in a low-priority thread and checks for un-referenced dynamically allocated memory space. If it finds some data that is no more referenced by any variable/reference, it re-claims it and returns the occupied memory back to the Operating System; so that it can be used by other programs as necessary. The presence of standard Garbage Collector frees the programmer from keeping track of dangling data.
The Software Development and Execution Flow in Microsoft.NET
With .NET development environment, a developer can write his/her code in any .NET compliant programming language like C#, VB.NET, J#, C++.NET, etc. In fact, various modules, components, projects of an application can be written and compiled in different .NET based programming languages. All these components are compiled to the same Intermediate language code (MSIL or CIL) understandable by the .NET CLR.
At runtime, the .NET assembly (compiled IL code) is translated to native machine code and executed by the CLR.
Microsoft .NET compared with Java based platforms (J2EE)
At root level architecture and components, Microsoft .NET and J2EE platforms are very similar. Both are virtual machine based architecture having CLR and Java Virtual Machine (JVM) as the underlying virtual machine for the management and execution of programs. Both provide memory, security and thread management on behalf of the program and both try to decouple the applications with the execution environment (OS and physical machine). Both, basically, target the Web based applications and especially the XML based web services. Both provide managed access to memory and no direct access to memory is allowed to their managed applications.
However, there are few contrasts in the architecture and design of the two virtual machines. Microsoft .NET framework’s architecture is more coupled to the Microsoft Windows Operating System which makes it difficult to implement it on various operating systems and physical machines. Java, on the other hand, is available on almost all major platforms. At the darker side, J2EE architecture and JVM is more coupled to the Java programming language while Microsoft .NET has been designed from scratch to support language independence and language integration. Microsoft .NET covers the component development and integration in much more detail than Java. The versioning policy of .NET is simply the best implemented versioning solution in the software development history. Java has got the support of industry giants like Sun, IBM, Apache and Oracle while the Microsoft .NET is supported by giants like Microsoft, Intel, and HP.
Microsoft .NET for Software Development
Well, most of the software development all over the world is done on and for Microsoft Windows Operating System. .NET is now the standard software development environment for the Microsoft Windows operating system. It dramatically simplifies the development of windows, web based, data access applications, components, controls and web services. .NET comes with amazing features like XML configuration, reflection, and attributes to ease the overall software development life cycle. Finally, the .NET is supported by the Microsoft Visual Studio Integrated Development Environment; the best IDE available for any software development environment. Visual Studio .NET (VS.NET) supports all the areas of software development from project creation to debugging and installation.
Shortcomings of Microsoft .NET Platform
The foremost shortcoming of .NET platform is that it is still the propriety of Microsoft. It is more coupled with the Microsoft Windows operating system and is implemented only on Microsoft Windows successfully. Microsoft .NET desktop applications can run only on Microsoft Windows, Web based applications and web services can only be deployed on Microsoft Internet Information Server (IIS). Since, .NET framework contains a lot of utilities, components, and framework class libraries, the size of downloadable framework is quite large (25MB compared to 5MB size of JVM). Not all types of applications can be written in .NET managed applications, for example, you can't write CLR or Operating System in your managed applications. The managed .NET applications are somewhat slower to start and run than the traditional Win32 applications. The compiled code of .NET managed applications is easier to de-compile back to the source code.
How True it is that .NET and Java programs are quite in-efficient when compared to C++
The startup of managed .NET and Java programs is definitely slower than the traditional C++ programs as it involves the hosting of CLR into managed application process in .NET and starting the JVM in a new process in case of Java. The execution also is a bit slower during the initial period of program execution as the intermediate code is translated to the machine code on the fly at runtime. But as the program runs various parts repeatedly, the execution gets pace too. Since, the CLR and JVM optimizes the code more efficiently than the static C++ compilers, the execution speed of the program may actually be faster after sometime of the program startup when most of the code is translated. Hence, in the longer run, the .NET and Java based programs should not be in-efficient when compared to C++. We used ‘should’ here as the actual performance depends on the particular implementation and implementation strategy.
Using COM Components in .NET
.NET does not encourage the use of COM component directly inside the managed application! Although, the .NET Framework contains utilities that enable COM components to be used inside the .NET applications seamlessly. How it is done? The .NET utilities like TlbImp generate the wrapper .NET assembly for the COM component which provides the same calling interface to the client as exposed by the COM component. Inside the wrapper methods, it calls the actual methods of the COM component and returns the result back to the caller. The generated wrapper .NET assembly is called the ‘Runtime Callable Wrapper’ or RCW.
To use a COM component in your Visual Studio .NET project, you need to add a reference of the COM component in the Reference node of the project node of the solution inside the solution explorer window. The great thing about Visual Studio .NET is that it allows you to add a reference to the COM component in exactly the similar way as you add the reference to the .NET assembly. The Visual Studio .NET automatically creates the runtime callable wrapper assembly for the referenced COM component.
To add a reference to a COM component, right click the ‘Reference’ node under the project node inside the Solution Explorer and select the ‘Add Reference…’ option. It will show you a user interface screen where you browse for the target COM component. When you have selected the component, press the ‘Select’ button and then press OK. This will add a new reference node in the Reference sub tree of the project. By selecting the added reference node, you can edit its properties from the properties window.
The process of importing a COM component into .NET is called ‘COM interoperability with .NET.
History
- 13th January, 2008: Initial post
