.

NET Namespaces
Each of us understands the importance of code libraries.
The point of libraries such as MFC, J2EE, is to give
developers a well-defined set of existing code to leverage
in their applications.
For example, MFC defines a number of C++ classes that
provide canned implementations of dialog boxes, menus,
and toolbars. This is a good thing for the MFC
programmers of the world, as they can spend less time
reinventing the wheel, and more time building a custom
solution.
Visual Basic and Java offer similar notions: intrinsic
types/global functions and packages, respectively.
Unlike MFC, Java, or Visual Basic 6.0, the C# language
does not come with a predefined set of language specific
classes. Ergo, there is no C# class library. Rather, C#
developers leverage existing types supplied by the .NET
Framework.
To keep all the types within this binary well organized,
the .NET platform makes extensive use of the namespace
concept.
The key difference between this approach and a languagespecific library such as MFC, is that any language
targeting the .NET runtime makes use of the same
namespaces and same types as a C# developer.
For example, the following three programs all illustrate the
ubiquitous "Hello World" application, written in C#, VB
.NET, and C++ with managed extensions (MC++):
// Hello world in C#
using System;
public class MyApp
{
public static void Main()
{
Console.WriteLine("Hi from C#");
}
}
' Hello world in VB .NET
Imports System
Public Module MyApp

Sub Main()
Console.WriteLine("Hi from VB .NET")
End Sub
End Module

// Hello world in Managed C++ (MC++)

#using <mscorlib.dll>
using namespace System;
void main()
{
Console::WriteLine("Hi from MC++");
}

System is the root namespace for numerous other .NET

namespaces. Simply put, namespaces are a way to group
semantically related types (classes, enumerations, interfaces,
delegates, and structures) under a single umbrella. For
example, the System.Drawing namespace contains a number of
types to assist you in rendering images onto a given graphics
device. Other namespaces exist for data access, Web
development, threading, and programmatic security (among
many others). From a very high level, Table offers a rundown of some
(but certainly not all) of the .NET namespaces.

.NET Namespaces
System

System.Collections

Meaning
Within
System
you
find
numerous low-level classes
dealing
with
primitive
types,
mathematical manipulations,
garbage
collection, as well as a number
of commonly used exceptions
and predefined attributes.
This namespace defines a
number of stock container
objects
(ArrayList, Queue, etc.) as well
as base types and interfaces
that allow you to build

System.Data
System.Data.Common
System.Data.OleDb
System.Data.SqlClient
System.Drawing
System.Drawing.Drawing2D
System.Drawing.Printing

System.IO
System.Security

System.Web

customized collections
These namespaces are
course) used for database
manipulations (ADO.NET).

(of

Here, you find numerous types

wrapping GDI+ primitives
such as bitmaps, fonts, icons,
printing
support,
and
advanced
graphical rendering support.
This namespace includes file
IO, buffering, and so forth.
Security is an integrated
aspect of the .NET universe. In
the
security-centric
namespaces
you find numerous types
dealing
with
permissions,
cryptography, and so on.
A number of namespaces are
specifically geared toward the
development of .NET Web
applications, including ASP.NET
and XML Web services.

Accessing a Namespace Programmatically :

Consider again the System namespace. From your perspective,
you can assume that System.Console represents a class named
Console that is contained within a namespace called System.
However, in the eyes of the .NET runtime, this is not so. The
runtime
engine
only
sees
a
single
entity
named
System.Console. In C#, the "using" keyword simplifies the
process of declaring types defined in a particular namespace.
Here is how it works. Let's say you are interested in building a
traditional desktop application. The main window renders a bar
chart based on some information obtained from a back-end
database and displays your company logo using a Bitmap type.

While learning the types each namespace contains takes study

and experimentation, here are some obvious candidates to
reference in your program:
// Here are all the namespaces used to build this
application.
using System; // General base class library types.
using System.Drawing; // Rendering types.
using System.Windows.Forms; // GUI widget types.
using System.Data; // General data centric types.
using System.Data.OleDb; // OLE DB data access types.
Once you have referenced some number of namespaces (and
set a reference to the associated external assembly), you are
free to create instances of the types they contain. For example,
if you are interested in creating an instance of the Bitmap class
(defined in the System.Drawing namespace), you can write:
// Explicitly list the namespaces used by this file...
using System;
using System.Drawing;
class MyClass
{
public void DoIt()
{
// Create a 2020 pixel bitmap.
Bitmap bm = new Bitmap(20, 20);
// Use the bitmap...
}
}
Because your application is referencing System.Drawing, the
compiler is able to resolve the Bitmap class as a member of this
namespace. If you did not directly reference System.Drawing in
your application, you would be issued a compiler error.
However, you are free to declare variables using a "fully
qualified name" as well:
// Not listing System.Drawing namespace!
using System;
class MyClass
{

public void DoIt()

{
// Using fully qualified name.
System.Drawing.Bitmap bm = new System.Drawing.Bitmap(20,
20);
...
}
}

Deploying the .NET Runtime

As you have most likely surmised, .NET assemblies can only be
loaded and executed on a machine that has been configured to
host the .NET runtime. As an individual who builds .NET
software, this should never be an issue, as your development
machine will be properly configured at the time you install the
.NET SDK (or Visual Studio .NET).
However, assume you have just created a fantastic .NET
application
and wish to copy it to a brand new machine. Of course, this
*.exe will fail to run if the target computer does not have .NET
installed.
Rather than opting for overkill and installing the full .NET SDK
on each and every machine that may run your application,
Microsoft has created a specific redistribution package named
Dotnetfx.exe that can be freely shipped and installed along
with your custom software. This installation program is included
with the .NET SDK (or VS .NET), however, it is also freely
downloadable (simply do a search on
http://www.microsoft.com).
Dotnetfx.exe will correctly configure a "virgin machine" to
execute .NET assemblies, as long as said machine is one of the

following flavors of Microsoft Windows (of course, future

versions of the Windows OS will have native .NET support):
Microsoft Windows 98
Microsoft Windows NT 4.0 (SP 6a or greater)
Microsoft Windows Millennium Edition (aka Windows Me)
Microsoft Windows 2000 (SP2 or greater)
Microsoft Windows XP Home / Professional
Once installed, the target machine will now host the necessary
base class libraries, mscoree.dll, and additional .NET
infrastructure (such as the Global Assembly Cache). Do
understand however, that if you are building a Web application
using .NET technologies, the end user's machine does not need
to be configured with the .NET redistribution kit (as the browser
will simply display generic HTML).
Running .NET on Non-Microsoft Operating Systems
The .NET platform is already being ported to other operating
systems. The key that makes this possible is yet another .NET
specification termed the
Common Language Infrastructure (CLI, which previously went
under the code name "rotor"). Simply put, the CLI is the ECMA
standard that describes the core libraries of the .NET universe.
Microsoft has released an open-source implementation of the
CLI (The Shared Source CLI) which can be compiled on Windows
XP, FreeBSD Unix as well as the Macintosh (OS X and higher).