The DevTree: A Practical Folder Layout for .NET Repositories

“Dev-tree” is shorthand for the directory structure of a development repository — the source files, configuration, libraries, and everything else that makes up a project. It typically mirrors what ends up in production, but with room for the extra folders development needs: test scripts, build configuration, local tooling.

A consistent dev-tree pays for itself the first time someone new joins a project and needs to find their way around without asking. Here’s a layout that’s worked well across multiple repositories.

The one universal rule

Every repository should have a Readme.md at the top level with basic information about what’s in it. It costs nothing and saves everyone the archaeology.

Repositories for production code

At the root of a repository intended for production code, these folders show up consistently:

Folder	What’s in it
`.paket`	Artifacts of the Paket dependency management toolset
`build`	Build and related tooling — effectively a “local” CI pipeline (e.g. via FAKE)
`cfg`	Configuration items
`data`	Sample data sets to experiment with (if the data matters long-term, it probably belongs in `cfg` instead)
`doc`	Project documentation
`src`	The source or solution tree — the actual source code
`tools`	Small helper applications, usually binaries. Best avoided in favor of proper package management where possible

A second set of folders shows up too, but these are generated during compilation and must never be committed:

Folder	What’s in it
`packages`	Extracted packages and temporary Paket artifacts
`paket-files`	Temporary Paket artifacts
`temp`	Generated output like xUnit test reports
`tools`	Same as above — sometimes populated with generated artifacts too

Folders you might also encounter

Beyond the core set, a handful of other folder names turn up often enough to be worth naming — some of them overlapping or duplicating each other (deps, ext, and lib all tend to mean roughly the same thing depending on who set up the repo):

assets, deps, ext, ci, ide, lib, loc, out, pkg, res, samples, util/utils — assets, dependencies, external code, CI/build tooling, IDE configuration, additional libraries, localization assets, a central output folder, packaging-related files, resources, demo projects, and general-purpose utilities, respectively.

There’s no requirement to use all of these — pick what your project actually needs and stay consistent about it.

Production vs. non-production code

Where integration tests, benchmarks, and similar non-production code should live relative to src deserves its own discussion — see the companion piece on organizing production vs. non-production code.

A lighter layout for proof-of-concept code

Not every repository needs the full structure above. For PoCs, spikes, and playgrounds, a minimal layout is enough — but it’s still worth carrying over the basic concepts rather than starting from a blank slate each time:

Folder	What’s in it
`doc`	Even for a PoC, a little documentation goes a long way
`src`	The source tree

See also the note on organizing code across repositories.

The `src` folder itself

The src folder — the “solution tree” — is where the bulk of a developer’s day-to-day work happens. How you slice it internally is its own decision:

Component-focused slicing, organizing by feature or component area.
DDD-style slicing, following domain boundaries — see Layers, Ports & Adapters, Part 3 for a solid treatment of this approach.

Neither is universally “correct” — the right choice depends on how your team thinks about the codebase’s boundaries.

A quick checklist for new repositories

Readme.md exists at the top level with basic context
The dev-tree follows the layout described above