This chapter is from the book
This chapter is from the book
This chapter is from the book
Fundamental Concepts
This book teaches you how to create Internet applications using the .NET Framework and the Visual Basic language. At least 90% of the material you need to learn is related to the .NET Framework, not to Visual Basic. We therefore don't try to teach Visual Basic, but assume you have at least a fundamental knowledge of the language. When needed, however, we do explain advanced Visual Basic language concepts when they are used in the examples.
To completely understand the code listings in the following chapters, you need to understand a few key terms, including the common language runtime (CLR), assemblies, namespaces, and event handlers. Today's lesson will give you enough information about each topic so that you have a good foundation to build your .NET knowledge.
The Common Language Runtime
The common language runtime (CLR) is the infrastructure that .NET uses to execute all your applications. The CLR includes a huge set of class libraries that you can use in your applications. Some interesting non-Internet–related classes include utilities that allow you to manipulate the Windows NT event log, Active Directory, cryptographic services, performance counters, COM+ services, object serialization, and Windows native services. If you aren't familiar with these terms, don't worry! This book will focus on the large amount of Internet programming-related classes, such as Web-based controls, Web Service classes, and Web security classes.
The CLR also takes care of compiling "intermediate language," or IL, code into native machine code. The basic process works as follows:
The Visual Basic compiler converts your code into IL. In terms of functionality and language complexity, IL is somewhere between assembly language and C. IL is optimized for quick compilation into machine code. Normally, you won't deal with IL in any of your development efforts. You can think of IL as an intermediate product of the compilation process.
Your Internet application is called by a user, or more precisely, by the Web server in response to a user's request.
The CLR takes over and compiles the IL into machine code. This happens function by function. If a function is used, it's compiled into machine code. If not, it remains as IL. The odds of an error occurring during this process are extremely small, equivalent to a compiler crash.
If this process seems roundabout and destined to make your application too slow, please suspend judgment until you've worked with .NET for a little while. You should be pleasantly surprised. At the minimum, this process makes development much faster, as the first step is much faster than other methods. You can also compile your .NET code directly into machine code by using standard tools installed with the .NET Framework.
The CLR contains other services, including support for running multiple .NET applications inside one process with a guarantee that they won't interfere with each other. This is a result of a concept called type safety. Any .NET language must guarantee type-safe code, which ensures that arrays and collections will never be accessed incorrectly, among other things. The Visual Basic compiler always enforces type safety when it compiles your code into IL.
Assemblies
All .NET code is compiled into assemblies. From the outside, an assembly looks exactly like a dynamic link library (.dll) or an executable program (.exe). The first few bytes inside each assembly contain machine code that invokes the common language runtime when the assembly is accessed by another program or by a user.
Inside the assembly is a mix of IL and machine code, depending on how much of the assembly has been compiled by the CLR. Assemblies also contain metadata. The metadata for a .NET program includes:
Information about every public class or type, including the name, what classes the class is derived from, and every interface that the class implements
Information about every public method in each class, including the name and return value
Information about every public parameter for every method, including each parameter's name and type
Information about every public enumeration, including the names and values for each enumeration member
Information about an assembly's specific version
Why have metadata? It solves a number of problems and enables some nice features. One problem DLL files have is that there is no way to examine what kinds of functions they support; you can find the names, but that's about it. COM, or component, files are usually built on top of DLL files and have the same problem. You can associate COM-type libraries with a COM object, depending on myriad Windows Registry entries that can easily become inconsistent.
By having such rich data in each assembly, the .NET Framework doesn't need to use the Registry to run assemblies. If a .NET program needs to use another .NET assembly, they only have to be located in the same directory. This means that if you want to deploy a .NET program on another computer, you can get away with simply copying the required files. Deployment is a complicated issue, however, and Day 20 will give you the necessary details.
You can write .NET code to examine another assembly's metadata to find out whether it supports the functions you need. This is an advanced topic, and this book won't explore the issue in much depth. This process is called Reflection, and Microsoft's online documentation contains plenty of details.
Namespaces
If you've used C++, you are familiar with the term namespace. A namespace is used in .NET languages to provide a container for a set of classes. This container allows you to create classes with the same names that other developers or the CLR uses. For example, you might use a set of utility Visual Basic classes that you downloaded from a Web site. These utility classes might contain a class named ErrorLogger, which writes out error messages to a text file. Unfortunately, you've already developed a class that also happens to be named ErrorLogger. Having the same name isn't a problem because the utility class uses a different namespace from your own.
To go into a little more detail, let's look at some Visual Basic code. The following example is typical of what you will see in the remaining lessons in the book because it contains a numbered code listing (don't include the line numbers in any code you develop) along with an Analysis section.
Listing 1.1 HelloWorld.vb: The Common "Hello World" Program That Every Book Requires
1: Imports System
2:
3: Module Module1
4:
5: Sub Main()
6:
7: Console.Writeline("Hello, world")
8:
9: End Sub
10:
11: End Module
Line 1 uses the Imports keyword, which tells the compiler to include the System namespace into this program. Line 7, which writes out Hello World., could be written differently. If the listing didn't use the Imports keyword on Line 1, Line 9 would turn into the following:
System.Console.WriteLine("Hello World.")
As you can see, namespaces group similar classes into one logical group to prevent naming conflicts.
Line 3 declares a module for the program's code, one way in which VB .NET organizes its code. Lines 5–9 define the subprocedure named Main(), where execution starts.