When do you add a new project for a nested namespace?

Answer 1

The question you have to ask yourself is: do the two sections of code logically fit together as one deployment unit? If so, keep them in the same project. If not, separate them.

To be honest, I would rarely create a new project for the "nested" namespace - it just doesn't seem to work that way usually. In particular, think about whether you'd want to access the "nested" namespace from the "outer" one and vice versa - if they would reasonably reference each other, then they should be in the same project.

Answer 2

Just adding my 2 cents to this question, to expand Jon's answer with some "been there - done that" experience:

I did use, in several solutions, at least two projects named by namespace (well, sort of). For instance, working on MyApp solution, I'd have MyApp.Web and MyApp.Web.Controls.

Or: MyApp.Service, MyApp.Core, MyApp.Core.Entities and so on. Pretty well known naming convention, where the root namespace goes like MyCompany.MyApp.Service etc...

Advantage: - found it very useful when working in a team, to highlight the dependencies between app modules. If your Web.Controls module (it's just an example, don't pick on it :) is shared across the web UI, you typically don't want app-specific code in your custom controls. Keeping the "child/nested" module separate (referenced by the main project) enforces this. - at least thinking of it will potentially help you create a better project structure. Which namespace goes in a separate project and which doesn't? Answering the question alone is helpful enough.

Disadvantage: - it's very easy to get "trigger happy" and create a hundred projects instead of making appropriate folders/namespaces.

That said, usually tend to create folders instead of separate projects, except for the case when it's really a "sub-module".