Projects and Namespaces

Why do you need more than one project?

You might not, but I am going to assume that since you are reading this at some point in your life you will write more than one program. This means you will likely need to reuse some of your code. Note that I said "reuse", not "copy and paste". The basic process is relatively simple - put any reusable code in a class library then reference that class library from your other projects. The specifics can be more complicated, but with a little guidance and some practice it becomes pretty intuitive.

One of these things is not like the other

Anyone who has watched at least a little bit of Sesame Street knows what that means. Even if you haven't, it should still be self-exlanitory and so should the logic used to determine what goes in what project. I recommend starting with one libary for common code, but instead of talking about what should go in there, let's think about what should not go in your common library. I would not reference System.Web or System.Windows from your common library. The logic here is that those are not really "common". While there are some circumstances whee you might want to be able to reference some "Windows" code from a web application, these are pretty few and far between. The odds of needing to reference web code in a Widnows application are even lower (although XAML/Silverlight/WPF might change that). So I recommend creating a Windows library and a web library to hold code for those specific platforms.

Finally, you might have some more specific code which is only going to be used by certain types of applications. This includes data access, physics, graphics (such as DirectX), etc. Even though some of these things like physics could be used anywhere, they are not as likely to be used in every application. So that is another discriminator I would use to determine how to split up your projects - how "common" is your code.

What's wrong with my namespace?

Many of you have downloaded or read samples from the internet. Most likely the namespace has been very simple - the name of the project. Even the Ajax Control Toolkit which is maintained by Microsoft developers uses the namespace "AjaxControlToolkit". While this isn't a horrible practice, it isn't as "clean" as it could be. The more common code you have, the more important namespaces become. I would start your project names (and therefore your default namespaces) with your company name if you have one. If you don't have one, you can make one up or just use your name. For open source projects, you can use the project name like I have done in these samples. To break your namespaces down further, just add folders to your projects and Visual Studio will create sub-namespaces for you.

Here are some sample namespaces:
  • HelloRealWorld.Common - Truly common code
  • HelloRealWorld.Console - Console application
  • HelloRealWorld.Windows - Windows-specific common code
  • HelloRealWorld.Windows.Forms - Forms for a Windows application
  • HelloRealWorld.Windows.Controls - User controls and custom controls for Windows forms
  • HelloRealWorld.WebApplication - Web application
  • HelloRealWorld.Web - Web-specific common code
  • HelloRealWorld.Web.Controls - Reusable web controls and common web-specific code

A quick note about file structure and source control

If you have downloaded any of the source code for this project you might have been suprised by the folder structure I am using. On my workstation, I have a folder for my project and inside that project I have 2 folders - "Main" and "Releases". The Main folder contains the solution file(s) and folders with all of the projects. This is because when I go to make a release, I "branch" the Main folder into a new folder under "Releases". This is very simple if you have Team Explorer and are using the TFS client for source control. If you aren't you can just copy and paste. The important concept here is the Main folder and that there is a separate folder within the root project folder which contains your main source code (and anything else you need for your application to run). Many people just create a new solution (if they bother purposely creating a solution at all) in the root of their Visual Studio project default folder and start coding away. If you ever bind that solution folder to a source control provider such as TFS you will have a hard time branching releases. For me it is easy. I just create a new folder under releases with the name of the release and then branch the main folder into that folder. What is really nice is that I only get the source code when I branch so there are no binary files to remove when I create my zip file to upload for the release.

Last edited Jul 13, 2009 at 4:00 AM by douglampe, version 8


No comments yet.