We read very often how to have a good architecture for a .NET project, but I don't read very often how to structure the folders of the project.
You might think it's a minor problem, but it's also important to have a good folder structure and especially one that is always the same, to make it easier to find things at a glance and also to make it easier for other people to get into the project faster.
In the picture below you can see my typical structure of a project.
Let's see what each item is.
- artifacts: where the build.cmd script puts the artifacts
- build: build customizations
- docs: markdown files, installation instructions, help files. I use this folder to put the Docusaurus project
- lib: if you have a custom library outside of NuGet, you can copy the files here
- samples: sample projects to use your solution or projects
- src: the code of your projects
- tests: all the tests projects live here
- .editorconfig: coding styles and other settings for your environment
- .gitignore: I think you don't need a description about it
- build.cmd: the script to build the project and create artifacts (I don't use it very often)
- LICENSE: the license file of your project. Useful especially for GitHub
- Project001.sln: the solution file of your projects
- README.md: useful for GitHub but also to give an overview of the project to the other people involved
Out of my curiosity: do you have a fixed structure for projects like me?
Share yours in the comments!
Top comments (13)
Great structure, I have been, for a long time, following Fowlers old gist. And try to get everyone else to follow it :) The biggest issue is that people create the project in VS and if they let VS decide it will need some hands on.
gist.github.com/davidfowl/ed756429...
Yes, it’s very similar and it inspired me a few years ago.
I didn’t invent nothing new 😀
By the way I have a PowerShell script to launch in the root folder when I create a new project to define the folders structure.
I think I should create VS extension.
What do you think?
I´d say an extension could be nice. But then again, its kind of good to fix it manually, at least in the start, to learn how to handle it (edit the .sln and so on)
A question, I usually put my yaml pipelines (CI/CD) in a folder named /build, where do you put yours ?
yes, in the build folder.
I see a lot of people with a folder called "deploy" for the same reason.
I don't have a fixed solution structure but have tried a few different things. What you've got there is pretty similar, I go back and forth on needing all the extra folders
github.com/stphnwlsh/CleanMinimalA...
I build and test is Dockerfile so there's no need for build and am not concerned about artifacts because I allow external systems like Codecov to own that data.
If I was working on a bigger project for an enterprise I'd add the extras as needed.
Love that you're thinking about this, structure is important!!
We use a fixed project structure all the time.
To the extend that when giving a training one of the trainees said oh I recognize this from project X I know what to do.
It makes it a lot easier to move devs between projects
Nice overview, thanks!
A great folder structure is the foundation for your project's structure. If you mess up your folders you mess up your project :)
Every thought about turning this into a dotnet new template? Would be pretty slick.
good idea
In addition I have a standardised Directory.Build.props file which also enforces repo-root per-project/per-TFM obj/bin folders. It also adds the repo-root LICENSE file into nuget packages you produce and adds standard dev-only packages I always use (e.g. SourceLink).
Nowadays, I never write cmd or shell scripts. Since the release of PowerShell Core, I have now replaced shell scripts with PowerShell for cross-platform compat. Also, build agents on GitHub and AzDevOps come with PowerShell pre-installed.
The reason for this is to avoid duplication.
Wouldn't visual studio keep suggesting to put new projects in the root folder, given the solution is in that folder?