I've recently read guidelines where it is recommended to organize projects
in directories that match assembly names. For example, if I have an assembly
called MyCompany.MyProduct.Data, then I should have the following folder
structure on my local disk and in version control system:

MyCompany
MyProduct
Data

Inside the innermost folder I will place a C# project that is called
MyCompany.MyProduct.Data.csproj

Then for each type/class defined in the project I will have a file with
class name.

I believe this is a very consistent approach, although I find recommendation
to create one file per enumeration type to be a bit extreme. However I am
bit confused if I should use assembly name or namespace name as a base for
my folders, and if assembly names and namespaces should have different
structure at all. What is your approach to namespace naming? Are there any
reasons they should not be different, i.e. a namespace should not be
assigned a name of its assembly? I have looked at our projects and in
principle it looks that we can unify their namespaces, so they will match
respective assembly names. It this a good idea?

Vagif Abilov
vagif @online.no
Oslo Norway

"Vagif Abilov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I've recently read guidelines where it is recommended to organize projects
> in directories that match assembly names. For example, if I have an
assembly
> called MyCompany.MyProduct.Data, then I should have the following folder
> structure on my local disk and in version control system:
>
> MyCompany
> MyProduct
> Data
>

<SNIP>

As with many things it is a matter of personal choice, but my 2p is that
organising into directories like that
based on assembly names is horrible! It's common in Java because a
dot-seperated typename is resolved
by traversing corresponding directories, but I haven't seen it in any .NET
projects.

I'd instead go with a seperation based on functionality of the code. This
may or may not match your
namespaces. Dividing into core/gui/tests is one strategy that I use often.
YMMV.

Ben

But do your assembly names match namespaces?


"B S Wootton" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>
> "Vagif Abilov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> I've recently read guidelines where it is recommended to organize
>> projects
>> in directories that match assembly names. For example, if I have an
> assembly
>> called MyCompany.MyProduct.Data, then I should have the following folder
>> structure on my local disk and in version control system:
>>
>> MyCompany
>> MyProduct
>> Data
>>
>
> <SNIP>
>
> As with many things it is a matter of personal choice, but my 2p is that
> organising into directories like that
> based on assembly names is horrible! It's common in Java because a
> dot-seperated typename is resolved
> by traversing corresponding directories, but I haven't seen it in any .NET
> projects.
>
> I'd instead go with a seperation based on functionality of the code. This
> may or may not match your
> namespaces. Dividing into core/gui/tests is one strategy that I use
> often.
> YMMV.
>
> Ben
>
>
>

"Vagif Abilov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> But do your assembly names match namespaces?
>

No, I would typically have many sub-namespaces in a given assembly. For
instance:

ben.core.dll:
- ben.core
- ben.core.remoting
- ben.core.logging

ben.gui:
- ben.gui.serialisation
- ben.gui

This is because my applications are usually driven like this. If you would
like to say, divide your logging stuff out for future use, by all means
refactor this into a seperate assembly. In this situaiton I would choose to
put it into a different directory based on it's function - rather than it's
namespace or assembly name.

Again, just my suggestion.

It might be worth downloading some large .NET open source frameworks and
seeing if you like their internal organisation. That's what I did!

Ben

Thank you Ben. I am currently looking at some examples from large projects.
Looks like we will go for "one namespace per assembly" approach.

Vagif


"B S Wootton" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Vagif Abilov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> But do your assembly names match namespaces?
>>
>
> No, I would typically have many sub-namespaces in a given assembly. For
> instance:
>
> ben.core.dll:
> - ben.core
> - ben.core.remoting
> - ben.core.logging
>
> ben.gui:
> - ben.gui.serialisation
> - ben.gui
>
> This is because my applications are usually driven like this. If you
> would
> like to say, divide your logging stuff out for future use, by all means
> refactor this into a seperate assembly. In this situaiton I would choose
> to
> put it into a different directory based on it's function - rather than
> it's
> namespace or assembly name.
>
> Again, just my suggestion.
>
> It might be worth downloading some large .NET open source frameworks and
> seeing if you like their internal organisation. That's what I did!
>
> Ben
>
>

"Vagif Abilov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you Ben. I am currently looking at some examples from large
> projects. Looks like we will go for "one namespace per assembly" approach.

I think you should reconsider.

I have found that going for a one-one relationship between assemblys and
namespaces almost defeats the purpose of using namespaces in the first place
(except for solving ambiguous classnames).

For large SOA projects I typically define assemlies per Facade, ie a can
have a customer and a order dll.
If I want to have entity validaors in several tier and or datasets on
several tiers I wrap them in separate assemblies.

However, my namespace/assembly group might look something like this (a
simple example):

customer.facade (customer.dll)
customer.data (dto.dll)
customer.validation (validator.dll)
order.facade (order.dll)
order.data (dto.dll)
order.validation (validator.dll)

Hence, I use namespaces to structure my code and assemblies to structure my
tiers and layers.

Hope this helps
- Michael S