NodePilot/Directory.Build.props at main · Sev7eNup/NodePilot · 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
48
49
<Project>

  <!--
    Repo-wide MSBuild props. Imported automatically by every .csproj under the repo root
    (the npm projects under src/nodepilot-ui and src/nodepilot-docs-ui have no .csproj and
    are unaffected).
  -->

  <!--
    Shared build settings — every NodePilot project targets the same TFM and opts into the
    same language surface. Individual csproj files no longer repeat these; change them here
    (or override per-project only when a project genuinely needs to differ).
  -->
  <PropertyGroup>
    <TargetFramework>net10.0-windows</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <LangVersion>latest</LangVersion>
    <Version>1.5.4</Version>
  </PropertyGroup>

  <!--
    Dependency audit, shifted left. CI already refuses vulnerable packages in its own step
    ("Reject vulnerable NuGet dependencies" in .github/workflows/ci.yml, which runs
    `dotnet list package` with the vulnerable + transitive switches and throws on any hit), so
    this is NOT the gate — it is the same verdict, one step earlier, on every local restore.
    Without it a developer only learns about a fresh advisory after pushing, because NuGetAudit
    defaults to direct-only findings emitted as warnings that scroll past in the build log.

      AuditMode=all      also walks transitive packages, which is where every security pin in
                         Directory.Packages.props came from (SQLitePCLRaw via Microsoft.Data.Sqlite,
                         Microsoft.OpenApi via Swashbuckle, System.Security.Cryptography.Xml via
                         the PowerShell SDK). Direct-only would have caught none of them.
      AuditLevel=low     report everything, matching what the CI step reports.

    NOTE: keep NU1901..NU1904 as warnings here. Promoting them via WarningsAsErrors in this file
    is tempting but wrong: CI is the enforcing gate, and a local hard failure would block work on
    an unrelated branch the moment an advisory lands. Escalate in CI, surface locally.

    Suppressing a specific finding is a deliberate act: add its code to NoWarn in the affected
    project WITH a comment stating why the advisory does not apply, exactly like the version pins.
  -->
  <PropertyGroup>
    <NuGetAudit>true</NuGetAudit>
    <NuGetAuditMode>all</NuGetAuditMode>
    <NuGetAuditLevel>low</NuGetAuditLevel>
  </PropertyGroup>

</Project>