5 tips for structuring Visual Studio solutions
If you’re starting a new project, with a new team of developers, it can be hard to know where to start. There’s a frightening amount of decisions to be made at the beginning, and it’s easy to get caught up in circular discussions (which, like circular references, only with humans, go round and around and achieve little).
One thing to decide early on is a standard project structure, which will depend largely on the type of applications you are writing. If you have a mix of applications, like MVC web sites, desktop and mobile apps, you will probably have different folder structures for each type of application. In general, though, there are some basic guidelines that you can follow to make sure your project remains manageable and well-structured.
Keep your naming conventions consistent.
It’s a good idea to create sub folders for the different layers within a project, usually to separate domain models, infrastructure, helper classes and business logic. Whatever names you choose for those folders, keep them consistent between different projects. This helps navigating a complex solutions folder structure immensely.
Minimize the number of sub folders in your solution.
Using a deeply nested folder structure might seem like good organization, but unfortunately, Visual Studio and various command line utilities don’t handle deep nested folder structures very well, and have maximum lengths for paths and file names. You need to find a balance, probably no more than three folders deep, and restrict the names of folders to no more than 10-15 characters.
Use virtual solution folders to group projects into domains.
It’s a good idea to separate a large solution into groups of projects split along domain boundaries. For example, you might have a solution containing 20 or more projects, or many more if implementing something like a micro-services architecture. To help understand the overall solution structure, it’s useful to create solution folders (right-click the solution, choose Add->Solution Folder) along these boundaries. For example, you might split the solution into 3 areas e.g. Core, Services and Integration. Within each area, there could be multiple projects implementing different services, or integrating with different 3rd parties. Solution folders are not physical disk folders, and therefore are much easier to manage, rename or move around without affecting project dependencies and assembly search paths.
Use the same name for the project and it’s physical folder.
Although it’s sometimes tempting to create the folders on disk first, and create projects within those folders, Visual Studio and some source control systems are not particularly good at handling this scenario. rather than fighting the default behavior, it’s much less trouble to just go with the flow on this one.
Avoid moving projects around into sub folders.
Once a project has been created, try to avoid moving the project around on disk, as this causes issues when finding assembly references, and can cause hard to diagnose errors in builds and/or deployments. If you decide to move a project from one folder to another, make you sure manually check the *.csproj files of the project being moved, and any dependent projects, to make sure all references and hint paths are still valid. In particular, look for <HintPath> and $(SolutionDir) references in the project files, and make sure the files being referenced can still be found in the specified location.