< Old To New C++ .Net 4 | Main | .Net Framework Class Library 2 >


 

 

The .NET Framework Class Library Review 1

 

 

In the following module we will be introduced to the .NET Framework class libraries. All the topic in this module is listed below. The code snippets if any are based on the new C++ .NET syntaxes.

  1. Introduction

  2. The .NET Framework

  3. The Common Language Runtime (CLR)

  4. Intermediate Language (IL)

  5. The Common Type System (CTS)

  6. The Common Language Specification (CLS)

  7. The .NET Framework Class Library

  8. Naming Conventions

  9. Assemblies

  10. Metadata

-----------Next------------------------------

  1. The .NET Framework Namespaces

  2. Using Namespaces in C++ Programs

  3. The System Namespace

  1. System Interfaces

  2. System Structures (struct)

  3. System Delegates

  4. System Enumerations (enum)

 

  1. Basic Types

  2. Floating-Point Types

  3. Console::WriteLine Examples

  4. The Collections Namespaces

  5. The Diagnostics Namespace

  6. The IO Namespace

  7. The Drawing Namespaces

  8. The Forms Namespace

  9. The Net Namespaces

  10. The Xml Namespaces

  11. The Data Namespaces

  12. The Web Namespaces

  13. .NET Compact Framework

  14. A summary for this module

 

 

Introduction

 

Starting with the .Net Framework class library, in this module we will begin learning on how to build real Microsoft .NET applications such as console applications, Windows forms, databases, web servers, and all the other mechanisms needed by the modern Microsoft Windows application if possible and that’s where the .NET Framework comes in. The .NET Framework is the new library of classes that you use to build Windows applications. It is large, quite complex, and far-reaching in its scope. This module will give you an overview of what the .NET Framework is and what it can do before we cover some of its features in more detail in later modules.

 

The .NET Framework

 

The .NET Framework is a computing platform that has been designed by Microsoft to simplify the development of modern applications, such as:

  1. Applications that use sophisticated GUI front ends.

  2. Applications that use the Internet.

  3. Applications that are distributed over more than one computer.

  4. Applications that make sophisticated use of databases.

 

There are two main components to the .NET Framework:

 

  1. The common language runtime (CLR) and

  2. The .NET Framework class library.

 

The Common Language Runtime (CLR)

 

You’ve already met some of the common language runtime, because this is the part of .NET that provides the “management” in the Managed Extensions for C++ (from this section, just forget about Managed Extensions for C++). The CLR is a run-time execution engine that is responsible for executing code within the .NET environment, providing services such as security, memory management, and remoting (communication between objects in different domains, processes, or computers). Code that is run by the CLR is known as managed code; code that executes outside the control of the CLR is unmanaged code. All Microsoft Visual Basic .Net and C# code is managed, but it’s possible to write both managed and unmanaged code in Microsoft Visual C++ and to have both types of code working together in the same program.

 

 

Intermediate Language (IL)

 

All .NET languages compile down into an intermediate form called intermediate language, or IL. Formerly known as MSIL, for Microsoft intermediate language, now known as Machine Symbolic Intermediate Language. IL is similar to Java bytecode, in that it’s an intermediate form of code produced by the compiler that can’t be directly executed on a target system. IL code is also portable. In contrast to Java, however, IL code is always converted into native code before it’s executed, which is done by a Just-In-Time (JIT) compiler. This conversion might happen on demand, function-by-function as a program executes, or all at once when a program is installed. One of the great innovations of IL is that it isn’t simply a low-level, machine- independent object code. In fact, support for object-oriented functionality, such as the ideas of classes, encapsulation and data hiding, polymorphism, and inheritance, is built into IL, so you can view it as a type of object-oriented assembler language. This functionality makes it far more powerful than Java bytecode, and it allows you to perform cross-language object-oriented programming, easily calling members in managed C++ classes from Visual Basic .Net and vice-versa, and even inheriting from a managed C++ class in Visual Basic. If you’re interested in seeing what IL looks like, you can use the IL Disassembler tool, ILDASM, to open a .NET executable and show you the code in IL.

 

The Common Type System

 

The Common Type System (CTS) provides a specification for how types are defined, managed, and used, which is an important part of the .NET cross-language integration. The CTS provides a set of rules that languages must obey, which helps to ensure that types created in different languages can interoperate with one another.

 

The Common Language Specification

 

The Common Language Specification (CLS) is a set of rules and constraints that compiler and library writers need to follow to make sure that the languages and code they produce will interoperate with other .NET languages. The CLS forms a subset of the CTS, and if a language or a library is CLS-compliant, it will completely interoperate with other CLS-compliant languages. You’ll see in the online documentation that some .NET member functions are marked as not CLS-compliant, which means that they might not be accessible from some .NET languages. For example, functions that use unsigned integers are not CLS-compliant because unsigned integers aren’t supported by Visual Basic .Net. As a result, unsigned integers are not included in the types specified by the CLS.

 

The .NET Framework Class Library

 

The .NET Framework class library is an object-oriented library of classes that provides all the tools you need to write a wide variety of programs. Over the years since Windows was first released, programmers have written Windows applications using the Windows API (application programming interface). This API such as Win32 gives you a large number, several thousand, of C functions that you can call from your programs to interact with Windows. However, there are two main problems with the Windows API:

 

  1. First, it isn’t object-oriented, and

  2. Second, it’s a C library, so it can’t easily be used from every language.

 

One of the benefits of object-oriented programming is the help that it gives in structuring and managing large-scale projects. The Windows API has grown to several thousand functions, and it gets harder and harder to manage such a large collection of unstructured routines. In addition to its other benefits, such as encapsulation and polymorphism, object-oriented programming lets you impose a structure onto code. So, for example, a Dialog class can contain all the functions relating to dialog boxes. This ability makes it much easier to use a library the size of the Windows API. The second problem with the Windows API is that it’s basically written for C programmers, so it uses many features that are unique to C, such as pointers and null-terminated strings, which makes it hard and sometimes impossible to use some functionality from languages other than C or C++. You also tend to need a lot of ugly “plumbing” to interface between languages such as Visual Basic .Net and the API.

The .NET Framework class library provides a set of classes that can be used from any .NET language because it works at the IL level. All .NET languages compile down to the same intermediate code, and because they all use references and agree on the basic set of value types, they can all use the classes defined in the class library. This is a huge step forward and provides language interoperability on a scale never seen before. In the past, compiler vendors who supported more than one language, have added features to their compilers to make it simple to mix their languages in multi-language applications, but no one has produced a language-independent programming framework on the scale of the .NET Framework before. The first release of the .NET Framework is on the Windows platform, but it has been designed so that it can be ported to other platforms as well.

 

 

Naming Conventions

 

.NET Framework types use a dot syntax naming scheme that connotes a hierarchy. This technique groups related types into namespaces so they can be searched and referenced more easily. The first part of the full name, up to the rightmost dot, is the namespace name. The last part of the name is the type name. For example:

System.Collections.ArrayList represents the ArrayList type, which belongs to the System.Collections namespace.

The types in System.Collections can be used to manipulate collections of objects. This naming scheme makes it easy for library developers extending the .NET Framework to create hierarchical groups of types and name them in a consistent, informative manner. It is expected that library developers will use the following guideline when creating names for their namespaces:

CompanyName.TechnologyName

For example, the namespace Microsoft.Word conforms to this guideline. The use of naming patterns to group related types into namespaces is a very useful way to build and document class libraries. However, this naming scheme has no effect on visibility, member access, inheritance, security, or binding. A namespace can be partitioned across multiple assemblies and a single assembly can contain types from multiple namespaces. The assembly provides the formal structure for versioning, deployment, security, loading, and visibility in the common language runtime. Take note that in Visual C++ .Net the dot (.) is replaced by the scope operator (::). You will find that Visual Basic .Net and C# use the dot.

 

Assemblies

 

Assemblies are the basic building blocks from which .NET applications are constructed, and they’re the fundamental unit of deployment and versioning. Assemblies contain IL code, metadata that describes the assembly and its contents, and any other files needed for run-time operation. An assembly is therefore much more self-contained than a standard Windows executable or COM object because there is no reliance on external sources of information such as the Windows Registry. Every .NET type is part of an assembly, and no .NET type can exist outside an assembly. There are several ways in which assemblies are fundamental to the .NET world:

  1. Versioning - The assembly is the smallest unit to which versioning is applied, and the assembly manifest describes the assembly’s version together with the versions of any assemblies on which it depends. This information means that it’s possible to check that components with the wrong version information aren’t being used at run time.

  2. Deployment - Assemblies are loaded only as needed, which makes them highly suitable for distributed applications.

  3. Type - A type’s identity includes the assembly in which it lives. Two types with the same name living in two different assemblies are considered to be two completely different types.

  4. Security - The boundary between assemblies is where security permissions are checked.

 

Metadata

 

.NET classes are self-describing in that they carry descriptive information with them in the EXE or DLL. This information, called metadata, includes the following information:

  1. The name, version, and culture-specific information (such as the language and calendar used) for the assembly.

  2. The types that are exported by the assembly.

  3. Other assemblies that this one depends on.

  4. Security permissions needed to run.

  5. Information for each type in the assembly: name, visibility, base class, interfaces implemented, and details of members.

  6. Additional attribute information.

 

Most of the metadata is standard and is created by the compiler when it produces the IL code, but you can use attributes to add extra metadata information. The following simple exercise shows you how to modify the standard metadata produced by the compiler.

 

1.        Create a CLR Console Application project named Meta1 (shown below are the steps for Visual C++ .Net 2005).

 

CLR console application new project page

 

Figure 1

 

The main project file, Meta1.cpp

 

Figure 1

 

 

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8

 


 

< Old To New C++ .Net 4 | Main | .Net Framework Class Library 2 >