Naming convention for Visual Studio solutions and projects

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.

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

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.

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.