Looking for Suggestions on Microsoft Visual Studio Solution and Project Naming Conventions

Question

There doesn't seem to be any tried and true set of best practices to guide you on how to setup your solutions, projects and the assemblies they output. Microsoft seemed to have tried back in the VS.net days, but they have since retired this content. For every method I read about I read another that claims the opposite is better, or a post that only concerns itself with "if only Microsoft would..." but really provide no solutions.

It appears there are many ways to do this that all seem to work for various groups in their situations, therefore I thought I would ask what conventions YOU use and why they work for YOU in your situation.

I hope that this will provide several good conventions for different situations, small development groups and projects to large diversely located development groups and projects.

What conventions do you use to...

• name your solutions, and why?
• name your projects, and why?
• name your assemblies, and why?
• know when to create a new project or add to an existing project, and why?
• know when to split up a solution into smaller solutions, and why?
• know when to break up a project into multiple projects, and why?

Just to be clear, the WHY is just as import as the HOW in these answers. There are many answers posted on the how here and other places, very few say why they use one convention over another.

Answer 1

In our case we keep our project names quite identical to namespaces that we chose for particular assembly. That way it becomes easy to map location of a class file in physical folder. For example - CompanyName.BusinessLine.BusinessService or CompanyName.Framework.Security. So if a developer is looking at CompanyName.Framework.Security.Cryptography.cs, he can immediately figure out the project and open that project.

Answer 2

That's a very broad question, but a good one. I will start with a simple structure that I use for ASP.Net web projects (MVC will look completely different).

Solution naming isn't a big deal to me. I tend to create solutions for a specific purpose, and add existing projects to the solutions. If your solution is over 15 projects (just a rough number) consider adding some of those projects as references. Most people don't need to work on more than 15 projects at a time.

Project Naming is a big deal to me.

// class library that supports the site itself and abstracts
// more complicated UI logic into a separate place
Company.ProductName.Web;

// website
Company.ProductName.Web.UI;

// main business object library for product
//
// of course, you can have as many of these as needed.
Company.ProductName;

I try to use enough folders in my projects so that all files in a folder can easily be viewed without scrolling the solution explorer.

My typical web project looks something like this. Note the different in casing to represent namespaced/compilable resources versus those that are not.

• client (css, javascript)
• config (private, custom config files, if any)
• Content (Master Pages, ASPXs and ASCXs, broken into logical folders)
• Handlers (ASHXs and such)
• images
• MSBuild (build scripts)
• WebServices (these should ONLY be small services that are directly related to the site in question. Otherwise, break them into a separate project).

I've started using partial classes more and more to create comprehensive classes that can do many things without having the code be cluttered. For example, I recently created a web service whose single purpose is to return JSON to the client, but the logic is spread across almost a dozen partial classes to organize it better.

Hope that gets you started.

Answer 3

As Tim says, this is very broad. A few things to note:

• A solution is usually just a collection of projects. Many solutions can include the same projects, for example. As such, it doesn't matter too much: if you don't like a solution name, you can throw it away with no refactoring at all.
• Like Pradeep, I tend to name projects with the top level namespace they contain. "Deeper" namespaces end up in subdirectories, so classes within the Foo.Bar.Baz namespace might be in the Baz directory of project Foo.Bar.

I tend to split into projects across:

• Elements of reusability (e.g. one assembly for a UI, one for a reusable set of model classes, one for a reusable general purpose utility classes)
• Elements of deployment (e.g. one for production, one for testing, in pairs)
• Elements of reference (e.g. if you have a common assembly Skeety.Common with some interfaces used by other classes, there might be a Skeety.Common.Testing assembly containing types which help you to test classes using Skeety.Common). This leads to these rules:
  • Production assemblies can only refer to other production assemblies
  • Testing assemblies can only refer to production assemblies and other production assemblies
  • Test assemblies (the ones containing the tests themselves) can only refer to production and testing assemblies, not to other test assemblies
  • No circular references are allowed, obviously

In many cases it actually doesn't matter too much how you split things up - but it does help to make the design cleaner as you work out the dependency layers (so a business logic assembly shouldn't have a reference to a UI assembly, but vice versa is fine).

Having too many project can definitely slow you down, both in terms of build times and just working out where everything should be. Having too few projects makes the design less clear. Over time you're likely to get more of a gut feeling for how things should be laid out - but I'm blowed if I'd claim to always know the best course of action :)