I think you alrady have this much of this down, but for
starters, I used to explain the concept of namespaces to
my students ilke this....
In science fiction movies, they often depict life on Mars
with people living inside these big, clear domes. If you
think of the people and things within those domes as
classes, then the domes themselves are akin to
namespaces. To put it yet another way, you can think of
namespaces to classes as aera codes are to telephone
numbers. They provide a means in which to wrap the naming
of your classes to prevent name conflicts later on when
applications or modules have to reference other
applications or modules that migth contain classes of the
same name.
In C#, when you create a project, in addition to the
individual classes (which, by contentional although not by
necessity are usually each stored in a separate .cs file)
within that project, you can refer to external components
(usually .DLL's). You do that by adding a reference to
your project, and specifying the path the .DLL your
classes within this project will reference. Now the
compiler knows where to go and look for the classes and
objects (we sometimes call them "symbols") you make
reference to in your code.
When you create a namesapce, you are basically creating a
wrapper for everything you define within it. My DLL
project, which contains a bunch of cool financial
functions, will have a namespace of "CoolFinancial". If I
tell C# this in my project properties in fact, it will go
ahead and automatically create that namespace in each
class file (.cs file) that I add to the project. So,
let's now say I have three classes "Banking", "Investing",
and "Spending". Each of their fully qualified class names
would begin with "CoolFiancial". That
is, "CoolFinancial.Banking", "CoolFinancial.Investing",
etc.
When I include my cool financial functions .DLL into
another project, I do so by adding a reference to it in
every project within the solution that will make a direct
reference to something within it. For instance, withni
my "Home" solution, I might have two
projects, "Budget", "Security", and "Family". "Budget"
will obviously do financial stuff, so it needs a reference
to the DLL that contains my cool financial stuff.
The "Family" and "Security" projects, while still part of
the "Home" solution, will probably not need this
reference, as they don't directly do financial things from
the Cool Financial stuff .DLL.
When you "import" (that is to say, include, by making a
reference to) a .DLL your C# project, you are including
references to every class, within every namespace that is
included as a part of that particular DLL's project. So,
your statement that you include not noly a class within a
namespace, but actually the whole namespace is correct,
although incomplete. While, generally speaking, a C#
project will contain only name space, it's possible to
have as many as you like. It's even possible and legal to
have multiple namespaces within an individual C# file.
Once you have the references to the DLL's your project
will use, you then need to tell C# how to resolve the
class and data type names you use within each .CS file.
When you'll be making references to classes or data types
defined outside the local project (even if they are in the
same namespace), then you'll need to put "using"
statements at the top of your .CS file. The "using"
statements specify the fully qualified names of all the
namespaces that are being used by this C# file.
Once you have your "using" statements at the top of yuor
file, you need only provide as much of the fully qualified
name as is necessary for C# to correctly resolve the class
and data type names. For example, in my one project
within our "Home" solution, "Budget" project, we might
have:
using System;
using CoolFinancial;
....
namespace Home.Budget
{
Banking MyBanking = new Banking();
CoolFinancial.Spending ExpenseAccount = new
CoolFinancail.Spending();
}
....
The CoolFinancial namespace contains a class
called "Banking". Everything within our "Budget" project
uses the "Home.Budget" namespace. Nothing is defined in
the Home.Budget namespace called "Banking", so we need not
use its fully qualified name to make reference to the
Banknig class. C# understands implicitly that it comes
from the CoolFinancial namespace. If, however we had
something created within our Home.Budget namespace that
was called "Spending", then we would need to explicitly
refer to CoolFinancial.Spending, as in the second example,
in order to make it clear what we were talking about.
You might also note the "This.That" style of the namespace
name. Again, this is a matter of style and convention,
not a requirement. Your namesapce names need not match
the names of the sulitions or projects that they are
contained within. Also, the dots within the namespace
name do not represent a hierarchial relationship. In
other words, if the "CoolFinancial" solution contained
namespaces "Banking", "Investing", and "Spending", then
you would need to explicitly refer to each namespace with
an individual "using" statement in your .CS fille. That
is:
using CoolFinancial.Investing;
using CoolFinancial.Spending;
using CoolFinancial.Banking;
and not:
using CoolFinancial; // Nope - Won't work
If you did this, C# would assume you were talking about a
fourth namespace, called "CoolFinancial". The dots are
purely a matter of style.
I hope that helps you out! Good luck! (And I apologize
for any typos. This keyboard loves to pick my keystrokes
in reverse order.)
JIM
-----Original Message-----
Trying to get the hang of Namespaces. I have primarly developed in VB and
am transitioning to C# and the .Net Environment. I have worked a bit with
Java as well in school about a year or so ago.
NameSpaces and Java Packages are similar in nature? In the dot net world,
you are not able to pick out (import) a particulare "class" within the
namespace - just the entire namespace. Is that Right?
In Java, I would carve out a place on my disk with a particulare "file
structure" such as "C:\Java\Utility\DB"
and "C:\Java\Utility\Print" and
