By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,743 Members | 1,072 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,743 IT Pros & Developers. It's quick & easy.

NameSpaces

P: n/a
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
then I would create the appropriate classes under that structure and then
create a jar file. I would then go into the "ClassPath" and tell Java
where to look for this software. (It has been a while, that I think that
is the jist of it).

When I wanted to use something from Utility\Print, I would create the
import statement for it and away I would go.

Assuming that I am clear on all of that, I'm not too clear on how to allow
other applications to access my namespaces. In ASP.Net, I would use Global
Assemble Cache or the @Imports directive? For window applications I would
use ???

When I want to add another "Print" utility, I must bring up the project
which encompasses that namespace and add it to that existing project, or
can I create a new project - specifiy the desired namespace and then some
how move it into the real namespace where ever that may be?

Just trying to get a handle on thing here...

Thanks in advance for your assistance!!!!!!!!!
Nov 15 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Jim
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 andam transitioning to C# and the .Net Environment. I have worked a bit withJava 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 thenamespace - just the entire namespace. Is that Right?

In Java, I would carve out a place on my disk with a particulare "filestructure" such as "C:\Java\Utility\DB" and "C:\Java\Utility\Print" andthen I would create the appropriate classes under that structure and thencreate a jar file. I would then go into the "ClassPath" and tell Javawhere to look for this software. (It has been a while, that I think thatis the jist of it).

When I wanted to use something from Utility\Print, I would create theimport statement for it and away I would go.

Assuming that I am clear on all of that, I'm not too clear on how to allowother applications to access my namespaces. In ASP.Net, I would use GlobalAssemble Cache or the @Imports directive? For window applications I woulduse ???

When I want to add another "Print" utility, I must bring up the projectwhich encompasses that namespace and add it to that existing project, orcan I create a new project - specifiy the desired namespace and then somehow move it into the real namespace where ever that may be?
Just trying to get a handle on thing here...

Thanks in advance for your assistance!!!!!!!!!
.

Nov 15 '05 #2

P: n/a
Man oh man, thanks for taking the time to "educate" me. I really
appreciate your insight.

So let me re-state your information to ensure I understand what you
conveyed.

Namespaces do not reflect hiearchy - so if you have a namespace called
MyStuff.Utility.Database it does not mean that there are any classes in
"MyStuff" or in "MyStuff.Utility" - in only means that there are classes
in MyStuff.Utility.DataBases. It also means that I could create a
Project in VS.Net with a namespace called "MyStuff.Utility.DataBase" and
place that in "C:\MyProjects" and create another project with the same
namespace name and place it in "D:\MyProjects" and I could link the one
in C:\MyProject to one project and then link the other to another
project and all would be well (not that I would want to do this....

To use an "external" namespace you must create a reference to that
namespace. In addition, you must use the "Using" statement to refer to
the namespace in the classes which will be using any of those external
Namspace classes. "External" is defined to be outside of the existing
project, even if in the same namespace?????

So "adding a Reference" would be similar to adding the location of the
Jar file into the ClassPath. It simply enables the system to be able to
locate the namespace but does does not "enable" the namespace for a
particular class within the project. For this you must use the "Using"
statement. Does that about convey how it works?

When you create a "reference" to the external namespace, is the acutally
coppying the dll into your bin folder, or is it just storing the
location to where the dll exist?

What is not clear to me is if you were not using VS.Net, how would you
create this reference?

Again, thanks for your insight!!!!!!!!
Nov 15 '05 #3

P: n/a
Java has the concept of name and location tied together - the package
denotes not only what the class is named but where it is lived (ignoring the
ways of packaging multiple classes together into one file).

In C#, these are two separate concepts.

Namespaces are a way to organize your classes, and to give them useful
names. I can declare a Utility namespace, and then my Calculator class in it
will be named "Utility.Calculator".

Assemblies are the way that you organize classes on disk, so that others can
use them. While they often mirror namespace layouts (ie there would likely
be a utility.dll that corresponds to all the items in my utility namespace),
there is no requirement that this be so.

To create a library that others would use, you would generally create a
class library project and then include the resulting .dll file as a
reference in the projects that use it.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Jim Heavey" <Ji*******@nospam.com> wrote in message
news:Xn*********************************@207.46.24 8.16...
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
then I would create the appropriate classes under that structure and then
create a jar file. I would then go into the "ClassPath" and tell Java
where to look for this software. (It has been a while, that I think that
is the jist of it).

When I wanted to use something from Utility\Print, I would create the
import statement for it and away I would go.

Assuming that I am clear on all of that, I'm not too clear on how to allow
other applications to access my namespaces. In ASP.Net, I would use Global Assemble Cache or the @Imports directive? For window applications I would
use ???

When I want to add another "Print" utility, I must bring up the project
which encompasses that namespace and add it to that existing project, or
can I create a new project - specifiy the desired namespace and then some
how move it into the real namespace where ever that may be?

Just trying to get a handle on thing here...

Thanks in advance for your assistance!!!!!!!!!

Nov 15 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.