Because Visual Basic was not tied to the operating systems low-level operations, its programmers had to use library calls to access functions of the Win32 Application Programming Interface (API), the library that “defines” Microsoft Windows.
This also accentuated the difference with other programming environments like Microsoft Visual C++ or other libraries like Microsoft Foundation Class (MFC). In fact, although Microsoft shipped Visual Studio 6 that combined various programming environments with different languages (Visual Basic, C++, ASP, Win32, etc), the only real thing they had in common was that they shipped in the same box (and the same DVD).
To unify the various languages or programming environments that Microsoft had developed for many years, the company created a new library aside from Win32. This was the birth of the .NET Framework. This library is used by, or shared among, different programming languages or environments so that programmers can benefit from a better collaboration.
Now it is possible for people who “speak”, that is, people who program in, different languages to work on the same project with less regard for compatibility issues. This is because (most of) the functions, classes, and resources, are used in conceptually the same way in the different languages.
Microsoft Visual Basic .NET is Microsoft’s implementation of the .NET Framework for Visual Basic programmers. Although Visual Basic .NET is a “child” of Visual Basic 6.0, there are many differences that can be interpreted as a complete shift, with a lot of improvements.
Because of these differences, many already Visual Basic 6.0 programmers resisted the move to this new environment (there were also many other considerations) but those programmers are catching up.
- Common Language Runtime
The CLR is the execution engine for the .NET Framework. This runtime manages all code compiled with VB.NET. In fact, code compiled to run under .NET is called managed code to distinguish it from code running outside of the framework. Besides being responsible for application loading and execution, the CLR provides services that will benefit component developers:
- Invocation and termination of threads and processes
- Object lifetime and memory management
- Cross-language integration
- Code access and role-based security
- Exception handling (even across languages)
- Deployment and versioning
- Interoperation between managed and unmanaged code
- Debugging and profiling support (even across languages)
Runtimes are nothing new. Visual Basic has always had some form of a runtime. Visual C++ has a runtime called MSVCRT.DLL. Perl, Python, and SmallTalk also use runtimes. The difference between these runtimes and the CLR is that the CLR is designed to work with multiple programming languages.
Every language whose compiler targets the .NET Framework benefits from the services of the CLR as much as any other language..NET is also similar to Java. Java uses a runtime called the Java Virtual Machine.
It can run only with Java code, so it has the same limitations as the other languages. Another distinction is that the JVM is an interpreter. Although all languages in the .NET environment are initially compiled to a CPU independent language called Intermediate Language (which is analogous to Java byte code), IL is not interpreted at runtime like Java.
When code is initially executed, one of several just-in-time (JIT) compilers translate the IL to native code on a method-by-method basis. Cross-language integration is one of the major benefits provided by the CLR. If a colleague has written a base class in C#, you can define a class in VB.NET that derives from it. This is known as cross-language inheritance.
Also, objects written in different languages can easily interoperate. The two parts of the CLR that make this interoperation possible are the Common Type System and the Common Language Specification. The Common Language Runtime (CLR) is the virtual machine component of Microsoft’s .NET framework and is responsible for managing the execution of .NET programs.
In a process known as Just-in-time compilation, the compiled code is converted into machine instructions that, in turn, are executed by the computer’s CPU.
The CLR provides additional services including memory management, type safety and exception handling. All programs written for the .NET framework, regardless of programming language, are executed by the CLR.
It provides exception handling, garbage collection and thread management. CLR is common to all versions of the .NET framework. The CLR is Microsoft’s implementation of the Common Language Infrastructure (CLI) standard. The Common Type System (CTS) defines rules that a language must adhere to in order to participate in the .NET Framework.
It also defines a set of common types and operations that exist across most programming languages and specifies how these types are used and managed within the CLR, how objects expose their functionality and how they interoperate.
The CTS forms the foundation that enables cross-language integration within .NET. The Common Language Specification (CLS) is a subset of the CTS that describes the basic qualities used by a wide variety of languages.
Components that use only the features of the CLS are said to be CLS-compliant. As a result, these components are guaranteed to be accessible from any other programming language that targets .NET. Because VB.NET is a CLS-compliant language, any class, object, or component that you build will be available from any other CLS-compliant programming language in .NET.
- Managed Execution
The .NET CLR provides a common context within which all .NET applications execute, regardless of the language in which they are written. CLR is responsible for handling every aspects of the managed code such as memory and resource management, secure environment to run in, garbage collection , access to the operating systems services etc. Code that targets the CLR is commonly known as managed code. The managed execution process includes the following steps:
- Choosing a proper compiler
- Generating MSIL code
- Compiling MSIL to CPU specific native code using JIT
- Executing the processor specific code.