One Project Isn't Enough — Why Solutions Hold Many
Your first solution in this track had one project. Almost no real software stays that way — and Visual Studio's solution/project split exists specifically to handle that growth.
A realistic solution has multiple projects, each with one job. A typical setup: a Web API project (the actual application), a Class Library project (shared code — models, business logic — used by more than one project), and a Test project (unit tests for the class library). Each is its own .csproj, but they build together and can reference each other, all inside one .sln.
Why not just one giant project? Separation gives you: independent reuse (the class library can be referenced by a second application later without copying code), independent testing (tests target the library directly, not through a full running app), and clearer boundaries (a change to "the API" shouldn't require touching "the shared logic" file-by-file with no separation).
Project references, not file copying. When Project A needs code from Project B, you add a Project Reference (right-click Project A's Dependencies → Add Project Reference) — Visual Studio then guarantees B builds before A, and A's code can use B's public classes directly, no copy-pasting.
This is different from a NuGet package reference. A Project Reference points at another project in the same solution (source code, rebuilds together). A NuGet package reference points at a published, versioned package (someone else's compiled code, or your own once you publish it). You'll use both, for different reasons — later courses cover NuGet in depth.
Why this matters for you
Once you can look at a multi-project solution and immediately understand "this is the app, this is the shared logic, this is the tests" — reading an unfamiliar codebase stops being intimidating. That's the actual goal of this course.
▶️ Before the next lesson
Open your solution from the Welcome course. You'll add a second project to it in this course's hands-on lesson, so keep it open.