Develop Reference

Disadvantages of separating code corresponding to independent blocks with different namespace rather than a different project in the same solution

I am working on a project in which my entire team is facing the following problem, please help me to discover the issues associated with the approach which we have decided to follow so that we can save ourselves beforehand :)
We have decided to separate out the entire code of our application into just three projects in a single solution.
1) One project will contain entire UI
2) Second will contain entire business logic. In this project the code corresponding to different modules of our application will be separated via different namespaces rahter than having separate project for each modules or dependent modules.
3) The third project will contain all the common code
I am still able to see that there might be some problem in future if we put the entire code in second project under different namespaces in a single dll rather that splitting it in different dlls/projects.
We are working on a WPF based application.
Please help!
Shahil Gautam

I am still able to see that there might be some problem in future if we put the entire code in second project under different namespaces in a single dll rather that splitting it in different dlls/projects. We are working on a WPF based application.
The only "problem" with doing this is that it's a bit easier to "accidentally" reference types in other namespaces. If you separate into separate projects, the only way to "pollute" your type with business logic unrelated to it would be to explicitly add a reference. When it's in the same project, you can have a using statement or a fully qualified type name, and "use" an unrelated type without any compiler warnings.

I think that's a sensible choice. I general, assemblies should be units of deployment. There is no need to have 10 assemblies if they are always going to be deployed together.
One issue however is that you will have to be more careful about your dependencies within a project. When separating things into different projects, there are physical barriers for introducing inappropriate dependencies, while now you will have to be more conscious about this. A tool like ndepend might help you find suspicious dependencies in your code.

I do not see why you would want to have multiple namespaces within your business logic project.
There are two possibilities:
ONE. All of the types that you define in the project have different unqualified names.
In this case, separating the namespaces would have little purpose. The only benifit would be that the intellisense object selections would be shorter and clearer when the usings to the other namespaces are omitted. Putting the types into separate projects would accomplish the same thing just as well, and offer better separation of concerns.
TWO. Some of the types in the different namespaces have the same unqualified names.
In this case, confusion could easily result, whenever a using from another namespace is added in an unsuccessful attempt to reference a type from another namespace with its unqualified name. If there is no danger of that happening, then, once again, why not put the objects into separate projects, since, clearly, the lines between the domains are sharply drawn?

Using a part of a class in multiple projects

I have a set of methods that do some utility work over SQL connection, and until now these have been copied over from project to project. But as time goes on, project numbers have grown and I need to keep these methods in sync in case I find a bug or need to update it.
I have managed to get it to the state that SQL access class is a partial class, one part is specific for project and contains wrappers for a specific database. The second part is the common one and contains methods that are used in all project-specific databases.
The problem is that now I would have the "utility" class copied over 8 projects, with the same content, but in different namespaces. In C/C++ it would have been simple, because I would just have #included the contents of the file wherever needed. What should I do in C#?

Separate out the class so that you can have a complete class containing all of the common code, in a common project. Use a common interface to represent the bits of functionality which will be project-specific, implementing that interface in each project and passing an instance of the interface into the common code where necessary.

As Jon says, a library assembly is a good idea.
There are some situations when an assembly reference doesn't lend it self to the requirements so, if creating a library assembly is not an option, it is possible to use a feature easily overlooked in Visual Studio, adding an existing file as a link.
This would allow you to maintain the common part of the partial class in a file that is available in all your projects.
The only restriction is that a relative path is used to reference the file.
The only problem I have had with this strategy is with the open source Mercurial scc provider. When removing a linked file from a project, the underlying file is deleted. Quite annoying but this may not be an issue for you.
Update: The linked file bug in the VS Mercurial SCC should be fixed in the next release.

Can you include only certain forms during a compile

We are developing two versions of an application. Not in the sense of a lite vs standard version of the application, where one version will have limited functionality etc. We will actually be displaying different types of information in the application, depending on the version (that's the best way I can describe it without going into too many details).
To differentiate the two versions of the application we've considered using the conditional attribute and the #if directive (if there are any other options or better way than these two, I'm open for suggestions). After some research and debate, we've decided to go with the #if approach, since this will not include the unnecessary code during the compile process (whereas the conditional attribute will just remove the calls to the methods that do not meet the condition, but still include the methods... if I'm not mistaken). I realize the two are not mutually exclusive, so we could always mix and match if need be.
Anyway... What we're now wondering, is if there is a way to only include certain windows forms during a compile, based on which version of the application we are compiling. We have split out all of the logic, so the forms are really just forms, with very little code inside them (mostly just calls to form manager classes that handle all of the business logic). The form manager classes will contain some of the #if statements inside of them, so the code can be reused in both versions of the application, whenever possible (instead of making two classes and putting a conditional attribute on the classes... though maybe this is something we should consider).
Is anyone aware of a good way to do this?
TIA
UPDATE:
Just an FYI of what we actually decided to do. We put the different versions of the forms into separate namespaces and then only had to use an #if statement around the namespace using statement at the top of the class that manages all of the forms. Worked out pretty slick and was very litte work.

I do this with library projects. I produce another project (.csproj), and then include into that project the existing sources. In VS2008, right click on the new project, Click add Existing Item... and then instead of clicking Add, use the select arrow to select "Add as Link".
Rather than duplicating source modules, Add as Link will include a reference to the existing source, into the new project. This way you can have N projects, each with a different combination of source modules. I use this in concert with #if statements within the source of common modules to produce different versions of a library.
Add Existing Item http://www.freeimagehosting.net/uploads/th.eff09391e9.png
full image
Add as Link http://www.freeimagehosting.net/uploads/th.f12b764887.png
full image

Another way to do this is using OO inheritance: put functionality that's common to both versions in a superclass, and then create separate subclasses which define the specializations of the superclass for each of your versions.
You can then build your superclass[es] as a shared library, and build each specialized subclass in separate assemblies (which reference the common shared library).
Doing this uses no conditional compilation nor conditional build options.

The solution suggested by ChrisW is probably the correct way to do it. However, it may involve a lot of changes to your design, so here is another one : instead of having several configurations for the same project, create another project with the same sources. To do that, the easiest way is to create a copy of your .csproj file and include it in the solution

C# single project organization

I am reorganizing my source files into a single solution with a single project, due to various reasons:
a paranoic configured antivirus software;
Advices on partitioning code through .NET assemblies
Control component dependencies to gain clean architecture
Benefit from the C# and VB.NET compilers perf
This leaves me with many namespaces, which are splitted across multiple files. So far, I am using this convention: given the namespace Company.Project.A, the files are named A.f1.cs, A.f2.cs and so on, and the Company.Project.B namespace is splitted across B.f1.cs, B.f2.cs, etc.
Given the single project restriction, are there any better ways to organize multiple files in multiple namespaces?

Yes - use folders.
If you create a folder within a project, new classes within that folder will automatically use the folder name as the basis for the namespace.
For instance, if you have a project with a default namespace of "Company.Project" and a folder "Foo" containing "Bar.cs" you'll end up with:
using System; // Etc
namespace Company.Project.Foo
{
class Bar
{
}
}

So the solution is right here. It's Folders. But it's sometimes tricky. First of all it's kind of a good idea to have one file per class. If you will pack several classes into one file - you'll have problems with finding them with time.
Second thing about folders - if you will click on a folder and choose for example "Add -> New Item", this item will be put into selected folder. But watch out! If you will move files between folders, namespaces are not updated.
It's common source of messing project. Just after a while you can end up with a project where you have neat organized folder and files, but not reflecting namespaces. So for example, if you have class MyClass in folder MyFolder make sure, your namespace for this class is something like MyApp.MyFolder and not some old rubbish.
So If you will not pack classes into one file and watch if classes namespaces reflect folder hierarchy - you're on the good road to make you project very easy to read and navigate.

100% agree with Jon Skeet.
To gain more overview at the folder level we're creating folders breaking the namespace structure by prefixing them with an underscore.

Should the folders in a solution match the namespace?

Should the folders in a solution match the namespace?
In one of my teams projects, we have a class library that has many sub-folders in the project.
Project Name and Namespace: MyCompany.Project.Section.
Within this project, there are several folders that match the namespace section:
Folder Vehicles has classes in the MyCompany.Project.Section.Vehicles namespace
Folder Clothing has classes in theMyCompany.Project.Section.Clothing namespace
etc.
Inside this same project, is another rogue folder
Folder BusinessObjects has classes in the MyCompany.Project.Section namespace
There are a few cases like this where folders are made for "organizational convenience".
My question is: What's the standard? In class libraries do the folders usually match the namespace structure or is it a mixed bag?

Also, note that if you use the built-in templates to add classes to a folder, it will by default be put in a namespace that reflects the folder hierarchy.
The classes will be easier to find and that alone should be reasons good enough.
The rules we follow are:
Project/assembly name is the same as the root namespace, except for the .dll ending
Only exception to the above rule is a project with a .Core ending, the .Core is stripped off
Folders equals namespaces
One type per file (class, struct, enum, delegate, etc.) makes it easy to find the right file

No.
I've tried both methods on small and large projects, both with single (me) and a team of developers.
I found the simplest and most productive route was to have a single namespace per project and all classes go into that namespace. You are then free to put the class files into whatever project folders you want. There is no messing about adding using statements at the top of files all the time as there is just a single namespace.
It is important to organize source files into folders and in my opinion that's all folders should be used for. Requiring that these folders also map to namespaces is unnecessary, creates more work, and I found was actually harmful to organization because the added burden encourages disorganization.
Take this FxCop warning for example:
CA1020: Avoid namespaces with few types
cause: A namespace other than the global namespace contains fewer than five types
https://msdn.microsoft.com/en-gb/library/ms182130.aspx
This warning encourages the dumping of new files into a generic Project.General folder, or even the project root until you have four similar classes to justify creating a new folder. Will that ever happen?
Finding Files
The accepted answer says "The classes will be easier to find and that alone should be reasons good enough."
I suspect the answer is referring to having multiple namespaces in a project which don't map to the folder structure, rather than what I am suggesting which is a project with a single namespace.
In any case while you can't determine which folder a class file is in from the namespace, you can find it by using Go To Definition or the search solution explorer box in Visual Studio. Also this isn't really a big issue in my opinion. I don't expend even 0.1% of my development time on the problem of finding files to justify optimizing it.
Name clashes
Sure creating multiple namespaces allows project to have two classes with the same name. But is that really a good thing? Is it perhaps easier to just disallow that from being possible? Allowing two classes with the same name creates a more complex situation where 90% of the time things work a certain way and then suddenly you find you have a special case. Say you have two Rectangle classes defined in separate namespaces:
class Project1.Image.Rectangle
class Project1.Window.Rectangle
It's possible to hit an issue that a source file needs to include both namespaces. Now you have to write out the full namespace everywhere in that file:
var rectangle = new Project1.Window.Rectangle();
Or mess about with some nasty using statement:
using Rectangle = Project1.Window.Rectangle;
With a single namespace in your project you are forced to come up with different, and I'd argue more descriptive, names like this:
class Project1.ImageRectangle
class Project1.WindowRectangle
And usage is the same everywhere, you don't have to deal with a special case when a file uses both types.
using statements
using Project1.General;
using Project1.Image;
using Project1.Window;
using Project1.Window.Controls;
using Project1.Shapes;
using Project1.Input;
using Project1.Data;
vs
using Project1;
The ease of not having to add namespaces all the time while writing code. It's not the time it takes really, it's the break in flow of having to do it and just filling up files with lots of using statements - for what? Is it worth it?
Changing project folder structure
If folders are mapped to namespaces then the project folder path is effectively hard-coded into each source file. This means any rename or move of a file or folder in the project requires actual file contents to change. Both the namespace declaration of files in that folder and using statements in a whole bunch of other files that reference classes in that folder. While the changes themselves are trivial with tooling, it usually results in a large commit consisting of many files whose classes haven't even changed.
With a single namespace in the project you can change project folder structure however you want without any source files themselves being modified.
Visual Studio automatically maps the namespace of a new file to the project folder it's created in
Unfortunate, but I find the hassle of correcting the namespace is less than the hassle of dealing with them. Also I've got into the habit of copy pasting an existing file rather than using Add->New.
Intellisense and Object Browser
The biggest benefit in my opinion of using multiple namespaces in large projects is having extra organization when viewing classes in any tooling that displays classes in a namespaces hierarchy. Even documentation. Obviously having just one namespace in the project results in all classes being displayed in a single list rather than broken into categories. However personally I've never been stumped or delayed because of a lack of this so I don't find it a big enough benefit to justify multiple namespaces.
Although if I were writing a large public class library then I would probably use multiple namespaces in the project so that the assembly looked neat in the tooling and documentation.

I think the standard, within .NET, is to try to do it when possible, but not to create unnecessarily deep structures just to adhere to it as a hard rule. None of my projects follow the namespace == structure rule 100% of the time, sometimes its just cleaner/better to break out from such rules.
In Java you don't have a choice. I'd call that a classic case of what works in theory vs what works in practice.

#lassevk: I agree with these rules, and have one more to add.
When I have nested classes, I still split them out, one per file. Like this:
// ----- Foo.cs
partial class Foo
{
// Foo implementation here
}
and
// ----- Foo.Bar.cs
partial class Foo
{
class Bar
{
// Foo.Bar implementation here
}
}

I'd say yes.
First, it will be easier to find the actual code files by following down the namespaces (say, when somebody e-mails you a naked exception call stack). If you let your folders go out of sync with namespaces, finding files in big codebases becomes getting tiring.
Second, VS will generate new classes you create in folders with the same namespace of its parent folder structure. If you decide to swim against this, it will be just one more plumbing job to do daily when adding new files.
Of course, this goes without saying that one should be conservative about how deep xis folder/namespace hierarchy goes.

Yes they should, only leads to confusion otherwise.

What's the standard?
There is no official standard but conventionally the folder-to-namespace mapping pattern is most widely used.
In class libraries do the folders usually match the namespace
structure or is it a mixed bag?
Yes, in most class libraries the folders match the namespace for organizational ease.