Finding Suggestions for Microsoft Visual Studio Solutions and Project Naming Conventions

Question

It seems that there is no proven and best practice to help you customize your solutions, projects and assembled assemblies. Microsoft seems to have tried in the days of VS.net, but they have since removed this content. For each method that I read, I read another that claims the opposite is better, or a message that only applies “if only Microsoft ...”, but doesn’t actually provide any solutions.

It seems that there are many ways to do this, that everyone seems to work for different groups in their situations, so I thought that I would ask what conventions you use and why they work for YOU in your situation.

I hope that this will provide some good agreements for different situations, small development groups and projects for large diverse development groups and projects.

What conventions do you use for ...

• What are your decisions and why?
• What are your projects and why?
• What are your builds and why?
• know when to create a new project or add to an existing project and why?
• know when to split a solution into smaller solutions and why?
• know when to split a project into several projects and why?

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

Answer 1

This is 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).

Naming solutions doesn't matter much to me. I tend to create solutions for a specific purpose and add existing projects to solutions. If your solution is more than 15 projects (just an approximate number), consider adding some of these projects as links. Most people do not have to work on more than 15 projects at a time.

Naming projects is very important 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'm trying to use enough folders in my projects so that all the files in the folder can be easily viewed without scrolling through the solution browser.

My typical web project looks something like this. Note that in the enclosure are different to represent resources with extension / compilation compared to those that are not.

• client (css, javascript)
• config (private, custom configuration files, if any)
• Content (master pages, ASPX and ASCX, divided into logical folders)
• Handlers (ASHX etc.)
• Images
• MSBuild (build scripts)
• WebServices (they should ONLY be small services that are directly related to the site, otherwise split them into a separate project).

I started using partial classes more and more to create comprehensive classes that can do many things without clogging the code. For example, I recently created a web service whose sole purpose is to return JSON to the client, but the logic extends to nearly a dozen partial classes in order to organize it better.

Hope you get started.

Answer 2

In our case, we keep the names of our projects completely identical to the namespaces that we selected for a particular assembly. Thus, it is easy to map the location of the class file in the physical folder. For example, CompanyName.BusinessLine.BusinessService or CompanyName.Framework.Security . Therefore, if a developer is looking for CompanyName.Framework.Security.Cryptography.cs , he can immediately find out the project and open this project.

Answer 3

According to Tim, this is very wide. A few notes:

• A solution is usually a collection of projects. For example, many solutions may include the same projects. So it doesn't really matter: if you don't like the name of the solution, you can throw it away without refactoring at all.
• Like Pradeep, I usually name projects with the top-level namespace that they contain. The "deeper" namespaces fall into subdirectories, so classes in the Foo.Bar.Baz namespace can be located in the Baz directory of the Foo.Bar project.

I tend to share on projects for:

• Reuse elements (for example, one assembly for the user interface, one for a reusable set of model classes, one for reusable universal classes)
• Deployment elements (for example, one for production, one for testing, in pairs)
• Link elements (for example, if you have a common assembly of Skeety.Common with some interfaces used by other classes, there may be a assembly of Skeety.Common.Testing containing types that will help you test classes using Skeety.Common ). This leads to the following rules:
  • Production assemblies can only refer to other production assemblies
  • Assembly testing may only apply to production assemblies and other production assemblies.
  • Test assemblies (those that contain the tests themselves) can relate only to production and test assemblies, and not to other test assemblies.
  • No circular references allowed, obviously

In many cases, it’s actually not so important how you separate things, but it helps to make the design cleaner when you develop dependency levels (therefore, building business logic should not reference the UI, but vice versa is good).

Too many projects can definitely slow you down, both in terms of build time, and for development, where everything should be. Too few designs make design less clear. Over time, you are likely to get more feeling from how everything should be laid out - but I'm blown up if I say that I always know the best way :)