What Are the Pieces and How Do They Fit Together? A .NET Framework Overview

Where do we start? The reason this chapter is titled "Visual Basic .NET from the Ground Up" is that we really do start at the bottom. Conceptually, the Visual Basic .NET compiler sits atop the .NET Framework. The Visual Basic .NET compiler simply exposes various parts of the .NET Framework that are specific to the Visual Basic language. The Visual Basic compiler enforces syntax, but all of the real action occurs at the level of the .NET Framework.

At the heart of the .NET Framework is the common language runtime. The CLR manages execution of .NET code and provides services that make the development process easier. Compilers and tools make the runtime's functionality available. Code that you write that targets the runtime is known as managed code. The CLR manages the code for, among other operations, cross-language integration and exception handling, starting and killing threads, security, versioning, and deployment support.

The CLR makes it easy for Visual Basic .NET developers to design and build applications whose objects can interact with objects written in other languages. This interaction is possible because the various language compilers and development tools that target the CLR use a common data type system defined by the runtime. Visual Basic .NET includes new data types, and older Visual Basic 6 types, such as the variant, are no longer supported. These changes were to accommodate the CLR specifications. (I'll start discussing the new data types and implications for developers in Chapters 2 and 3.) How you experience the runtime depends on which language compiler you use—each one exposes a slightly different subset of runtime functionality. But what the compiler does expose is identical across languages. This brings to mind one word—interoperability.

Let's take a look at all the moving parts of the .NET Framework. As shown in Figure 1-1, at the top level is the Visual Basic compiler (as well as compilers for many other languages). Below the compiler is the common language specification (CLS). This specification is a set of rules that govern the minimum language features that must be supported to ensure that a language will interoperate with other CLS-compliant components and tools. As long as a language conforms to the CLS, it is guaranteed to work with the CLR. In this way, when third-party compilers target the .NET Framework, as long as they conform to the CLS, the code is guaranteed to run.

As you can see from the illustration, Visual Basic is now a peer of C++, C#, and any other language targeting .NET. Visual Basic .NET now has the same variable types, arrays, user-defined types, classes, graphical forms, visual controls, and interfaces as these other languages. This common structure makes calling a class in one .NET language from another .NET language effortless.

Figure 1-1 also indicates that you can use the Visual Studio .NET integrated development environment (IDE) to program with Visual Basic and target the .NET platform. Because the new IDE is similar to the Visual Basic 6 IDE (although more streamlined), Visual Basic programmers will immediately feel at home.

An overview of the .NET Framework.

Web Services

Web Services provide a Web-enabled user interface with tools that include various Hypertext Markup Language (HTML) controls and Web controls. Web Services also handle various Web protocols, security, and session state. The beauty is that the Web Services idiom is the same as that for Windows Forms, which are part of the User Interface component next to Web Services. You can build a Web form just as easily as a Windows form, which reduces the learning curve for .NET development. Web Forms applications generate standard HTML 3.2, permitting the form to be rendered on any browser on any platform without you having to do a thing. If you have ever struggled to write code to detect the brand of client browser and the particular version of the browser that's running and then substitute the correct scripting code, you will really appreciate this.

User Interface

At the same level as Web Services is the User Interface. This block represents the design information for Windows (or PC-based) forms. The User Interface is where Windows forms live. It also provides code for drawing to the screen, printing, rendering text, and displaying images. A sophisticated two-dimensional drawing capability is also built-in that will permit advanced users to do things like create gradient color buttons, once the province only of C++ programmers.

Data and XML

Both Web Services and the User Interface sit on top of the Data and XML block. As you progress through this book, you will learn just how important eXtensible Markup Language (XML) is to passing data over the Internet. If you are familiar with HTML, you will note a similarity. While both HTML and XML use markup tags, HTML markup is used for instructions about how to display data, while XML markup is used to describe and represent data. Both work hand-in-hand with the SOAP protocol, which permits instructions and data to be encapsulated in XML and wrapped in an HTML file that can be sent through corporate firewalls. All firewalls permit text to be sent through Port 80, the port for browsing Web sites. SOAP is text based, so no rogue ports that could be compromised by hackers need to be opened to accommodate the SOAP format.


	XML is rapidly becoming the lingua franca of the Web. You have probably read that XML has taken center stage for moving data across the Internet, so it is central to the .NET strategy. In a simple program we create later in this chapter, you'll see what the format of XML looks like. I don't cover XML basics in this book. You should become familiar with XML to work effectively with Visual Studio .NET.

Base Class Library

The base class library (BCL) is underneath the Data and XML block. This area is the origin for the base class of all .NET programs. Everything in Visual Basic .NET is an object, and all objects originate from a class named System. The BCL also provides collections, localization, text objects, interoperability with non-.NET code and ActiveX controls, and a variety of other services.

Most classic Visual Basic programmers are familiar with APIs. But C++ programmers use the Microsoft Foundation Classes (MFC), while developers using Java to create Windows applications rely on yet a different framework. The unified programming classes in the BCL ensure that all languages use this same object-oriented, hierarchical, and extensible set of class libraries.

Common Language Runtime

Holding up the framework is the common language runtime, which I described briefly earlier. The CLR does the heavy lifting for .NET Framework programs. Of course, run times are nothing new for programming languages. To run a classic Visual Basic program, the VBRUN run time has to be installed on the client machine. Likewise, Visual C++ must have MSVCRT installed, Java must have its own run time installed, and so on. Only the CLR is needed to make .NET code run on any machine.

The CLR is a set of standard resources that any .NET program can take advantage of, from any .NET-supported language. All languages will be more equal in capability than they have ever been before—.NET is the great equalizer. But not all .NET languages will support all .NET services. You can perform some operations in Visual Basic .NET that you can't do in C#, and vice versa. The capabilities of each language are dictated by the language's compiler.

The CLR includes support for the BCL, where the architecture for our controls and forms actually live. It is also responsible for managing threads and exceptions (what were errors held in the Err object in classic Visual Basic). Garbage collection—or releasing objects that are no longer in use—is also done by the CLR. (I'll touch on garbage collection again later in this chapter and describe it in more detail in Chapter 4, "Visual Basic .NET Data Types and Features.")

As I mentioned, the CLR takes the code generated by the Visual Basic .NET compiler (or any other compiler that targets .NET, for that matter) and converts it to the native language of the current platform architecture. Through this conversion, the magic of interplatform execution is achieved. Visual Basic programmers write code in the Visual Basic syntax, and the CLR is responsible for converting it to any platform that can run the CLR. Programmers are abstracted several levels from the hardware and really don't need to know or care what platform their code will be run on. As long as we use proper Visual Basic syntax and the application can be built without the compiler barking at us, .NET takes care of the rest.

As you can see in Figures 1-1 and 1-2, the CLR provides support for everything above it, as well as the conversion of Visual Basic .NET code to the specific architecture an application is running on. It also automatically provides type-safe code, which means that the code can do only what we want it to do. You have all heard stories about rogue code that either through sloppiness or maliciousness overran buffers and trashed a machine, killing all other programs on board. By design, this situation can't happen with Visual Basic .NET code.

The common language runtime provides a number of powerful services.

When code is targeted for .NET, it is called managed code, which means that the code automatically runs under a "contract of cooperation" with the CLR. Managed code supplies the information necessary for the runtime to provide services such as memory management, cross-language integration, code access security, and the automatic lifetime control of all of our objects.

Don't worry if trying to digest all this information seems like trying to drink water from a fire hose. As you start building your first Visual Basic .NET programs, you'll rapidly see how the pieces fit together.

Abstraction Layers

The idea of an abstraction layer is not new. The concept is an extension of the Hardware Abstraction Layer (HAL) in the Windows operating system. Before Windows 3.0, if you wrote a program for a PC, you had to know the answer to all sorts of questions. For example, how do I print a document? Because each printer has its own driver and printer control language, you had to write software that accommodated and spoke to all sorts of printers. What monitor was used? Did the PC have expanded or extended memory? Sheesh! This code was incredibly difficult to write. When the Windows operating system came on the scene, it became the great equalizer. All you had to do was program to Windows, and it took care of the messy details. You could just say "print" and Windows figured out how to do it. Windows handled monitor resolution, memory management, and all the other nagging details that had to be handled by programmers in the DOS world. With .NET, the CLR is also the great equalizer but on a grander scale. Instead of just handling individual printers and monitors, it handles the differences in the underlying hardware architecture. This capability is nothing short of amazing and will provide an incredible boost in productivity immediately.

Where Do We Start to Access Functionality from Visual Basic .NET Source Code?

What you might notice first when looking over this architecture is that all related logical functionality is grouped in the .NET Framework's components for easy management. You can access this functionality in your programs by referring to what's called a namespace. Namespaces are a hierarchical naming scheme for grouping types into logical categories of related functionality in .NET. For example, when you create your first form, the IDE will add Imports System.Windows.Forms to the code. The new Imports directive is similar to adding references in Visual Basic 6.0. Importing a namespace is all you need to do to inherit the functionality from the User Interface block in order to build and draw forms. I suspect that you are starting to see the elegance and power of this approach.

What I hope is also starting to become clear is that .NET provides a host of services that are there for the taking, finally making the Holy Grail of code reuse a reality. These services, along with other benefits, are designed to increase our productivity over the course of development—from design and coding to deployment and security. You can continue to develop stand-alone applications for PCs with Visual Basic .NET, but you can also handle any task on any platform that the job demands or might demand in the future.