Organizing .NET Core Projects

Truth be told — I have been coding for many years. For as long as I coded I could never really settle on one approach to organizing my code. The purpose of this post is to highlight an approach. The goal would be to stick to the approach for future projects.

Before I dive into a “better” approach lets discuss my existing approach. It is also important to understand why a good folder structure is conducive to better overall productivity. From my personal point-of-view its important to understand that no approach is “wrong”. It does come down to what works for you. In saying so I have noticed several approaches in other source code repositories of late. It would not be a terrible idea to learn from the approaches taken by others.

Project Structure — Current Approach

I keep a folder in my root called Projects. Any new projects get their own folder. Code is written and saved inside the project folder. My “issue” has always been a consistent approach. I am in dire of one approach to serve me well for a while at least.

Notice the folder structure above — it is structured. Just not as structured as I feel it should be. The .gitignore and .git artifacts indicate a git repository — no problem. The design and Designs folders contain Adobe Illustrator files — should design assets be version controlled? Are they considered binary files? Binary files typically do not belong in a clean repository. DotNetCore and DotNetFramework are easy to understand. It contains .NET and .NET Core projects. Is it the best approach? Should both folders be placed inside the src folder? Extras — forgot its purpose actually. Images contain, well, images. Infrastructure — the idea here was to place Powershell, Docker or any script used in the running and hosting of the application. NonProfit — I think here I was trying to follow something DDD-inspired. Again it should go under src I feel. Finally we have something called “src”. Website should also be kept under src.

Project Structure — from Microsoft

I was pleasantly surprised to find documentation from Microsoft. Off the bat they show a directory structure for a project:

The Visual Studio solution file (.sln) references Visual C# Projects located in different folders. Interesting to note is the src folder containing the code for the particular solution being built. The tests folder contains Visual C# Unit Test Projects. I’m not particularly interested in projects other than .NET Core.

Project Structure — AWS Lambda Templates for .NET Core

The AWS Lambda Templates for .NET Core generate a very similar solution structure. I created a folder aws-vanilla. It contains projects generated from the templates. I can then use the generated templates to reference to code. I can adapt the code for my own purposes.

As can be seen above I created four projects from the provided AWS Templates. Notice the pattern for each project? A src and test folder? The src folder contains the code. The test folder contains the unit test projects for the projects in src.

Sample .NET Project — Dapper

Dapper is my favourite data access library for .NET. It is also extremely popular. It is hosted on GitHub. It is interesting to note the folder structure of the project.

Notice no src or test folders. Some tests appear in Dapper.Tests. Other tests appear in Dapper.Tests.Contrib and Dapper.Tests.Performance. The code for Dapper itself lives in the Dapper project. I read the other folders as “separate components”.

Sample Project .NET Project — ASP.NET Core

ASP.NET Core is hosted on GitHub. Note I’m only looking at the folders in the root — not other files at this stage:

Notice the use of “src”. No tests. Also note the “docs” folder.

Conclusion

It appears as if most newer solutions follow the src/test/docs convention.