.NET project structure best practices

  • Thread starter Thread starter Vagif Abilov
  • Start date Start date
V

Vagif Abilov

We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/2005/01/26/361369.aspx

Here is what Brad (and AFAIK Microsoft) suggests regarding project folder
structure:

"Directory names should follow the namespace for the class
For example, I would expect to find the public class
"System.Windows.Forms.Control" in "System\Windows\Forms\Control.cs"."

Sounds logical, and it simplifies search for projects and files for specific
assembly. However we found two main issues:

1. Non-Web projects. Let's say we have an assembly MyCompany.Data. It is
placed in a folder MyCompany.Data and stored in version control sysmtem
using the same folder structure. Now we create another project, called
MyCompany.Data.SqlServer to manage SQL Server-specific functions. According
to Microsoft's recommendations, we will place it under MyCompany.Data. This
means on developer's machine the folder MyCompany.Data will not only contain
source files and binaries owned by MyCompany.Data assembly, but will also
have a sub-folder SqlServer that has nothing to do with MyCompany.Data
project. It's not a sub-project, but it will be placed in a subfolder simply
because it's namespace has MyCompany.Data in it's root.

2. Web projects. Here we have the same situation, but with possibly more
serious consequences. Web projects may have many sub-folders with resources,
images, scripts etc. Placing sub-folders there is misleading - it looks like
sub-project is a part of a Web site (and it may even be copied using XCOPY
deployment), but in fact it has nothing to do with the Web site. Again it
just has co-related namespace.

We haven't found so far an elegant resolutions to these problems. If
somebody follows the guidelines above and has some ideas about how to handle
this, please let me know.

Thanks in advance

Vagif Abilov
Oslo Norway
 
Vagif Abilov said:
We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/2005/01/26/361369.aspx

Here is what Brad (and AFAIK Microsoft) suggests regarding project folder
structure:

"Directory names should follow the namespace for the class
For example, I would expect to find the public class
"System.Windows.Forms.Control" in "System\Windows\Forms\Control.cs"."

Sounds logical, and it simplifies search for projects and files for
specific assembly. However we found two main issues:

1. Non-Web projects. Let's say we have an assembly MyCompany.Data. It is
placed in a folder MyCompany.Data and stored in version control sysmtem
using the same folder structure. Now we create another project, called
MyCompany.Data.SqlServer to manage SQL Server-specific functions.
According to Microsoft's recommendations, we will place it under
MyCompany.Data. This means on developer's machine the folder
MyCompany.Data will not only contain source files and binaries owned by
MyCompany.Data assembly, but will also have a sub-folder SqlServer that
has nothing to do with MyCompany.Data project. It's not a sub-project, but
it will be placed in a subfolder simply because it's namespace has
MyCompany.Data in it's root.
Click to expand...

No. If MyCompany.Data.SqlServer is a seperate assembly then it goes in a
seperate project and a seperate folder structure:

c:\projects\MyCompany.Data\MyCompany\Data\*.cs

c:\projects\MyCompany.Data.SqlServer\MyCompany\Data\SqlServer\*.cs

Although I would disagree with this guidance. It stinks of Java. Each
assembly should have a root namespace. For instance MyCompany.Data should
have a root namespace of MyCompany.Data, duh. Then in the project folder
for MyCompany.Data classes in the MyCompany.Data namespace should appear in
the root of the project folder. If the assembly also has classes in the
MyCompany.Data.Common namespace, they should go in a "Common" subfolder:

c:\projects\MyCompany.Data\*.cs
c:\projects\MyCompany.Data\Common\*.cs

2. Web projects. Here we have the same situation, but with possibly more
serious consequences. Web projects may have many sub-folders with
resources, images, scripts etc. Placing sub-folders there is misleading -
it looks like sub-project is a part of a Web site (and it may even be
copied using XCOPY deployment), but in fact it has nothing to do with the
Web site. Again it just has co-related namespace.
Click to expand...

You can resolve this with factoring out most of your web project code to a
seperate project. The code behind files go in the web project, and perhaps
a couple of utility classes, but any substantial amount of code should go in
a seperate assembly.

David
 
c:\projects\MyCompany.Data.SqlServer\MyCompany\Data\SqlServer\*.cs

This does not make sense to me. I agree it would be nice to place each
project in its own folder, but why creating all these subfolders in
c:\projects\MyCompany.Data.SqlServer? I see your point, but I would swap
prefix and suffix:

c:\projects\MyCompany\Data\SqlServer\MyCompany.Data.SqlServer\*.cs

Then the folder c:\projects\MyCompany\Data\ can be used as a root for other
projects with namespace derived from MyCompany.Data.

Just my 2 cents
Vagif
 
My two cents. The last thing you want is a deep dir structure. You want it
wide, not deep. So having nesting is just a major pain if you ask me. Make
things simple. Each project has it own directory in the root project dir -
period. If you create containers in your projects to logically orginize
stuff, fine. Also create a "subst" drive to your project directory for easy
access from the command line (I use V:). If your at the command line, last
thing you want to do is surf dirs to find stuff.
 
This must be one of the worst idea I've seen in a long time!!

I just create my directories under my "Projects" directory. The directory
has the same name as the namespace.
 
Thanks William,

Yes, this is one option: all assemblies are siblings. It's a question then
if it's consistent to make Web projects and Web services siblings or
standard assemblies, and there are auxilliary projects, tools, tests etc. So
it will quickly grow up to a hundred of siblings even for a small company.
But I see your point.

Vagif
 
What about Web projects then? Web services, tools, tests? Also on the same
level?

Vagif
 
Back
Top