109
End If End Sub
The Const
directive defines a symbolic constant for the compiler. This constant is later referenced in the
If directives. If the constant evaluates to
True , the statements within the
If block are
compiled into the application. If the constant evaluates to False
, the statements within the If
block are ignored.
The scope of constants defined by the Const
directive is the source file in which the directive appears. However, if the constant is referenced prior to the definition, its value is
Nothing . It is
therefore best to define constants near the top of the file. Alternatively, compiler constants can be defined on the command line or within the Visual Studio .NET IDE. If youre compiling from the
command line, use the define
compiler switch, like this: vbc MySource.vb define:DEBUG=True
You can set multiple constants within a single define
switch by separating the symbol=value
pairs with commas, like this: vbc MySource.vb define:DEBUG=True,SOMECONSTANT=42
To assign compiler constants in Visual Studio .NET: 1. Right-click on the project name in the Solution Explorer window and choose Properties. This
brings up the Project Property Pages dialog box. If the Solution Explorer window is not visible, choose View
Solution Explorer from the Visual Studio .NET main menu to make it appear. 2. Within the Project Property Pages dialog box, choose the Configuration Properties folder.
Within that folder, choose the Build property page. This causes the configuration build options to appear on the right side of the dialog box.
3. Add values to the Custom constants text box on the right side of the dialog box.
2.24 Summary
This chapter provided an overview of the syntax of the Visual Basic .NET language. In Chapt er 3
, youll learn about the .NET Framework—an integral part of developing in any .NET language.
Subsequent chapters will teach you how to accomplish specific programming tasks in Visual Basic .NET.
110
111
Chapter 3. The .NET Framework
The .NET Framework is the next iteration of Microsofts platform for developing component-based software. It provides fundamental advances in runtime services for application software. It also
supports development of applications that can be free of dependencies on hardware, operating system, and language compiler.
This chapter provides an overview of the architecture of the .NET Framework and describes the base features found in the core of its class library.
3.1 Common Language Infrastructure CLI and Common Language Runtime CLR
At the heart of the .NET Framework is a new mechanism for loading and running programs and managing their interactions. This mechanism is described in the Common Language Infrastructure
CLI, a specification for a runtime environment that allows software components to:
• Pass data between each other without regard to the programming language in which each
component is written •
Execute on different operating systems and on different hardware platforms without having to recompile the high-level source code a low-level compilation still automatically occurs on the
target platform, as will be discussed in this chapter
Although the CLI specification was created by Microsoft, it has since been submitted to the ECMA standards organization
ht t p: w w w .ecm a.ch , which now has responsibility and control over it.
The CLI is just a specification—it has to be implemented in order to be useful. An implementation of the CLI is known as a Common Language Runtime CLR. Microsofts CLR implementation on the
Windows platform is not under ECMAs control, but it is Microsofts intention that the CLR be a fully compliant implementation of the CLI. As of this writing, the CLI has not been implemented on non-
Windows platforms, but Microsoft and others have announced intentions to do so.
The CLI specifies how executable code is loaded, run, and managed. The portion of the CLR that performs the tasks of loading, running, and managing .NET applications is called the virtual execution
system VES. Code run by the VES is called managed code .
The CLI greatly expands upon concepts that exist in Microsofts Component Object Model COM. As its core feature, COM specifies how object interfaces are laid out in memory. Any component that can
create and consume this layout can share data with other components that do the same. COM was a big step forward when it was introduced circa 1992, but it has its shortcomings. For example, in spite
of its name, COM actually has no concept of an object—only object interfaces. Therefore, COM cant support passing native types from one component to another.
3.2 Common Type System CTS
The CLI specification defines a rich type system that far surpasses COMs capabilities. Its called the Common Type System CTS. The CTS defines at the runtime level how types are declared and used.
Previously, language compilers controlled the creation and usage of types, including their layout in memory. This led to problems when a component written in one language tried to pass data to a
component written in a different language. Anyone who has written Visual Basic 6 code to call Windows API functions, for instance, or who has tried to pass a JavaScript array to a component
written either in Visual Basic 6 or C++, is aware of this problem. It was up to the developer to translate the data to be understandable to the receiving component. The CTS obliterates this problem by
providing the following features:
