.NET namespaces

Question

My background is primarily as a Java Developer, but lately I have been doing some work in .NET. So I have been trying to do some simple projects at home to get better at wor

Answer 1

A VS solution normally contains one or more projects. Thse projects have default namespaces (usually the namespace is just the name of the project). Normally, if you add a folder within the project, all the classes in it will be named as follows:

DefaultNamespace.FolderName.ClassName

Of course, you can change the default namespace of the project, and have your classes be named in whatever manner you wish.

As far as when/how to break stuff into projects, that's a matter of experience and/or preference. However, you should absolutely break stuff into projects within a solution, in order to keep your project organized. If managing too many assemblies becomes cumbersome (as Blair suggested), you can always ILMerge your assemblies into a single assembly. What's great about ILMerge is that even though you end up with just one assembly, all your classes keep their original fully qualified names.

It's also important to remember that a VS solution has no bearing on code - ie. they do not get built. VS Solutions are nothing but a way to group projects; it's the projects that are built and turned into DLLs.

Finally, VS let's you add "virtual" folders anywhere in the solution. These folders do not map to a folder in the filesystem, and are just used as another mean to help you organize your projects and other artifacts within the solution.

Answer 2

Namespaces are purely semantic. Whilst they usually do reflect a folder structure, at least when using Visual Studio IDE, they do not need to.

You can have the same namespace referenced in multiple libraries, ugly but true.

Answer 3

Namespaces are a logical grouping, while projects are a physical grouping.

Why is this important? Think about .NET 2.0, 3.0, and 3.5. .NET 3.0 is basically .NET 2.0 with some extra assemblies, and 3.5 adds a few more assemblies. So for instance, .NET 3.5 adds the DataPager control, which is a web control and should be grouped in System.Web.UI.WebControls. If namespaces and physical locations were identical, it couldn't be because it's in a different assembly.

So having namespaces as independent logical entities means you can have members of several different assemblies which are all logically grouped together because they're meant to be used in conjunction with each other.

(Also, there's nothing wrong with having your physical and logical layouts pretty similar.)

Answer 4

You can add folders to your solution for each namespace. While it'll still compile to a single executable, it organizes your source files and gives (what I think is) the desired effect?

I typically add a folder for each namespace in my project, and nest them according to the same hierarchy (MyApp.View.Dialogs for example)

Answer 5

I've always considered source file organization and assigning identifiers to classes and objects to be two separate problems. I tend to keep related classes in groups, but not every group should be a namespace. Namespaces exist (more or less) to solve the problem of name conflicts—in flat-namespace languages like C, you can't walk two feet without tripping over identifiers like mycompany_getcurrentdate or MYCGetCurrentDate, because the risk of a conflict with another function in a third-party (or system) library is that much smaller. If you created a package or namespace for every logical separation, you would get (Java example) class names like java.lang.primitivewrapper.numeric.Integer, which is pretty much overkill.

Answer 6

Yep, in .NET namespace doesn't depend on file system or anything else. It's a great advantage in my opinion. For example you can split your code across different assemblies which allows flexible distribution.

When working in Visual Studio, IDE tends to introduce new namespace when you add new folder to project tree.

Here is a useful link from MSDN:

Namespace Naming Guidelines

The general rule for naming namespaces is to use the company name followed by the technology name and optionally the feature and design as follows.
CompanyName.TechnologyName[.Feature][.Design]

Of course you can use namespaces in the way you find more suitable. However if you going to share your code, I would recommend to go along with accepted standards.

EDIT:

I highly recommend to any .net developer to get a copy of Framework design guidelines This book will help you to understand how and why .NET is designed.