Solution Files and Multi-Project Structure

📚 DotNet Fullstack + Angular 📂 Chapter 16: Project Structure, NuGet and Solution Files 📄 Lesson 16020 Intermediate 🕒 March 17, 2026

A solution (.sln) is a container that groups multiple related projects together. When you open a solution in Visual Studio or Rider, all member projects are loaded simultaneously, cross-project navigation works, and builds respect project dependencies. From the CLI, dotnet build BlogApp.sln builds all projects in dependency order. Multi-project solutions are the standard for any non-trivial .NET application — separation into projects enforces layer boundaries and makes each project independently testable, independently deployable, and clearly bounded in responsibility.

Creating and Managing Solutions

// ── Create a solution and add projects ────────────────────────────────────
// Run from terminal:

// Create a blank solution
dotnet new sln -n BlogApp

// Create projects
dotnet new classlib  -n BlogApp.Domain         -o src/BlogApp.Domain
dotnet new classlib  -n BlogApp.Application    -o src/BlogApp.Application
dotnet new classlib  -n BlogApp.Infrastructure -o src/BlogApp.Infrastructure
dotnet new webapi    -n BlogApp.Api            -o src/BlogApp.Api
dotnet new xunit     -n BlogApp.Tests          -o tests/BlogApp.Tests

// Add projects to the solution
dotnet sln BlogApp.sln add src/BlogApp.Domain/BlogApp.Domain.csproj
dotnet sln BlogApp.sln add src/BlogApp.Application/BlogApp.Application.csproj
dotnet sln BlogApp.sln add src/BlogApp.Infrastructure/BlogApp.Infrastructure.csproj
dotnet sln BlogApp.sln add src/BlogApp.Api/BlogApp.Api.csproj
dotnet sln BlogApp.sln add tests/BlogApp.Tests/BlogApp.Tests.csproj

// Add project references (dependency direction: outer depends on inner)
dotnet add src/BlogApp.Application/BlogApp.Application.csproj reference \
    src/BlogApp.Domain/BlogApp.Domain.csproj

dotnet add src/BlogApp.Infrastructure/BlogApp.Infrastructure.csproj reference \
    src/BlogApp.Application/BlogApp.Application.csproj

dotnet add src/BlogApp.Api/BlogApp.Api.csproj reference \
    src/BlogApp.Application/BlogApp.Application.csproj

dotnet add src/BlogApp.Api/BlogApp.Api.csproj reference \
    src/BlogApp.Infrastructure/BlogApp.Infrastructure.csproj

// Build the whole solution
dotnet build BlogApp.sln

Note: The .sln file uses an older, human-unfriendly format maintained by Microsoft — avoid editing it manually. Use dotnet sln add, dotnet sln remove, and dotnet sln list for all solution management operations. IDEs regenerate solution files correctly on project changes. The solution file records the GUIDs, names, and paths of all member projects — if a project moves, update the .sln with the CLI rather than editing the raw XML.

Tip: Use solution folders to organise large solutions — Visual Studio and Rider display solution folders as virtual directory nodes in the project explorer. You can add solution folders with dotnet sln add --solution-folder "Source Projects" src/BlogApp.Api/BlogApp.Api.csproj. Common conventions: src/ for application projects, tests/ for test projects, tools/ for utilities and code generators. This folder convention is used in the ASP.NET Core repository itself and is widely adopted in the .NET ecosystem.

Warning: Circular project references (A references B, B references A) cause build failures. MSBuild resolves the build order based on project references and cannot compile circular dependencies. If you find yourself wanting a circular reference, it usually indicates that the two projects belong in the same project, or that you need a third shared project that both can reference. The solution to circular dependencies is to extract the shared abstraction (usually an interface) into a lower-level project that both can safely reference.

Solution Directory Layout

// Recommended solution directory structure:
// BlogApp/
// ├── BlogApp.sln
// ├── .gitignore
// ├── .editorconfig
// ├── Directory.Build.props          ← shared MSBuild properties for all projects
// ├── Directory.Packages.props       ← centralised NuGet version management
// ├── src/
// │   ├── BlogApp.Domain/            ← entities, value objects, domain events
// │   │   └── BlogApp.Domain.csproj
// │   ├── BlogApp.Application/       ← use cases, DTOs, service interfaces
// │   │   └── BlogApp.Application.csproj
// │   ├── BlogApp.Infrastructure/    ← EF Core, email, storage, external APIs
// │   │   └── BlogApp.Infrastructure.csproj
// │   └── BlogApp.Api/               ← controllers, middleware, startup
// │       └── BlogApp.Api.csproj
// └── tests/
//     ├── BlogApp.Unit.Tests/        ← unit tests for domain and application
//     └── BlogApp.Integration.Tests/ ← integration tests for infrastructure

Common Mistakes

Mistake 1 — Putting all code in a single project (monolith csproj)

❌ Wrong — one big project with no layer separation; domain logic mixed with HTTP concerns.

✅ Correct — separate into at minimum Domain, Application, Infrastructure, and API projects.

Mistake 2 — Wrong dependency direction (inner depending on outer)

❌ Wrong — Domain project references Infrastructure (domain knows about the database).

✅ Correct — Domain has zero project references; Infrastructure references Application; API references both Application and Infrastructure.

🧠 Test Yourself

The Application layer defines an IPostRepository interface. The Infrastructure layer implements it as EfPostRepository. Which project references which?

Application references Infrastructure — Application needs the EF Core implementation
Infrastructure references Application. Application defines the interface contract; Infrastructure provides the implementation. Infrastructure must know about the interface (in Application) to implement it. Application must not know about Infrastructure — it depends only on the abstraction. This is the Dependency Inversion Principle: the high-level Application layer defines what it needs (IPostRepository); the low-level Infrastructure layer fulfils that contract without Application depending on it
Both reference each other — it is a bidirectional dependency
Neither — they are decoupled at runtime through reflection only

Creating and Managing Solutions #

Solution Directory Layout #

Common Mistakes #

Mistake 1 — Putting all code in a single project (monolith csproj) #

Mistake 2 — Wrong dependency direction (inner depending on outer) #

🧠 Test Yourself #

📚 More in this Tutorial Series

Creating and Managing Solutions

Solution Directory Layout

Common Mistakes

Mistake 1 — Putting all code in a single project (monolith csproj)

Mistake 2 — Wrong dependency direction (inner depending on outer)

🧠 Test Yourself