namespaces - what's the point?

[Guest]

Hi
Can somebody please tell me what namespaces are actually for?

I notice that when I start a new project in C#, it puts everything in a
namespace of the same name as the project.
I found them a bit annoying as when I save a class's .cs file to my 'generic
code' folder, and then put it in another project, I have to manually go and
change the namespace name. This I find a bit of a PITA.
I used VB.NET for a bit and found it didn't have namespaces by default, but
that it can have them if it wants. I also found that although C# has them by
default, I don't actually have to have them in order to compile.
So - they're not necessary, and seeing as I don't like them, why can't I
turn them off?

And what's the logic behind them being optional in both languages, but on by
default in C# yet off by default in VB.NET?

 

[Jon Skeet [C# MVP]]

Can somebody please tell me what namespaces are actually for?

It means that:
o If you absolutely have to, you can have two types with the same names
in different namespaces. It's worth trying to avoid this wherever
possible though.
o You can easily see what namespaces a class uses, assuming it doesn't
explicitly use full type names, through the using directives at the
top of the class.
o Intellisense will only display the relevant type names, rather than
showing *every* type.
o When creating your own types, it gives the reader a clear idea of the
kind of class it is - for instance, if a type is in a namespace with
a name like "BusinessLogic" then it's going to be related to business
logic.

Put it this way: do you keep absolutely everything in one directory on
your computer? Use namespaces in a similar way to how you'd use
directories.

I notice that when I start a new project in C#, it puts everything in a
namespace of the same name as the project.

You can change the root namespace of the project - I usually change it
to an empty string so that my namespace structure then exactly matches
the directory structure.

I found them a bit annoying as when I save a class's .cs file to my 'generic
code' folder, and then put it in another project, I have to manually go and
change the namespace name. This I find a bit of a PITA.

If you're reusing code, you should have a project containing all that
code, rather than duplicating it in each project.

I used VB.NET for a bit and found it didn't have namespaces by default, but
that it can have them if it wants. I also found that although C# has them by
default, I don't actually have to have them in order to compile.
So - they're not necessary, and seeing as I don't like them, why can't I
turn them off?

Well, you can edit the template that C# uses to create a new class if
you want - look at

C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\VC#Wizards
\CSharpAddClassWiz\Templates\1033\NewCSharpFile.cs

You can edit that and similar templates to get rid of the namespace
declaration if you really want.

And what's the logic behind them being optional in both languages, but on by
default in C# yet off by default in VB.NET?

Well, you will always be using namespaces to some extent in C#. You
just don't have to put types in a namespace other than the "empty
name" one.

Personally I'd recommend always using a namespace though.

 

[Marina]

Would you put every single file on your system into one folder? No, you
origanize them in meaningful ways, with folders that have subfolders etc.

If you didn't, not only would you have thousands of files all in one place
(making it virtually impossible to find anything), you would only be able to
use a filename once, since they are all in the same folder.

Same reasoning goes for namespaces.

 

[Jay B. Harlow [MVP - Outlook]]

Patty,
In addition to the other comments.

I used VB.NET for a bit and found it didn't have namespaces by default,

but

VB.NET has namespaces and the are ON by default!!!

The difference between VB.NET & C# is that VB.NET puts the namespace as a
project level setting, while C# includes the namespace in the source file.
You can use Project - Properties to change the Root Namespace used in
VB.NET, which is normally the same as the project (just as C# does!)

If you use ILDASM or reference either assembly (VB.NET & C#) you will see
that all classes are in a namespace!

Hope this helps
Jay

 

[Jon Skeet [C# MVP]]

No, but I only have an average of 15 files in each project. (That's
increasing with the complexity of the projects I do, though...)
I did try organising them like directories, but to be quite frank I found
the total time I spent each day just typing the word 'using' was becoming a
bit laborious, so I quit..... I might bite the bullet again.

I suspect you will have to, yes. Any project of significant complexity
is going to become a pain if you don't use namespaces.

A project containing ALL my generic code wouldn't be workable, as some of
the code's relevant to different type of projects, for example console
application, web application, windows forms.
Or is it that you're saying I should make DLLs out of it, and not bother
compiling it in?

That's exactly what I'm suggesting, yes.

I suppose I have my VB6 background to blame for that, as
it's handling of DLL references is far worse than .NET, to such an extent
that VB6 DLLs are unworkable at our office, but .NET DLLs are seamless. I
think that could be the way, really: can you just confirm to me one thing
though: when I reference a DLL, should I get it out of the bin\release folder
(rather than obj\release)? And it then copies it to the client project's bin
directory automatically?
And when i'm building a DLL with a test project, I should reference it by
using the 'projects' tab (when the references gives me the choice of '.NET',
'COM' or 'project')?

Definitely use "Project" - that way your previous question doesn't
matter (it gets it out of the relevant directory itself).

 

[Scott M.]

Your project files are not analogous to namespaces, classes are. You can
have 1000 files and 10,000,000 classes and decide to put all those classes
into any number of namespaces.

Think of it this way, there is a Textbox class for use in ASP.NET projects
and there is a Textbox class for use in Windows Forms projects. It doesn't
make sense to have a textbox be called anything other than a Textbox, so you
have to have 2 classes with the same name. But if you have 2 classes with
the same name, how do you know which is which? Enter namespaces. They
qualify a class and tell us where the actual class definition is for a name.

 

[Nick Malik]

Just one more note:

I think that could be the way, really: can you just confirm to me one thing
though: when I reference a DLL, should I get it out of the bin\release folder
(rather than obj\release)? And it then copies it to the client project's bin
directory automatically?

If you are referencing an assembly within the same solution, you can use
"project" references. However, if you do create assemblies with generic
reusable code, sooner or later you will need to reference the compiled DLL.
In that case, ALWAYS reference out of the 'obj' directory. Use the 'bin'
directory to run your debugger or copy files for "xcopy deployment". Never
use this directory for making a reference to a compiled assembly.

--- Nick Malik

 

[Guest]

Definitely use "Project" - that way your previous question doesn't
matter (it gets it out of the relevant directory itself).

Interesting... I do like the way the 'project' setting abstracts the need to
choose between obj and bin, but are you saying to use that all the time, even
when I'm not necessarily working on a test project, but actually using the
DLL, knowing that it works correctly? That sounds fine, the only issue being
that if I want to give a co-worker one of my DLLs or vice versa, they need
all the project files, not just the DLL file itself?

Can source control get round this?

 

[Jon Skeet [C# MVP]]

Interesting... I do like the way the 'project' setting abstracts the need to
choose between obj and bin, but are you saying to use that all the time, even
when I'm not necessarily working on a test project, but actually using the
DLL, knowing that it works correctly? That sounds fine, the only issue being
that if I want to give a co-worker one of my DLLs or vice versa, they need
all the project files, not just the DLL file itself?

Can source control get round this?

If you've just got the DLL, add a reference to that. If you've got the
project in the same solution, add a reference to the project instead.

 

[Nick Malik]

no. Source control doesn't get around this.

If you are sharing the DLL with another project, on a machine that has the
source, refer to the OBJ directory.
If you are sharing the DLL with another coworker, and they don't have the
source, just have them refer to the DLL.

--- Nick