The .NET Framework provides a rich library of
commonly used functionality to developers creating applications using
managed code. This library is known as the Base Class Library. For
example, the Base Class Library allows developers to access the
file system, use regular patterns, read and write to Active Directory,
and much more. Usually a single, most granular logical entity providing
specific functionality is known as a class. There are thousands of
classes in the Base Class Library. Classes are divided into logical
groups called namespaces and are physically stored as assemblies. An
assembly is an EXE or DLL file containing managed code. Usually an
assembly contains one or more namespaces, with each namespace
containing related classes.
To
get a feel for the richness of the ready-made functionality available
to you when using the .NET Framework, let’s take a look at some
examples of namespaces and classes. Table 4.1
lists some of the namespaces available to us from the Base Class
Library, and the functionality provided by classes in these namespaces.
Note that Table 4.1 is not a complete list of classes in the Base Class Library; there are thousands of classes available.
Table 4.1. Base Class Library Class and Namespace Examples
| Namespace | Class | Functionality |
|---|
| System.IO | File, Directory, FileStream | Manipulate files and directories; read and write to and from files in the file system |
| System.Data | DataSet, DataTable, DataRow | Manipulate tabular data in memory; the data can be populated from a variety of data sources |
| System.Xml | XMLDocument, XMLElement | Load and manipulate XML data |
| System.Security.Cryptography | CryptoStream, TripleDES, RSACryptoServiceProvider | Encrypting and decrypting data using a variety of industry-standard algorithms |
| System.Drawing | Brush, Font, Bitmap | Creating and manipulating on-screen graphics |
| System.Web.Services | WebService | Create and consume an XML Web service |
| System.Threading | Thread, Mutex, Semaphore | Create and synchronize multiple processor threads |
Developers
use classes from the Base Class Library to perform their desired
functionality. The ability to access readily available functionality is
one of the major advantages of the .NET Framework. When creating CLR
objects for SQL Server, only
a subset of the Base Class Library is available to you. CLR objects,
such as CLR stored procedures, run within the context of SQL Server.
Not all classes from the Base Class Library should be called within
this context. For example, it makes no sense to create and launch
visual forms or manipulate graphics from within a SQL Server stored
procedure. Other classes, like those in the System. Threading
namespace, could impact the stability of SQL Server if used. You can
access any .NET class from within SQL Server, but not all are supported
for use with SQL Server.
The
namespaces that are listed as supported in SQL Server documentation
have been tested for stability with SQL Server. Assemblies containing
supported namespaces are loaded from the Global Assembly Cache (GAC) by
default, and are always available to you when creating CLR-integrated
objects. You don’t need to do anything special to use classes from
these namespaces. As of February 2009, the following namespaces and
assemblies are listed as supported by SQL Server 2008:
CustomMarshalers
Microsoft.VisualBasic
Microsoft.VisualC
mscorlib
System
System.Configuration
System.Data
System.Data.OracleClient
System.Data.SqlXml
System.Deployment
System.Security
System.Transactions
System.Web.Services
System.Xml
System.Core.dll
System.Xml.Linq.dll
Even
if the class you wish to call is in an unsupported assembly, it doesn’t
mean you cannot use it. Any custom assembly that you write yourself is
unsupported, unless you can persuade the makers of SQL Server to test
it for you. This unlikely event notwithstanding, you will have to use
the unsupported library at your own risk. Unsupported libraries are not
loaded by SQL Server by default, and therefore you have to register
them explicitly. We will learn how to register assemblies with SQL
Server later in this chapter. When using functionality from an
unsupported assembly, you are responsible for testing it and ensuring
it performs well, without affecting the stability of SQL Server.
For
those among us who are not developers by profession, programming terms
like class, namespace, and assembly can be confusing and intimidating.
You will see these terms, possibly all of them, in the exam. To make
matters worse, these terms can be used interchangeably in some
situations, but in certain circumstances they cannot be exchanged for
one another. First of all, it is worth mentioning that assemblies are
purely a component of the .NET Framework, while the concept of classes
and, to some extent, namespaces, can be found in other programming
realms—for example, Java.
A
class is a single logical programming entity and usually has methods
(functionality) and properties (descriptors). For example, a FileStream class is used to read or write binary data to and from a file. It has properties like Length, which designates the size of a file in bytes. It has methods like ReadByte and WriteByte to read or write a single byte to the file. You could use a FileStream object to open a file from a file share and load its data into a SQL Server table.
A namespace is a logical group of classes. For example, the FileStream object belongs in the System.IO namespace, along with classes like File, Path, and Directory.
These classes are all logically related and are grouped by their
creator in the same namespace. On the other hand, a class like XMLElement doesn’t belong in the System.IO namespace and therefore lives in a different namespace—System.XML.
An
assembly is a physical EXE or DLL file containing MSIL code for one or
more classes and namespaces. An assembly can also contain other
resources beyond code, such as images, icons, or data. Developers write
classes, group them in namespaces, and compile them into assemblies.
Other developers can then load an assembly and use classes contained
within it. When you come to create custom code for your CLR stored
procedures and functions, you will both create and use assemblies.
The
question is: When you use assemblies in your application, where do they
come from? Some assemblies are stored with the application in their
application folders—for example, C:\Program Files\My App\MyAssembly.
dll. These are called local assemblies, because they are specific to
the individual application. Other assemblies are used by many
applications on your computer. These are shared assemblies. Shared
assemblies are registered in the GAC. The GAC is a special repository
for shared assemblies, and it stores information about them such as
their versions. Assemblies that comprise the Base Class Library are
stored in the GAC. You can see what’s in the GAC by navigating to
%Windir%\Assembly. If you delete an assembly out of the GAC or update
it with a different version, this will affect all applications that use
that assembly.
In
summary, classes are grouped into namespaces and are contained within
physical assemblies. These physical assemblies can be stored locally or
in the GAC.
