The System Namespace
The System namespace sits at the top of the namespace hierarchy. All the
rest of the libraries in this chapter梐nd in this book梬ill be descended
from the System namespace. (The .NET Framework does include some namespaces
that aren't part of the System namespace, but we won't be discussing them
in this book.) The most important items contained within the System
namespace are the classes that represent the base data types, such as
Object, Integer, Long, String, and so on.
In addition to these base data types, there are dozens of classes in the
System namespace. These classes cover areas such as data handling
(DataSet), garbage collection (GC), and threading (Threading).
The System namespace also contains namespaces that provide the bulk of the
.NET Framework functionality. These secondary namespaces are generally
grouped into areas of functionality. For example, data access is handled by
System.Data, System.Xml, and System.Xml.Serialization, whereas the
System.Drawing and System.Windows.Forms namespaces handle user interfaces.
A System.GC (Garbage Collection) Example
As an example of the System namespace, this section takes a look at garbage
collection. Garbage collection is one of the important new features you can
control when you use the .NET Framework. In COM, instantiated objects are
allocated memory automatically. These COM components kept an internal
counter of the number of connections being made to them. When this counter
drops to zero, the object is supposed to drop out of memory.
In your client code, you can instantiate a COM component (creating an
object in memory) and later kill it by setting your object reference to
Nothing. As long as you have the only connection to the COM object (the
most likely scenario), the object is destroyed immediately.
The problem with using COM reference counting is that it's possible梐nd
actually far too easy梖or one component to maintain a reference to another,
while the second maintains a reference back to the first. Because neither
component can be destroyed (each has a "live" inward reference), neither
object can ever remove itself from memory. This circular reference problem
has led to many memory leaks.
Memory management is now handled automatically by the .NET Framework,
without reliance on reference counting. The circular reference problem is
gone, because the Framework decides when objects are to be released from
memory, based on their usage. This means that you do not know exactly when
objects will be destroyed, so you can't be sure when the memory is to be
cleaned up.
If you want more control, you can force garbage collection to occur by
calling the Collect method of the GC class. In the following code snippet,
you can see the Collect method being called:
Dim oCust As New Customer()
oCust.CompanyName = "Microsoft Corporation"
...
oCust = Nothing
GC.Collect()
This code instantiates a hypothetical Customer object. It sets the
CompanyName property and then might perform other actions on the object.
When it's done, the code sets the object reference to Nothing and
explicitly calls the Collect method of the GC class. Not calling the
Collect method would mean that the object, while no longer referenced,
might still be alive in memory. It would be marked for garbage collection
but might not be removed until garbage collection is run.
Perhaps you're wondering why you might ever call the garbage collector
manually, given that .NET is so good about handling memory for you? Realize
that the component, although dereferenced (set to Nothing), may still exist
in memory for some time. Not only is it taking up memory, but more
importantly, any resources it was accessing may still be held open. For
example, database connections and file handles might still be held open
until the object is actually dropped from memory. Therefore, you might want
to explicitly call the garbage collector and have the object taken out of
memory. Of course, a careful programmer would close all open resources
before an object is dereferenced.
Working with Namespace Names
The previous example works with the System.GC class, yet it's referred to
simply as GC. How is that possible? How can the compiler determine which
exact class you're referring to? When referring to members of a namespace
(that is, objects provided by a namespace), you must somehow indicate to
Visual Basic .NET which exact object you want to use. In general, you must
type the entire object name, including its full namespace. For example, to
refer to a SqlDataReader object, you would have to write code like this:
Dim dr As New System.Data.SqlClient.SqlDataReader()
If you refer to objects in the same namespace often, you may want to find
some way to simply refer to the objects themselves, rather than the entire
namespace. To make this possible, VB .NET provides the Imports statement,
which you can place at the top of any file. This statement acts much like a
file-wide With…End With statement. If, for example, you have placed the
statement
Imports System.Data.SqlClient
at the top of a file, you could modify the previous code example to look
like this:
Dim dr As New SqlDataReader()
To make this easier for you, VB .NET projects created in Visual Studio .NET
always add implicit Imports statements for you. You can check the list of
implicit Imports by right-clicking an open project in the Solution
Explorer. Select Imports from the list of common properties in the
project's property pages, and you'll see a list of Imports statements that
VB .NET automatically handles for you.
In your code, you can only refer to objects that are provided by the
assemblies your project references. That is, unless Visual Studio .NET has
automatically set a reference to an assembly or you've manually added the
reference, you won't be able to use an object. Also, you can only add
Imports statements for classes you've referenced. To add a reference to an
assembly, use the Project, Add Reference menu item and select the .NET tab.
NOTE
The GC class provides only shared members. The shared keyword indicates
that you don't need to create an instance of the class before using its
methods or properties. Many .NET Framework classes use shared members (such
as GC.Collect) rather than requiring you to declare a GC variable and
create a new instance. Instance properties and methods (such as the Length
property of a specific string) are more common.
