One solution, several modules: repository structure – Blazor architecture at scale (W11, lesson 3)

What you learn in this lesson

organize a repository with src, tests and a .slnx so that every project on disk is also in the solution, and secure that with a test

keep build settings in one Directory.Build.props and package versions in one Directory.Packages.props in one place, and explain where MSBuild looks for these files

pin the SDK version with a global.json and say what happens when it is not installed

make the decision between a monorepo and several repositories for a team, with reasons and conditions

say what Nx does for .NET projects and which of the Nx tags carry over to our checks

Three modules with a contract each are quickly set up in one solution. After half a year you can see what the shape of the repository did not secure: one project targets net9.0, the others net10.0, two test projects take different versions of the same test library, and a module that someone created on a Friday is not in the solution, so no build of the solution ever compiles it. This lesson organizes the repository of the Kladde so that such errors show up in the build or do not arise at all, and then asks whether everything belongs in one repository.

Where the Kladde stands

The lesson presupposes W11.1.2 (three modules with contracts, a host, the test projects). What is new is only what lies in the repository above the projects. The four files in question were already in the solution without any lesson explaining them: Kladde.slnx, Directory.Build.props, Directory.Packages.props and global.json.

What you learn in this lesson

Where the Kladde stands

This lesson belongs to course W11