ToDoApp/Directory.Build.props at main · bgard68/ToDoApp · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
<Project>
  <PropertyGroup>
    <!-- Instructs dotnet restore to create packages.lock.json files for projects that use PackageReference -->
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>

    <!--
      Treat the lock file as authoritative on CI: restore FAILS if resolution would differ from
      packages.lock.json, instead of silently rewriting it. Without this, the lock files looked
      like pinning without being it, so a restore could quietly pull a package nobody reviewed
      (review finding M5). Locally it stays off so adding a package does not need a flag; CI sets
      ContinuousIntegrationBuild=true and passes the locked-mode restore flag to enforce it.

      After changing a PackageReference version, refresh the lock files by running
      "dotnet restore TodoApp.sln" with the force-evaluate flag.
    -->
    <RestoreLockedMode Condition="'$(ContinuousIntegrationBuild)' == 'true'">true</RestoreLockedMode>

    <!-- Keep the built-in .NET analyzers on across src/ and tests/. -->
    <EnableNETAnalyzers>true</EnableNETAnalyzers>
    <AnalysisLevel>latest</AnalysisLevel>

    <!--
      Warnings are errors (review finding L11). A warning nobody fails on is a warning nobody
      reads, and the ones that matter (obsolete crypto APIs, nullability holes) hide in the noise.
      Turned on only after the existing warning surface was cleared to zero, so it lands as a
      guarantee rather than a wall of unrelated failures.
    -->
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

    <!--
      NuGet's own vulnerability audit, failing the restore rather than reporting.

      The frontend has run npm audit at high severity since it was added; the API had no
      equivalent, so its dependency tree was the one part of this repository nothing checked.
      `all` rather than the default `direct`: a vulnerable package three levels down ships
      exactly the same code as one named in a csproj, and almost nothing here is a direct
      reference to the thing that would actually be exploited.

      NU1901-NU1904 are the four audit severities. Named explicitly rather than relying on
      TreatWarningsAsErrors above, because restore-time NuGet warnings do not always inherit
      it — the point of a gate is that it fails, and "probably fails" is not that.
    -->
    <NuGetAudit>true</NuGetAudit>
    <NuGetAuditMode>all</NuGetAuditMode>
    <WarningsAsErrors>$(WarningsAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsAsErrors>
  </PropertyGroup>
</Project>