UNIT I - VISUAL BASIC .NET AND FRAME WORK The Common Type System- The Common Language Specification- The Common Language Runtime -Microsoft Intermediate Language- Metadata- Executable Code-Managed Execution- Side−by−Side Execution- Understanding Assemblies- Assembly- - Strong Names Introduction to Visual Basic .NET Development environment. COMMON TYPE SYSTEM A key piece of functionality that enables Multiple Language Support is a Common Type System, in which all commonly used data types, even base types such as Longs and Booleans are actually implemented as objects. Since all languages are using the same library of types, calling one language from another doesn't require type conversion or weird calling conventions. For example, what we called an Integer in VB6 and earlier, is now known as a Short in Visual Basic.NET. The common type system defines how types are declared, used, and managed in the runtime, and is also an important part of the runtime's support for cross-language integration. The common type system performs the following functions: Establishes a framework that helps enable 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 LANGUAGE SPECIFICATION Languages that fit into.NET must satisfy the Common Language Specification (CLS), which sets the constraints the languages must meet. If a language adheres to this spec, it gets an appropriate level of language interoperability. There are actually three categories of compliance to the CLS that .NET languages can subscribe to. Briefly they are: Compliant producer – The components in the language can be used by any other language. Consumer – The language can reuse classes produced in any other language. This basically means the ability to instantiate classes in the way that, for example, scripting languages can instantiate COM objects today. Extender – Languages in this category can do more than just instantiate classes – they can also extend those classes using the inheritance features of .NET. All the confirmed languages in the Visual Studio suite (VB, VC++, C#) are expected to satisfy all three categories of the CLS. Third party languages can select the levels of compliance that make sense for them. The .NET Framework includes classes, interfaces, and value types that expedite and optimize the development process and provide access to system functionality. To facilitate interoperability between languages, the .NET Framework types are CLS-compliant and can therefore be used from any programming language whose compiler conforms to the common language specification (CLS). The .NET Framework types are the foundation on which .NET applications, components, and controls are built. The .NET Framework includes types that perform the following functions: Represent base data types and exceptions. Encapsulate data structures. Perform I/O. Access information about loaded types. Invoke .NET Framework security checks. Provide data access, rich client-side GUI, and server-controlled, client-side GUI. The .NET Framework provides a rich set of interfaces, as well as abstract and concrete (non-abstract) classes. You can use the concrete classes as is or, in many cases, derive your own classes from them. To use the functionality of an interface, you can either create a class that implements the interface or derive a class from one of the .NET Framework classes that implements the interface. THE COMMON LANGUAGE RUNTIME The Common Language Runtime is therefore the environment in which we run our .NET applications that have been compiled to a common language, namely Microsoft Intermediate Language (MSIL), often referred to simply as IL. At the base is the Common Language Runtime, often abbreviated to CLR. This is the heart of the .NET framework, the engine that drives key functionality. It includes, for example, a common system of data types. These common types, plus a standard interface convention, make cross-language inheritance possible. In addition to allocation and management of memory, the CLR also does reference counting for objects, and handles garbage collection. Common Type System Intermediate Language Execution Support Security Garbage Collection, Code Manager Class Loader, Memory Layout That small part in the middle, called Execution Support, contains most of the capabilities normally associated with a language runtime (such as the VBRUNxxx.DLL runtime used with Visual Basic). The rest is new, at least for Microsoft platforms. The design of the CLR is based on the following goals: Simpler, faster development Automatic handling of memory management and process communication Good tool support Scalability The most ambitious aspect of the CLR is that it is designed to support multiple languages and allow unprecedented levels of integration among those languages. By enforcing a common type system, and by having complete control over interface calls, the CLR allows languages to work together more transparently than ever before. Previously, one language could instantiate and use components written in another language by using COM. Sometimes calling conventions were difficult to manage, especially when Visual Basic was involved, but it could generally be made to work. It is straightforward in the .NET Framework to use one language to subclass a class implemented in another language. A class written in Visual Basic can inherit from a base class written in C++, or in COBOL for that matter (at least one major vendor is at work on a COBOL implementation for .NET). The VB program doesn't even need to know the language used for the base class, and we're talking full implementation inheritance with no problems requiring recompilation when the base class changes. How can this work? The information furnished by metadata makes it possible. There is no Interface Definition Language (IDL) in .NET because none is needed. A class interface looks the same, regardless of the language that generated it. The CLR uses metadata to manage all the interfaces and calling conventions between languages. MICROSOFT INTERMEDIATE LANGUAGE Microsoft Intermediate Language (MSIL) represents the transient stage in the process of conversion of source code written in any .NET language to machine language as a pseudo-assembly language code that's between the source code you write-such as Visual Basic .NET or C#-and Intel-based assembly language or machine code. When you compile a .NET program, , the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. When we execute the code, MSIL is converted to CPU-specific code, usually by a just-in-time (JIT) compiler. Because the common language runtime supplies one or more JIT compilers, the same set of MSIL can be JIT-compiled and executed on any supported architecture. During compilation of .NET programming languages, the source code is translated into MSIL code rather than machine-specific object code. MSIL is a CPU- and platform-independent instruction set that can be executed in any environment supporting the .NET framework. MSIL code is verified for safety during runtime, providing better security and reliability than natively compiled binaries METADATA Metadata is defined as "data about data". The metadata is generated by a compiler and stored automatically in an EXE or DLL. It's in binary, but the framework offers an API to export metadata to and from an XML schema or a COM type library. Some of the items in the metadata defined for the .NET framework are: • Description of a deployment unit (called an assembly) Name, version, culture (which could determine, for example, the default user language) A public key for verification Types exported by the assembly Dependencies – other assemblies which this assembly depends upon Security permissions needed to run • Base classes and interfaces used by the assembly • Custom attributes User defined (inserted by the developer) Compiler defined (inserted by the compiler to indicate something special about the language) Compilers are some of the most extensive users of metadata. For example, a compiler can examine a module produced by a different compiler and use the metadata for cross-language type import. It can also produce metadata about its own compiled modules, including such elements as flags that a module has compiled for debugging, or a language-specific marker. Even information that might appear in a tool tip can be embedded in metadata. This extendable data store about a compiled module greatly facilitates the simpler deployment available under the .NET Framework. An API, called the Reflection API, is available for scanning and manipulation of metadata elements Managed execution process includes the following steps: Choosing the right compiler .Net Framework is a Multilanguage execution environment, the runtime supports a wide variety of data types and language features. In order to obtain the full benefits provided by the common language runtime , you should use one or more language (VB.Net, C# etc.) compilers that target the runtime Compiling the code to MSIL Unlike the execution style of compiling source code into machine level code, .Net language compilers translate the source code into Microsoft