Naming convention for Visual Studio solutions and projects

Question

We were thinking about organizing our BIG project this way:

\trunk
  [CompanyName]
    [Product1]
        [Project1]
          CompanyName.Product1.Project1.csproj
        [Project2]
          CompanyName.Product1.Project2.csproj
        CompanyName.Product1.sln
    [Product2]

We were trying to follow Microsoft's recommendation that namespace names follow folder structure, but are there any drawbacks for making it this way? What is the naming convention for solutions and projects that you apply?

Answer 1

An alternative that I've used is to have all my solution files in the same directory.

\trunk
  [CompanyName]
    CompanyName.Product1.sln
    CompanyName.Product2.sln
    [Product1]
        [Project1]
          CompanyName.Product1.Project1.csproj
        [Project2]
          CompanyName.Product1.Project2.csproj
    [Product2]
        [Project3]
          CompanyName.Product2.Project3.csproj

Answer 2

With respect to file names - I prefer that my project file name match the output assembly name because it makes it much easier to know what produces what. Doing a directory listing is much faster than searching the csproj files in a tree for the one that produces the assembly I care about.

I don't get worked up about solution files because they don't influence our build environment so I end up making my own to have the exact scope I want (and the specific per-solution items, like test metadata, that I want).

With respect to folder structure - I don't worry too much if the folders leading down the project files match the namespaces. I want my code to sit on disk in a way that makes the most sense for the project. Sometimes this means the test code and product code are in sibling directories - sometimes it means they are much further apart. Sometimes there is a namespace that is contributed to by multiple teams (not advocating that design, just a reality) - but those teams want to life in their own folders for whatever reason.

Don't forget the importance of version control branching strategies in your overall project design. The Company and Product boundaries may be branches and therefore would not necessarily need to represented as directories on disk.

Don't let this be a source of analysis paralysis though. Make a reasonable choice. Use version control. You can always change later if you are wrong.

Answer 3

Looks like taken from the school book. That's usually how my solutions get set up, and I have found it to work quite well over the years.

Answer 4

Looks good to me.

It's a point to note that by default, the default namespace in a Visual Studio project is just the project name. Surely that indicates that naming your projects like your namespaces is "the Visual Studio Way".

Solutions are most naturally named after the product/project. Like you indicate.

Answer 5

I consider this is better

\trunk
  [CompanyName]
    [Product1]
      CompanyName.Product1.sln
      [Main] --Optional
        CompanyName.Product1.csproj
      [Project1]
        CompanyName.Product1.Project1.csproj
      [Project2]
        CompanyName.Product1.Project2.csproj
    [Product2]
      CompanyName.Product2.sln
      [Main] --Optional
        CompanyName.Product2.csproj
      [Project1]
        CompanyName.Product2.Project3.csproj
      [Project2]
        CompanyName.Product2.Project2.csproj
      [Project3]
        CompanyName.Product2.Project2.csproj

Why? Because when you get the code from repository you get, by example, "Product1" directory, it contains all you need to work. The [Main] directory contains the default base namespace, usually the exe or main project. It is optional.

Answer 6

Downsides to naming projects / solutions with name spacing are that:

1. Your solution project will not build due to Windows ( my version and previous ) imposing a max limits on the length of path ( not a problem on <cough><cough> mac ). Two solutions are:

 1. Changing an operating system setting.
 2. Configure build to shorten path.

2. Various apps important to you like say, SourceTree, may encounter problems. I figure this is due to the assumption as to filepath length. This problem is detailed in this Stack Overflow question:Filename too long in Git for Windows

Regarding Problem (1) Visual Studio might warn you

I don't yet know how to enact (2).

If you choose (1), then this will have an affect on your downstream environments: build OS, dev OS, qa build OS, qa OS, production OS as you will either need to make changes to the OS. Stack overflow question with answer describing change to operating system: Could not write lines to file "obj\Debug\net5.0\SolutionName.GeneratedMSBuildEditorConfig.editorconfig exceeds the OS max path limit

Code MSB3491

https://www.google.com/search?q=Code+MSB3491+max+path+limit

Could not write lines to file "obj\Debug\net5.0\------------my namespace------------..GeneratedMSBuildEditorConfig.editorconfig". Path: obj\Debug\net5.0\------------my namespace------------.GeneratedMSBuildEditorConfig.editorconfig exceeds the OS max path limit. The fully qualified file name must be less than 260 characters.
-------------my namespace--------------------------------
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\Microsoft.Managed.Core.targets

Regarding Problem (2)

To fix, possible solutions are:

(1) Tell SourceTree to use the git installed on the system. I only had Atlassian's version of git with which to work.

(2) Tell Atlassian's git to work with long file paths. Run cmd as administrator, then run this command: c:\Users\{theuser}\AppData\Local\Atlassian\SourceTree\git_local\cmd\git.exe config --system core.longpaths true

If you choose either of these resolutions, then you should expect to make changes to systems / processes down the line from your development machine.