.NET project structure best practices

[Vagif Abilov]

We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/...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

[David Browne]

"Vagif Abilov" <va***@online.no> wrote in message
news:O1**************@TK2MSFTNGP10.phx.gbl...

We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/...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.
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\Dat a\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.

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

[Vagif Abilov]

c:\projects\MyCompany.Data.SqlServer\MyCompany\Dat a\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.Dat a.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
"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Vagif Abilov" <va***@online.no> wrote in message
news:O1**************@TK2MSFTNGP10.phx.gbl...

We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/...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.

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\Dat a\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.

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

[William Stacey [MVP]]

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.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Vagif Abilov" <va***@online.no> wrote in message
news:uY**************@tk2msftngp13.phx.gbl...

c:\projects\MyCompany.Data.SqlServer\MyCompany\Dat a\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.Dat a.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
"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Vagif Abilov" <va***@online.no> wrote in message
news:O1**************@TK2MSFTNGP10.phx.gbl...

We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/...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.

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\Dat a\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.

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

[Relaxin]

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.

"Vagif Abilov" <va***@online.no> wrote in message
news:O1**************@TK2MSFTNGP10.phx.gbl...

We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/...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]

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
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Ov**************@TK2MSFTNGP15.phx.gbl...

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.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Vagif Abilov" <va***@online.no> wrote in message
news:uY**************@tk2msftngp13.phx.gbl...

c:\projects\MyCompany.Data.SqlServer\MyCompany\Dat a\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.Dat a.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
"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

>
> "Vagif Abilov" <va***@online.no> wrote in message
> news:O1**************@TK2MSFTNGP10.phx.gbl...
>> We decided to adopt .NET coding guidelines posted by Brad Abrams from
>> Microsoft:
>> http://blogs.msdn.com/brada/archive/...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.
>
> 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\Dat a\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.
>
> 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
>

[Vagif Abilov]

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

Vagif

"Relaxin" <so*******@amer.com> wrote in message
news:uM*************@TK2MSFTNGP10.phx.gbl...

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.

"Vagif Abilov" <va***@online.no> wrote in message
news:O1**************@TK2MSFTNGP10.phx.gbl...

We decided to adopt .NET coding guidelines posted by Brad Abrams from
Microsoft:
http://blogs.msdn.com/brada/archive/...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