Lecture 13- The NET Framework

Outline In the last lecture, we continued our discussion of Objects…

By finishing our our own custom Collection: JTrainCollection By inheriting from the .NET System Class, CollectionBase.

And illustrated its use, with a generalized Multiple-JTrain Example, Including the addition of two Shared Members.

We now continue our discussion with some related topics: The .NET Framework and .NET Framework Classes

Which provide us with a platform for Windows Application Development; And supporting basis for our Object-oriented approach:

Namespaces Which place a hierarchical structure on all .NET Classes…

Both the Framework Classes, and Developer Classes

Inheriting From Object Think back to when we first defined JTrain…

We used a default New() Constructor provided ‘by the System’. So…where did this Constructor come from?

Recall that we later used JTrain’s default Constructor… When we made our first instance of JFreightTrain:

We used the Inherits Keyword to get this functionality: JFreightTrain Inherits from JTrain

So, this type of behavior implies Inheritance. However, we did NOT use the ‘Inherits’ keyword when we defined JTrain.

In turns out that all VB Objects automatically inherit from Object… So that the Class Object serves as the universal Base Class.

Even though the VB Keyword ‘Inherits’ is not necessary, for this. Several useful methods are thus available from Object, including:

ToString() : returns a String representation of the Object (we’ve used this). GetType() : returns a Type Object, representing the Object’s data type

This brings us to a discussion of the .NET Framework Classes To discuss this, we first need to discuss the .NET Framework.

Windows Application Development

In this class, we have discussed Windows Application Development Now, let’s talk a little bit about the underlying systems…

The .NET platform and how it relates to Objects. The Windows O.S. and its interface with developed software.

All software written by developers must communicate with Windows: To store data, a block of memory must be reserved:

The Windows Memory Manager is called. To write data to the disk:

The Windows Disk Subsystem is called. To draw a Window on the screen:

The Windows Graphics Subsystem is called.

This communication is supported by the Win32 API The Windows 32 Abstract Programming Interface.

The Windows 32 API

The Win API provides a layer of abstraction via a set of interfaces… And a set of associated programs for implementing these interfaces.

Each of which provides a standard hand-shake with a Windows Subsystem.

Examples: When a file is to be written or read, a standard DialogBox is provided:

From the API’s Common Dialog Box Library. When a Window is to be drawn on the screen:

The API’s User Interface is used, together with the Common Control Library.

In the past, Windows developers used the Win32 API directly… Using a Software Development Kit (SDK) which included:

The Win32 API. Tools to assist in use of the Win32 APU.

However: the API is difficult to learn and tricky to use! Ex: Roughly 100 lines of code required to draw a basic Window.

VB: Abstracting away the API VB helped by providing developers with a big simplification:

Tricky API functions were packaged in an user-friendly way. In VB, a Window can be drawn with only a few lines of code…

Which provide many more details, ‘hidden underneath’…

Thus, VB provides an Abstraction Layer on top of the Windows API So users don’t have to deal with the API directly. This was greatly responsible for the big success of VB.

This situation was quite frustrating for non-VB developers… C++ and Java developers have their own advantages:

C++ provides lots of control over program function... Java makes programs extremely portable.

However, development tasks that are easy in VB e.g., GUI development. Take a really long time in Java, for instance.

This VB-Windows dependency was also dangerous for Microsoft: What happens if Windows is no longer dominant in 20 years?

The .NET Framework Classes In 1992, Microsoft improved this situation quite a bit....

By introducing the Microsoft Foundation Classes (MFC)… A set of C++ Classes, each of which provides a wrapper:

Encapsulating and simplifying an API function. Essentially, providing an Object Oriented layer of abstraction on the API.

Along with the Visual Studio IDE.

Later, Microsoft recast this concept within the larger .NET Framework.

The .NET Framework is completely object-oriented: Anything done in .Net will be done using an Object.

Ex: To to open a file, you use a System Object designed for this purpose. This set of objects is actually a huge set of Base Classes (approx. 3500)

called the .NET Framework Classes.

All .NET developers will use this same set of classes… Regardless of the platform they are on!

Windows, Linux, Pocket PC, Mac… Very developer-friendly!

Regardless of the high-level language (HLL) they choose! VB .NET, C++, C#, J# (.NET version of Java), etc.

Common Language Infrastructure This is accomplished by compiling HLL code in two steps:

First to Microsoft Intermediate language: CIL (Common Intermediate Language; also called MSIL).

All high-level languages are compiled to this same CIL code. This language is NOT dependent on any processor or platform.

Then to platform-specific native (machine) code later on… At runtime, by the Common Language Runtime (A Virtual Machine):

So-called ‘Just-In-Time’ (JIT) Compilation.

So, the Common Language Infrastructure, CLI = CIL + CLR

In this way, Microsoft freed itself from its dependence on Windows… As well, in principle, as its dependence on Intel Chip sets.

Note that the Java concept is similar: It is also compiled to an intermediate language, called ‘Byte Code’.

Which then runs in the Java Virtual Machine. However, while Java is “One Language / Many Platforms”…

.NET started as ‘Many Languages / One Platform’ (and then expanded).

Common Language Runtime (CLR) The Heart of the .NET Framework is the CLR, which handles:

Loading and Executing Code: The primary task of JIT Compilation (Most) languages supported by the CLR are referred to as ‘Managed Code’.

Application Isolation: Individual applications should run separately :

So that they may crash separately from the OS. Idea: Prevent software-based system crashes (Blue Screen of Death)

Applications now have built-in security: Code requires ‘evidence’ to run in CLR (determined via programmer-set policies). In contrast, old Windows applications have unlimited access to system data.

Inter-language Interoperability: Available Data Types are shared by all managed languages…

Exception Handling and Memory Management: Provide appropriate structures for error recovery (we’ve discussed this).

Formally, the CLR consists of 4 elements: A JIT Compiler and a Virtual Execution System (VES, or Virtual Machine) The Common Language Runtime (CLR) and Specification (CLS)

Achieving Language Interoperability Language interoperability in .NET goes beyond common compilation:

The idea is really much more general: It would be best if classes which are defined/extended in one language…

Are then freely available to all. Example: Our JTrain Class should be extendable by a C# Programmer

So that the Classes will function properly in a C# program (!)

.NET introduced the Common Type System (CTS) to support this: Primitive data types are handled the same in all managed languages…

Integers, Doubles, Strings, etc are defined consistently. Previously, they were defined differently, in different HLLs.

This simplifies the job of interoperability between languages.

.NET also introduced the Common Language Specification (CLS): Along with managed code comes the concept of managed data…

Nearly all CLR-managed Data are represented as Objects. Specifically: Classes in the .NET Framework and derived Classes

These can be passed between managed languages.

This brings us back to the .NET Framework…

Overview of the CLI

The .NET Framework Classes

The .NET Framework consists of two components: The Common Language Runtime (Actually, the CLI). The .NET Framework Classes.

A huge set (> 3500) of Base Classes for developer use. A bit hard to navigate…

Fortunately, the Framework Classes are conveniently divided into related groups. Each group is associated with a specific Namespace. The overall collection of namespaces is hierarchical:

Namespaces can contain other namespaces. Created by stringing together the namespaces with the dot (.) operator

Each class must belong to exactly 1 namespace: Its ‘containing’ namespace, followed by its specific Class name.

The System Namespace

Most Framework Classes are contained in the System namespace. In fact, we have already been using System Classes extensively… Examples:

System.Windows.Forms – Classes for drawing Forms System.Console – A Class for designing Console Applications System.Object – Here, we see that Object derives from Class System.

We were allowed to use abbreviated versions… Ex: We used Console.ReadLine() rather than System.Console.ReadLine()

Now, we talk about finding Namespaces and Namespace Creation:

Finding the Current Namespace

Using the Object Browser

Creating Your Own Namespace

Multiple Inheritance

Some languages support Multiple Inheritance By which Objects can combine behaviors from several ‘superclasses’.

Sounds interesting…but this can cause ambiguity troubles. Examples:

C++ permits multiple inheritance Java technically does not…

but supports the use of multiple interfaces, instead.

In the .NET Framework, Multiple-inheritance is not allowed. Each Class must be derived (directly inherit) from exactly one Class.

In other words, only 1 Class can be included in a Class’s Inherits Clause. Recall: all Objects ultimately inherit from System.Object

For derived Classes, there will be a chain of inheritance-relationships: JFreightTrain inherited from JTrain…

JTrain inherited from System.Object.

Preview: Software Engineering

In the next course, we continue with our tour of VB .NET: Advanced topics in OO Programming, including:

Partial and Abstract Classes Interfaces and Generics

Creating Class Libraries Which encapsulate related sets of Classes for re-use. Registering your Libraries…

So that you can find the classes of your library with the Object Browser.

Creating Custom Controls Custom Graphics Then, some related technologies:

Database Access (ADO.NET) Server-Side Programming (ASP.NET)

In the Software Engineering Seminar, we will discuss using C# .... This will allow us to do Embedded Programming ( Course 4 )

You may not get much C# until the seminar.

We will probably look at J# concurrently (Microsoft’s version of Java)

Conclusion and Final Project

In this Course, we discussed Application Programming Fundamentals: Specifically: development for Windows Applications. Along the way, we discussed:

The most frequently-used Controls. Basic and Advanced topics in Object Oriented Programming.

In the next course, we will continue with a more VB .NET: Advanced OO Topics Creating Class Libraries Creating Custom Controls Custom Graphics. Then, some related technologies:

Database Access (ADO.NET) Server-Side Programming (ASP.NET)

The C# language will be discussed in my seminar… To allow us to do Embedded Programming ( Course 4 )

Now, let’s discuss your FINAL PROJECT.