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?

Conventioneer

what about the lowest level, organizing the *.CS files under [src] folder under [Project1] folder? Does it make sense? – Tomfoolery

Answer 1

That looks pretty good if you ask me. Especially naming your projects by their full name including full name space part. I've found this helpful when there are numerous projects, especially if there happens to be similar projects across different products.

How and whether you split on product and project (where I assume project is more like an application than a solution project) is very much down to the size of your organisation, it's make-up and your preferences.

Inca

What about unwieldy assembly names like CompanyName.PoductName.ProjectName.exe that get produced in the process? I've read this but that looks like dirty hacks to me or entails using of an additional tool (MSBuild) and that doesn't look trivial. – Lacework

Ideally you could make snappier product or project names. Not always possible obviously. Then acronyms or nicknames could be consider, e.g. MSFT.AI.WindowsServer but if you look at Nuget the answer still seems true and commonly followed by most projects on it. – Inca

Answer 2

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

Unseen

what is the added value having the solutions in the same folder? – Tomfoolery

Answer 3

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.

Hamill

Answer 4

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.

Branny

Answer 5

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.

Postpositive

Answer 6

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.

Appendicular

Regarding "getting the code". What about general class-libraries that are used by multiple projects. Where would these sit. And specifically when you don't get them as nuget packages? ``` [CompanyName] [Product1] <uses ClassLibrary1> [ClassLibrary1] <contains generic stuff used companywide> ``` Now you can't "get" the "Product1" code but also have to get the related libraries Sorry: Can't use markup in comments so this reads bad! – Watering

Answer 7

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.

Johnsiejohnson