You are asked to set build governance for a monorepo of 250 .NET projects owned by twelve teams. How would you design the repo-wide build configuration, and how do you keep it healthy?

1. Start from goals, not files

Every file and rule below should serve one of these goals. If a rule doesn't, drop it.

2. The layered build contract

repo/
|-- global.json                     SDK 10.0.1xx, rollForward latestFeature, allowPrerelease false
|-- nuget.config                    <clear/>, internal feed with upstreams, package source mapping
|-- Directory.Packages.props        CPM, transitive pinning, GlobalPackageReference analysers
|-- Directory.Build.props           net10.0, Nullable, AnalysisLevel, UseArtifactsOutput, lock files
|-- Directory.Build.targets         guard targets, packaging defaults for libraries
|-- .editorconfig                   code style and analyser severities
|-- .github/CODEOWNERS              build files -> @platform-build
|-- eng/                            shared pipeline templates, scripts, docs, CHANGELOG.md
|
|-- src/
|   |-- Directory.Build.props       imports root; TreatWarningsAsErrors on
|   `-- <team>/<service>/*.csproj   5 to 10 lines each
|-- tests/
|   |-- Directory.Build.props       imports root; IsPackable=false; test-only NoWarn
|   `-- ...
`-- samples/
    `-- Directory.Build.props       imports root; relaxed analysers

Each nested file must import its parent with GetPathOfFileAbove; the property audit in section 5 catches the ones that don't.

3. Policies, written as code

A rule that lives only on a wiki page drifts within weeks. A rule in a build file applies to every build.

4. A warning policy that ratchets

  stage 1: AnalysisLevel=latest-recommended everywhere, warnings visible, nothing fails
  stage 2: TreatWarningsAsErrors=true for new projects and projects already at zero warnings
  stage 3: teams opt in folder by folder (EnableStrictBuild=true in their props)
  stage 4: strict becomes the default; remaining projects opt OUT with a ticket and expiry
  stage 5: raise AnalysisLevel or add rules; repeat

• Track the warning count per team on a dashboard; the number should only go down.
• Every NoWarn entry needs a comment with the reason and a ticket. Prefer .editorconfig severities scoped to folders over project-wide NoWarn.
• Never ship a new error-level rule to everyone at once in a legacy codebase; that produces blanket suppressions.

5. Guard rails

Property audit in CI. -getProperty evaluates only the project you name, so loop over every project file and fail on outliers:

for proj in $(git ls-files 'src/*.csproj' 'tests/*.csproj'); do
  values=$(dotnet msbuild "$proj" -getProperty:TargetFramework -getProperty:TreatWarningsAsErrors \
           -getProperty:Nullable -getProperty:ManagePackageVersionsCentrally)
  echo "$proj $values" >> property-audit.txt
done
# then compare property-audit.txt with the expected defaults and the exceptions register

Print the table before and after every change to the build files, so reviewers see exactly which projects moved.

Guard targets. Small, cheap checks in Directory.Build.targets that fail the build locally and in CI, for example an unsupported TFM without AllowLegacyTargetFramework. Only write guards for things the SDK doesn't already enforce: with CPM, a Version on a PackageReference already fails with NU1008.

Exceptions register. A file in eng/ listing every VersionOverride, NoWarn, legacy TFM and opt-out, with owner, reason, ticket and expiry date. CI fails if an exception in code isn't in the register, and the register is reviewed quarterly.

6. CI design

 PR opened
    |
    v
 changed files --> project graph --> affected projects + everything that depends on them
    |
    v
 shared template:
   setup-dotnet (global.json)
   restore --locked-mode   (NuGet cache keyed on lock files)
   format --verify-no-changes   (affected projects only)
   build -c Release -graph
   test affected test projects (TRX + coverage)
   upload binlog on failure
    |
 main branch and nightly: full build and full test suite

• Teams consume one versioned template (GitHub reusable workflows, Azure Pipelines templates), so a fix to the pipeline reaches everyone at once.
• Affected-project builds come from the ProjectReference graph. Community tools such as dotnet-affected compute it, or a traversal project can be generated from the changed set. Keep a nightly full build as the safety net.
• The template runs the same dotnet commands developers run locally; no build logic exists only in YAML.

7. Build performance as a product

Measure with binary logs: the Structured Log Viewer shows the slowest projects and targets. Publish build-time trends so regressions are noticed within days, not months.

8. Ownership and change management

• A small platform build team owns the root contract and the CI templates. Twelve teams contributing directly to root files without an owner doesn't scale.
• RFC-lite for significant changes (a new analyser pack, a TFM upgrade, a new restore rule): a short write-up, a canary on two or three volunteer teams, then a staged rollout.
• A build changelog in eng/CHANGELOG.md, linked from release notes, so a team whose build broke can see what changed.
• Office hours or a channel where teams can ask for exceptions and help. Governance that only blocks loses support quickly.

9. Upgrades as a routine

.NET 8 and .NET 9 reach end of support on 10 November 2026, so a governed repo should already have everything on net10.0; anything left is an exception with an owner and a date.

10. Metrics that keep governance honest

11. Security and compliance

• The contract maps onto controls auditors ask about: approved package sources, patch timeliness (Essential Eight "patch applications"), restricted change to shared configuration (CODEOWNERS plus branch protection), and an audit trail for exceptions.
• For systems that handle personal information under the Privacy Act, being able to show when a vulnerable dependency was removed matters as much as removing it.
• Build files and custom targets run code on every developer machine and agent. Review changes to them like any other privileged script.

12. .NET 11 awareness

.NET 11 is due in November 2026 as an STS release. Run it in a scheduled canary job with its own global.json to find breaking changes and new warnings early, but keep main on the .NET 10 SDK and net10.0 until you decide, as an organisation, whether to adopt the STS release or wait for the next LTS.

13. Try it yourself

1. Create a repo with src/ and tests/, a root Directory.Build.props with UseArtifactsOutput, and layered props files that import the root.
2. Add Directory.Packages.props, convert two projects to CPM, then add a Version to one PackageReference and read NU1008.
3. Add a guard target that fails for TFMs other than net10.0, set one project to net8.0 and build; then add AllowLegacyTargetFramework to that project.
4. Write the property-audit loop from section 5 and make it fail on outliers.
5. Build with dotnet build -bl, open the log in the Structured Log Viewer and find the slowest target.
6. Change one file in a leaf project and work out, from the ProjectReference graph, which projects a PR build would need to rebuild and test.

<!-- Directory.Build.props (root) -->
<Project>
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <AnalysisLevel>latest-recommended</AnalysisLevel>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
    <UseArtifactsOutput>true</UseArtifactsOutput>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    <Company>Contoso Pty Ltd</Company>
  </PropertyGroup>

  <PropertyGroup Condition="'$(CI)' == 'true' or '$(TF_BUILD)' == 'true'">
    <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
  </PropertyGroup>
</Project>

<!-- Directory.Build.targets (root): cheap guard rails -->
<Project>
  <!-- Runs per target framework; the outer build of a multi-targeted project has no TargetFramework, so skip it -->
  <Target Name="EnforceBuildPolicy" BeforeTargets="CoreCompile" Condition="'$(TargetFramework)' != ''">
    <Error Condition="'$(TargetFramework)' != 'net10.0' and '$(AllowLegacyTargetFramework)' != 'true'"
           Text="$(MSBuildProjectName) targets $(TargetFramework). Use net10.0 or register an exception (AllowLegacyTargetFramework)." />
  </Target>
</Project>

# CODEOWNERS
/global.json                 @contoso/platform-build
/nuget.config                @contoso/platform-build
/Directory.*.props           @contoso/platform-build
/Directory.*.targets         @contoso/platform-build
/.editorconfig               @contoso/platform-build

GITHUB_ACTIONS sets CI=true and Azure Pipelines sets TF_BUILD=True; MSBuild compares strings case-insensitively, so the condition matches both. Libraries that still multi-target for older consumers set AllowLegacyTargetFramework in their project file, which makes the exception visible in review.